running yarn throws this error

yarn install v1.12.3
warning package.json: No license field
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
warning<EMAIL_ADDRESS>No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
[1/2] ⠐ ref
error C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref: Command failed.
Exit code: 1
Command: node-gyp rebuild
Arguments:
Directory: C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref
Output:
C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )
gyp info it worked if it ends with ok
gyp info using<EMAIL_ADDRESS>gyp info using<EMAIL_ADDRESS>| win32 | x64
gyp info spawn C:\Python27\python.exe
gyp info spawn args [
gyp info spawn args   'C:\\Program ' +
gyp info spawn args     'Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\gyp\\gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'msvs',
gyp info spawn args   '-G',
gyp info spawn args   'msvs_version=2015',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\Manav-Work\\Desktop\\New ' +
gyp info spawn args     'folder\\rust-typescript-bindgen\\node_modules\\ref\\build\\config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\Manav-Work\\.node-gyp\\12.3.1\\include\\node\\common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=C:\\Users\\Manav-Work\\.node-gyp\\12.3.1',
gyp info spawn args   '-Dnode_gyp_dir=C:\\Program ' +
gyp info spawn args     'Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp',
gyp info spawn args   '-Dnode_lib_file=C:\\Users\\Manav-Work\\.node-gyp\\12.3.1\\<(target_arch)\\node.lib',
gyp info spawn args   '-Dmodule_root_dir=C:\\Users\\Manav-Work\\Desktop\\New ' +
gyp info spawn args     'folder\\rust-typescript-bindgen\\node_modules\\ref',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'C:\\Users\\Manav-Work\\Desktop\\New ' +
gyp info spawn args     'folder\\rust-typescript-bindgen\\node_modules\\ref\\build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe
gyp info spawn args [
gyp info spawn args   'build/binding.sln',
gyp info spawn args   '/clp:Verbosity=minimal',
gyp info spawn args   '/nologo',
gyp info spawn args   '/p:Configuration=Release;Platform=x64'
gyp info spawn args ]
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
  binding.cc
  win_delay_load_hook.cc
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(222): error C2661: 'v8::Value::BooleanValue': no overloaded function takes 0 arguments [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(253): error C2660: 'v8::Value::Uint32Value': function does not take 0 arguments [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(2567): note: see declaration of 'v8::Value::Uint32Value' (compiling source file ..\src\binding.cc)
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(360): error C2664: 'v8::String::Utf8Value::Utf8Value(const v8::String::Utf8Value &)': cannot convert argument 1 from 'v8::Local<v8::Value>' to 'const v8::String::Utf8Value &' [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(360): note: Reason: cannot convert from 'v8::Local<v8::Value>' to 'const v8::String::Utf8Value'
  c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(360): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(447): error C2664: 'v8::String::Utf8Value::Utf8Value(const v8::String::Utf8Value &)': cannot convert argument 1 from 'v8::Local<v8::Value>' to 'const v8::String::Utf8Value &' [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(447): note: Reason: cannot convert from 'v8::Local<v8::Value>' to 'const v8::String::Utf8Value'
  c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(447): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(521): error C2660: 'v8::Value::Uint32Value': function does not take 0 arguments [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(2567): note: see declaration of 'v8::Value::Uint32Value' (compiling source file ..\src\binding.cc)
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(550): error C2660: 'v8::Value::Uint32Value': function does not take 0 arguments [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(2567): note: see declaration of 'v8::Value::Uint32Value' (compiling source file ..\src\binding.cc)
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(582): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(583): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(584): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(585): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(586): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(587): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(588): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(589): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(590): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(591): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(593): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(594): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(595): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(596): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(597): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(598): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(599): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(600): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(601): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(602): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(603): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(604): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(605): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(606): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(608): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(615): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(616): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(617): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(618): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(619): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(620): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(621): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(622): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(623): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(624): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(625): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(626): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(627): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(628): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(629): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(630): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(631): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(632): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(633): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(634): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(635): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(636): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(637): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(638): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(641): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(642): warning C4996: 'v8::Object::Set': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\.node-gyp\12.3.1\include\node\v8.h(3358): note: see declaration of 'v8::Object::Set'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(643): warning C4996: 'Nan::ForceSet': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\nan\nan_maybe_43_inl.h(117): note: see declaration of 'Nan::ForceSet'
c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\ref\src\binding.cc(644): warning C4996: 'Nan::ForceSet': was declared deprecated [C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref\build\binding.vcxproj]
  c:\users\manav-work\desktop\new folder\rust-typescript-bindgen\node_modules\nan\nan_maybe_43_inl.h(117): note: see declaration of 'Nan::ForceSet'
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:200:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\Manav-Work\Desktop\New folder\rust-typescript-bindgen\node_modules\ref
gyp ERR! node -v v12.3.1
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok

On running yarn I get this error
Could soneone please help me debug this

The ref module currently does not support Node.js 12 and would need to release a new compatible version: https://github.com/TooTallNate/ref/issues/107 and https://github.com/TooTallNate/ref/pull/114.


Reading noahmp table for parameter initialization in surface-bmi

Added three noah-mp tables: SOIL, MPTABLE (updated to the recent HRLDAS), and GENPARM, and
a module (ParameterRead.f90) including noah-mp table reading routine
NOTE: This commit just added the above files, and table reading routine has not been tied to the rest of code yet. so the code just work as before.

Since surface_bmi version is being used by the framework team, we may not want to do any new merges to that version to avoid affecting their runs.

this is obsolete (and invalid).  so closed


Default value on autocomplete and select field.

Hello there. It would be nice to have a default submittable value option on both of the following fielts:

Select
Autocomplete

@Lucasmiguelmac thank you for asking, try to do :

Check this repl  as example and make sure you install last version 1.1.2 (released today) if you try to test on your local project

@Lucasmiguelmac thank you for asking, try to do :
* Check this [repl](https://svelte.dev/repl/3a58d8a23e6f4779b1b1d0bda84a64d1?version=3.46.4)  as example and make sure you install last version 1.1.2 (released today) if you try to test on your local project

Hi. Just checked the repl. Default value wont't work if you set multiple to false. Made a fork of your repl for you to see:
https://svelte.dev/repl/7d3c145bc9ca4e659831c783f64a78e9?version=3.46.4

cannot understand what do u mean, if you want to add multiple values to field autocomplete you can do :
value: [
  {
    value: 2,
    title: "item 2",
  },
  {
    value: 4,
    title: "item 4",
  },
]

and that s what i get :

What I meant is that in autocomplete field, when you set multiple to false:

The form will look like this:

Ok then, thank you very much. So, for those in the future looking for an answer, you gotta manually set placeholder to "".


Feat/redux

Why
Adds redux store to the app so that we can store the last search result from a scan.
Related Tickets

Closes #68
Closed #69

Considerations
This does not store it across sessions, so if a user opens a new tab, it won't have the last saved results, is this something we want to add? [saving results long term might be a bit overkill]
What other things do we want to store in redux, and what things need to be stored as session cookies so they are accessible in our page loaders / actions?

This is legitimately great work. Nice job D:
I'll look more closely at the changes when I get into work tomorrow, but a quick pass through had made sense. 👏

Ok I have approved too @Acen are we good to merge or do you want more time to look it over?


[5.1] After callbacks for gate

This allows to make additional actions after receiving log result, e. g. event triggering or logging check results.
Gate::after(function($user, $ability, $result) {
    // Do some stuff
});

You missed forUser. You have to pass along the after callbacks.

@JosephSilber done

:+1:


Suggestion: Make a server only package

I was setting up a server instance for Syncplay on a server. When i attempted to install the .deb package, the hard dependency on vlc/mpv makes the package manager want to install the whole dependency chain for that (X11 server among other things).
This is really not ideal when trying to install just the server, i don't want to install X11 on a headless machine somewhere in cloud. I solved this by repackaging the deb file and removing the vlc/mpv and pyside2 dependency.
My suggestion is, that there should be a server only package so that you don't have to repackage, but still get the benefits of using a package manager.

I believe the discussion at #335 is relevant, especially the comments by @daniel-123. Linux isn't my area, but my understanding is that if someone is willing to implement and maintain support for a server-only package then they are free to make a PR. You would probably want to wait for PR #374 to be resolved before trying to make a PR implementing this feature, though.

Because you are second person to ask about this, I actually think that there is enough demand for such package to bother me enough to get around and make it.
Though like @Et0h said - we are currently right in the middle of migrating entire CI process over to different provider in #374 so this will have to wait.
Right now I'm thinking of simply making a no-gui version since that's only matter of removing dependencies and won't require any significant modification to the build script: https://github.com/Syncplay/syncplay/blob/master/travis/deb-script.sh
Last tidbit I'd mention is that server code hasn't been really touched for a good while. Only change it had in recent years is adding TLS support and that's it.

I've been looking for such thing as well!

I've been looking for such thing as well!

I made a fork of syncplay which removed all the client side code a while back. Ii isn't neat, and I changed a large chunk of the code to work with my specific use case, but it's here if you want it.

I made a fork of syncplay which removed all the client side code a while back. Ii isn't neat, and I changed a large chunk of the code to work with my specific use case, but it's here if you want it.

@Morsine @tippl I've made a pull request with server package. Could you test the results? You can download the zip with both server and full packages here: https://github.com/Syncplay/syncplay/suites/1888847905/artifacts/36933740
The package is architecture independent, so it will work on Raspberry Pi as is.

@Morsine @tippl I've made a pull request with server package. Could you test the results? You can download the zip with both server and full packages here: https://github.com/Syncplay/syncplay/suites/1888847905/artifacts/36933740
The package is architecture independent, so it will work on Raspberry Pi as is.

@daniel-123 Just tested it on my server. Works great, does not require the gui packages, starts and i'm able to connect to it. I see no issues with it.

@daniel-123 Just tested it on my server. Works great, does not require the gui packages, starts and i'm able to connect to it. I see no issues with it.

Implemented in #382

Implemented in #382


installation support

Greetings @adelevie,
This fork adds Installation support and tests
The .save test fails as we cannot send a device_token(deviceToken) that parse likes (ie. that Apple has on record as a valid and current deviceToken) - don't know how to reconcile
also, the second part fails to validate as the save doesn't "save"
cheers/jshow

This should probably should close. parse-ruby-client as an installation object.


feature(dbt projects): models and tests

It would be nice to have mocked tests that will check data mapping between API response and go-structures.

It would be nice to have mocked tests that will check data mapping between API response and go-structures.

Added. :)


Compatibility with ad

I have been trying to use this package with nonlinear-optimization and ad for maximum likelihood computations, however this is highly non-practical since distributions always return Double -> Double and ad needs some kind of polymorphic interface to work.  Are there any barriers for such a polymorphic interface?
One problem I see is the need for different contraints depending on the distribution (Erf for Normal, Num for others).

Unfortunately there are. Mostly because some distributions use functions like (incomplete) beta/gamma functions. Current implementations in math-functions are specialized to Doubles and making them generic is a lot of work.
To make matter more complicated there are also efficiency concerns. For example for incomplete beta/gamma functions derivative exist in closed form and could be calculated very cheaply without using all complicated approximations.


add lambda-github-runner to comparison chart

Hi y'all!
Thanks for this great resource. I'd love to see how lambda-github-runner stacks up!

Hi @fgregg, thanks for pointing to that solution, maybe the maintainer (or you) are interested in creating a PR here 😊

it's quite cool in concept, but the docs were incomplete in getting it set up. and once i did get it set up, my github action workflows didn't really work (various hacks need to be put in place to deal with the fact that within a lambda container you can only write to /tmp)
not an actively developed project right now, so can probably pass.

thank you for testing!


I'm not happy with the current code quality.

With the changes in #9 I'm much happier with things.


Added map Note Jump Speed to the right of BPM

Requires beatsaber-http-status v1.4.0 or later (The one released for Beat Saber 0.13.0)

Looks good, thanks!


MultiPolygon - Longitude set incorrectly

Hello,
I'm having an issue with MultiPolygons, this is the WKT that I send to the PHP to convert. If you add the WKT to the link, it shows valid polygons: Example
MULTIPOLYGON(((-121.70727129016115 47.91151164684206,-122.30053300891113 47.87099440824224,-122.45434160266113 47.64203147502187,-122.02038164172362 47.59759967271398,-121.70727129016115 47.91151164684206)),((-121.64409990344237 47.89494024438798,-121.92150468859859 47.59019070106464,-121.53423662219235 47.51789824966218,-121.64409990344237 47.89494024438798)),((-121.5754353526611 47.89494024438798,-121.46282548937984 47.549422605485006,-121.13323564562985 47.68272745792498,-121.5754353526611 47.89494024438798)))
The issue is that when converted to a MultiPolygon object the longitude (#lng) for the first point in each polygon is "0.0". Any help is appreciated.
MultiPolygon {#283
  #polygons: array:3 [
    0 => Polygon {#285
      #linestrings: array:1 [
        0 => LineString {#286
          #points: array:5 [
            0 => Point {#287
              #lat: 47.911511646842
              #lng: 0.0
            }
            1 => Point {#288
              #lat: 47.870994408242
              #lng: -122.30053300891
            }
            2 => Point {#289
              #lat: 47.642031475022
              #lng: -122.45434160266
            }
            3 => Point {#290
              #lat: 47.597599672714
              #lng: -122.02038164172
            }
            4 => Point {#291
              #lat: 47.911511646842
              #lng: -121.70727129016
            }
          ]
        }
      ]
    }
    2 => Polygon {#292
      #linestrings: array:1 [
        0 => LineString {#293
          #points: array:4 [
            0 => Point {#294
              #lat: 47.894940244388
              #lng: 0.0
            }
            1 => Point {#295
              #lat: 47.590190701065
              #lng: -121.9215046886
            }
            2 => Point {#296
              #lat: 47.517898249662
              #lng: -121.53423662219
            }
            3 => Point {#297
              #lat: 47.894940244388
              #lng: -121.64409990344
            }
          ]
        }
      ]
    }
    4 => Polygon {#298
      #linestrings: array:1 [
        0 => LineString {#299
          #points: array:4 [
            0 => Point {#300
              #lat: 47.894940244388
              #lng: 0.0
            }
            1 => Point {#301
              #lat: 47.549422605485
              #lng: -121.46282548938
            }
            2 => Point {#302
              #lat: 47.682727457925
              #lng: -121.13323564563
            }
            3 => Point {#303
              #lat: 47.894940244388
              #lng: -121.57543535266
            }
          ]
        }
      ]
    }
  ]
}

After a bit of debugging it seems some of the points start with a bracket
array:2 [
  0 => "(-121.59466142687987"
  1 => "47.756638883935466"
]

I also noticed this if you have a space after MULTIPOLYGON


[#1806] Fix number deltas not being accepted on actor sheet

This is a bug fix to bug #1806.
Changed most of the numericInput fields on the character sheet to text input.
Added regex based input validation to accommodate this into the _onChangeInputDelta function on base-sheet.mjs.
Added parsing to the property return in _onChangeInputDelta to make JS preform addition instead of concatenation.
Added a new HTML class, "delta-input", which is now what jquery looks for to determine if some input field is one that can have deltas entered.
What I discovered with some help from the discord was that certain browsers would cut off the + from an input like "+100". I made the inputs text inputs to fix this. To accommodate this I added input validation and parsing.

Perhaps, I tried to do some of those, but I will look at their files and run some updates

@Fyorl I updated this to fix actor-spellbook.hbs as per your suggestion.

@Fyorl I updated this to fix actor-spellbook.hbs as per your suggestion.

I can see there are still many places that have been converted to text input fields where it's very debateable how useful having deltas would be. For example, vehicle mishap threshold, damage threshold, and action thresholds I am almost certain would never need delta support.
Character resources are probably fine, but I don't think ability scores should have deltas even if they might be occasionally useful. Really our metric for whether a field should have delta support should be 'is this field almost exclusively updated via deltas?'. For HP, XP, and currency, I believe that's the case, but for most other fields I am doubtful.

This is fair, since you are more experienced with this codebase feel free to change some. I really missed this on currency and HP, so I can see why we might want to not have it for many things.
However I would say that ability scores are often effected by delta's. Examples being monsters that change scores, e.g. intelligence devourer, and items like books. While the math for these are not difficult, I do see this as a good source of utility.

However I would say that ability scores are often effected by delta's. Examples being monsters that change scores, e.g. intelligence devourer, and items like books. While the math for these are not difficult, I do see this as a good source of utility.

I would probably disagree with 'often'. You have to adjust HP, XP, and currency pretty much every encounter, but you don't fight Intellect Devourers or Shadows, or find Very Rare magical items every encounter by a wide margin. I can definitely understand the argument for delta-enabling ability scores though, so if you feel strongly, we can keep them in. Ultimately, the cost of having a delta-enabled field is not particularly high.

As far as I'm concerned, this is done.


Make result set getColumn by name case insensitive.  Add test for same.

Fixes #40 .  Adds unit test both for column names from resultset as well as tablename itself, since we're already there.
This uses equalsIgnoreCase rather than the previous `contentEquals,' which is ever so slightly different (String to String versus String to CharSequence/String/StringBuffer, respectively), but I think that shouldn't make a difference in these use cases.

Hi @Mause, since i run into this bug: which other class did you mean?


Map width cannot be increased when using st_folium

Hi there, I noticed that the map width doesn't change in my web app when the width argument in st_folium is modified. The height argument works well though. You may find my code to reproduce the web app below. Thank you.
import pandas as pd
import numpy as np
import json
from geopy.geocoders import Nominatim
import requests
import folium
import streamlit as st
from streamlit_folium import folium_static, st_folium

def center():
   address = 'Singapore'
   geolocator = Nominatim(user_agent="id_explorer")
   location = geolocator.geocode(address)
   latitude = location.latitude
   longitude = location.longitude
   return latitude, longitude

def tiles_func(input):

    mapping = {
        "OpenStreetMap" : "OpenStreetMap",
        "https://maps-a.onemap.sg/v3/Grey/{z}/{x}/{y}.png" : "OneMap"
    }

    output = mapping[input]

    return output

centers = center()
options = ("https://maps-a.onemap.sg/v3/Grey/{z}/{x}/{y}.png", "OpenStreetMap")

add_select = st.sidebar.selectbox(label="Choose your base map", options=options, format_func=tiles_func)

m = folium.Map(tiles=add_select, location=[centers[0], centers[1]], zoom_start=11, attr="map")
m.add_child(folium.LatLngPopup())
st.title('Map of Singapore')

data = st_folium(m, width=2000)

if data["last_clicked"] is None:
    data = ""
else:
    st.text(f'Latitude: {data["last_clicked"]["lat"]}\nLongitude: {data["last_clicked"]["lng"]}')

Unfortunately, at this point the maximum width of a bidirectional streamlit component like this is not in our control, and is limited to approximately 700px. If you set the app to wide-mode in the page config, the map is able to expand more, depending on the width of your screen.

I see, ok I'll make do with the page config for now. Thank you.


Allow using local shared libraries instead of Julia-shipped one

The following error was reported by @bgeihe when running an executable linked against a PackageCompiler-compiled libtrixi:
*** Trixi controller ***  Initialize Trixi
trixi_initialize: 'project_directory' is non-null but will not be used
fatal: error thrown and no exception handler available.
InitError(mod=:Trixi, error=ErrorException("could not load library "/home/user/install/t8code/lib/libt8.so"
/home/user/libtrixi/LibTrixi.jl/lib/build/lib/julia/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/user/install/t8code/lib/libt8.so)"))

It seems like the local installation of t8code was built against a newer version of libstdc++ (/usr/lib/libstdc++.so.6.0.32) that expects GLIBCXX_3.4.32 , while Julia's own libstdc++ (libstdc++.so.6.0.30) only provides an older variant.
The problem could be remedied by preloading the system libstdc++, i.e., by calling the executable with
LD_PRELOAD=/usr/lib/libstdc++.so.6 ./simple_trixi_controller_c ...

This seems like an issue that a) could come up at other systems as well and b) that is super annoying to solve for the users. It would therefore be great if we found a solution to
a) detect this issue during the build
b) fix this issue automatically during the build

xref https://discourse.julialang.org/t/precedence-of-local-and-julia-shipped-shared-libraries/104258

@bgeihe Can you please try to install PackageCompiler.jl from this branch
https://github.com/sloede/PackageCompiler.jl/tree/msl/bundle-dynamically-selected-libstdc%2B%2B
and see if it fixes the problem?
With this version of PC.jl, on your system with the newer version /usr/lib/libstdc++.so.6.0.32 you should end up with a build/lib/julia directory that contains the following libstdc++ names:
build/lib/julia/libstdc++.so -> libstdc++.so.6.0.32
build/lib/julia/libstdc++.so.6 -> libstdc++.so.6.0.32
build/lib/julia/libstdc++.so.6.0.32

while before you ended up with
build/lib/julia/libstdc++.so -> libstdc++.so.6.0.30
build/lib/julia/libstdc++.so.6 -> libstdc++.so.6.0.30
build/lib/julia/libstdc++.so.6.0.30

Of course, the true test would then be if you can run your programs linked against libtrixi.so without having to specify LD_PRELOAD anymore.

It works!
PackageCompiler picks up the right version

│    ├── libstdc++.so.6.0.32 - 20.516 MiB

The right library ends up in

../LibTrixi.jl/lib/build/lib/julia/libstdc++.so.6.0.32

And simple_trixi_controller_c successfully without LD_PRELOAD.
Awesome!

Awesome 👍 And thanks for verifying so quickly!
Can you also confirm that PREFIX/lib/julia contains the right symlinks as stated above?
Maybe you can add the confirmation that it works as expected yourself as a reply to https://github.com/JuliaLang/PackageCompiler.jl/pull/853#discussion_r1341936041. Otherwise, I can also let them know.

Yep! Symlinks are correct as well!

If this issue has been resolved for you @bgeihe, could you please let me know and/or close the issue?

All good!


How do I execute trace file by this?

The application trace file obtained through the pin tool, how to use  the simulator to execute this trace file. Can you give me an example? thank you!

HMC-Sim will not ingest Pin traces directly.  It is only designed to function as a backend memory simulation tool.  If you are firm in using Pin to generate traces, I would suggest using a larger infrastructure such as Sandia’s SST (http://sst-simulator.org).  This is a PDES that supports Pin as a CPU model (Ariel) and HMC-Sim as the backend memory model. This will allow you to pass cycle-driven traces from Pin to HMC-Sim


Build failure with cython 0.28

make cython, which runs python setup.py build_ext --inplace --with-cython, fails with the following errors. My environment is Arch linux with python 3.6.4, cython 0.28.1, and setuptools 39.0.1.
Compiling mxnet/cython/ndarray.pyx because it changed.
Compiling mxnet/cython/symbol.pyx because it changed.
[1/2] Cythonizing mxnet/cython/ndarray.pyx

Error compiling Cython file:
------------------------------------------------------------
...
# Licensed to the Apache Software Foundation (ASF) under one
^
------------------------------------------------------------

mxnet/cython/ndarray.pyx:1:0: 'mxnet/_cy3/.ndarray' is not a valid module name
Traceback (most recent call last):
  File "setup.py", line 108, in <module>
    ext_modules=config_cython(),
  File "setup.py", line 96, in config_cython
    return cythonize(ret)
  File "/usr/lib/python3.6/site-packages/Cython/Build/Dependencies.py", line 1026, in cythonize
    cythonize_one(*args)
  File "/usr/lib/python3.6/site-packages/Cython/Build/Dependencies.py", line 1146, in cythonize_one
    raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: mxnet/cython/ndarray.pyx

Downgrading cython to 0.27.3 resolves this but gives warnings and different errors.
Warning: Extension name 'mxnet/_cy3/.ndarray' does not match fully qualified name 'ndarray' of 'mxnet/cython/ndarray.pyx'
Warning: Extension name 'mxnet/_cy3/.symbol' does not match fully qualified name 'symbol' of 'mxnet/cython/symbol.pyx'
Compiling mxnet/cython/ndarray.pyx because it changed.
Compiling mxnet/cython/symbol.pyx because it changed.
[1/2] Cythonizing mxnet/cython/ndarray.pyx
[2/2] Cythonizing mxnet/cython/symbol.pyx
running build_ext
error: each element of 'ext_modules' option must be an Extension instance or 2-tuple

If I run python setup.py build_ext --with-cython (without --inplace), the build succeeds with cython 0.27.3.

@nswamy @sandeep-krishnamurthy please label this - "Build"

@mxnet-label-bot add [Bug]

This issue is similar to #10738 and might be fixed by #10951.

Duplicate of #10738

@Roshrini Can you please mark this bug as a duplicate of #10738 and close it. Thank you!

closing as duplicate

@mxnet-label-bot add [python]


Update visual script property selector

WIP for proposal #3528
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The search functionality of EditorHelpSearch seems more capable and understandable so I will try to implement this as a new foundation.
Implement the filters expected of both property inspectors. These filters are dependant on the input data.
Implement filters based on scope. Now only base classes are used to give results, for example when using the input class it's most likely you only want to base results on the Inheritors.
3.1 (Optional) Make filter conditions and presets extendable and overwritable by plugins. To support different programming styles
And last, when not enough solutions are provided automatically start ignoring the filters until you find solutions.
Then reimplement the creation of nodes based on the selection.
And last provide the possibility to create snippets when creating none base nodes.
6.1. Use Typecast when creating inheriter nodes.
6.2. Use HasFunction when creating unrelated nodes.
6.3. (Optional) Maybe make these sippet conditions and result extendable and overwritable by plugins. Similar to PropertyEditor

Please amend the commit log, there's one typo per word :|

Propery selecotor cahnge UI and scope variable
Update VisualScriptPropertySelector user interface.
Issues Icons not showing

Property selector change UI and scope variables
Update the VisualScriptPropertySelector user interface.
Will look into the bug when I've done my tasks and am free.

Thank you for your correction.
This push has a few errors but I wanted to show how scope is implemented.

Superseded by https://github.com/godotengine/godot/pull/56252.


json insert

hello i use mysql 8 server
in mysql doc write example - INSERT INTO t1 VALUES('{"key1": "value1", "key2": "value2"}');
i try
                let a = {"key1": "value1", "key2": "value2"}
                pool.query( 'INSERT INTO news VALUES(?)' , [a], function (error, results, fields) {
                    if (error) throw error;
                        console.log(error)
                });

dont work, how i can send data in json format?

You can find the rules for how we stringify values at https://github.com/mysqljs/mysql/blob/master/Readme.md#escaping-query-values

Objects are turned into key = 'val' pairs for each enumerable property on the object.

Which is not what you want. You need to JSON.stringify the value before passing to this lib.


experiment setting

Do you have any plan to make run.sh file?

No, but as you can see in README.MD, there is an example of shell script as follows.
python3 main.py --dataset HAPT --gpu 0 --seed 0 --lp platprob --al random --no_plat_reg 1 --temp 2.0


Plan 9 Support

Getting Billy (osfs) to build on Plan 9 is possible by adding the following:
osfs/os_plan9.go
// +build plan9

package osfs

import (
	"os"
)

func (f *file) Lock() error {
	f.m.Lock()
	defer f.m.Unlock()

	s, err := f.Stat()
	if(err != nil) {
		return err
	}

	// Add exclusive bit
	return (f.File).Chmod(s.Mode() | os.ModeExclusive)
}

func (f *file) Unlock() error {
	f.m.Lock()
	defer f.m.Unlock()

	s, err := f.Stat()
	if(err != nil) {
		return err
	}

	// Remove exclusive bit
	return (f.File).Chmod(s.Mode() & ^os.ModeExclusive)
}

I changed osfs/os_posix.go's build header to the following, but I'm not sure it's necessary:
// +build !windows,!plan9

@henesy I think Lock is supposed to block until it acquires the lock (the posix implementation doesn't use LOCK_NB with flock). Maybe we can do something similar to the lockedfile package used by cmd/go.
Go's internal/filelock package does not support Plan 9.

I'll be sending a PR for Plan 9 support soon.
It's not really possible to implement Lock/Unlock using the "exclusive use" bit:

Per http://man.cat-v.org/plan_9/5/stat: “Exclusive use files may be open
for I/O by only one fid at a time across all clients of the server. If a
second open is attempted, it draws an error.”

Since Lock is called on an open file, if we can't open a locked file in the first place, we never even get into the Lock function to wait for the file to be unlocked by the other client. I think go-billy will need to use an API similar to the lockedfile package to support file locking on Plan 9.
I got all the tests passing on Plan 9, but I found that running go test ./... hangs in TestTempFileMany and TestTempFileManyWithUtil if we're using test cache. This is possibly a go tool bug. If I run the tests with go test -count 1 ./... everything passes.


Experiencing panic/crash while obtaining yaml package dependency

Hi there.
I have an issue/bug here .
I am using gollvm - you can reproduce the bug, by installing my "release" build from here.
If someone curious about gollvm("llvm-goc") itself - you can find my build folder, compressed, out here.

This seems unrelated to the SDK, seems to be a go tooling issue.


Issue-feat: makes toggle switch edit color-mode attribute

Automated Review Comments
Issues in src/components/Header.tsx:

(5, 'Line exceeds 80 characters')
(5, 'Hardcoded string found')
(6, 'Line exceeds 80 characters')

I got it.


Format color (instead of simply print colored to stream)

PrettyPrinter version: 0.18.0
Python version: 3.7.4
Operating System: MacOS

Description
It doesn't appear that there is a cpformat-like function to format a colored string (with ansi styles, etc.). I wouldn't mind much if it weren't for the fact that user-defined classes show up as default object stubs (e.g. <SomeClass object>) and the __repr__ magic method only supports returning strings.
This makes it nearly impossible to have a nicely formatted class instance when consumed by prettyprinter.

Until this shows up in the API, you can easily create your own cpformat() function by wrapping cpprint(), redirecting it's stream output to a StringIO stream to capture it, and then returning the text as a string.
It turns out that prettyerinter's own pformat() is essentially implemented the same way internally.
Put the code below into a cprettyprinter.py file:
"""Colorized prettyprinter format

Implements cpformat() to return a colorized pretty printed formatted string.
As of 0.17.0 the prettyprinter library does not yet implement a cpformat() function.
"""
from prettyprinter import cpprint
from io import StringIO

def cpformat(object, **kwargs):
    """Return a pretty printed colorized representation of the object as a str.

    Args:
        object: The object to format.
        Any other keyword arguments supported by prettyprinter's cpprint() function.

    Returns:
        A colorized representation of the object as a str.
    """
    output = StringIO()
    cpprint(object, stream=output, **kwargs)
    return output.getvalue()

And use it like this:

Added bonus:
I always use the colorama library to create colored text in Python.  For some reason (which I haven't gotten to the bottom of) if you init colorama with colorama.init(autoreset=True) it modifies your stdout in a way that inhibits prettyerinter's cpprint() from working (i.e. the output renders uncolored).  But printing the output of cpformat() (e.g. print(cpformat(my_object)) ) successfully renders in color even when colorama's autoreset is enabled.

Until this shows up in the API, you can easily create your own cpformat() function by wrapping cpprint(), redirecting it's stream output to a StringIO stream to capture it, and then returning the text as a string.
It turns out that prettyerinter's own pformat() is essentially implemented the same way internally.
Put the code below into a cprettyprinter.py file:
"""Colorized prettyprinter format

Implements cpformat() to return a colorized pretty printed formatted string.
As of 0.17.0 the prettyprinter library does not yet implement a cpformat() function.
"""
from prettyprinter import cpprint
from io import StringIO

def cpformat(object, **kwargs):
    """Return a pretty printed colorized representation of the object as a str.

    Args:
        object: The object to format.
        Any other keyword arguments supported by prettyprinter's cpprint() function.

    Returns:
        A colorized representation of the object as a str.
    """
    output = StringIO()
    cpprint(object, stream=output, **kwargs)
    return output.getvalue()

And use it like this:

Added bonus:
I always use the colorama library to create colored text in Python.  For some reason (which I haven't gotten to the bottom of) if you init colorama with colorama.init(autoreset=True) it modifies your stdout in a way that inhibits prettyerinter's cpprint() from working (i.e. the output renders uncolored).  But printing the output of cpformat() (e.g. print(cpformat(my_object)) ) successfully renders in color even when colorama's autoreset is enabled.


ETV eating up all swap & RAM in about 24 hours

I run ETV in an Ubuntu 22.04 LXC on a Proxmox machine, the same LXC I use for my Jellyfin server and which ran happily for weeks with 2 CPUs, 2 GB RAM and nearly zero swap.
Now I thought I’d give it a little more room for ETV and increased to 4 CPUs and 4 GB RAM. When running ETV, swap gets filled and sticks at 100% rather fast, and within ~24 hours all available RAM gets used. I increased again to 6 CPUs and 6 GB RAM, which are now after almost a day also used up.

Health Check:

I suspect some memory leak, since the container ran just fine with Jellyfin over weeks (and with only 2 CPUs and 2 GB RAM).
If it helps, I had the Jellyfin AndroidTV client running for a few hours on my TV. Now I have disconnected all streaming clients and the RAM usage has dropped by ~1 GB, CPUs from 16% to 0.04%. I’ll leave it like this for a few more hours and see if it also increases when no clients are streaming. (The stream for the last 3 hours was a flooding 30s fallback video loop with a 80% size and 70% opacity watermark on it.)
Any way I can help diagnosing this and get back to normal? I mean, a media and TV server should be able to run for years, or—considering updates—at least months without bringing the server to a halt after only a day…
ETV is 0.8.2-beta-docker-vaapi and runs fine except the memory and swap issue.
I use this docker-compose.yml:
version: '3'
services:
  app:
    image: 'jasongdove/ersatztv:latest-vaapi'
    restart: unless-stopped
    ports:
      - '8409:8409'
    environment:
      TZ: 'Europe/Berlin'
      'Bugsnag:Enable': 'false'
    devices:
      - '/dev/dri/card0:/dev/dri/card0'
      - '/dev/dri/renderD128:/dev/dri/renderD128'
    volumes:
      - ./config:/root/.local/share/ersatztv
      - /mnt/media/Videos/Elements:/mnt/media/Videos/Elements

Some more info in case it turns out being relevant:
Machine: HP Z230 Workstation
CPU: 8 x Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (1 Socket)
$ vainfo
error: can't connect to X server!
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Desktop - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD

(Of course it can't find an X server on a headless system. But it looks like I could use i965 instead of the default driver. Capabilities.)

Selecting the appropriate driver for hardware acceleration is a good first step! Some other changes I would recommend:

Use a tmpfs (ram disk) mount for the transcode folder
Use docker to enforce a memory limit on ETV. I use 4G but you can certainly experiment with lower values.

    tmpfs:
      - /root/.local/share/etv-transcode
    deploy:
      resources:
        limits:
          memory: 4G

Thread Count should be overridden by ETV back down to 1 when hardware acceleration is used, since many of those components don't support threading, but it wouldn't hurt to set to 1 in the ffmpeg profile.
I would also watch for source content that is encoded with HEVC/H265 since your GPU does not support decoding that content, it will always be done in software/CPU. It also doesn't support encoding HEVC, so it's a good decision to leave the video format in the ffmpeg profile set to h264.

@jasongdove Thanks for coming back on this!

tmpfs: I’m not too much into Docker (yet), what does the path specify? A folder in the host? Where else would I need to set things?
Mem limit sounds like a good idea, didn’t know how to do that. Assuming my currently 6 GB, and leaving some room for Jellyfin, would you think 3 GB ok? (The actual hardware only has 32 GB, and there are some resource-hungry VMs running already.)
ffmpeg thread count: It originally was set to 0 and (before using VAAPI) it ate all my CPUs, so I wanted to play safe. I can confirm that it now always only uses 1 thread (when using VAAPI). If it doesn’t block other things, I’ll set it to 1 now.
H265: Yep, unfortunately the hardware can’t do that. Would be nice to save bandwith but I opted for H264 since it’s much faster. Fortunately, this was also a decision I made some time ago for my sources, so most of them are actually H264. Nevertheless, I do have a few that are in H265. As I understand it, decoding should still be… well, okay…, and I’m encoding to H264 anyway.

Could we agree that you check for any possible mem leaks, and I set ffmpeg threads to 1, add the docker mem limit and tmpfs and come back with testing results here?
I started a playout again after changing to the i965 driver (so ETV will actually do something), and already see mem usage slowly increasing again (swap full). Love the heavily decreased CPU load!

The tmpfs path is within the container and where etv already (temporarily) places transcoding output. No other configuration beyond what I pasted is needed.

Cool, thanks! (I read it up in the Docker docs in the meantime.)
My current docker-compose.yml now looks like this:
version: '3'
services:
  app:
    image: 'jasongdove/ersatztv:latest-vaapi'
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 3G
    tmpfs:
      - /root/.local/share/etv-transcode
    ports:
      - '8409:8409'
    environment:
      TZ: 'Europe/Berlin'
      'Bugsnag:Enable': 'false'
    devices:
      - '/dev/dri/card0:/dev/dri/card0'
      - '/dev/dri/renderD128:/dev/dri/renderD128'
    volumes:
      - ./config:/root/.local/share/ersatztv
      - /mnt/media/Videos/Elements:/mnt/media/Videos/Elements

(Let me know if enabling the Bugsnag makes any sense for debugging this. I’m not against it, just think I’d like to enable it only if problems occur.)
The immediate result looks promising but I’ll keep watching it:

This is transcoding one stream with the settings I mentioned, and Jellyfin running in the same LXC, streaming to my browser, and also transcoding again using the same VAAPI.

Bugsnag is not needed.

This is transcoding one stream with the settings I mentioned, and Jellyfin running in the same LXC, streaming to my browser, and also transcoding again using the same VAAPI.

This will often/always be the case when streaming using an intermediate media server like Jellyfin, Emby or Plex, even more so when the final client is a browser.
ETV transcodes (normalizes) content to be in a consistent format as input to the media servers (like "real" IPTV channels). The media servers then transcode for compatibility with their clients.
One way to avoid the second transcode is to use an IPTV client like TiviMate or Kodi (IPTV Simple Client) and point it directly to ETV.

Yep, I noticed Jelly is notorious in re-encoding to browsers. A good test for server load anyway ;-)
It’s much better when using KODI or the Jellyfin Desktop Media Player:

I’m back to giving ETV 4 out of 8 GB RAM, which seems to work well. Swap goes to 100% at times, and takes a long time (like half a day) to go back, but everything works so far.
Let’s close this for now.


Make the UI for setting a bot as an incoming webhook bot more fancy/self-explanatory

As part of #5082, we added a basic dropdown menu for making it possible to set a bot as an incoming webhook, with limited permissions to only send messages.
I think it's probably worth doing a pass at making that look really nice, keeping in mind that we'll eventually have at least 4 choices:

Incoming webook
Outgoing webhook (with sub-options for format)
Generic bot
Embedded bot (with sub-options for which one)

@zulipbot claim

@zulipbot claim

@zulipbot abort

claim

@zulipbot claim

@zulipbot claim
I'm with a pending PR waiting to be merged, so I would like to work on this meanwhile :)

@zulipbot claim

claim

@zulipbot claim

Is there more I should do for this issue? Happy to make any kinds of changes based on feedback, thanks!

@joseph-dewitt oops, so the problem here was that you didn't post a comment on the PR when you updated it to address the last comment; as a result, nobody knew that you'd done so.
Please in the future always post a GitHub comment when you're ready for a new review; GitHub does not have a reliable mechanism for inferring whether you're ready for another review if you just push changes to a PR.

@timabbott Hi Tim! Thanks for clearing that up for me, appreciate it. I'm comment in the PR when it's ready for review again.

Still working on it

@zulipbot claim

@zulipbot claim

@timabbott Can you please tell me know about the remaining work on this issue?

Currently Working on this !

@zulipbot claim

I'll like to work on this issue.
@zulipbot claim

@zulipbot claim

I think the current UI is fine, and we should just link to a reference page in the help center.
Closing in favor of #27047.


I've read through all the documentation / examples and still don't understand how to use this plugin.

Maybe it's just me but I don't find that the Usage section or documentation is very intuitive. Perhaps it needs clarification or I'm just dense. I'm using PIXIJS 6.2.1.
Here's the specific things I found confusing:

Readme:
"Nothing will work if you dont create Stage and set it as root. Please do it or read full explanation."

My thought: Ok but doesn't the standard app (const app = new PIXI.Application();) have a Stage attached as app.stage by default? So does this mean I need to create a new one, like app.stage = new PIXI.display.Stage() or what? This doesn't even work, I get the error: Uncaught TypeError: Cannot read properties of undefined (reading 'Stage')

Readme:

import { Layer } from '@pixi/layers'

let layer = new Layer();

A DisplayObject/Container can be rendered inside its layer instead of direct parent
bunnySprite.parentLayer = layer;

My thought: Ok then all I have to do is create a single global layer and assign a reference to it on every sprite in my scene like sprite.parentLayer = layer. Then, according to the readme I should set layer.group.enableSort = true; and then I can just do:
layer.group.on('sort', function onWillSort(sprite) {
    sprite.zOrder = sprite.y
});

So I tried that and nothing happened. My app didn't break, but onWillSort didn't get triggered (I added a console log inside to check).

So at this point I'm looking through all the examples for references to a complete set of working code, so I open up https://pixijs.io/examples/#/plugin-layers/zorder.js
My thought: But wait, none of the code in here references anything the Readme's Usage section showed. new Layer() isn't called anywhere, there's not even an import of '@pixi/layers', so how is the plugin attached? Is there some external thing I have to do to initiate the plugin or what? This example left me confused.

So I went back to the Readme to re-read and see if I missed something. I notice "{@link Layer} extends {@link PIXI.Container}:".
My thought: Oh so I use this just like a Container instance, so maybe I need to do something like:
const globalLayer = new Layer();
const app = new PIXI.Application();
app.stage.addChild(globalLayer)
globalLayer.group.on('sort', function onWillSort(sprite) {
    sprite.zOrder = sprite.y
});

... and assign globalLayer (like sprite.parentLayer = globalLayer) to any sprites that get added to any child of globalLayer or its children. And then any Container instances I add as a child of globalLayer  will have support for layers. Nope. Now nothing is rendering, and no errors either.
I don't know about everyone else, but I am seriously missing something here. I wish there was a single simple example that shows from start to finish how to use the plugin. Or maybe there is and I just don't get it or missed something.

For point 3:

But wait, none of the code in here references anything the Readme's Usage section showed. new Layer() isn't called anywhere, there's not even an import of '@pixi/layers', so how is the plugin attached?

I see (search for keyword "layer" there) :
Example Code (plugins used: pixi-layers)

...

// This is demo of pixi-layers.js, https://github.com/pixijs/pixi-layers
// Drag the rabbits to understand what's going on

...

// Drag is the best layer, dragged element is above everything else
const dragGroup = new PIXI.display.Group(2, false);

...

// PixiJS v5 sorting - works on zIndex - and layer gets its zIndex from a group!
app.stage.sortableChildren = true;
// sorry, group cant exist without layer yet :(;
app.stage.addChild(new PIXI.display.Layer(greenGroup));
app.stage.addChild(new PIXI.display.Layer(blueGroup));
app.stage.addChild(new PIXI.display.Layer(dragGroup));
app.stage.addChild(new PIXI.display.Layer(shadowGroup));

so instead of new Layer() there is: new PIXI.display.Layer(greenGroup) etc

Also about: how is the plugin attached? - see:
https://github.com/pixijs/examples/blob/main/examples/manifest.json#L519-L525
https://github.com/pixijs/examples/blob/main/src/js/pixi-examples.js#L66
so is a logic of this "Pixi examples" website which loads plugins required for specific examples.
Of course for your project you can do it differently and simpler.
Here is some random working example i found - it has "import" usage etc. It was written for pixi v4 but i converted it to pixi v6: https://codesandbox.io/s/stupefied-marco-cwjji?file=/src/index.js
Some notes:

look at usage of words "layer" and "group"
try changing values of monicaGroupZIndex or mainGroupZIndex to change order of Groups / Layers
If you see things like new PIXI.display.Stage or PIXI.display.Layer or PIXI.display.Group  in other examples then you will now know to use it like this instead:

import { Layer, Group, Stage } from "@pixi/layers";
...
app.stage = new Stage();
...
const monicaGroup = new Group(monicaGroupZIndex, true);
...
const monicaLayer = new Layer(monicaGroup);

If you create a layer, and assign element.parentLayer = layer - element will be rendered the same time as layer. That's it, nothing more. Everything else is optional.
Group is only needed if you have multiple stages and you want to make global variable, you dont need it.
Sorting is needed only if you dont sort characters yourself or through pixi mechanism.
useRenderTexture is needed if you understand how layering, renderTextures and filters work.

If you create a layer, and assign element.parentLayer = layer - element will be rendered the same time as layer. That's it, nothing more. Everything else is optional.
Group is only needed if you have multiple stages and you want to make global variable, you dont need it.
Sorting is needed only if you dont sort characters yourself or through pixi mechanism.
useRenderTexture is needed if you understand how layering, renderTextures and filters work.

I'm following but it doesn't seem to be working for me, what stupid mistake am I making?
https://i.gyazo.com/4a1357bdab6729f3d3062e2ff5ac421c.png
You'll notice I use require rather than import (it's an Electron.js application) but I logged the classes out so you could see they're imported correctly.

you didnt add layer here. The whole point is "element is rendered like its a child of layer". If layer is not in stage, well, when do you want to render this thing?

you didnt add layer here. The whole point is "element is rendered like its a child of layer". If layer is not in stage, well, when do you want to render this thing?

I see my mistake. Now it works perfectly. I missed that in the examples because I thought PIXI.display.Layer was a native PIXI construct rather than a construct of your plugin. I would still suggest that a basic working example would be appropriate on the Usage section of the Readme. It might help others not have the same confusion. Perhaps everyone else understood it and I'm just slow.
Anyhow, thanks for your help. @domis86 Thank you too, it was your example that cleared up some things for me.

For the record, this barely impacts my performance at all, and after spending 12 hours straight trying to achieve the same outcome, resulting in terrible performance, I have incredible appreciation and respect for what you guys have done with this program.

OK, so now performance is ok?

Yes, however you guys did it, it seems to be efficient.

Pixi layers work the same way people usually do it. It has one linear visitor, so it can be slow at 10000 elements or so. If you dont sort stuff - its efficient :)
Also, if you have 100 characters , each has one shadow, one hpbar, one body, e.t.c. , all you have to do is enable pixi sort with zIndex, and contents of characters will be distributed to layers according to that sort - only 100 elements instead of 300

Pixi layers work the same way people usually do it. It has one linear visitor, so it can be slow at 10000 elements or so. If you dont sort stuff - its efficient :)

I thought the main point of the project was to be able to sort things (with a container independent zIndex that PIXI wouldn't normally allow you to)?

Also, if you have 100 characters , each has one shadow, one hpbar, one body, e.t.c. , all you have to do is enable pixi sort with zIndex, and contents of characters will be distributed to layers according to that sort - only 100 elements instead of 300

Are you basically saying that when the contents of a container doesn't require global zIndexing, and could be handled with normal PIXI zIndex sorting, I can enable standard PIXI zIndexing for that container? Like if I set container.sortableChildren = true on a container, this plugin can handle the container more efficiently?

structure:
container->
char1 -> hpbar1, shadow1, body1
char2 -> hpbar2, shadow2, body2
you can enable sort on container with zIndex, for example char1 and char2 will switch places.
If you enable layers,
layer Shadow will contain shadow2, shadow1
layer hpbar - hpbar2 , hpbar1
layer body - body2, body1
because container has order of children char2, char1, because pixi sorted it

structure: container-> char1 -> hpbar1, shadow1, body1 char2 -> hpbar2, shadow2, body2
you can enable sort on container with zIndex, for example char1 and char2 will switch places.
If you enable layers, layer Shadow will contain shadow2, shadow1 layer hpbar - hpbar2 , hpbar1 layer body - body2, body1 because container has order of children char2, char1, because pixi sorted it

I think I understand.
If I'm close to publishing my game a year from now and have any performance issues how about I just hire you for a week or two to make PIXI layer optimizations lol.


Rallying Call

Changelog

#176
#185
#175

Rallying Call

Leads the company in a glorious charge, inspiring them to greater feats of tenacity and determination.
Grants 125% movement, 4 DV and 50% morale loss for 12 seconds (subject to change)

Lucius Ajam

Reduced Awakened AV from 46 to 44
Max mana lowered from 50 to 40
Mana regen lowered from 2 to 1
Gains Rallying Call at Restored (replaces Courage)

Kyran Delroba

Gains Max mana 40, mana regen 1 and Rallying Call at Restored

If we are restricting this to Kyran for now, It would help his initial charge/flanking efforts at enlightened pretty well!
He's a rather boring Melee kohan with a niche of being decent at flanking archers. (essentially a scout kohan if you want to use his personal stats as they match his speed and he won't get targeted down super fast)
He could be used with more micro on infantry comps to stack his DV buff as it comes up but the duration won't help much and most units will be at minimal damage vs Channel cleric. The bonus MS for engaging would be nice in that circumstance.
Super flexible spell does a little of everything, but not for long.
Strongest I imagine when used with Super scouts or Dragoons (short dragoons even as a secondary to your main force)
Sound effect is nice.


Strange behavior of Path.relative_to

Path.relative_to work wrong
It always add redundant ../ to the top of result path
So here is a test code fir simplest trivial case.
This code also work same wrong way if call .expand(home: true) to both target and base
BASE = Path.["~/.profile"]
TARGET = Path.["~/.aliases"]

puts "#{BASE} #{TARGET.relative_to(BASE)}"

So my result is:
~/.profile ../.aliases

According documentation here normalized paths base.join(target.relative_to(base)) is equivalent to target.
But it's clearly visible what ~/.aliases not equal to ../.aliases
Anyway lets check it with test code from documentation
BASE = Path.["~/.profile"]
TARGET = Path.["~/.aliases"]

puts "base: #{BASE}\ntarget:#{TARGET}\n#{BASE.join(TARGET.relative_to(BASE))}"

Result is
base: ~/.profile
target:~/.aliases
~/.profile/../.aliases

So again ~/.profile/../.aliases is not the same as ~/.aliases
My environment
$ crystal -v
Crystal 1.0.0 (2021-03-22)

LLVM: 11.1.0
Default target: x86_64-apple-macosx

I didn't get it. ~/.profile/../.aliases is the same as ~/.aliases.

The docs only say "equivalent to", not "same as"; there is Path#normalize which should get what you want.

The behaviour is correct and intended.
The relative path from ~/.profile to ~/.aliases is ../.aliases. Joining that to the original base results in ~/.profile/../.aliases which is equivalent to ~/.alisases. It's not literally the same as the original target on purpose. .profile/.. may or may not be equivalent to .. Removing it could potentially result in a different path if symbolic links are involved. So it's not redundant but essential for correctness.
Path values are purely virtual and not connected to any file system, so there's no way to check if that would be the case. If you want a normalized path, just call Path#normalize on the result.

Here is example why I suppose it it incorrect
May be theoretically it is, but in practice not - it is not the same file. At least existing behavior doing it useless. I expect programming language should resolve real tasks.

So may be this relative_to only work with directories where such behavior is correct?
BASE = Path.["~/"]
TARGET = Path.["~/.config/neovim"]

puts "base: #{BASE}\ntarget:#{TARGET}\n#{BASE.join(TARGET.relative_to(BASE))}"

Result is correct:
base: ~/
target:~/.config/neovim
~/.config/neovim

But when used with regular files it work wrong way

Path values are purely virtual and not connected to any file system, so there's no way to check if that would be the case. If you want a normalized path, just call Path#normalize on the result.

So in this case I expect relative_to methods should be moved to Dir module, where it has some meaning, to avoid confusion.

@HertzDevil The docs only say "equivalent to", not "same as"; there is Path#normalize which should get what you want.
@straight-shoota If you want a normalized path, just call Path#normalize on the result.

Yes - it work. Thanks!

Hmm about Path#normalize yes - it work well, but normalize not the result i want - I need relative path. Real relative path.
My task was to move file from one folder to another
For example:
BASE = Path.["~/.config/neovin/init.vim"]
TARGET = Path.["~/.vim/init.vim"]

puts "#{BASE} -> #{TARGET.relative_to(BASE)}"

So I am calculating relative path and this path pointing to place up to one level of desired.
~/.config/neovin/init.vim -> ../../../.vim/init.vim
Yes -  Path#normalize resolved it but from point of view of my shell this path is incorrect.

@straight-shoota
Removing it could potentially result in a different path if symbolic links are involved. So it's not redundant but essential for correctness.

Irony of situation is what I got an issue trying to symlink files and found it in wrong place (up to one directory).

You probably need to call Path#expand on both the base and the target before using #relative_to, while paying attention to the working directory.

You probably need to call Path#expand on both the base and the target before using #relative_to, while paying attention to the working directory.

Tested it with no difference. The only difference is regular file or directory. Last part of path always designated as directory and for such assumption this behavior is correct. But for regular file it is great confusion.
Just checked Ruby equivalent - there relative path calculation work same way as crystal.

So may be this relative_to only work with directories where such behavior is correct?

Kind of, yes. When resolving a path relative to another one, it is assumed that the base path is traversable.
I suspect you might actually be looking to build a path relative to the base's parent path when the base is a file.


How do I set a diagonal hatch style when using canvas mode?

In my project I have to have L_PREFER_CANVAS = true to allow leaflet-image.  On my maps, I'm styling a layer with an option of fillColor: 'url(#diagonalHatch)'.  This works great when I don't have L_PREFER_CANVAS, but I need that set for leaflet-image.  When I have it as true, that styled area on the map layer becomes solid black with no styling.  Is there an alternative way to get a diagonal hatch styling or something similar?
Original:

Using canvas:

Hi, great to hear that you find Leaflet useful!
However, this issue tracker is used for reporting bugs and discussing new features. For questions on using Leaflet, please use gis.stackexchange.com or stackoverflow.

@IvanSanchez , you could consider it a bug then - cause it's not working with fillColor and having L_PREFER_CANVAS = true set.  I can open a new issue if that's preferred.

I don't consider it a bug, as the documentation doesn't say anywhere that you can use fillColor to use a pattern.
Feel free to open a new issue for a feature request (and this time please avoid language such as "In my project I need to have" or "How can I do...?").
It is certainly doable, as the documentation for CanvasRenderingContext2D.fillStyle allows for instances of CanvasPattern to be used. If and how to implement that (and whether we want to have that in the leaflet core, and how to deal with the asynchrony of loading images, and how to deal with CORS exceptions) should be up for discussion in the feature request. And obviously pull requests would be welcome.

@IvanSanchez, I think this must be a matter of semantics with the definition of "bug" then.  The documentation just says it can use a string, so it's fairly ambiguous in that sense.  If the code allows it's usage and responds correctly, but then doesn't in some circumstances, that sounds like the definition of a bug to me...
Ultimately I just want to know ways to get that sort of styling when using the mode of canvas.


RunnerLogs repeat lines infinitly

Microsoft PowerToys version
0.57.2
Running as admin

[X] Yes

Area(s) with issue?
General
Steps to reproduce
I don't know what i did, I just wanted to let you know this could happen.
PowerToysReport_2022-04-30-15-15-22.zip
✔ Expected Behavior
Logs wouldn't grow infinitly and clear themselves
❌ Actual Behavior
Powertoys wrote 32GB of logs that only consist of repeating these lines:
[2022-04-28 00:00:00.004015] [p-1568] [t-19640] [warning] GetShellWindow() returned null. Shell window is not available
[2022-04-28 00:00:00.004016] [p-1568] [t-19640] [warning] Scheduled restart failed. Trying restart as admin as fallback...
[2022-04-28 00:00:00.016416] [p-5156] [t-9496] [info] runner logger is initialized
[2022-04-28 00:00:00.016425] [p-5156] [t-9496] [info] Running powertoys with cmd args: --dont-elevate
[2022-04-28 00:00:00.016756] [p-5156] [t-9496] [info] apply_general_settings: {}
[2022-04-28 00:00:00.016761] [p-5156] [t-9496] [info] Scheduling restart as non elevated
[2022-04-28 00:00:00.016799] [p-5156] [t-9496] [info] run_non_elevated with params=--dont-elevate

(Screenshot of WinDirStat)
Other Software
No response

@jaimecbernardo thought this was fixed in .2

Thought it was after .2 🤔

This was after .2
@GrimJu You can delete the logs. When you restart the machine, does it keep writing the logs like that?

/dup #17720


Victor VosMottor: Watch +31 6 86014004

Victor VosMottor requests the watch of the watch_number +31 6 86014004. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Spevacus in Charcoal HQ

Approved by Spevacus in Charcoal HQ


Remove debugger statement

Looks like a debugger statement slipped in to master as part of cc6e127e.
Fixes #14244.

I went ahead and reverted the offending commit since it included some other changes I didn't intend to make. I'm juggling multiple copies of atom/atom due to the Electron upgrade and got careless.


Ensure single jupyter extension works for both Stable and Insider VS Code builds

I don't think we need this. What is the work to do?


Packaging for Firefox?

Hey Forbes, I love using your extension, though Google have made changes to chrome that mean it's no longer a browser I feel good about using. I did a bit of research, and it looks like your extension is pretty much entirely compatible with Firefox (the only warning is on the icon size).
Would you be open to publishing to the Firefox Addons directory too? I saw #6, and respect that.
If you're not open to doing the publication, would you be okay with me doing the publication, as I'd like to continue using this extension.

There's also a porting guide here: https://extensionworkshop.com/documentation/develop/porting-a-google-chrome-extension/


Supporting Mixtral model

Could you provide some guidance on how to extend your results to the Mixtral model?

Thank you for your interest. We believe that our codes will work with Mixtral as well with little modifications, as we only make changes to the attention module. Here are the parts that need to be checked in the code:

src/model.py

In this file, we attach LoRA to the model and expand the embedding. Modifications may be needed to adapt this part to the Mixtral model.

src/arch/ccm_llama.py

Memory components need to be added to the model function. Specifically, you need to add compression parts and adjust positional encoding appropriately. We have marked the changed parts in the file.

We plan to release the code applied to Mixtral in the near future, so you can look forward to it!

Hello!
We now support the Mistral model! (Check out the setup in the README.)
In the case of Mixtral, we are not able to test it in our computing environment.
You can refer to src/arch/ccm_mistral.py and make a modification for the use of Mixtral.


current editor default theme is too dark and not constrasted ennough

Hi,
I don't know how it is for other Godot users, but at long, current theme is becoming very painful for my eyes when I'm working in a room with natural lighting from windows.
I think current theme is more adapted to work in dark rooms.
Would it be possible to :

make a slightly better contrasted theme that would be more adapted for both illuminated and dark rooms ?
or add an option to switch between several themes ?
or apply a pixel-shader script that would allow users to tweak theme contrast and hue in real time ?

after 1.1, will be working on a new theme
On Wed, Mar 18, 2015 at 10:40 AM, UsernameIsAReservedWord <
<EMAIL_ADDRESS>wrote:

Hi,
I don't know how it is for other Godot users, but at long, current theme
is becoming very painful for my eyes when I'm working in a room with
natural lighting from windows.
I think current theme is more adapted to work in dark rooms.
Would it be possible to :

make a slightly better contrasted theme that would be more adapted
for both illuminated and dark rooms ?
or add an option to switch between several themes ?
or apply a pixel-shader script that would allow users to tweak theme
contrast and hue in real time ?

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1524.

--
OkamStudio

Personal suggestion (if it's not already the case), keep old purple and current dark theme along with the new theme you will work on, this will let the user choose what they prefer in a few clicks.

@okamstudio: After 1.1 you also work on a new GUI. Will it be written in GDScript and in the GUI-Builder and in Godot itself or like until now in C++?
/tools/editor/editor_node.cpp (EditorNode) and /tools/editor/project_manager.cpp (ProjectManager) are already components, which can be used in Godot and for which existing an icon for the first one in the GUI designer (/tools/editor/icons/icon_editor_node.png). But it would be nice to create both in Godot itself. Then the GUI can also easier improved. Modifying the GUI is then not more, then moving the controls of the GUI in the GUI Builder.

It will remain to be in C++ ( I honestly like to use C++ for tools), but
completely extensible in GDScript. Most of this work is done, but it needs
clean up and documentation.
On Wed, Mar 18, 2015 at 12:38 PM, theuserbl<EMAIL_ADDRESS>wrote:

@okamstudio https://github.com/okamstudio: After 1.1 you also work on a
new GUI. Will it be written in GDScript and in the GUI-Builder and in Godot
itself or like until now in C++?
/tools/editor/editor_node.cpp (EditorNode) and
/tools/editor/project_manager.cpp (ProjectManager) are already components,
which can be used in Godot and for which existing an icon for the first one
in the GUI designer (/tools/editor/icons/icon_editor_node.png). But it
would be nice to create both in Godot itself. Then the GUI can also easier
improved. Modifying the GUI is then not more, then moving the controls of
the GUI in the GUI Builder.
—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1524#issuecomment-83024347.

What's the status regarding the integration of @ndee85's theme? Is it completed already?
And if so, is it better contrasted now, or are there still things we could improve?

The theme introduced in 2.0 solves the dark problem. There may be new themes for future versions, but I think this issue is solved.

I'm working on a new screen and into a different room, and current theme is okay.
If no one objects, I agree to close this issue.
Though, applying some sort of pixel-shader to the editor's theme to tweak contrast and hue could be a cool feature to add.

Closing as per above comments. The editor can also be themed now, and it will be possible to share themes in the asset sharing platform :)


More directions on the arrows

Add more directions to the arrows, like the diagonals.

One suggestion, try to create a generic function to create the arrows in all directions. I see in the code the directions are hard-coded.

I have worked on the generation of arrows in more directions in the Painter part (program process that generates the images that are shown in the HTML and md) here I show the result:

Note: The end user will not yet be able to create arrows in these directions, for that it will be necessary to wait for the update by @vmms, who will include this function directly in the user interface.
You can find the detail on the following code: https://github.com/SlicerLatinAmerica/TutorialMaker/blob/painter/enrique-code/TutorialMaker/Lib/painter.py

I will close this issue, once we have another issue opened for that improvement and now the extensions already have more directions to drow the arrow.


Hack Day Phosim CPU time prediction via machine learning

Don't merge yet.  We will do it at 4:30 pm-ish today.

Thanks a lot, Humna, Tom, and Phil.  I was impressed how far the analysis got today, and I think I learned a lot.  I have not deleted the branch - Humna noted several points for further development on issue #178, and David Kirkby posted a notebook showing how to calculate the sky brightness for a given filter, airmass, and moon altitude, phase, and angular distance; the CPU time ought to correlate quite closely with the sky brightness.  David's notebook also shows how to connect to an Opsim database to extract information about the observations.  Actually, for the Run 1 runs we are looking at here, someone has already done that and posted a csv file here.


Add new VMEMORY attribute to do overcommitment as VCPU

Author Name: Tino Vázquez (Tino Vázquez)
Original Redmine Issue: 1328, https://dev.opennebula.org/issues/1328
Original Date: 2012-07-03

VMEMORY would be used for the hypervisor, MEMORY for the scheduler.

Original Redmine Comment
Author Name: Ruben S. Montero (@rsmontero)
Original Date: 2013-05-09T13:40:14Z

Duplicate


D435i camera stop working with my apllication

Required Info

Camera Model
D435i

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10

Platform
PC

SDK Version
{ librealsense 2.36.0 }

Language
{C++ }

Segment
{Robot/Smartphone/VR/AR/others }

Issue Description
I got a realsense D435i camera. It works perfectly until the beginning of this week. Now my app cannot connect to camera but when I open RealSense Viewer I can get images from camera.
Also if I try to run hello-realsense from rs-examples.sln the program '[15112] hello-realsense.exe' has exited with code 1 (0x1). But if i try to run rs-hello-realsense.exe it work.
I already try to reinstall RealSense SDK
Do you have any idea how to solve it?

If i run hello-realsense.exe which I was built from rs-examples.sln it doesn't work.
It gives me this error:
C:\Program Files (x86)\Intel RealSense SDK 2.0\bin\x64>align.exe -c RealSense error calling rs2_pipeline_wait_for_frames(pipe:00000263C25E9A10):     Frame didn't arrive within 15000