Compiling problems on macOS 10.12 (error: 'futurechaiscript::Boxed_Value' is unavailable)

I'm trying to compile OSPRay head on OS X.  The OS/Compiler version is:
$ uname -a
Darwin jbw-macbook-pro.local 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
$ clang --version
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin16.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bi

The errors are:

[ 76%] Building CXX object builddir/apps/intel64/common/script/CMakeFiles/ospray_script.dir/OSPRayScriptHandler.cpp.o
In file included from /Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/OSPRayScriptHandler.cpp:19:
In file included from /Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/chaiscript_stdlib.hpp:25:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1170:1: error: 'future<chaiscript::Boxed_Value>' is unavailable: introduced in macOS 10.8
future<_Rp>::get()
^
/Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/dispatchkit/bootstrap_stl.hpp:631:35: note: in instantiation of member function 'std::__1::future<chaiscript::Boxed_Value>::get' requested here
          m->add(fun(&FutureType::get), "get");
                                  ^
/Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/chaiscript_stdlib.hpp:51:36: note: in instantiation of function template specialization 'chaiscript::bootstrap::standard_library::future_type<std::__1::future<chaiscript::Boxed_Value> >' requested here
        lib->add(standard_library::future_type<std::future<chaiscript::Boxed_Value>>("future"));
                                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1074:57: note: 'future<chaiscript::Boxed_Value>' has been explicitly marked unavailable here
class _LIBCPP_TYPE_VIS_ONLY _LIBCPP_AVAILABILITY_FUTURE future
                                                        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:680:1: error: '__assoc_state<chaiscript::Boxed_Value>' is unavailable: introduced in macOS 10.8
__assoc_state<_Rp>::move()
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1175:17: note: in instantiation of member function 'std::__1::__assoc_state<chaiscript::Boxed_Value>::move' requested here
    return __s->move();
                ^
/Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/dispatchkit/bootstrap_stl.hpp:631:35: note: in instantiation of member function 'std::__1::future<chaiscript::Boxed_Value>::get' requested here
          m->add(fun(&FutureType::get), "get");
                                  ^
/Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/chaiscript_stdlib.hpp:51:36: note: in instantiation of function template specialization 'chaiscript::bootstrap::standard_library::future_type<std::__1::future<chaiscript::Boxed_Value> >' requested here
        lib->add(standard_library::future_type<std::future<chaiscript::Boxed_Value>>("future"));
                                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:601:35: note: '__assoc_state<chaiscript::Boxed_Value>' has been explicitly marked unavailable here
