….0.0: on unix at least it works wiht localhost, 0.0.0.0 and 127.0.0.1

when "stack too deep" is the err string, the location `rb_eval_string("$@.to_s");` will fail

The child class Ctor will intialize it

…p error

…e MeasureManager too

… fail when calling arguments(model) for an OLD reporting measure

…t take model prior to 3.0.0

Also unload the Ruby measures or it'll crash when trying to load it again

…se it uses the MeasureManager

…it has no effect and getMeasureInfo just fetches the previous one

…_utf8string

The MeasureManager server uses the cpprest SDK, which is an asynchronous
library that is implemented on top C++ threads. The challenge is that
API endpoints involving Ruby and Python are not thread safe. (This is
generally true for all conventional implementations of Ruby and Python,
not just OpenStudio's encapsulation of the scripting engines) The
solution implemented here, is to use a task queue so that all of the
"work" done by the API endpoints is done on the common main thread.

ref #4885

…hread does the actual ruby/python work

… missing)

… files

…r_c++

…into 4885_MeasureManager_c++

Use `std::fflush(std::cout)` instead of `std::cout << std::flush`

Co-authored-by: Julien Marrec <julien.marrec@gmail.com>

This issue only pertained to Mac and was occuring when a Python Measure was run before a Ruby Measure.
The fix is to set the dlopen flags to RTLD_LOCAL prior to importing OpenStudio in Python.

Test OpenStudioCLI.Labs.Run_PythonRuby demonstrates the original issue and will now pass.

close #4945

…nStudio into 4885_MeasureManager_c++