Fail to run 'HandManipulateBlock-v0'

[navid-hoseini]

Thanks for the nice api. I managed to run CartPole-v0 using python example_agent.py command. Now I need to run HandManipulateBlock-v0. But this environment is not available in gym 0.7.4 (specified in requirements.txt). So I changed the versions of numpy, gym and requests in requirements.txt to the following:
numpy==1.15.0,
gym==0.10.5,
requests==2.19.1
Now gym-http-api recognizes HandManipulateBlock-v0 environment. But when I try to run the environment using python example_agent.py, the execution halts with the followint exception:

Traceback (most recent call last):
File "/home/navid/gym-http-api/gym_http_client.py", line 22, in _parse_server_error_or_raise_for_status
j = resp.json()
File "/home/navid/my-gym-http-api/lib/python3.5/site-packages/requests/models.py", line 896, in json
return complexjson.loads(self.text, **kwargs)
File "/usr/lib/python3.5/json/init.py", line 319, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.5/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.5/json/decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Could anyone give me some hint about how to fix this? Thanks.
Best regards,
Navid

[BoltzmannBrain]

Also wanting to run the mujoco environments, I upgraded the pypi packages (in requirements.txt) to their latest, and get what looks to be a segfault running the python example:

Server starting at: http://127.0.0.1:5000
 * Serving Flask app "gym_http_server" (lazy loading)
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: off
2018-10-02 11:18:38.612 python[39830:1196208] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff40b7543d __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff6ca82720 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff40b8eec1 -[NSException raise] + 9
	3   AppKit                              0x00007fff3e0932a5 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 324
	4   AppKit                              0x00007fff3e09068c -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
	5   AppKit                              0x00007fff3e0900b6 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
	6   _ctypes.cpython-37m-darwin.so       0x0000000114215ef7 ffi_call_unix64 + 79
	7   ???                                 0x000070000a50a1f0 0x0 + 123145475367408
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

FWIW I'm on OSX 10.14 in a Python3.7 virtual env.

[machinaut]

We don't use the HTTP API internally, so it hasn't got much attention lately.

What's your use case for needing it? Could you use the regular (python) api instead?

[BoltzmannBrain]

Thanks for following up @machinaut. The rest of my code (i.e. the "agent") is in C++. I could write bindings s.t. the experiments are run with the standard gym python api, passing observations/actions to/from the C++ agent, but I was hoping to avoid that by using this repo.

[machinaut]

I think there isn't currently an effort to maintain this repo, so I would recommend using it as-is with older packages if the older environments are sufficient for your needs.

If you need the newer mujoco environments, then I would recommend looking at a different way of communicating with the python API.

I've personally had a lot of success integrating c++ and python code by making the C++ code into modules using the C extension api: https://docs.python.org/3/c-api/intro.html

[BoltzmannBrain]

Okay, not a problem, but I would suggest adding a note to the README:

This repo is not actively supported beyond commit ___. Proceed at your own risk if using package version greater than those defined in requirements.txt, as some gym/mujoco functions and environments may not be useable.

And yes I'm familiar with the C extension API, having used it with Boost.Python and pybind. If I end up implementing the bindings, would this be desired functionality for the gym repo?

[machinaut]

It would be useful to have, but maybe not in the primary gym repo. External bindings could be a separate package instead.