class _LIBCPP_AVAILABILITY_FUTURE __assoc_state
                                  ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2367:16: error: no matching function for call to '__make_async_assoc_state'
        return _VSTD::__make_async_assoc_state<_Rp>(_BF(__decay_copy(_VSTD::forward<_Fp>(__f)),
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:397:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
              ^
/Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/chaiscript_stdlib.hpp:52:107: note: in instantiation of function template specialization 'std::__1::async<const std::__1::function<chaiscript::Boxed_Value ()> &>' requested here
        lib->add(chaiscript::fun([](const std::function<chaiscript::Boxed_Value ()> &t_func){ return std::async(std::launch::async, t_func);}), "async");
                                                                                ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2312:1: note: candidate template ignored: substitution failure [with _Rp = chaiscript::Boxed_Value]: 'future<chaiscript::Boxed_Value>' is unavailable: introduced in macOS 10.8
__make_async_assoc_state(_Fp&& __f)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2375:16: error: no matching function for call to '__make_deferred_assoc_state'
        return _VSTD::__make_deferred_assoc_state<_Rp>(_BF(__decay_copy(_VSTD::forward<_Fp>(__f)),
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:397:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2299:1: note: candidate template ignored: substitution failure [with _Rp = chaiscript::Boxed_Value]: 'future<chaiscript::Boxed_Value>' is unavailable: introduced in macOS 10.8
__make_deferred_assoc_state(_Fp&& __f)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:2377:12: error: 'future<chaiscript::Boxed_Value>' is unavailable: introduced in macOS 10.8
    return future<_Rp>{};
           ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1074:57: note: 'future<chaiscript::Boxed_Value>' has been explicitly marked unavailable here
class _LIBCPP_TYPE_VIS_ONLY _LIBCPP_AVAILABILITY_FUTURE future
                                                        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1162:1: error: 'future<chaiscript::Boxed_Value>' is unavailable: introduced in macOS 10.8
future<_Rp>::~future()
^
/Users/josephwinston/src/Graphics/INTEL/OSPRay/apps/common/script/chaiscript/chaiscript_stdlib.hpp:52:102: note: in instantiation of member function 'std::__1::future<chaiscript::Boxed_Value>::~future' requested here
        lib->add(chaiscript::fun([](const std::function<chaiscript::Boxed_Value ()> &t_func){ return std::async(std::launch::async, t_func);}), "async");
                                                                                ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1074:57: note: 'future<chaiscript::Boxed_Value>' has been explicitly marked unavailable here
class _LIBCPP_TYPE_VIS_ONLY _LIBCPP_AVAILABILITY_FUTURE future
                                                        ^
6 errors generated.

My google search isn't bringing up anything specific with error: 'future<chaiscript::Boxed_Value>' is unavailable

I had the same error on El Capitan with the new Xcode 8.
What worked for me:

Set CMAKE_OSX_SYSROOT to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
Set CMAKE_OSX_DEPLOYMENT_TARGET to 10.12  (or at least 10.8)

HTH, Tim

Thanks @timbiedert.  Compiles and runs.

I tried the fix, which got me past the first issue, but now I'm getting this error. Any ideas @timbiedert @josephwinston ?
[ 38%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/Geometry.cpp.o
[ 39%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/TriangleMesh.cpp.o
[ 39%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/StreamLines.cpp.o
[ 40%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/Instance.cpp.o
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:24:3: error:
      redefinition of enumerator 'OSP_VOID_PTR'
  OSP_VOID_PTR,
  ^
/usr/local/include/ospray/OSPDataType.h:24:3: note: previous definition is here
  OSP_VOID_PTR,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:27:3: error:
      redefinition of enumerator 'OSP_OBJECT'
  OSP_OBJECT,
  ^
/usr/local/include/ospray/OSPDataType.h:27:3: note: previous definition is here
  OSP_OBJECT,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:30:3: error:
      redefinition of enumerator 'OSP_CAMERA'
  OSP_CAMERA = 10,
  ^
/usr/local/include/ospray/OSPDataType.h:30:3: note: previous definition is here
  OSP_CAMERA = 10,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:31:3: error:
      redefinition of enumerator 'OSP_DATA'
  OSP_DATA,
  ^
/usr/local/include/ospray/OSPDataType.h:31:3: note: previous definition is here
  OSP_DATA,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:32:3: error:
      redefinition of enumerator 'OSP_FRAMEBUFFER'
  OSP_FRAMEBUFFER,
  ^
/usr/local/include/ospray/OSPDataType.h:32:3: note: previous definition is here
  OSP_FRAMEBUFFER,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:33:3: error:
      redefinition of enumerator 'OSP_GEOMETRY'
  OSP_GEOMETRY,
  ^
/usr/local/include/ospray/OSPDataType.h:33:3: note: previous definition is here
  OSP_GEOMETRY,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:34:3: error:
      redefinition of enumerator 'OSP_LIGHT'
  OSP_LIGHT,
  ^
/usr/local/include/ospray/OSPDataType.h:34:3: note: previous definition is here
  OSP_LIGHT,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:35:3: error:
      redefinition of enumerator 'OSP_MATERIAL'
  OSP_MATERIAL,
  ^
/usr/local/include/ospray/OSPDataType.h:35:3: note: previous definition is here
  OSP_MATERIAL,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:36:3: error:
      redefinition of enumerator 'OSP_MODEL'
  OSP_MODEL,
  ^
/usr/local/include/ospray/OSPDataType.h:36:3: note: previous definition is here
  OSP_MODEL,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:37:3: error:
      redefinition of enumerator 'OSP_RENDERER'
  OSP_RENDERER,
  ^
/usr/local/include/ospray/OSPDataType.h:37:3: note: previous definition is here
  OSP_RENDERER,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:38:3: error:
      redefinition of enumerator 'OSP_TEXTURE'
  OSP_TEXTURE,
  ^
/usr/local/include/ospray/OSPDataType.h:38:3: note: previous definition is here
  OSP_TEXTURE,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:39:3: error:
      redefinition of enumerator 'OSP_TRANSFER_FUNCTION'
  OSP_TRANSFER_FUNCTION,
  ^
/usr/local/include/ospray/OSPDataType.h:39:3: note: previous definition is here
  OSP_TRANSFER_FUNCTION,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:40:3: error:
      redefinition of enumerator 'OSP_VOLUME'
  OSP_VOLUME,
  ^
/usr/local/include/ospray/OSPDataType.h:40:3: note: previous definition is here
  OSP_VOLUME,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:41:3: error:
      redefinition of enumerator 'OSP_PIXEL_OP'
  OSP_PIXEL_OP,
  ^
/usr/local/include/ospray/OSPDataType.h:41:3: note: previous definition is here
  OSP_PIXEL_OP,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:44:3: error:
      redefinition of enumerator 'OSP_STRING'
  OSP_STRING,
  ^
/usr/local/include/ospray/OSPDataType.h:44:3: note: previous definition is here
  OSP_STRING,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:47:3: error:
      redefinition of enumerator 'OSP_CHAR'
  OSP_CHAR  =100,
  ^
/usr/local/include/ospray/OSPDataType.h:47:3: note: previous definition is here
  OSP_CHAR  =100,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:50:3: error:
      redefinition of enumerator 'OSP_UCHAR'
  OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
  ^
/usr/local/include/ospray/OSPDataType.h:50:3: note: previous definition is here
  OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:50:19: error:
      redefinition of enumerator 'OSP_UCHAR2'
  OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
                  ^
/usr/local/include/ospray/OSPDataType.h:50:19: note: previous definition is here
  OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
                  ^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:50:31: error:
      redefinition of enumerator 'OSP_UCHAR3'
  OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
                              ^
/usr/local/include/ospray/OSPDataType.h:50:31: note: previous definition is here
  OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
                              ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[2]: *** [builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/TriangleMesh.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [builddir/ospray/intel64/CMakeFiles/ospray.dir/all] Error 2
make: *** [all] Error 2

You already have an OSPRay installation in /usr/local  (see the hint in the message “note: previous definition is here”).   Just delete it before compiling and reinstalling.   I also had this error once :-)

On 19 Oct 2016, at 21:01, Michael Fogleman<EMAIL_ADDRESS>wrote:
I tried the fix, which got me past the first issue, but now I'm getting this error. Any ideas @timbiedert https://github.com/timbiedert @josephwinston https://github.com/josephwinston ?
[ 38%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/Geometry.cpp.o
[ 39%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/TriangleMesh.cpp.o
[ 39%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/StreamLines.cpp.o
[ 40%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/Instance.cpp.o
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:24:3: error:
redefinition of enumerator 'OSP_VOID_PTR'
OSP_VOID_PTR,
^
/usr/local/include/ospray/OSPDataType.h:24:3: note: previous definition is here
OSP_VOID_PTR,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:27:3: error:
redefinition of enumerator 'OSP_OBJECT'
OSP_OBJECT,
^
/usr/local/include/ospray/OSPDataType.h:27:3: note: previous definition is here
OSP_OBJECT,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:30:3: error:
redefinition of enumerator 'OSP_CAMERA'
OSP_CAMERA = 10,
^
/usr/local/include/ospray/OSPDataType.h:30:3: note: previous definition is here
OSP_CAMERA = 10,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:31:3: error:
redefinition of enumerator 'OSP_DATA'
OSP_DATA,
^
/usr/local/include/ospray/OSPDataType.h:31:3: note: previous definition is here
OSP_DATA,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:32:3: error:
redefinition of enumerator 'OSP_FRAMEBUFFER'
OSP_FRAMEBUFFER,
^
/usr/local/include/ospray/OSPDataType.h:32:3: note: previous definition is here
OSP_FRAMEBUFFER,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:33:3: error:
redefinition of enumerator 'OSP_GEOMETRY'
OSP_GEOMETRY,
^
/usr/local/include/ospray/OSPDataType.h:33:3: note: previous definition is here
OSP_GEOMETRY,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:34:3: error:
redefinition of enumerator 'OSP_LIGHT'
OSP_LIGHT,
^
/usr/local/include/ospray/OSPDataType.h:34:3: note: previous definition is here
OSP_LIGHT,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:35:3: error:
redefinition of enumerator 'OSP_MATERIAL'
OSP_MATERIAL,
^
/usr/local/include/ospray/OSPDataType.h:35:3: note: previous definition is here
OSP_MATERIAL,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:36:3: error:
redefinition of enumerator 'OSP_MODEL'
OSP_MODEL,
^
/usr/local/include/ospray/OSPDataType.h:36:3: note: previous definition is here
OSP_MODEL,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:37:3: error:
redefinition of enumerator 'OSP_RENDERER'
OSP_RENDERER,
^
/usr/local/include/ospray/OSPDataType.h:37:3: note: previous definition is here
OSP_RENDERER,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:38:3: error:
redefinition of enumerator 'OSP_TEXTURE'
OSP_TEXTURE,
^
/usr/local/include/ospray/OSPDataType.h:38:3: note: previous definition is here
OSP_TEXTURE,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:39:3: error:
redefinition of enumerator 'OSP_TRANSFER_FUNCTION'
OSP_TRANSFER_FUNCTION,
^
/usr/local/include/ospray/OSPDataType.h:39:3: note: previous definition is here
OSP_TRANSFER_FUNCTION,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:40:3: error:
redefinition of enumerator 'OSP_VOLUME'
OSP_VOLUME,
^
/usr/local/include/ospray/OSPDataType.h:40:3: note: previous definition is here
OSP_VOLUME,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:41:3: error:
redefinition of enumerator 'OSP_PIXEL_OP'
OSP_PIXEL_OP,
^
/usr/local/include/ospray/OSPDataType.h:41:3: note: previous definition is here
OSP_PIXEL_OP,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:44:3: error:
redefinition of enumerator 'OSP_STRING'
OSP_STRING,
^
/usr/local/include/ospray/OSPDataType.h:44:3: note: previous definition is here
OSP_STRING,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:47:3: error:
redefinition of enumerator 'OSP_CHAR'
OSP_CHAR  =100,
^
/usr/local/include/ospray/OSPDataType.h:47:3: note: previous definition is here
OSP_CHAR  =100,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:50:3: error:
redefinition of enumerator 'OSP_UCHAR'
OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
^
/usr/local/include/ospray/OSPDataType.h:50:3: note: previous definition is here
OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:50:19: error:
redefinition of enumerator 'OSP_UCHAR2'
OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
^
/usr/local/include/ospray/OSPDataType.h:50:19: note: previous definition is here
OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
^
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/TriangleMesh.cpp:28:
In file included from /Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/ospray.h:44:
/Users/fogleman/Kitware/ospray/ospray/geometry/../include/ospray/OSPDataType.h:50:31: error:
redefinition of enumerator 'OSP_UCHAR3'
OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
^
/usr/local/include/ospray/OSPDataType.h:50:31: note: previous definition is here
OSP_UCHAR =110, OSP_UCHAR2, OSP_UCHAR3, OSP_UCHAR4,
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[2]: *** [builddir/ospray/intel64/CMakeFiles/ospray.dir/geometry/TriangleMesh.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [builddir/ospray/intel64/CMakeFiles/ospray.dir/all] Error 2
make: *** [all] Error 2
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ospray/OSPRay/issues/85#issuecomment-254909096, or mute the thread https://github.com/notifications/unsubscribe-auth/ATm8IcBzP7h95LaBbbl__aOLhF-3g-Y1ks5q1mj4gaJpZM4KHu2w.

Ah... Thanks!


Call jQuery .()change when modifying .val() on text fields

When pasting (or autofilling via 1Password/etc) the values are correctly set on the specific form fields but change events are not being triggered when the reformats occur. This breaks integration with frameworks like Ember who use change to update the value of input bindings.

Hi there! Sorry for the very late reply.
The 'change' event is a tricky beast and not something that we want to manually trigger. Browsers don't agree on what it really means, and as far as I know it always only triggers after a commit-like action on an input field (blurring, submitting, etc), so we definitely don't want to trigger it synthetically on .val() updates. I'm not familiar with Ember and I'm not sure why it would only be listening for raw 'change' events.
I'm going to close this. If you are still having trouble, please feel free to re-open, but please provide a jsfiddle link to a minimal reproduction, as well as information about which browsers and operating systems are affected.


Change how progress notifications are dispatched

Based on one possible interpretation of https://github.com/realm/realm-cocoa/issues/4626. See that ticket for discussion and rationale.

Adding reviewers to open up discussion. (We might not want to go with this approach.)

Fixes #4623.

One of the builds failed because the compiler segfaulted, the other three failed because of various CI issues.


ability to migrate events from newest and backwards would be good

it would be good if would be possible to migrate most recent events first and work backwards. Since often more recent historic events are more important that the most recent.

Currently we can't do this due to the way person properties get overridden (set-once never overrides, set always does despite the timestamp of the event). However we are considering changing person properties updates to use timestamps logic as described here: https://posthog.com/docs/integrate/user-properties#how-do-values-get-overridden however that work is currently paused delayed behind some more urgent changes in ingestion.


Add more Inovelli blue switch entities

Are these supported for all devices?

Seems like the Dimming mode option is only for VZM31-SN and VZM36, the rest are in all three device's parameter table.

Seems like the Dimming mode option is only for VZM31-SN and VZM36, the rest are in all three device's parameter table.

We should restrict those to the models they apply to then

We also need to make sure the attributes are already merged in the mfg cluster in quirks before this can be merged.
We really should migrate all of these to v2 quirks so it’s all in one spot at some point

do you mean these? https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/inovelli/init.py#L212 sorry I'm very new to this :)

do you mean these? https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/inovelli/init.py#L212 sorry I'm very new to this :)

If they are common across all devices they go in the base class: https://github.com/zigpy/zha-device-handlers/blob/acecf704f2b253c9297d901eed8909dbd589ea97/zhaquirks/inovelli/init.py#L94
Otherwise they go in the appropriate extension

yes, all these attributes are already there.


Update to Edit Command

fixes #17
No major fix required for the edit command from the last discussion the developers had on 10 Oct.
Amended the UG accordingly to follow the edit command requirements.

for review and merge PR ! thank you pals!


fix upper cases for linux env

Fix upper cases to compile npm on Linux and mac systems.

@SamProf Not sure if your going to merge pull requests while on vacation but this looks good to merge in.

Thank you! I am in vacation now. After 25 July this PR will be checked and marged.


[Improvement][K8S] Custom label of a K8S task can be passed to the pod

Purpose of the pull request

close #15368

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (c849501) 37.81% compared to head (3061066) 37.81%.

:exclamation: Current head 3061066 differs from pull request most recent head 67428eb. Consider uploading reports for the commit 67428eb to get more accurate results

Additional details and impacted files
@@            Coverage Diff            @@
##                dev   #15369   +/-   ##
=========================================
  Coverage     37.81%   37.81%
+ Complexity     4682     4681    -1
=========================================
  Files          1304     1304
  Lines         44937    44901   -36
  Branches       4812     4789   -23
=========================================
- Hits          16991    16980   -11
+ Misses        26098    26073   -25
  Partials       1848     1848

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update deploy.sh to use the right ENV vars

deploy.sh was using ENV vars to set the image versions
incorrectly. This causes the images to be pushed using
versions already in the Makefile, rather than the overrides
in the deploy script.
This is now fixed by updating the right ENV variables.
Signed-off-by: ShyamsundarR<EMAIL_ADDRESS>

@humblec @phlogistonjohn PTAL


broken link

Describe the bug
the links to
You will also need a phone mount. Here is one option:

    Mpow Dashboard Car Phone Mount (EU, US)

on Build your own
are not available.
I tried searching for a new page of the same product but couldn't find any.
However, the 3d printed one is amazingly good.

found this product that might be a nice fit
https://www.banggood.com/Ulanzi-ST-06S-Phone-Clip-with-Two-Cold-Shoe-Vertical-Shooting-Smartphone-Clamp-Mount-Holder-Tripod-Mount-DSLR-Camera-Mount-for-Vlog-Live-Broadcast-Photography-p-1889176.html?cur_warehouse=CN


Issues using vue-class-component

My component runs fine with vue-cli but when I attempt to build I get the following error: (commonjs plugin) SyntaxError: Unexpected character '@' (101:0)
The code at line 101 is
 @Component({
Am I missing something in the rollup.config file? I set the following external dependencies:
const external = [
  // list external dependencies, exactly the way it is written in the import statement.
  // eg. 'jquery'
  'vue-class-component',
  'fuse.js',
  'lodash',
  'vue-property-decorator'
];

Behind the scenes, the vue cli uses webpack and babel. The setup vue-sfc-rollup generates uses bublé for transpiling instead of babel. This is relevant because vue-class-component uses experimental decorators, which are not yet part of the official spec.
I suspect that you need to swap rollup-plugin-buble for rollup-plugin-babel and make the necessary configuration adjustments.
For a list of features supported by bublé, refer to their docs.

@GregOSP did you add typescript plugin?
my rollup config looks somewhat like this:
import typescript from "rollup-plugin-typescript2";

const baseConfig = {
  input: 'src/entry.js',
  plugins: [
    replace({
      'process.env.NODE_ENV': JSON.stringify('production'),
    }),
    commonjs(),
    typescript({
      useTsconfigDeclarationDir: true,
      clean: true,
      objectHashIgnoreUnknownHack: true,
    }),
    vue({
      css: true,
      compileTemplate: true,
      template: {
        isProduction: true,
      },
    }),
    buble(),
  ],
};

and my tsconfig.json file contains:
"experimentalDecorators": true

If what @jarekcieslak said works, great! I personally don't have as much experience using the vue/typescript decorators. I guess it makes sense if typescript does the first pass that it could add in the appropriate parts.

@jarekcieslak thanks for the suggestion. Unfortunately I can't get typescript to recognize props defined in @Component() as  valid and keep getting an error on compile semantic error TS2339 Property 'PropName' does not exist on type 'MyComponent'.


added postcss-vwh plugin

@himynameisdave Hi! It's been here for over a month. Have I done something wrong?

@gVguy nope, sorry I just haven't had time to look at this yet!


--supermarket-site option behaves differently than knife.rb

knife supermarket list --supermarket-site mysupermarket.com
ERROR: Connection refused connecting to https://localhost/mysupermarket.com/api/v1/cookbooks?items=10&start=0, retry 1/5
note the /localhost/ in the url
echo "knife[:supermarket_site] = 'https://mysupermarket.com'" > knife.rb
knife supermarket list
mycookbook1 mycookbook2

This may have been a bug in knife itself. Testing the same command with version 0.2.1 of the plugin and with knife in Chef 12.5.1 works:
» knife supermarket list -m 'https://nowhere.example.org'
ERROR: Connection refused connecting to https://nowhere.example.org/api/v1/cookbooks?items=10&start=0, retry 1/5

Note: I included the https:// protocol in the site string—as you did for the addition to knife.rb—otherwise the command will error complaining about JSON parsing.


oranda: 0.4.1 -> 0.5.0

Diff: https://github.com/axodotdev/oranda/compare/v0.4.1...v0.5.0
Changelog: https://github.com/axodotdev/oranda/blob/v0.5.0/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 260462 run on x86_64-linux 1

1 package built:

oranda

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

oranda:

warning: EvalError
Cannot evaluate attribute ‘oranda’ in ‘/nix/store/lvkq6xa7vysm51ap9da3wz0sb48pmpsf-nixpkgs’.


Deep Linking

Are you planning on adding Deep Linking? It would be really helpful as most apps these days have this requirement?
References:
https://facebook.github.io/react-native/docs/linking.html
https://www.lullabot.com/articles/navigation-and-deep-linking-with-react-native

Good call!  We'll make this a TODO item.

Any ideas how to do this with the current structure?

https://github.com/aksonov/react-native-router-flux/issues/704 looks promising.

Ignite 2.0 is looking to ship with react-navigation which uses this feature out-of-the-box.

Any update on this please... I need to get this working in my app, it's holding me back for production launch. Any help on this would be greatly appreciated. Thanks.

@samtoya Can you post the results of ignite doctor please? If you're still having trouble with it, that is.

I'm unable to run ignite doctor successful, I have the ignite video plugin installed.
I'm using<EMAIL_ADDRESS>.
Here's my output;
`
Error: Error: Couldn't load command video -- needs a "run" property with a function.

command-loader.js:53 Object.loadCommandFromFile
[lib]/[ignite-cli]/[gluegun]/build/loaders/command-loader.js:53:15

plugin-loader.js:40
[lib]/[ignite-cli]/[gluegun]/build/loaders/plugin-loader.js:40:105

Array.map

plugin-loader.js:40 Object.loadPluginFromDirectory
[lib]/[ignite-cli]/[gluegun]/build/loaders/plugin-loader.js:40:59

runtime.js:175 Runtime.addPlugin
[lib]/[ignite-cli]/[gluegun]/build/runtime/runtime.js:175:38

runtime.js:204
[lib]/[ignite-cli]/[gluegun]/build/runtime/runtime.js:204:58

Array.map

runtime.js:204 Runtime.addPlugins
[lib]/[ignite-cli]/[gluegun]/build/runtime/runtime.js:204:24

builder.js:150
[lib]/[ignite-cli]/[gluegun]/build/domain/builder.js:150:61

Array.forEach

/Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/index.js:13
throw up;
^
Error: Error: Couldn't load command video -- needs a "run" property with a function.
at Object.loadCommandFromFile (/Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/loaders/command-loader.js:53:15)
at /Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/loaders/plugin-loader.js:40:105
at Array.map ()
at Object.loadPluginFromDirectory (/Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/loaders/plugin-loader.js:40:59)
at Runtime.addPlugin (/Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/runtime/runtime.js:175:38)
at /Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/runtime/runtime.js:204:58
at Array.map ()
at Runtime.addPlugins (/Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/runtime/runtime.js:204:24)
at /Users/samtoya/.nvm/versions/node/v10.16.0/lib/node_modules/ignite-cli/node_modules/gluegun/build/domain/builder.js:150:61
at Array.forEach ()
`

@jamonholmgren Here....:
System
platform           darwin
arch               x64
cpu                4 cores                                         Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
directory          /Users/samtoya/Code/TechNation/RN/aftownmusic
JavaScript
node               10.16.0      /Users/samtoya/.nvm/versions/node/v10.16.0/bin/node
npm                6.11.3       /Users/samtoya/.nvm/versions/node/v10.16.0/bin/npm
yarn               1.17.3       /Users/samtoya/.nvm/versions/node/v10.16.0/bin/yarn
React Native
react-native-cli   2.0.1
app rn version     0.59.9
Ignite
ignite-cli           3.1.6                                                                                /Users/samtoya/.nvm/versions/node/v10.16.0/bin/ignite
createdWith          3.1.5
boilerplate          ignite-andross
examples             classic
navigation           react-navigation
askToOverwrite       true
generators           {"component":"ignite-andross","container":"ignite-andross","listview":"ignite-andross","list":"ignite-andross","redux":"ignite-andross","saga":"ignite-andross","screen":"ignite-andross"}
boilerplateVersion   4.1.0
Android
java               1.8.0_222    /usr/bin/java
android home       -            /Users/samtoya/Library/Android/sdk
iOS
xcode              11.0

Hey @samtoya , please file a new issue on Ignite Andross. Thanks!

Okay.. @jamonholmgren
Thanks.


validates uniqueness of fails with UUID pk

{ [SQLError: error: select count(*) as "count" from "accounts" where "accounts"."email" = $1 and "accounts"."id" != $2 - invalid input syntax for uuid: "1"]
  message:
   { error: invalid input syntax for uuid: "1"
       at Connection.parseE (/home/samps/sites/personal/dus/office.downundersports.com/node/node_modules/pg/lib/connection.js:567:11)
       at Connection.parseMessage (/home/samps/sites/personal/dus/office.downundersports.com/node/node_modules/pg/lib/connection.js:391:17)

I don't know where that "1" would be coming from. this is on create of a brand new record

the id is being set on new
newAccount = Account.new({email: account.email.toLowerCase(), password: account.password})
console.log(newAccount); #=> `<Account {id:"1"<EMAIL_ADDRESS>password:"password" athlete_id:null created_at:null updated_at:null}>`

found it. I'll put together a PR

fixed in https://github.com/PhilWaldmann/openrecord/pull/49

You can close this once everything's merged in

Perfekt! Thx
I'll release the new version tomorrow


Non-centered parent node

Hi!
Is it possible to draw a hierarchy tree where parent not centered based on the children nodes, we need to have the children in the right side or lift side of the parent?
We review the online examples, source code, without any success!

I think we have the same requirement as @devmsh (if I understand him correctly). We want to lay the tree out with the root node at the top left and all descendants cascading down (never up) and to the right. Looking at the d3-hierarchy source, it seems like we’d need to implement a custom layout. Perhaps there are already 3rd-party layouts that do this?

Found this: https://bl.ocks.org/mbostock/1093025

Do you mean something like this maybe: https://github.com/VisualStorytelling/d3-hierarchy/blob/7312254d45355fad2720cad2a6f31d1f3ae05660/img/gratzl.png ? I just opened a pull request for this kind of layout


Blog post on "classes of service": portable, non-portable, and default classes

Part of #775
What seems to be the problem?
Crossplane added a new model of support for "classes of service" with portable, non-portable, and default classes that enable new functionality and fundamentally change the way that all dynamic provisioning takes place. We want to make it clear how strongly typed resource classes are different from the generic ResourceClass pattern and provide our motivation for the shift.
What could Crossplane do to help?
Give a detailed breakdown of how managed resources were being passed configuration details using the generic ResourceClass pattern, and how it differs with strongly typed resource classes. Explain how defaulting makes things easy and what improvements we're thinking about for the future. In addition, the changes in examples and docs should be pointed out and linked.
What does it look like when we're done?
New blog post on blog.crossplane.io
Todo

[x] draft blog post
[ ] review
[ ] publish

I'm going to suggest we don't do this given that by the time we get around to it they won't exist anymore - should be replaced by an 0.4 blog post about simple resource class selection.


Can't add two numbers in Windows 10 Webview

Description
The plus + arithmetic operator is replaced by the Windows 10 Webview. I can't add a simple + as it will be replaced by a blank space. This happens when I add the + operator inside the HTML, it doesn't matter if it's inside a script tag. If I try to add two numbers like  console.log(5 + 5); the + is replaced by a blank space, it doesn't happen when substracting numbers.
package main

import "github.com/webview/webview"

func main() {

	var HTML = `<!DOCTYPE html>

Hello world! There should be some plus operators here -> + + +.

	`

	debug := true
	w := webview.New(debug)
	defer w.Destroy()
	w.SetTitle("Minimal webview example")
	w.SetSize(800, 600, webview.HintNone)
	w.Navigate("data:text/html," + HTML)
	w.Run()
}

Here is an screenshot of the problem:

Using url_encode or  url.PathEscape doesn't fix it neither.
I'm using the data:text/html method as using localhost is something I don't want to do.

Ok, this can be fixed by calling url.QueryEscape(HTML).
Working example:
package main

import (
	"net/url"

	"github.com/webview/webview"
)

func main() {

	var HTML = `<!DOCTYPE html>

Hello world! There should be some plus operators here -> + + +.

	`

	debug := true
	w := webview.New(debug)
	defer w.Destroy()
	w.SetTitle("Minimal webview example")
	w.SetSize(800, 600, webview.HintNone)
	w.Navigate("data:text/html," + url.QueryEscape(HTML))
	w.Run()
}


Make settle time less than validity time in pin tip tests

Fixes a test so we can do a release

Closing in favour of https://github.com/DiamondLightSource/hyperion/pull/1005


Are you interested in accessing the taskbar

(1) Get the count of buttons in taskbar.
(2) Get the index of the active button.
(3) Activate a button by its index.
If implement these 3 functions, we will overcome a lot of difficulties, such as:
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=105129&p=466883&hilit=taskbar#p466883
https://www.autohotkey.com/boards/viewtopic.php?f=6&t=107976&p=480328&hilit=taskbar#p480328
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=108539&p=482839&hilit=taskbar#p482839
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=108597&p=483071&hilit=taskbar#p483071
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=108826&p=483921&hilit=taskbar#p483921
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=110582&p=491690&hilit=taskbar#p491690
... more and more ...

Hmm.
I plan to stick to VirtualDesktop related functions. Are you talking about IApplicationView functions? I know those can be used to replicate ALT+TAB switcher accurately, I don't know about buttons in taskbar, but I guess they are same.
I have removed those helpers in Rust version, there was a bunch of those in the C++ version.
I don't plan to add those here.

Thank you for your advice. Could you give me a URL about IApplicationView? I can't find it by bing.


New ListView layout: image, main text, detail text stacked vertically

Describe the desired feature
ListView should have a layout that is image, main text, detail text stacked vertically.
A layout where the image has nothing beside it allow the image to be scaled much larger. Most horizontal (swipe left/right) layouts make use of large pictures, e.g. music album covers or people's faces. ListView can be oriented horizontally, but that feature currently isn't very usable.

@SusanRatiLane can i work on this ?

@SusanRatiLane i have attached an image below. are you asking for that type of layout?

@SusanRatiLane are you asking for this type of layout?

@SusanRatiLane ohk got it. if you haven't already started on this should i work on it?

@devarsh-mavani-19 lets work on it together ?

I think it's probably too much for you both to try to coordinate working on it together. Since @Yash621 asked first, I'm assigning to him.
You're thinking in good directions, @devarsh-mavani-19 . I encourage you to look for another item.

@SusanRatiLane thank you ,I will raise a PR for this shortly.

@SusanRatiLane no worries I will work on something else thanks :)

Probably you need to look at ListView.java ListAdapterWithRecyclerView.java which are in component/ folder under com.google.appinventor.components.runtime package.

@Yash621 I have one question for you, are you familiar with App Inventor source? Because first you asked in which files you need to look and now you are asking about functionality.
I suggest you to explore more in App Inventor source.

@Yash621 you haven't posted in a while. So just in case you are not working on it, I think I can solve this issue.

It is still open can you reassign it to me?


Move up to intermediate folder structure

Is your feature request related to a problem? Please describe.
I think this app has grown so much, it's time we moved up to the intermediate folder structure.
Describe the solution you'd like
Add __tests__ to every folder that the app generates.
Describe alternatives you've considered
There are no alternatives.

@TheoBr when do you think we would be able to move to senior structure? Should we roadmap this?

We won't be adding tests in the template.

For the record, this was just a meme...

I was told yeah 😆
I hadn't watched the vod when you made this issue.


assert len(img_files) == len(anno) error

Hi, I encountered some wired errors.
1st, when I unzip the files from BaiduYun, I only got 335 archives  that doesn't match the numbers in list.txt file.
Then I create a new list file with my 335 folders and continue my training, the error assert len(img_files) == len(anno) in got10k.py, line 66 came out.
Can anyone help me?Thanks.

I think it is caused by something wrong with BaiduYun's source or my operation: cat *.zip > train_data.zip.

have you find the solution? I met the same error


added .net core 3.0 information and fixed bug for modify output path

@bishal-pdMSFT I made the change to not take the folder of Project file as the project name, but rather take the project file name as the project name.
Do you think it should be done ?


Tracking issue: trivialBuild should retire in favor of elpaBuild and friends

Describe the bug
According to @jian-lin the trivialBuild function has some problems that make it a bad fit for Emacs ecosystem in Nixpkgs.

The builtin package manager package.el will not activate it at the Emacs' startup

autoloaded commands does not work out-of-the-box, requiring code like  (require 'foo-autoloads)`
info manual becomes inaccessible viaM-x info

References:

https://github.com/NixOS/nixpkgs/pull/278201#discussion_r1441301238
its package dir is not searched by Emacs
it does not contain a foo-pkg.el file

Add a :+1: reaction to issues you find important.

I think we should:

make reviewers and contributors aware that trivialBuild has some issues and its usage is discouraged
replace existing trivialBuild in manual-packages with melpaBuild or elpaBuild

We should do this in reverse: first by looking at current code that uses trivialBuild, and only then to warn new devs.
I say this because I remember some packages fail with melpaBuild.

Directories inside pkgs/applications/editors/emacs/elisp-packages/manual-packages/ that call trivialBuild:

[ ] agda-input
[ ] agda2-mode
[ ] codeium
[ ] color-theme-solarized
[ ] control-lock
[ ] copilot
[ ] ess-R-object-popup
[ ] evil-markdown
[ ] font-lock-plus
[ ] git-undo
[ ] helm-words
[ ] hsc3
[ ] idris2-mode
[ ] isearch-plus
[ ] isearch-prop
[ ] jam-mode
[ ] llvm-mode
[ ] lspce
[ ] notdeft
[ ] ott-mode
[ ] perl-completion
[ ] pod-mode
[ ] prolog
[ ] rect-mark
[ ] sunrise-commander
[ ] sv-kalender
[ ] urweb-mode
[ ] voicemacs
[ ] wat-mode
[ ] yes-no
[ ] youtube-dl

elpaBuild expects src to be a file or a tarball meeting some requirements.  The requirement of src of melpaBuild is less strict than the one of elpaBuild.
Have you tried melpaBuild?

I tried it a long time ago. But let's do it again:
{ lib
, emacs
, fetchFromGitHub
, melpaBuild
, writeText
}:

melpaBuild {
  pname = "sunrise-commander";
  ename = "sunrise-commander";
  version = "unstable-2021-09-27";

  src = fetchFromGitHub {
    owner = "sunrise-commander";
    repo = "sunrise-commander";
    rev = "16e6df7e86c7a383fb4400fae94af32baf9cb24e";
    hash = "sha256-D36qiRi5OTZrBtJ/bD/javAWizZ8NLlC/YP4rdLCSsw=";
  };

  packageRequires = [
    emacs
  ];

  recipe = writeText "recipe" ''
    (sunrise-commander :repo "sunrise-commander/sunrise-commander" :fetcher github :files ("*.el"))
  '';

  fileSpecs = [ "*.el" ];

  meta = {
    homepage = "https://github.com/sunrise-commander/sunrise-commander/";
    description = "Orthodox (two-pane) file manager for Emacs";
    license = lib.licenses.gpl3Plus;
    maintainers = [ lib.maintainers.AndersonTorres ];
    platforms = lib.platforms.all;
  };
}

Log:
emacs-sunrise-commander-unstable> Running phase: installPhase
emacs-sunrise-commander-unstable> Error: file-missing ("Opening input file" "No such file or directory" "/build/packages/sunrise-commander-unstable-2021-09-27.tar")
emacs-sunrise-commander-unstable>   mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0xcc6be0a6510e41>))
emacs-sunrise-commander-unstable>   debug-early-backtrace()
emacs-sunrise-commander-unstable>   debug-early(error (file-missing "Opening input file" "No such file or directory" "/build/packages/sunrise-commander-unstable-2021-09-27.tar"))
emacs-sunrise-commander-unstable>   insert-file-contents-literally("/build/packages/sunrise-commander-unstable-2021-09-27.tar")
emacs-sunrise-commander-unstable>   (if is-tar (insert-file-contents-literally file) (insert-file-contents file))
emacs-sunrise-commander-unstable>   (progn (if is-tar (insert-file-contents-literally file) (insert-file-contents file)) (if is-tar (progn (tar-mode))) (elpa2nix-install-from-buffer))
emacs-sunrise-commander-unstable>   (unwind-protect (progn (if is-tar (insert-file-contents-literally file) (insert-file-contents file)) (if is-tar (progn (tar-mode))) (elpa2nix-install-from-buffer)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
emacs-sunrise-commander-unstable>   (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (if is-tar (insert-file-contents-literally file) (insert-file-contents file)) (if is-tar (progn (tar-mode))) (elpa2nix-install-from-buffer)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))))
emacs-sunrise-commander-unstable>   (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (if is-tar (insert-file-contents-literally file) (insert-file-contents file)) (if is-tar (progn (tar-mode))) (elpa2nix-install-from-buffer)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))))
emacs-sunrise-commander-unstable>   (let ((is-tar (string-match "\\.tar\\'" file))) (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (if is-tar (insert-file-contents-literally file) (insert-file-contents file)) (if is-tar (progn (tar-mode))) (elpa2nix-install-from-buffer)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))))))
emacs-sunrise-commander-unstable>   elpa2nix-install-file("/build/packages/sunrise-commander-unstable-2021-09-27.tar")
emacs-sunrise-commander-unstable>   (progn (setq package-user-dir elpa) (elpa2nix-install-file archive))
emacs-sunrise-commander-unstable>   (let ((archive x0) (elpa x2)) (progn (setq package-user-dir elpa) (elpa2nix-install-file archive)))
emacs-sunrise-commander-unstable>   (if (null x3) (let ((archive x0) (elpa x2)) (progn (setq package-user-dir elpa) (elpa2nix-install-file archive))))
emacs-sunrise-commander-unstable>   (let* ((x2 (car-safe x1)) (x3 (cdr-safe x1))) (if (null x3) (let ((archive x0) (elpa x2)) (progn (setq package-user-dir elpa) (elpa2nix-install-file archive)))))
emacs-sunrise-commander-unstable>   (if (consp x1) (let* ((x2 (car-safe x1)) (x3 (cdr-safe x1))) (if (null x3) (let ((archive x0) (elpa x2)) (progn (setq package-user-dir elpa) (elpa2nix-install-file archive))))))
emacs-sunrise-commander-unstable>   (let* ((x0 (car-safe command-line-args-left)) (x1 (cdr-safe command-line-args-left))) (if (consp x1) (let* ((x2 (car-safe x1)) (x3 (cdr-safe x1))) (if (null x3) (let ((archive x0) (elpa x2)) (progn (setq package-user-dir elpa) (elpa2nix-install-file archive)))))))
emacs-sunrise-commander-unstable>   (if (consp command-line-args-left) (let* ((x0 (car-safe command-line-args-left)) (x1 (cdr-safe command-line-args-left))) (if (consp x1) (let* ((x2 (car-safe x1)) (x3 (cdr-safe x1))) (if (null x3) (let ((archive x0) (elpa x2)) (progn (setq package-user-dir elpa) (elpa2nix-install-file archive))))))))
emacs-sunrise-commander-unstable>   elpa2nix-install-package()
emacs-sunrise-commander-unstable>   command-line-1(("-l" "/nix/store/4jj63z4v1xp13rh2md053dccq920hd45-elpa2nix.el" "-f" "elpa2nix-install-package" "/build/packages/sunrise-commander-unstable-2021-09-27.tar" "/nix/store/6gf924kvnbpjgf7mrwmm93ih5pcjpkrr-emacs-sunrise-commander-unstable-2021-09-27/share/emacs/site-lisp/elpa"))
emacs-sunrise-commander-unstable>   command-line()
emacs-sunrise-commander-unstable>   normal-top-level()
emacs-sunrise-commander-unstable> Opening input file: No such file or directory, /build/packages/sunrise-commander-unstable-2021-09-27.tar

Here is a working example: ename and recipe need to be change to sunrise and commit is needed for now
{ lib
, emacs
, fetchFromGitHub
, melpaBuild
, writeText
}:

melpaBuild {
  pname = "sunrise-commander";
  ename = "sunrise";
  version = "20210924.1620";

  src = fetchFromGitHub {
    owner = "sunrise-commander";
    repo = "sunrise-commander";
    rev = "16e6df7e86c7a383fb4400fae94af32baf9cb24e";
    hash = "sha256-D36qiRi5OTZrBtJ/bD/javAWizZ8NLlC/YP4rdLCSsw=";
  };

  # not sure whether it is still needed when a newer[1] package-build is used
  # [1]: https://github.com/NixOS/nixpkgs/pull/276943 is in the staging branch for now
  commit = "foo";

  # should be redundant
  # packageRequires = [
  #   emacs
  # ];

  recipe = writeText "recipe" ''
    (sunrise :repo "sunrise-commander/sunrise-commander" :fetcher github)
  '';

  meta = {
    homepage = "https://github.com/sunrise-commander/sunrise-commander/";
    description = "Orthodox (two-pane) file manager for Emacs";
    license = lib.licenses.gpl3Plus;
    maintainers = [ lib.maintainers.AndersonTorres ];
    platforms = lib.platforms.all;
  };
}

Nice. Now we need to wait the Staging Truckload.

Where did the attribute version = "20210924.1620"; come from?
I have grepped the installed files and it comes from nowhere except an autogenerated sunrise-pkg.el...
What does fileSpecs do? It is not documented anywhere...

https://github.com/NixOS/nixpkgs/issues/190746 is related

Where did the attribute version = "20210924.1620"; come from?

This is the version format MELPA unstable uses.
(let ((time<PHONE_NUMBER>))
  (concat (format-time-string "%Y%m%d."
I think fileSpecs has no effect since https://github.com/NixOS/nixpkgs/commit/d3cea4860862754d74f60a4332c24b646f1446c9#diff-2a37290b0927d8abb03148a01a10a84dd3a18be9be80d27c7aac6c02d8ea6841L14

Some obvious findings:

The recipe format is described here: https://github.com/melpa/melpa#recipe-format
maybe it can be Nixified.

Thanks for your work on this, y'all! 🙌

I created https://github.com/NixOS/nixpkgs/pull/316107 to improve the UX of melpaBuild.

With https://github.com/NixOS/nixpkgs/pull/316726, the UX of melpaBuild should be on a par with elpaBuild and trivialBuild.
Given that it has fewer issues than trivialBuild and that its requirement for src is looser than elpaBuild, it should be recommended as the default builder for manual packages.

Now that it reached Master, we can restart!

How do you use melpaBuild to create very simple in-line packages?
          (e.trivialBuild {
            pname = "foo";
            version = "2024-07-15";
            src = builtins.toFile "foo.el" ''(defun foo-three () 3) (provide 'foo)'';
          })

I use this to create light-weight emacs plugins from my Nix config, it's a neat way to integrate the broader system config into Emacs.

@hraban you can look at https://github.com/NixOS/nixpkgs/pull/325168 to take some inspiration.
The problem is that maybe melpaBuild is a bit stricter, since it transfers control to Emacs build system.

I will split this in order to accomodate EmacsWiki repacks:

[ ] control-lock
[ ] isearch-plus
[ ] isearch-prop
[ ] perl-completion
[ ] rect-mark
[ ] sv-kkalender
[ ] yes-no

The minimal melpaBuild equivalent is
  e.melpaBuild {
    pname = "foo";
    version = "0-unstable-2024-07-15";
    # version = "20240715.0"; # if your Nixpkgs is old
    src = builtins.toFile "foo.el" ''
      ;;; foo.el ---
      (defun foo-three () 3) (provide 'foo)
    '';
  };

The first line (file header) ;;; foo.el --- is needed by melpaBuild to generate foo-pkg.el.

Thanks! Good catch: that line was necessary for melpaBuild but not for trivialBuild

If trivialBuild works well for your use case, then there is no need to switch to melpaBuild. melpaBuild is still a good fit for "normal" packages.

That'd be good for my use case, I was going off the impression from this issue title that trivialBuild is on the way to becoming obsolete but if it's still available that's nice.

EmacsWiki repacks (they should be dealt with separately):

@AndersonTorres What do you mean by "they should be dealt with separately"?  Why and how?

It is better explained with an example:
Let's pick control-lock.
Webpage: https://www.emacswiki.org/emacs/ControlLock
Download page: https://www.emacswiki.org/emacs/download/control-lock.el
There is virtually no version control.
However, there is a backup at GitHub:
https://github.com/emacsmirror/emacswiki.org/blob/master/control-lock.el
My intention is to create a "package" for this EmacsWiki mirror and do something like files = ''("control-lock.el")''.

Another thing to be seen is the auto-update scripts.

Another thing to be seen is the auto-update scripts.

Since trivialBuild works well in that use case (autolaoding is not used by update-melpa.el) and users is unlikely to look at that file, it's fine to not change it to melpaBuild.

I am working on the last piece of this issue, i.e., writing doc for these builders.

I wasn't clear. I was talking about passthru.updateScript.

@AndersonTorres Could you switch mkDerivation to melpaBuild for cask?

Yes I can. However I will need to study cask a little bit, since Cask is a commandline app.

For now the only "non-conforming" packages are xapian-lite and cedille.
However Cedille is broken:

Broken due to Agda update.  See
https://github.com/NixOS/nixpkgs/pull/129606#issuecomment-881107449.

The bug you mention is that Emacs lisp packages built by elpaBuild have emacs itself in their closures.  This bug have already been fixed, which means nixos-24.11 and nixos-unstable do not have this bug.  If you are using older nixos releases, one way to fix the bug is to use Emacs lisp packages from emacs-overlay.
If you want to discuss this bug future, please open a new issue.


Adding issue template

I would like to issue template for pr request, bug report, feature request template, custom template

https://docs.google.com/forms/d/e/1FAIpQLSeqyBIbjWqEzDRBWk37-c8ZBAinhtssYOfaZTdraVVGdX71Qw/formResponse


Fix typo around ciphersuite

Addresses an inconsistency raised by @christianpaquin w.r.t the input data type of Ciphersuite_ID

Minor editorial tweak, multiple approvals, merging


Please indicate LICENSE for this project

Hi,
Sorry, I forgot it in each of my repositories, I'm gonna fix it thanks !


Cancel Button

It is great that we have a Rerun button now but a Cancel button would be awesome too!

Thanks for report! Just to confirm, are you talking about the button that would allow you to stop execution in the middle of the process?

That is correct.
On Thu, Oct 15, 2015 at 8:04 PM, Kirill Enykeev<EMAIL_ADDRESS>wrote:

Thanks for report! Just to confirm, are you talking about the button that
would allow you to stop execution in the middle of the process?
—
Reply to this email directly or view it on GitHub
https://github.com/StackStorm/st2web/issues/240#issuecomment-148557629.

@enykeev anymore movement on this?

@outcast sorry for the delay, just got back from the vacation. I've put together a PR for this change (see #268). I haven't talked with the team yet so I can't say when this change will go live, though.

@emedvedev did this get implemented?

@outcast: Yes, https://github.com/StackStorm/st2web/pull/268 is merged. Sorry, should've notified you before closing, just assumed you were following the PR as well :)


Add GitHub actions

This pull request should add support for github actions. It is in a very early stage and should be significantly improved before merged.
Any help or review is greatly appreciated. Especially, help in creating MSVC tests would be great.
To help improve this pull request, please fork https://github.com/andreasbuhr/cppcoro/tree/add_github_actions and create a pull request toward this branch.

Starting to look nice, have a look here: https://github.com/andreasbuhr/cppcoro/runs/1245006472
Next step is to add MSVC.

Feel free to steal bits from libunifex actions config.
https://github.com/facebookexperimental/libunifex/blob/master/.github/workflows/libunifex-ci.yml

This pull request is now open for two month. I now stop maintaining this pull request. From now on, I will continue to maintain the master branch in https://github.com/andreasbuhr/cppcoro. There we have CMake support, a CI based on Github Actions, and support for the latest compilers.


In CPP targets when cancel file dialog select event dispatch with empty path and app crash.@jgranick

@:noCompletion private function openFileDialog_onSelect(path:String):Void
{
	// TODO: #2352 In CPP targets when cancel file dialog select event dispatch with empty path and app crash.@jgranick
	 if (path == null || path == "")
	 {
	 	dispatchEvent(new Event(Event.CANCEL));
	 	return;
	}

....


Update zio-sbt-website to 0.1.5+21-de576a1e-SNAPSHOT

Updates dev.zio:zio-sbt-website from 0.1.5+10-49adf3d7-SNAPSHOT to 0.1.5+21-de576a1e-SNAPSHOT.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio", artifactId = "zio-sbt-website" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "dev.zio", artifactId = "zio-sbt-website" }
}]

labels: sbt-plugin-update, early-semver-build-metadata, semver-spec-build-metadata, commit-count:1

Superseded by #799.


Don't show null and not-null for scalar not-null columns

We should not show null and not-null for scalar columns of the main table that are not-null.
Another improvement is also not providing these options for all outbound foirengkey facets that all the columns involved are not-null.

There are two special cases that ermest might return a null value for a not-null column:

When user right is null and therefore it's row-based.
When user is looking at a snapshot of old catalog and data might be missing.

Therefore we are going to be more strict in our check and we're going to check for not-null, right = true, and no catalog snapshot.


Unhandled Redis Connection Errors

Thanks for this library. Its super helpful!
We currently have nebulex_ecto configured to use the nebulex_redis_adapter and its working pretty well. The issue we're seeing currently is exceptions being thrown by the underlying redis adapter if there is a temporary disconnection. As this is a cacheing library, I'd expect the library to go to the repo if there was a problem reading the value from the cache instead of crashing my process.
Expected behavior: If there was an error trying to read data from the cache, the library should read the data from the db instead.
Observed behavior: Temporary disconnects cause nebulex_ecto to raise.
Stacktrace:
#PID<0.7956.9> running ApolloWeb.Endpoint (cowboy_protocol) terminated Server:
apollo.fantag.live:80 (http) Request: GET / ** (exit) an exception was raised:
** (Redix.ConnectionError) :disconnected (redix)
lib/redix.ex:407: Redix.pipeline!/3 (nebulex_redis_adapter)
lib/nebulex_redis_adapter.ex:358: NebulexRedisAdapter.with_ttl/4 (nebulex)
lib/nebulex/cache/object.ex:12: Nebulex.Cache.Object.get/3 (fantag)
lib/fantag/redis_cache.ex:2: Fantag.RedisCache.with_hooks/3 (fantag)
lib/fantag/cacheable_repo.ex:2: Fantag.CacheableRepo.do_get/4 (fantag)
lib/fantag/guardian.ex:16: Fantag.Guardian.resource_from_claims/1 (guardian)
lib/guardian/plug/load_resource.ex:58: Guardian.Plug.LoadResource.resource/3 (guardian)
lib/guardian/plug/load_resource.ex:49: Guardian.Plug.LoadResource.call/2

We are seeing the underlying redix library reconnecting automatically and subsequent requests to the cache are successful.

@sbennett33, did you find any workaround on this?


Visual bug with Magnesium (Forge version of Sodium)

Hello.
Visual bug with Magnesium (Forge version of Sodium) of "slime fern" and "kabloom pulp". I have tried to change the json but nothing changed. If it is not possible to solve this, how can I avoid those plants to spawn naturally please ? Changing Magnesium settings doesn't solve this.
https://i.ibb.co/d500Nq9/2022-01-29-15-11-49.png
FILES USED
1.18.1-forge-39.0.63
habitat-1.1.2.jar
magnesium-0.4.0-alpha6.jar

There is no config to disable plant spawning at the moment. I think it would be better to report this to Magnesium.

Ok, thank you! There is this kind of problem for many other mods (list below), so I will ask to Magnesium author.

Biome-Makeover (visual bug)
Brassgeodes (visual bug)
Macaws-bridges (visual bug)
Chisels bits (doesn't show blocks)
Chalk (doesn't show marks)
Snow-real-magic (doesn't show snow)


[Investigation] Block time is not stable in cc2 (around 7s)

telemetry.polkadot.io-1608263862604.log
After analyze the log, it looks like that work report would affect block number. The operational dispatch class might be the reason.

--execution wasm turns out that report_works and register in swork need 200x weight than --execution native

we should run with --execution wasm --wasm-execution compiled witch just 10x times than native! I dodo the test and it work. https://github.com/paritytech/substrate/issues/7779

we should run with --execution wasm --wasm-execution compiled witch just 10x times than native! I dodo the test and it work. paritytech/substrate#7779

Resolved by this method

we should run with --execution wasm --wasm-execution compiled witch just 10x times than native! I dodo the test and it work. paritytech/substrate#7779

Resolved by this method


Updated run.sh.

Separated dmg download step from dmg2img conversion step.

Seems good to me, even if I was surprised and didn't understood at first the way you check the availability of the dmg2img command with the which  (I'm not used to the to set -e flag, but I'm not a shellscripting expert...). Totally good.
The way I usually do this is I build an array of dependencies then loop over the items to check to availibility of each command, and echo a message informing the user about a missing dependency.


Add "save" command

#113

@rultor please merge.

@rultor please merge.

@extsoft OK, I'll try to merge now. You can check the progress of the merge here

@rultor please merge.

@extsoft Done! FYI, the full log is here (took me 2min)


[#48] JS: Check if window is defined in systemLocale

This looks good to me. Thank you for quickly addressing all feedback!


NIFI-3194: PutElasticsearchHttp should route flowfiles to failure on connection errors

Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Reviewing

+1
Visually verified code and did a contrib-check build. In a standalone instance, tested many different variations of misconfigured PutES processor hitting ES 2.3.3 and all worked as expected (routing to failure/retry). Thanks @mattyb149 I will merge it in.


[auto-bump] dependency by max-hoffman

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by `go get`ing the dependency.
```
$ cd ./go
$ go get github.com/dolthub//go@
$ go mod tidy
```
Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/1620

This PR has been superseded by https://github.com/dolthub/bounties/pull/1621


DateTime handling in client sqlite

Can someone confirm for me whether datetimes that are kind local are automatically converted to utc on insert to sqlite? It appears that the opposite is true as well and in my initial testing utc dates inserted via InsertAsync get converted to local.
I upgraded from the mobile services client and now my dates have gone all wonky. In mobile service client the utc dates came out of the local db as local datetimes but they were actually the utc values, so I changed the DateTime.Kind without changing the value so that using .ToLocal would work properly when displaying to the end users.
Before I go rework my code I want to make sure I understand how DateTime is treated.
Thanks.

Ok, to follow up with what I was asking and maybe to partially answer my own question I ran this code on iOS in a Xam.Forms app:
 var testDates = new TestDatesModel
 {
	 Id = "1",
	 DateTimeUtc = DateTime.UtcNow,
	 DateTimeLocal = DateTime.Now
 };
 Debug.WriteLine("Saving Records====================");
 Debug.WriteLine("Before Being Saved::");
 Debug.WriteLine("UTC = " + testDates.DateTimeUtc + " : " + testDates.DateTimeUtc.Kind);
 Debug.WriteLine("Local = " + testDates.DateTimeLocal + " : " + testDates.DateTimeLocal.Kind);

 await App.Current.MobileServiceClient.GetSyncTable<TestDatesModel>().InsertAsync(testDates);

 Debug.WriteLine("After Being Saved::");
 Debug.WriteLine("UTC = " + testDates.DateTimeUtc + " : " + testDates.DateTimeUtc.Kind);
 Debug.WriteLine("Local = " + testDates.DateTimeLocal + " : " + testDates.DateTimeLocal.Kind);

 Debug.WriteLine("Retrieving Records===================");

var testDatesOut = await App.Current.MobileServiceClient.GetSyncTable<TestDatesModel>().Where(s=>s.Id == "1").ToListAsync();
var testDateOut = testDatesOut.First();

 Debug.WriteLine("UTC = " + testDateOut.DateTimeUtc + " : " + testDateOut.DateTimeUtc.Kind);
 Debug.WriteLine("Local = " + testDateOut.DateTimeLocal + " : " + testDateOut.DateTimeLocal.Kind);

 testDateOut.DateTimeUtc = testDateOut.DateTimeUtc.EnsureUniversal();

 Debug.WriteLine("Converted UTC Date From Local to UTC::");
 Debug.WriteLine("Converted UTC = " + testDateOut.DateTimeUtc + " : " + testDateOut.DateTimeUtc.Kind);

 await App.Current.MobileServiceClient.GetSyncTable<TestDatesModel>().UpdateAsync(testDateOut);

 Debug.WriteLine("After Being Updated in Db::");
 Debug.WriteLine("UTC = " + testDateOut.DateTimeUtc + " : " + testDateOut.DateTimeUtc.Kind);
 Debug.WriteLine("Local = " + testDateOut.DateTimeLocal + " : " + testDateOut.DateTimeLocal.Kind);

 testDatesOut = await App.Current.MobileServiceClient.GetSyncTable<TestDatesModel>().Where(s => s.Id == "1").ToListAsync();
 testDateOut = testDatesOut.First();

 Debug.WriteLine("After Being Updated in Db with converted UTC then Read Again::");
 Debug.WriteLine("UTC = " + testDateOut.DateTimeUtc + " : " + testDateOut.DateTimeUtc.Kind);
 Debug.WriteLine("Local = " + testDateOut.DateTimeLocal + " : " + testDateOut.DateTimeLocal.Kind);

Which yields this output:
[0:] Saving Records====================
[0:] Before Being Saved::
[0:] UTC = 5/8/2016 2:16:44 PM : Utc
[0:] Local = 5/8/2016 10:16:44 AM : Local
[0:] After Being Saved::
[0:] UTC = 5/8/2016 10:16:44 AM : Local
[0:] Local = 5/8/2016 10:16:44 AM : Local
[0:] Retrieving Records===================
[0:] UTC = 5/8/2016 10:16:44 AM : Local
[0:] Local = 5/8/2016 10:16:44 AM : Local
[0:] Converted UTC Date From Local to UTC::
[0:] Converted UTC = 5/8/2016 2:16:44 PM : Utc
[0:] After Being Updated in Db::
[0:] UTC = 5/8/2016 2:16:44 PM : Utc
[0:] Local = 5/8/2016 10:16:44 AM : Local
[0:] After Being Updated in Db with converted UTC then Read Again::
[0:] UTC = 5/8/2016 10:16:44 AM : Local
[0:] Local = 5/8/2016 10:16:44 AM : Local

You can see that when you Insert a record the UTC date is converted to a Local DateTime value, but when you Update the UTC date is not and gives you the same UTC value back.
Shouldn't this behavior be consistent?

The problem here is the API semantics.
MobileServiceSyncTable.InsertAsync() inserts an item and returns the inserted value (the inserted value will have the ID property set to a GUID string if it was not set already). Note that the API will not modify the parameter passed to it.
However, MobileServiceSyncTable<T>.InsertAsync() inserts an item but does not return the inserted value. It instead modifies the item passed to it (parameter) to reflect the changes made to it while inserting.
As can be seen, the 2 InsertAsync() APIs above behave differently. Ideally, both variants of InsertAsync() should return the inserted value and leave the value passed to it as parameter untouched.
On the other hand, UpdateAsync() neither modifies the item passed to it nor does it return anything. This is as expected.

The DateTime handling also causes issues when saving a timestamp in the ambiguous hour when changing from daylight savings to standard time: http://stackoverflow.com/questions/39890764/azure-mobile-apps-saves-incorrect-datetime-in-sqlite-database

If I look at how Frank does it in sqlite-net he does:
if (value is DateTime) {
					if (storeDateTimeAsTicks) {
						SQLite3.BindInt64 (stmt, index, ((DateTime)value).Ticks);
					}
					else {
						SQLite3.BindText (stmt, index, ((DateTime)value).ToString (DateTimeExactStoreFormat, System.Globalization.CultureInfo.InvariantCulture), -1, NegativePointer);
					}

Always good to store UTC :) and as ticks


Base layer information

Displays information about the undermost layer.

We have to wait with the merge until @alsturm did his review


Concerns about eth1 voting in the context of caching

I think the current eth1 voting mechanism has some undesirable properties when we consider that staking eth2 clients should cache eth1 blocks. They should cache because:

Requiring a call to some external server during block production is risky. If the eth1 node is unavailable at that time, we miss a beacon slot.
The amount of data required to make the vote is >1,000 blocks. Doing this remote call during block production will add significant (likely infeasible) lag to block production.

First I will state two undesirable properties of the current system in the context of caching and then suggest a simpler system.
Undesirable property 1: Clients must cache the eth1 chain all the way up to the head
Consider the first block proposer in the eth1 voting period (slot % SLOTS_PER_ETH1_VOTING_PERIOD == 0). In order to calculate get_eth1_data(distance) it needs to know the block number of the eth1 block at the start of the voting period (now). That block is the head of the eth1 chain.
This is the primary problem I have and it has two effects:

The eth2 client caches must be concerned with eth1 re-orgs, whilst the core eth2 protocol is not.
There are points in time (the start of the voting period) where an eth2 node's ability to vote is reduced by not having a cache that is immediately up to date.

Undesirable property 2: You need to cache all the way back to the current eth1_data
In order to cast a vote (i.e., not trigger an exception in the spec), a node must have in their cache all descendants of the block represented by state.eth1_data (at the start of the current voting period). So, the cache grows linearly with the time since a successful eth1 voting period.
Additionally, if a node wants their cache to be safe in the case of an eth2 re-org, they should cache all the way back to the eth1_data in the last finalized block. Therefore, the cache also grows linearly with the time since finalization.
My proposal:
Below is some rough Python code that I think is minimal and viable. I'm not convinced this should be the final solution, but it's a starting point at least.
It has the following properties that the present solution does not:

Clients can go for ETH1_FOLLOW_DISTANCE * SECONDS_PER_SLOT without contacting an eth1 node and still vote perfectly.
The size of this cache is limited to the amount of eth1 blocks in ETH1_FOLLOW_DISTANCE * SECONDS_PER_SLOT.
It is reasonable to assume that a re-org will never affect this cache.

def voting_period_start(state: BeaconState):
    eth1_voting_period_start_slot = state.slot % SLOTS_PER_ETH1_VOTING_PERIOD
    state.genesis_time + eth1_voting_period_start_slot * SECONDS_PER_SLOT

def is_candidate_block(block: Eth1Block, period_start: uint64) -> Bool:
    block.timestamp <= period_start - SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE and \
    block.timestamp >= period_start - SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE * 2

def get_eth1_vote(state: BeaconState) -> Eth1Data:
    period_start = voting_period_start(state)
    # `eth1_chain` abstractly represents all blocks in the eth1 chain.
    votes_to_consider = [get_eth1_data(block) for block in eth1_chain if
                         is_candidate_block(block, period_start)]

    valid_votes = [vote for vote in state.eth1_data_votes if vote in votes_to_consider]

    return max(
        valid_votes,
        key=lambda v: (valid_votes.count(v), -valid_votes.index(v)),  # Tiebreak by smallest distance
        default=get_eth1_data(ETH1_FOLLOW_DISTANCE),
    )

Basically, solution makes the following changes:

We select the range of viable votes using only timestamp, instead of the timestamp/block number hybrid we have now. This frees us from undesirable property 1.
Don't try and vote on blocks prior to the current voting period (i.e., ditch all_eth1_data). This frees us from undesirable property 2.

WRT (2), it's not clear to me why we bother with all_eth1_data. I have some ideas, but I'd be keen to hear the original motivations.

why all_eth1_data
The original intent of new_eth1_data vs all_eth1_data is to attempt to only cast repeat votes for new eth1 data if at the "start" of the period, and then in the tail of the period, favor just coming to consensus on anything valid.
This is to fight against the case in which an attacker has control of some proposers early in a voting period and just selects say the next block past the last eth1data. This tactic is relatively easy to conduct, costs nothing, and would majorly stall the induction of new validators into the beacon chain.
Proposer honestly assumption as justification of new design
What we lose by only considering "new" when casting repeat votes instead of opening up to "all" in the tail seems marginal, at best. Even in the case in which an attacker has all of the proposers during the first sqrt(SLOTS_PER_ETH1_VOTING_PERIOD) (32) slots, it is very likely that at least one honest proposer shows up before substantially further into the voting period. After which, honest votes would coalesce upon their vote. In fact, we actually already make the assumption that we have at least 1 honest proposer per 32 slots as a liveness assumption for getting attestations on chain to facilitate FFG finality. If this assumption consistently fails, we (1) are unlikely to be able to control the eth1 voting mechanism from the attacker and (2) might have bigger fish to fry.
Will the change affect the finality gadget?
One thing to consider is how this operates when SLOTS_PER_ETH1_VOTING_PERIOD and ETH1_FOLLOW_DISTANCE are reduced when introducing the finality gadget.
When SLOTS_PER_ETH1_VOTING_PERIOD is reduced, we rely more and more on our honesty assumption because our random sampling of proposers decreases. This seems unaffected by the proposal.
When ETH1_FOLLOW_DISTANCE is reduced into the range of potential forking (say 25-50 eth1 blocks), to ensure that proposers can coalesce on one vote even if the chain has a high degree of forking, we might need to have validators consider the recent eth1 block tree instead of just the PoW canonical chain. This requirement is debatable, but I don't think this proposal affects that potential requirement. It might require building a local cache (both with block depth or timestamp) so we should at least keep cache requirements in mind when researching and spec'ing finality gadget.
I'm in favor
I'm in favor.
This seems like something that we can release in a spec ASAP because it won't actually interfere interoperability in clients in 99%+ of the cases. With different clients running the existing algorithm and this new algorithm, validators might end up with disagreements on early votes, but would start to agree during the period_tail.
Let's gauge the temperature on the call tomorrow

This is to fight against the case in which an attacker has control of some proposers early in a voting period and just selects say the next block past the last eth1data.

I'm not following how all_eth1_data prevents this. As I understand it, the presence of all_eth1_data would make it more likely that honest clients end up voting on older eth1 blocks. This is because all_eth1_data must contain blocks that are either (a) in new_eth1_data or (b) older (lower block #) than all blocks in eth1_data.

Let's gauge the temperature on the call tomorrow

SGTM

edit: where are your return statements?! Do you even python?

Return statements are so passé.

I like it. This is close to what we do in Prysm, except for the tie breaking for vote decisions. We don't consider anyone elses vote at the moment when determining our eth1data vote.
I am a bit concerned about caching and eth1 reorgs. If everyone caches the same way and no one invalidates their cache on eth1 re-org, that coud be a problem. Could you elaborate on the assumption that eth1 re-orgs cannot affect this cache method?

I like it.

Glad to hear that!

Could you elaborate on the assumption that eth1 re-orgs cannot affect this cache method?

The present voting mechanism (when considered alongside the validator on-boarding logic) makes an assumption that eth1 will never re-org a block that is more than 128 blocks deep. This is fine, but my gripe is that eth1 voting is structured in such a way that a client is most likely going to need to keep a cache that occasionally includes all blocks up to the current eth1 head.
The mechanism I have proposed addresses my gripe by making a slightly different assumption; instead of saying "eth1 will never re-org a block that is more than 128 blocks deep", it says "eth1 will never re-org a block that is more than 128 times the expected block time (15s) deep". In other words, we judge a blocks depth in the eth1 chain by eth1_block.timestamp instead of eth1_block.number.
The important part about my mechanism is that it only requires the client to cache blocks that are at least SECONDS_PER_ETH1_BLOCK * ETH1_FOLLOW_DISTANCE seconds prior to the current eth1 head. So, if we can make the assumption that eth1 will never re-org a block with a timestamp more than 32 minutes old (15 secs * 128) then we can also assume that our caches will never experience a re-org.
Note: the assumption is not necessarily "eth1 will never re-org a block 32 minutes deep", it's more along the lines of "if eth1 re-orgs past 32 min then we need an extra-protocol solution to patch eth2".

Closed via #1553


feat/Osmosis Chain Connector

Before submitting this PR, please make sure:

[x ] Your code builds clean without any errors or warnings
[x ] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
Adds Osmosis (with LP) support as a chain, plus some updates to Cosmos chain.
Cosmos amm.routes.ts models don't match up well with the rest due to inherent differences in their data. This has been handled by allowing certain endpoints to receive Cosmos-specific models switched by chain, eg. AddLiquidityRequest | CosmosAddLiquidityRequest.
Tests performed by the developer:
Jest tests added for all Osmosis functions. Very little patch use, instead a testnet wallet is instantiated and trades/liquidity actions are performed with it.
yarn test:cov is ~80% for Osmosis, improved for Cosmos.
Tips for QA testing:
THIS LINE MUST to be added to HBOT client native_tokens[]
"osmosis": "OSMO",
in hummingbot/core/utils/gateway_config_utils.py
Submitting separate PR for that file as well.

Hi @chasevoorhees good day,
For adding new connector:

Please submit a NCP, see https://docs.hummingbot.org/governance/proposals/#new-connector-proposals
After NCP is submitted, please create thread about the Osmosis Chain Connector on proposals on discord so our community can have a look with it 🙇🏼

Hi @rapcmia
The proposal post in Discord can be found here: https://discord.com/channels/530578568154054663/1090857407942500352/1090857407942500352
The NCP has been submitted here: https://snapshot.org/#/hbot-ncp.eth/proposal/0x2e159b270c17ac68f47774a7dc6741aab48b638274cfc6519d38b1847351901a
Cheers!

Submitted a new PR on the dev branch
https://github.com/hummingbot/gateway/pull/237


chore: CRW-4582 add more exceptions for known issues

chore: CRW-4582 add more exceptions for known issues
Signed-off-by: Nick Boldt<EMAIL_ADDRESS>

/ok-to-test

/lgtm
/approve


[Dev] Do not build lucy twice

In our CI pipeline we are building test executive twice. First time in build-artifacts.sh script which is launched per every codename (Bullseye/Focal/Buster) and publishing to our debian repo. Second, in separate job for test executive build which puts exe on s3 storage which then is taken by execute tests jobs. My change was to rely in test execute job on deb package rather than cached binary from s3

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me


Upgrade to Scala.js 1.0.0-RC1 and Scala 2.12.10, and add Scala 2.13.1.

Updated. I also added a commit to add support for 2.13.1.


Documentation for how to create/release a package

Docs: https://dbt.readme.io/v0.8/docs/building-packages

made a small change to the justification for including tests in the package. lgtm!
👍

good change, thanks, closing


Recomp to PS1

Is this possible? Because I think that playing Mario 64 on the original Playstation would be awesome

Answered here: https://github.com/Mr-Wiseguy/N64Recomp/issues/42
Please, close the issue.


Python;After i fixed the "Undefined variable" problem, the yellow wave line still telling me the wrong variable  name.

VS Code Version:
OS Version:
版本: 1.56.0 (system setup)
提交: cfa2e218100323074ac1948c885448fdf4de2a7f
日期: 2021-05-04T22:09:06.405Z
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19042
Steps to Reproduce:

Python in vscode. After i fixed the "Undefined variable" problem, the yellow wave line still telling me the wrong variable  name.

Does this issue occur when all extensions are disabled?: Yes/No

/extPython


[RFC] Make mouse key used for drag/resize configurable

This makes it possible to define what mouse button key (left|right) to use for dragging/resizing.
Right now you define the following commands in the config or leave them out if you just want the default behavior.
dragging_key right
resizing_key left

default is the reverse of the above.
Do you like this version or should I call the config commands something different?
As an alternative you could have a single command like this, where you just define if it should be:
normal (left = dragging, right = resizing) or inverse (left = resizing, right = dragging).
dragging_resizing_mode inverse

or it could be an extension to floating_modifier
floating_modifier $mod inverse

What do you think?
(I will update manpage and the default config when a command definition has been decided on)

I like the idea of adding an extension to floating_modifier.

Great, me too actually. I have updated it to use floating_modifier and added that information to the example config and manpage.
I'm not sure I used the correct man page notation is [normal|inverse]correct if that whole option is optional?

Yep, that's fine. You may also want to explain in the text that it's optional. I'll review+merge this after work today.

LGTM.


bpf: nat: support additional code points for IPv4 ICMP_DEST_UNREACH

Add some more code points for ICMP_DEST_UNREACH. For the SNAT / RevSNAT of
the inner packet we can re-use the existing ICMP_FRAG_NEEDED code.
In particular this enables the EGW to return such ICMP responses back
to the client pod.

/test

(stashed some tests in https://github.com/cilium/cilium/pull/35672, but that's not ready for prime-time yet / more effort to backport)


slurm - s_p_parse_file: unable to status file /etc/slurm/slurm.conf

Description
Jobs fail to start when running as user:
[joe@login1 ~]$ srun -N 1 hostname
srun: error: s_p_parse_file: unable to status file /etc/slurm/slurm.conf: Permission denied, retrying in 1sec up to 60sec
srun: error: ClusterName needs to be specified
srun: fatal: Unable to process configuration file

The directory /etc/slurm is created with mode 0700:
[joe@login1 ~]$ ls -ld /etc/slurm/
drwx------. 2 slurm slurm 4096 Aug 22 22:55 /etc/slurm/

The role slurm uses the module user to create the slurm user and its home directory /etc/slurm. This module relies on the UMASK defined in /etc/login.defs to set permissions. It does not allow to set the permissions in the role. We might need to add a task to set the permissions accordingly.
Info
BlueBanquise 1.3-RC2
CentOS Linux release 8.2.2004 (Core)
ansible 2.9.11
slurm 19.05.4

Closed without resolution? This solution says that slurm.conf needs to be readable by all users. Copied and pasted here for posterity:

Your solution is correct.  The proper permissions are discussed in the SLURM documentation[1]
The slurm.conf file must be readable by all users of Slurm, since it is used by many of the Slurm commands. Other files that are defined in the slurm.conf file, such as log files and job accounting files, may need to be created/owned by the user "SlurmUser" to be successfully accessed. Use the "chown" and "chmod" commands to set the ownership and permissions appropriately. See the section FILE AND DIRECTORY PERMISSIONS for information about the various files and directories used by Slurm.

That's right, this is the fix I implemented.
GitHub automatically closed this with merge of #337, with a link to the commit as resolution: oxedions closed this in 0ad8955 on 25 Aug

Ah! My bad, didn't see the closed this in 0ad8955. Thank you!