internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: ray-project/ray

Issue:
Incorrect Title for Failed Tasks
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### What is the problem?
When a task fails, the process title of the failed task remains. This appears in both the dashboard and to the OS (`htop`).

*Ray version and other system information (Python version, TensorFlow version, OS):*
Python: 3.7
OS: MacOS 10.15.4
Ray: Latest Master

### Reproduction (REQUIRED)
```
import ray
ray.init()
@ray.remote
def fail():
    import NonRealModule
fail.remote()
```

Then run `htop` and "`__main__.fail()`" will remain even after the function errors and returns. 

If we cannot run your script, we cannot fix your issue.

- [x] I have verified my script runs in a clean environment and reproduces the issue.
- [x] I have verified the issue also occurs with the [latest wheels](https://ray.readthedocs.io/en/latest/installation.html).



Discussion:

Resolving patch:
diff --git a/python/ray/worker.py b/python/ray/worker.py
--- a/python/ray/worker.py
+++ b/python/ray/worker.py
@@ -1349,8 +1349,10 @@ def disconnect(exiting_interpreter=False):
 @contextmanager
 def _changeproctitle(title, next_title):
     setproctitle.setproctitle(title)
-    yield
-    setproctitle.setproctitle(next_title)
+    try:
+        yield
+    finally:
+        setproctitle.setproctitle(next_title)
 
 
 def register_custom_serializer(cls,


Test patch:
Repository: ray-project/ray

Issue:
[ray] Build failure when installing from source
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### What is the problem?
I am trying to install ray from source. However, I receive the following error during the install process:
```
HEAD is now at 8ffe41c apply cpython patch bpo-39492 for the reference count issue
+ /usr/bin/python setup.py bdist_wheel
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'bdist_wheel'
Traceback (most recent call last):
  File "setup.py", line 178, in <module>
    setup(
  File "/usr/lib/python3.8/site-packages/setuptools/__init__.py", line 144, in setup
    return distutils.core.setup(**attrs)
  File "/usr/lib/python3.8/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.8/distutils/dist.py", line 966, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.8/distutils/command/build.py", line 135, in run
    self.run_command(cmd_name)
  File "/usr/lib/python3.8/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "setup.py", line 107, in run
    subprocess.check_call(command)
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['../build.sh', '-p', '/usr/bin/python']' returned non-zero exit status 1.
```

Note: `error invalid command 'bdist_wheel'`

*Ray version and other system information (Python version, TensorFlow version, OS):*
ray: 0.8.4
python: 3.8.2
os: Arch Linux

### Reproduction (REQUIRED)
Please provide a script that can be run to reproduce the issue. The script should have **no external library dependencies** (i.e., use fake or mock data / environments):

If we cannot run your script, we cannot fix your issue.

- [ ] I have verified my script runs in a clean environment and reproduces the issue.
- [ ] I have verified the issue also occurs with the [latest wheels](https://ray.readthedocs.io/en/latest/installation.html).

The above does not apply since this is a build issue.



Discussion:

Resolving patch:
diff --git a/python/setup.py b/python/setup.py
--- a/python/setup.py
+++ b/python/setup.py
@@ -191,7 +191,7 @@ def find_version(*filepath):
     # The BinaryDistribution argument triggers build_ext.
     distclass=BinaryDistribution,
     install_requires=requires,
-    setup_requires=["cython >= 0.29.14"],
+    setup_requires=["cython >= 0.29.14", "wheel"],
     extras_require=extras,
     entry_points={
         "console_scripts": [


Test patch:
Repository: ray-project/ray

Issue:
Lots of "INFO worker.py:439 -- ray.get_gpu_ids() currently does not work in LOCAL MODE." messages printed in local mode
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### What is the problem?
When I run in local mode I see lots of the following message being printed many times such that the console isn't really useable:
```
INFO worker.py:439 -- ray.get_gpu_ids() currently does not work in LOCAL MODE.
```
I'm not sure why this message is being printed as I'm not using a GPU (num_gpus=0, although my machine does have a GPU enabled).  As I recall some time ago I was running in local mode and found that the GPU was being used when it wasn't supposed to be however. I first see this message printed with code version 9bfc2c4b5462871f0fe669b3aabc5f2772bc3a6f, and so assume it was caused by #7670.  I'm not sure why this message is being printed when I shouldn't be using a GPU, and also I think the message should only be printed once and then suppressed in future instances when it would otherwise be printed

*Ray version and other system information (Python version, TensorFlow version, OS):*
Running on Azure NC6s_v2 machine
ray: 0.9.0.dev0 (latest wheels installed on 4/27/20)
python: 3.7.6 
tensorflow: 2.1
torch: 1.4.0
OS: Ubuntu 16.04.6 LTS

### Reproduction (REQUIRED)
Please provide a script that can be run to reproduce the issue. The script should have **no external library dependencies** (i.e., use fake or mock data / environments):

I'm just running the following example, but changing `ray.init()` to `ray.init(local_mode=True)`
```bash
python examples/custom_env.py
```
If we cannot run your script, we cannot fix your issue.

- [x] I have verified my script runs in a clean environment and reproduces the issue.
- [x] I have verified the issue also occurs with the [latest wheels](https://docs.ray.io/en/latest/installation.html).



Discussion:
cc @ijrsvt - can we mute this warning?
Yes we can

Resolving patch:
diff --git a/python/ray/worker.py b/python/ray/worker.py
--- a/python/ray/worker.py
+++ b/python/ray/worker.py
@@ -435,10 +435,6 @@ def get_gpu_ids():
     """
 
     # TODO(ilr) Handle inserting resources in local mode
-    if _mode() == LOCAL_MODE:
-        logger.info("ray.get_gpu_ids() currently does not work in LOCAL "
-                    "MODE.")
-
     all_resource_ids = global_worker.core_worker.resource_ids()
     assigned_ids = [
         resource_id for resource_id, _ in all_resource_ids.get("GPU", [])


Test patch:
Repository: ray-project/ray

Issue:
[tune] close logger after updating Trial status
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### Describe your feature request

Several experiment tracking systems, such as [neptune](https://neptune.ai/) or [Weights&Biases](https://www.wandb.com/) offer to categorize experiments as "Succeeded" or "Failed". This status is set when closing the logger.

Today, the `RayTrialExecutor._stop_trial` method closes the loggers before updating the status of the trial and updating its `trial.error_msg` attribute. When loggers are closed, it is impossible to know whether the trial is terminated normally or with an error, and therefore to set correct status in the experiment trackers.

To me, the solution seems as simple as moving these two lines:
https://github.com/ray-project/ray/blob/8625e09067a0f87b9951b2b41a7c7e0fead66f6e/python/ray/tune/ray_trial_executor.py#L259-L260
at the end of the `_stop_trial` method.

Is there any reason to close logger at the beginning of `_stop_trial`? 
Happy to create a PR otherwise!

Thanks,


Discussion:
Yeah that sounds good - in the finally block right?

A PR would be really appreciated - thanks!

Resolving patch:
diff --git a/python/ray/tune/ray_trial_executor.py b/python/ray/tune/ray_trial_executor.py
--- a/python/ray/tune/ray_trial_executor.py
+++ b/python/ray/tune/ray_trial_executor.py
@@ -256,9 +256,6 @@ def _stop_trial(self, trial, error=False, error_msg=None,
             error_msg (str): Optional error message.
             stop_logger (bool): Whether to shut down the trial logger.
         """
-        if stop_logger:
-            trial.close_logger()
-
         self.set_status(trial, Trial.ERROR if error else Trial.TERMINATED)
         trial.set_location(Location())
 
@@ -278,6 +275,8 @@ def _stop_trial(self, trial, error=False, error_msg=None,
             self.set_status(trial, Trial.ERROR)
         finally:
             trial.set_runner(None)
+            if stop_logger:
+                trial.close_logger()
 
     def start_trial(self, trial, checkpoint=None, train=True):
         """Starts the trial.


Test patch:
Repository: ray-project/ray

Issue:
Bump msgpack to 1.0.0 for Python
We've started bumping msgpack to 1.0.0 in some of our repos at our company. However, some of our repos use Ray, which doesn't support version 1.0.0 for msgpack. We're hoping that Ray could support msgpack 1.0.0 - it doesn't look like there are too many breaking changes, and it looks like both major versions 0 and 1 can be supported. Thanks!



Discussion:
cc @simon-mo.

Thanks for reporting this @alecbrick . We will see if we can have time to work on this, but always feel free to contribute!

Resolving patch:
diff --git a/python/setup.py b/python/setup.py
--- a/python/setup.py
+++ b/python/setup.py
@@ -194,7 +194,7 @@ def find_version(*filepath):
     "google",
     "grpcio",
     "jsonschema",
-    "msgpack >= 0.6.0, < 1.0.0",
+    "msgpack >= 0.6.0, < 2.0.0",
     "numpy >= 1.16",
     "protobuf >= 3.8.0",
     "py-spy >= 0.2.0",
diff --git a/streaming/python/runtime/gateway_client.py b/streaming/python/runtime/gateway_client.py
--- a/streaming/python/runtime/gateway_client.py
+++ b/streaming/python/runtime/gateway_client.py
@@ -69,4 +69,4 @@ def serialize(obj) -> bytes:
 
 def deserialize(data: bytes):
     """Deserialize the binary data serialized by `PythonGateway`"""
-    return msgpack.unpackb(data, raw=False)
+    return msgpack.unpackb(data, raw=False, strict_map_key=False)
diff --git a/streaming/python/runtime/serialization.py b/streaming/python/runtime/serialization.py
--- a/streaming/python/runtime/serialization.py
+++ b/streaming/python/runtime/serialization.py
@@ -41,7 +41,7 @@ def serialize(self, obj):
         return msgpack.packb(fields, use_bin_type=True)
 
     def deserialize(self, data):
-        fields = msgpack.unpackb(data, raw=False)
+        fields = msgpack.unpackb(data, raw=False, strict_map_key=False)
         if fields[0] == _RECORD_TYPE_ID:
             stream, value = fields[1:]
             record = message.Record(value)


Test patch:
Repository: ray-project/ray

Issue:
import error
ray 0.8.5,when I try to use ray， it occurs  Ray must be imported before pickle5 because Ray requires a specific version of pickle5 (which is packaged along with Ray.

I want to know it must import  pickle5 before import ray,  Right?


Discussion:
yes, we are using an internal version of pickle5, because the current pickle5 has memory leak issues. so we have to import ray before importing the pickle5 library.

I have created a PR in the upstream (pickle5-backport), it would address the problem once merged.

Resolving patch:
diff --git a/python/ray/__init__.py b/python/ray/__init__.py
--- a/python/ray/__init__.py
+++ b/python/ray/__init__.py
@@ -9,9 +9,13 @@
 # raylet modules.
 
 if "pickle5" in sys.modules:
-    raise ImportError("Ray must be imported before pickle5 because Ray "
-                      "requires a specific version of pickle5 (which is "
-                      "packaged along with Ray).")
+    import pkg_resources
+    version_info = pkg_resources.require("pickle5")
+    version = tuple(int(n) for n in version_info[0].version.split("."))
+    if version < (0, 0, 10):
+        raise ImportError("You are using an old version of pickle5 that "
+                          "leaks memory, please run 'pip install pickle5 -U' "
+                          "to upgrade")
 
 if "OMP_NUM_THREADS" not in os.environ:
     logger.debug("[ray] Forcing OMP_NUM_THREADS=1 to avoid performance "


Test patch:
Repository: ray-project/ray

Issue:
"lr_schedule" option ignored using torch framework and PPO algorithm
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

*Ray version and other system information (Python version, TensorFlow version, OS):*
- Ray: [0.9.0.dev0 (2c599dbf05e41e338920ee2fbe692658bcbec4dd)](https://s3-us-west-2.amazonaws.com/ray-wheels/releases/0.8.5/02c1ab0ec6d615ad54ebf33bd93c51c04000534e/ray-0.8.5-cp36-cp36m-manylinux1_x86_64.whl)
- CUDA: 10.1
- Pytorch: 1.4.0 with GPU support
- Ubuntu 18.04
- Python 3.6

### What is the problem?

Setting the hyperparameter "lr_schedule" as no effect when using PyTorch as backend framework and PPO learning algorithm.

### Reproduction (REQUIRED)

```
import ray 
from ray.rllib.agents.ppo import PPOTrainer, DEFAULT_CONFIG 
 
config = DEFAULT_CONFIG.copy() 
for key, val in { 
    "env": "CartPole-v0", 
    "num_workers": 0, 
    "use_pytorch": False, 
    "lr": 1.0e-5, 
    "lr_schedule": [ 
        [0, 1.0e-6], 
        [1, 1.0e-7], 
    ] 
}.items(): config[key] = val 
 
ray.init() 

for use_pytorch in [False, True]: 
    config["use_pytorch"] = use_pytorch 
    agent = PPOTrainer(config, "CartPole-v0") 
    for _ in range(2): 
        result = agent.train() 
        print(f"use_pytorch: {use_pytorch} - Current learning rate: "\
              f"{result['info']['learner']['default_policy']['cur_lr']}")
```

- [x] I have verified my script runs in a clean environment and reproduces the issue.
- [x] I have verified the issue also occurs with the [latest wheels](https://docs.ray.io/en/latest/installation.html).



Discussion:
Thanks for filing this issue @duburcqa . Will take a look ...
cc @krfricke 
I can confirm this - would appreciate an update on it

Resolving patch:
diff --git a/rllib/agents/ppo/ppo_torch_policy.py b/rllib/agents/ppo/ppo_torch_policy.py
--- a/rllib/agents/ppo/ppo_torch_policy.py
+++ b/rllib/agents/ppo/ppo_torch_policy.py
@@ -223,4 +223,7 @@ def setup_mixins(policy, obs_space, action_space, config):
     extra_grad_process_fn=apply_grad_clipping,
     before_init=setup_config,
     after_init=setup_mixins,
-    mixins=[KLCoeffMixin, ValueNetworkMixin])
+    mixins=[
+        LearningRateSchedule, EntropyCoeffSchedule, KLCoeffMixin,
+        ValueNetworkMixin
+    ])


Test patch:
Repository: ray-project/ray

Issue:
[rllib] PyTorch and SampleAsync validation
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### What is the problem?

PyTorch is supposed to be thread-safe, as long as you don't write a tensor using multiple threads. Please see https://discuss.pytorch.org/t/is-pytorch-supposed-to-be-thread-safe/36540/2 

It might be worth removing the validation of sample_async and use_pytorch for A3C (and maybe others?).

Ray Version 0.9.0dev (but this applies to any ray version actually)

### Reproduction (REQUIRED)
Please provide a script that can be run to reproduce the issue. The script should have **no external library dependencies** (i.e., use fake or mock data / environments):

If we cannot run your script, we cannot fix your issue.

- [x] I have verified my script runs in a clean environment and reproduces the issue.
- [x] I have verified the issue also occurs with the [latest wheels](https://docs.ray.io/en/latest/installation.html).

[rllib] PyTorch and SampleAsync validation
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### What is the problem?

PyTorch is supposed to be thread-safe, as long as you don't write a tensor using multiple threads. Please see https://discuss.pytorch.org/t/is-pytorch-supposed-to-be-thread-safe/36540/2 

It might be worth removing the validation of sample_async and use_pytorch for A3C (and maybe others?).

Ray Version 0.9.0dev (but this applies to any ray version actually)

### Reproduction (REQUIRED)
Please provide a script that can be run to reproduce the issue. The script should have **no external library dependencies** (i.e., use fake or mock data / environments):

If we cannot run your script, we cannot fix your issue.

- [x] I have verified my script runs in a clean environment and reproduces the issue.
- [x] I have verified the issue also occurs with the [latest wheels](https://docs.ray.io/en/latest/installation.html).



Discussion:

Resolving patch:
diff --git a/rllib/agents/a3c/a3c.py b/rllib/agents/a3c/a3c.py
--- a/rllib/agents/a3c/a3c.py
+++ b/rllib/agents/a3c/a3c.py
@@ -54,11 +54,6 @@ def get_policy_class(config):
 def validate_config(config):
     if config["entropy_coeff"] < 0:
         raise DeprecationWarning("entropy_coeff must be >= 0")
-    if config["sample_async"] and config["use_pytorch"]:
-        config["sample_async"] = False
-        logger.warning(
-            "The sample_async option is not supported with use_pytorch: "
-            "Multithreading can be lead to crashes if used with pytorch.")
 
 
 def execution_plan(workers, config):


Test patch:
Repository: ray-project/ray

Issue:
[tune] Tune dashboard : use scientific notation
When displaying parameters in the tune dashboard, they are displayer using standard float format 
with only 2 significant digits.

For example, if your learning rate is lower than 1e-2, it appears as zero.

Similarly, if your experiments return a metric whose value are in a narrow range, the displayed digits are all equal and you cannot know which one is better (for example, for an accuracy between 0 and 100% treated as a float, values displayed are between 0.00 and 1.00, with a resolution corresponding to 1%, which is really not much).


Discussion:

Resolving patch:
diff --git a/python/ray/dashboard/dashboard.py b/python/ray/dashboard/dashboard.py
--- a/python/ray/dashboard/dashboard.py
+++ b/python/ray/dashboard/dashboard.py
@@ -875,7 +875,7 @@ def clean_trials(self, trial_details):
 
             # round all floats
             for key in float_keys:
-                details[key] = round(details[key], 3)
+                details[key] = round(details[key], 12)
 
             # group together config attributes
             for key in config_keys:


Test patch:
Repository: ray-project/ray

Issue:
[CLI] version option
### Describe your feature request

`ray --version` should output the version. Judging from the output of `ray --help`, it looks like Click is used. Version flags should be easy in click; see https://click.palletsprojects.com/en/7.x/api/#click.version_option. 


Discussion:
This wouldn't be hard to implement; @sumanthratna would you be willing to push a quick PR?

just tag me and I'll help you get it merged!
Sure! Is [python/ray/scripts/scripts.py](https://github.com/ray-project/ray/edit/master/python/ray/scripts/scripts.py) the only file I need to change?

Resolving patch:
diff --git a/python/ray/scripts/scripts.py b/python/ray/scripts/scripts.py
--- a/python/ray/scripts/scripts.py
+++ b/python/ray/scripts/scripts.py
@@ -60,6 +60,7 @@ def check_no_existing_redis_clients(node_ip_address, redis_client):
     default=ray_constants.LOGGER_FORMAT,
     type=str,
     help=ray_constants.LOGGER_FORMAT_HELP)
+@click.version_option()
 def cli(logging_level, logging_format):
     level = logging.getLevelName(logging_level.upper())
     ray.utils.setup_logger(level, logging_format)


Test patch:
Repository: ray-project/ray

Issue:
Ray should remove ssh fingerprints from known_hosts when tearing down a cluster
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### Describe your feature request
When Ray kills a node or tears down a cluster, it should remove the ssh fingerprints for the corresponding IP addresses from ~/.ssh/known_hosts. GCP often reuses IP addresses, so if you delete and reprovision a node, it is common for GCP to give you the same IP. Because it's a new VM, the fingerprint is going to be different than the last node's fingerprint. This triggers `WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!`, which ruins the current action. This issue probably hasn't been noticed until now because AWS rarely gives you the same IP. Currently I've been fixing this by manually deleting entries from known_hosts, but it would be nice if this happened automatically (e.g. by executing `ssh-keygen -R $DEST`). This should also happen if Ray notices that the cluster has been deleted through the GCP/AWS console.


Discussion:
cc @thomasdesr This seems to be that scary error that I've seen sometimes? 

Resolving patch:
diff --git a/python/ray/autoscaler/updater.py b/python/ray/autoscaler/updater.py
--- a/python/ray/autoscaler/updater.py
+++ b/python/ray/autoscaler/updater.py
@@ -169,7 +169,14 @@ def __init__(self, log_prefix, node_id, provider, auth_config,
     def get_default_ssh_options(self, connect_timeout):
         OPTS = [
             ("ConnectTimeout", "{}s".format(connect_timeout)),
+            # Supresses initial fingerprint verification.
             ("StrictHostKeyChecking", "no"),
+            # SSH IP and fingerprint pairs no longer added to known_hosts.
+            # This is to remove a "REMOTE HOST IDENTIFICATION HAS CHANGED"
+            # warning if a new node has the same IP as a previously
+            # deleted node, because the fingerprints will not match in
+            # that case.
+            ("UserKnownHostsFile", os.devnull),
             ("ControlMaster", "auto"),
             ("ControlPath", "{}/%C".format(self.ssh_control_path)),
             ("ControlPersist", "10s"),


Test patch:
Repository: ray-project/ray

Issue:
[tune][rllib] Windows: FileExistsError when running rllib tune job
<!--Please include [tune], [rllib], [autoscaler] etc. in the issue title if relevant-->

### What is the problem?
My script (available below) runs fine on Linux but does not fully run yet on Windows.
I can't tell exactly what went wrong, but the two major errors I see is:
`TypeError: len() of unsized object`
`FileExistsError: [WinError 183] Cannot create a file when that file already exists`

Full error log:
https://gist.github.com/juliusfrost/acbca090259610a176847e7026dd6d30

### Reproduction
Run on Windows OS
Install pytorch
Install the latest `ray` and `rllib` versions
Install `atari-py` if necessary
Download `train_a2c.py` from https://gist.github.com/juliusfrost/61b8be67d33b9bc9ab1faf7ada9d2ae3
Run `python train_a2c.py BreakoutNoFrameskip-v4`
if you don't have a gpu add `--gpus 0`



Discussion:
#9114 Seems related
cc @mehrdadn 
Thanks for the report! I added this to the list.

Resolving patch:
diff --git a/python/ray/tune/trial_runner.py b/python/ray/tune/trial_runner.py
--- a/python/ray/tune/trial_runner.py
+++ b/python/ray/tune/trial_runner.py
@@ -276,7 +276,7 @@ def checkpoint(self, force=False):
         with open(tmp_file_name, "w") as f:
             json.dump(runner_state, f, indent=2, cls=_TuneFunctionEncoder)
 
-        os.rename(tmp_file_name, self.checkpoint_file)
+        os.replace(tmp_file_name, self.checkpoint_file)
         if force:
             self._syncer.sync_up()
         else:


Test patch: