text:
[HIPIFY] link error to Clang-9

CMakeFiles/hipify-clang.dir/src/ArgParse.cpp.o: In function _GLOBAL__sub_I_ArgParse.cpp': ArgParse.cpp:(.text.startup+0xe8): undefined reference to vtable for llvm::cl::OptionValuestd::string'
ArgParse.cpp:(.text.startup+0xf3): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> >' ArgParse.cpp:(.text.startup+0xfe): undefined reference to vtable for llvm::cl::parserstd::string'
ArgParse.cpp:(.text.startup+0x224): undefined reference to vtable for llvm::cl::OptionValue<std::string>' ArgParse.cpp:(.text.startup+0x22f): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parserstd::string >'
ArgParse.cpp:(.text.startup+0x23a): undefined reference to vtable for llvm::cl::parser<std::string>' ArgParse.cpp:(.text.startup+0x5b1): undefined reference to vtable for llvm::cl::OptionValuestd::string'
ArgParse.cpp:(.text.startup+0x5bc): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> >' ArgParse.cpp:(.text.startup+0x5c7): undefined reference to vtable for llvm::cl::parserstd::string'
ArgParse.cpp:(.text.startup+0x6d3): undefined reference to vtable for llvm::cl::OptionValue<std::string>' ArgParse.cpp:(.text.startup+0x6de): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parserstd::string >'
ArgParse.cpp:(.text.startup+0x6e9): undefined reference to vtable for llvm::cl::parser<std::string>' ArgParse.cpp:(.text.startup+0x7f5): undefined reference to vtable for llvm::cl::OptionValuestd::string'
ArgParse.cpp:(.text.startup+0x800): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> >' ArgParse.cpp:(.text.startup+0x80b): undefined reference to vtable for llvm::cl::parserstd::string'
ArgParse.cpp:(.text.startup+0x917): undefined reference to vtable for llvm::cl::OptionValue<std::string>' ArgParse.cpp:(.text.startup+0x922): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parserstd::string >'
ArgParse.cpp:(.text.startup+0x92d): undefined reference to vtable for llvm::cl::parser<std::string>' ArgParse.cpp:(.text.startup+0x1381): undefined reference to vtable for llvm::cl::OptionValuestd::string'
ArgParse.cpp:(.text.startup+0x138c): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parser<std::string> >' ArgParse.cpp:(.text.startup+0x1397): undefined reference to vtable for llvm::cl::parserstd::string'
ArgParse.cpp:(.text.startup+0x1707): undefined reference to vtable for llvm::cl::parser<std::string>' ArgParse.cpp:(.text.startup+0x185f): undefined reference to vtable for llvm::cl::parserstd::string'
ArgParse.cpp:(.text.startup+0x1abb): undefined reference to vtable for llvm::cl::OptionValue<std::string>' ArgParse.cpp:(.text.startup+0x1ac6): undefined reference to vtable for llvm::cl::opt<std::string, false, llvm::cl::parserstd::string >'
ArgParse.cpp:(.text.startup+0x1ad1): undefined reference to vtable for llvm::cl::parser<std::string>' CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o: In function HipifyAction::cudaSharedIncompleteArrayVar(clang::ast_matchers::MatchFinder::MatchResult const&)':
HipifyAction.cpp:(.text+0x2924): undefined reference to clang::QualType::getAsString() const' HipifyAction.cpp:(.text+0x2b4a): undefined reference to clang::DeclarationName::getAsString() const'
CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o: In function HipifyAction::cudaDeviceFuncCall(clang::ast_matchers::MatchFinder::MatchResult const&)': HipifyAction.cpp:(.text+0x3181): undefined reference to clang::DeclarationName::getAsString() const'
CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o: In function HipifyAction::cubNamespacePrefix(clang::ast_matchers::MatchFinder::MatchResult const&)': HipifyAction.cpp:(.text+0x32f3): undefined reference to clang::DeclarationName::getAsString() const'
CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o: In function HipifyAction::cubUsingNamespaceDecl(clang::ast_matchers::MatchFinder::MatchResult const&)': HipifyAction.cpp:(.text+0x341c): undefined reference to clang::DeclarationName::getAsString() const'
CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o: In function HipifyAction::cubFunctionTemplateDecl(clang::ast_matchers::MatchFinder::MatchResult const&)': HipifyAction.cpp:(.text+0x35c3): undefined reference to clang::DeclarationName::getAsString() const'
CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o:HipifyAction.cpp:(.text+0x3765): more undefined references to clang::DeclarationName::getAsString() const' follow CMakeFiles/hipify-clang.dir/src/HipifyAction.cpp.o: In function clang::ast_matchers::hasName(std::string const&)':
HipifyAction.cpp:(.text._ZN5clang12ast_matchers7hasNameERKSs[_ZN5clang12ast_matchers7hasNameERKSs]+0x62): undefined reference to clang::ast_matchers::internal::HasNameMatcher::HasNameMatcher(std::vector<std::string, std::allocator<std::string> >)' CMakeFiles/hipify-clang.dir/src/LLVMCompat.cpp.o: In function llcompat::getReplacements(clang::tooling::RefactoringTool&, llvm::StringRef)':
LLVMCompat.cpp:(.text+0x20): undefined reference to clang::tooling::RefactoringTool::getReplacements()' CMakeFiles/hipify-clang.dir/src/main.cpp.o: In function appendArgumentsAdjusters(clang::tooling::RefactoringTool&, std::string const&, char const*)':
main.cpp:(.text+0x1cd8): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)' main.cpp:(.text+0x1ce3): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocatorstd::string > (std::vector<std::string, std::allocatorstd::string > const&, llvm::StringRef)>)'
main.cpp:(.text+0x1d0c): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)' main.cpp:(.text+0x1d17): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocatorstd::string > (std::vector<std::string, std::allocatorstd::string > const&, llvm::StringRef)>)'
main.cpp:(.text+0x1dd8): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)' main.cpp:(.text+0x1de3): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocatorstd::string > (std::vector<std::string, std::allocatorstd::string > const&, llvm::StringRef)>)'
main.cpp:(.text+0x1e0c): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)' main.cpp:(.text+0x1e17): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocatorstd::string > (std::vector<std::string, std::allocatorstd::string > const&, llvm::StringRef)>)'
main.cpp:(.text+0x1ea0): undefined reference to llvm::sys::fs::getMainExecutable(char const*, void*)' main.cpp:(.text+0x1f00): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x1f0b): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x1f41): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x1f4c): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x1f82): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x1f8d): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x1fc3): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x1fce): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x2018): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2023): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x2059): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2064): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x209a): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x20a5): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x20db): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x20e6): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x2130): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x213b): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x21de): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x21e9): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x221d): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2228): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x225e): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2269): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x22a8): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x22b3): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x22e9): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x22f4): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x2377): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2382): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x241c): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2427): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x2474): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x247f): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x24b2): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x24bd): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x24f9): undefined reference to clang::tooling::getInsertArgumentAdjuster(char const*, clang::tooling::ArgumentInsertPosition)'
main.cpp:(.text+0x2504): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' main.cpp:(.text+0x252a): undefined reference to clang::tooling::getClangSyntaxOnlyAdjuster()'
main.cpp:(.text+0x2535): undefined reference to clang::tooling::ClangTool::appendArgumentsAdjuster(std::function<std::vector<std::string, std::allocator<std::string> > (std::vector<std::string, std::allocator<std::string> > const&, llvm::StringRef)>)' CMakeFiles/hipify-clang.dir/src/main.cpp.o: In function main':
main.cpp:(.text+0x2e1c): undefined reference to clang::tooling::CompilationDatabase::loadFromDirectory(llvm::StringRef, std::string&)' main.cpp:(.text+0x4a86): undefined reference to clang::tooling::RefactoringTool::RefactoringTool(clang::tooling::CompilationDatabase const&, llvm::ArrayRefstd::string, std::shared_ptrclang::PCHContainerOperations)'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [hipify-clang] Error 1
make[1]: *** [CMakeFiles/hipify-clang.dir/all] Error 2
make: *** [all] Error 2

Could you please provide a command line for CMake? Clang is of 9.0.0 or 9.0.1 version? Was it built or installed from the package? What is the target OS?

Thank you for your reply!
*1. *On Centos 7,  Clang is 9.0.1 version and CUDA si 10.1,  the command
line for llvm + clang as follows:
cmake
-DLLVM_ENABLE_PROJECTS=clang
-DCMAKE_INSTALL_PREFIX=../dist
-DLLVM_SOURCE_DIR=../llvm
-DCMAKE_BUILD_TYPE=Release
../llvm
and  for HIPIFY, the command line for CMake as follows:
cmake
-DHIPIFY_CLANG_TESTS=1
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=../dist
-DCMAKE_INSTALL_PREFIX=/home/summit/llvm-project/build/bin
-DCMAKE_PREFIX_PATH=/home/summit/llvm-project/dist
-DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda-10.1
-DLLVM_EXTERNAL_LIT=/home/summit/llvm-project/build/bin/llvm-lit
..
and when "make hipify-clang", The error (linker error)  is as I described
on Github.
Evgeny Mankov notifications@github.com 于2020年11月10日周二 下午5:39写道：

Could you please provide a command line for CMake? Clang is of 9.0.0 or
9.0.1 version? Was it built or installed from the package? What is the
target OS?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ROCm-Developer-Tools/HIPIFY/issues/219#issuecomment-724585166,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKJ4BZRFQXF2T4DQ5BAWGU3SPEC4HANCNFSM4TPMBCUA
.

-DLLVM_ENABLE_PROJECTS=clang shouldn't be used for building LLVM < 10 (in case of being used by hipify-clang). Please see https://github.com/ROCm-Developer-Tools/HIPIFY#-hipify-clang-testing, section LLVM 9.0.1 or older. I consider this is the root cause. I think that LLVM should be rebuilt from scratch.
To minimize the building time, please use -DLLVM_TARGETS_TO_BUILD="X86;NVPTX" as only these targets are used by hipify-clang.
And, btw, in hipify-clang's cmake cmd. line the first -DCMAKE_INSTALL_PREFIX will be overwritten by the second one.

Thank you for your reply! According to your suggestion, I made changes to
the relevant command line. However, it also failed. Details as follows:
1. In order to be exactly the same as the example in Github（the
example  of building hipify-clang with testing support on Ubuntu 20.04.1 at
github), I changed my system environment to ubuntu 20.04;
*2. The CUDA version is 11.0 and also make the LLVM + Clang 11.0, the CMame
command line as follows: *
cmake
-DCMAKE_INSTALL_PREFIX=../dist
-DLLVM_SOURCE_DIR=../llvm-project
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX"
-DLLVM_ENABLE_PROJECTS="clang"
-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DCMAKE_BUILD_TYPE=Release
../llvm-project/llvm
make -j install
3. Then, I have building hipify-clang with testing support on Ubuntu
20.04, the Cmake command line as follows:
cmake
-DHIPIFY_CLANG_TESTS=1
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=../dist
-DCMAKE_PREFIX_PATH=/home/summit/llvm-project/dist
-DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda-11.0
-DCUDA_DNN_ROOT_DIR=/usr/local/cuda-11.0
-DCUDA_CUB_ROOT_DIR=/home/summit/software/cub
-DLLVM_EXTERNAL_LIT=/home/summit/llvm-project/build/bin/llvm-lit
..
At this point, the result shows is no problem. As follows:

The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LLVM 11.0.0:
--    - CMake module path: /home/summit/llvm-project/dist/lib/cmake/llvm
--    - Include path     : /home/summit/llvm-project/dist/include
--    - Binary path      : /home/summit/llvm-project/dist/bin
-- Linker detection: GNU ld
-- Found PythonInterp: /home/summit/anaconda2/bin/python2.7 (found
suitable version "2.7.16", minimum required is "2.7")
-- Found lit: /home/summit/anaconda2/bin/lit
-- Found FileCheck: /home/summit/HIPIFY/dist/bin/FileCheck
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found CUDA: /usr/local/cuda-11.0 (found version "11.0")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/summit/HIPIFY/build

*4. while, when "make test-hipify ", It failed. The 66 test all
failed, the output results are similar, as follows: *
[100%] Running HIPIFY regression tests
CUDA 11.0 - will be used for testing
LLVM 11.0.0 - will be used for testing
x86_64 - Platform architecture
Linux 5.4.0-52-generic - Platform OS
64 - hipify-clang binary bitness
64 - python 2.7.16 binary bitness
-- Testing: 66 tests, 8 workers --
FAIL: hipify :: unit_tests/headers/headers_test_02.cu (1 of 66)
******************** TEST 'hipify ::
unit_tests/headers/headers_test_02.cu' FAILED ********************
Script:
: 'RUN: at line 1';   "/home/summit/HIPIFY/tests/run_test.sh"
"/home/summit/HIPIFY/build/hipify-clang"
"/home/summit/HIPIFY/tests/unit_tests/headers/headers_test_02.cu"
"/home/summit/HIPIFY/build/unit_tests/headers/Output/headers_test_02.cu.tmp"
"--cuda-path=/usr/local/cuda-11.0" -v
-DTHRUST_IGNORE_CUB_VERSION_CHECK
-isystem'/usr/local/cuda-11.0'/samples/common/inc -D__LP64__
-I'/usr/local/cuda-11.0'/include -I'/home/summit/software/cub'
Exit Code: 127
Command Output (stdout):
$ ":" "RUN: at line 1"
$ "/home/summit/HIPIFY/tests/run_test.sh"
"/home/summit/HIPIFY/build/hipify-clang"
"/home/summit/HIPIFY/tests/unit_tests/headers/headers_test_02.cu"
"/home/summit/HIPIFY/build/unit_tests/headers/Output/headers_test_02.cu.tmp"
"--cuda-path=/usr/local/cuda-11.0" "-v"
"-DTHRUST_IGNORE_CUB_VERSION_CHECK"
"-isystem/usr/local/cuda-11.0/samples/common/inc" "-D__LP64__"
"-I/usr/local/cuda-11.0/include" "-I/home/summit/software/cub"
command stderr:
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/summit/HIPIFY/build
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
Found CUDA installation: /usr/local/cuda-11.0, version 11.0
warning: Unknown CUDA version 11.0. Assuming the latest supported
version 10.1 [-Wunknown-cuda-version]
clang Invocation:
"/home/summit/HIPIFY/build/clang-tool" "-cc1" "-triple"
"x86_64-unknown-linux-gnu" "-target-sdk-version=11.0" "-aux-triple"
"nvptx64-nvidia-cuda" "-fsyntax-only" "-disable-free"
"-disable-llvm-verifier" "-discard-value-names" "-main-file-name"
"headers_test_02.cu-c61974.hip" "-mrelocation-model" "static"
"-mframe-pointer=all" "-fmath-errno" "-fno-rounding-math"
"-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64"
"-fno-split-dwarf-inlining" "-debugger-tuning=gdb" "-v"
"-resource-dir" "/home/summit/llvm-project/dist/lib/clang/11.0.0"
"-internal-isystem"
"/home/summit/llvm-project/dist/lib/clang/11.0.0/include/cuda_wrappers"
"-internal-isystem" "/usr/local/cuda-11.0/include" "-include"
"__clang_cuda_runtime_wrapper.h" "-isystem"
"/usr/local/cuda-11.0/samples/common/inc" "-I"
"/home/summit/HIPIFY/tests/unit_tests/headers" "-D"
"THRUST_IGNORE_CUB_VERSION_CHECK" "-D" "LP64" "-I"
"/usr/local/cuda-11.0/include" "-I" "/home/summit/software/cub"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward"
"-internal-isystem" "/usr/local/include" "-internal-isystem"
"/home/summit/llvm-project/dist/lib/clang/11.0.0/include"
"-internal-externc-isystem" "/usr/include/x86_64-linux-gnu"
"-internal-externc-isystem" "/include" "-internal-externc-isystem"
"/usr/include" "-internal-isystem" "/usr/local/include"
"-internal-isystem"
"/home/summit/llvm-project/dist/lib/clang/11.0.0/include"
"-internal-externc-isystem" "/usr/include/x86_64-linux-gnu"
"-internal-externc-isystem" "/include" "-internal-externc-isystem"
"/usr/include" "-Wno-pragma-once-outside-header" "-std=c++11"
"-fdeprecated-macro" "-fdebug-compilation-dir"
"/home/summit/HIPIFY/build/unit_tests/headers" "-ferror-limit" "19"
"-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions"
"-internal-isystem" "/home/summit/HIPIFY/build/include/cuda_wrappers"
"-internal-isystem" "/home/summit/HIPIFY/build/include" "-faddrsig"
"-x" "cuda" "/tmp/headers_test_02.cu-c61974.hip"
clang -cc1 version 11.0.0 based upon LLVM 11.0.0 default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
ignoring nonexistent directory "/include"
ignoring nonexistent directory "/home/summit/HIPIFY/build/include/cuda_wrappers"
ignoring nonexistent directory "/home/summit/HIPIFY/build/include"
ignoring duplicate directory "/usr/local/cuda-11.0/include"
as it is a non-system directory that duplicates a system directory
ignoring duplicate directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory
"/home/summit/llvm-project/dist/lib/clang/11.0.0/include"
ignoring duplicate directory "/usr/include/x86_64-linux-gnu"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/home/summit/HIPIFY/tests/unit_tests/headers
/home/summit/software/cub
/usr/local/cuda-11.0/samples/common/inc
/home/summit/llvm-project/dist/lib/clang/11.0.0/include/cuda_wrappers
/usr/local/cuda-11.0/include
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward
/usr/local/include
/home/summit/llvm-project/dist/lib/clang/11.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
/home/summit/HIPIFY/tests/run_test.sh: line 30: FileCheck: command not found
sed: couldn't flush stdout: Broken pipe
error: command failed with exit status: 127
--
Evgeny Mankov notifications@github.com 于2020年11月11日周三 上午12:55写道：

-DLLVM_ENABLE_PROJECTS=clang shouldn't be used for building LLVM < 10 (in
case of being used by hipify-clang). Please see
https://github.com/ROCm-Developer-Tools/HIPIFY#-hipify-clang-testing,
section LLVM 9.0.1 or older. I consider this is the root cause. I think
that LLVM should be rebuilt from scratch.
To minimize the building time, please use
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX" as only these targets are used by
hipify-clang.
And, btw, in hipify-clang's cmake cmd. line the first
-DCMAKE_INSTALL_PREFIX will be overwritten by the second one.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ROCm-Developer-Tools/HIPIFY/issues/219#issuecomment-724830643,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKJ4BZRU3CBSAUIPPPTEYL3SPFV73ANCNFSM4TPMBCUA
.

Well, it is yet another story. You successfully built hipify-clang by GCC 9.3, but against clang 11. I believe with clang 9 all would also be successful with a correct cmake command line for building LLVM.
As for your new issue with FileCheck according to the README.md you should do one of the following:

Linux: copy from /usr/llvm/11.0.0/build/bin/ to CMAKE_INSTALL_PREFIX/dist/bin
Or specify the path to FileCheck in CMAKE_INSTALL_PREFIX option

Btw, for using hipify-clang with CUDA > 11.0, the patch for clang 11.0.0 should be applied to LLVM, and then LLVM should be rebuilt (not necessarily from scratch).

well, in fact, the file of "FileCheck" was found in step 3 , "-- Found
FileCheck: /home/summit/HIPIFY/dist/bin/FileCheck", while when "make
test-hipify", it report " FileCheck: command not found", this confused me.
Evgeny Mankov notifications@github.com 于2020年11月11日周三 下午6:57写道：

Well, it is yet another story. You successfully built hipify-clang by GCC
9.3, but against clang 11. I believe with clang 9 all would also be
successful with a correct cmake command line for building LLVM.
As for your new issue with FileCheck according to the README.md
https://github.com/ROCm-Developer-Tools/HIPIFY#-hipify-clang-testing
you should do one of the following:

Linux: copy from /usr/llvm/11.0.0/build/bin/ to
CMAKE_INSTALL_PREFIX/dist/bin
Or specify the path to FileCheck in CMAKE_INSTALL_PREFIX option

Btw, for using hipify-clang with CUDA > 11.0, the patch for clang 11.0.0
https://github.com/ROCm-Developer-Tools/HIPIFY/blob/master/patches/patch_for_clang_11.0.0_bug_47332.zip
should be applied to LLVM, and then LLVM should be rebuilt (not necessarily
from scratch).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ROCm-Developer-Tools/HIPIFY/issues/219#issuecomment-725355389,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKJ4BZTB3JYTE22NFGP67ZDSPJUZTANCNFSM4TPMBCUA
.

Nonetheless, the fact is that "FileCheck: command not found". Please, check your FileCheck existence.

Thank you!  It is true that the path of FileCheck is wrong. After I
corrected it, I got the correct test result like the README. But for my
project application, I need your help in three aspects:

How to deal with the header files in the project during conversion,
whether to add a path, can you give an example.
I used the texture memory of NVIDIA in my project, and the thrust of
CUDA, whether these two cases do not support conversion.
Can the entire folder be converted as a whole? (The file in the folder
includes C++ code and CUDA code).

Evgeny Mankov notifications@github.com 于2020年11月11日周三 下午11:48写道：

Nonetheless, the fact is that "FileCheck: command not found". Please,
check your FileCheck existence.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ROCm-Developer-Tools/HIPIFY/issues/219#issuecomment-725498878,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKJ4BZT7YP5ABKNYDACBLSDSPKW3BANCNFSM4TPMBCUA
.

If the issue is resolved, let's close it.

To take into account header files set -I option to the containing folder.
Which kind of conversions are not supported by HIP/hipify-clang? Please, file a different issue.
Yes, it can be converted at once. Use hipconvertinplace-perl.sh script for that purpose.

authors: HWang-Summit emankov

repo: ROCm-Developer-Tools/HIPIFY


text:
[Issue]: AMD Clang - Warnings

Problem Description
Switch to AMD Clang++ creates a few warnings
[  7%] Building CXX object amd_openvx/openvx/CMakeFiles/openvx.dir/ago/ago_haf_cpu_color_convert.cpp.o
/home/kiriti/develop/mivisionx-kiriti/MIVisionX/amd_openvx/openvx/ago/ago_drama_alloc.cpp:771:141: warning: result of comparison of constant 2 with expression of type 'vx_direction_e' is always false [-Wtautological-constant-out-of-range-compare]
  771 |                     if (it == superNodeInfo->inputList.end() && (node->parameters[i].direction == VX_INPUT || node->parameters[i].direction == VX_BIDIRECTIONAL))
      |                                                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~
/home/kiriti/develop/mivisionx-kiriti/MIVisionX/amd_openvx/openvx/ago/ago_drama_alloc.cpp:774:143: warning: result of comparison of constant 2 with expression of type 'vx_direction_e' is always false [-Wtautological-constant-out-of-range-compare]
  774 |                     if (it == superNodeInfo->outputList.end() && (node->parameters[i].direction == VX_OUTPUT || node->parameters[i].direction == VX_BIDIRECTIONAL))
      |                                                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~

[ 14%] Building CXX object amd_openvx/openvx/CMakeFiles/openvx.dir/api/vxu.cpp.o
/home/kiriti/develop/mivisionx-kiriti/MIVisionX/amd_openvx/openvx/ago/ago_interface.cpp:2297:101: warning: result of comparison of constant 2 with expression of type 'vx_direction_e' is always false [-Wtautological-constant-out-of-range-compare]
 2297 |                         (node->parameters[i].direction == VX_INPUT || node->parameters[i].direction == VX_BIDIRECTIONAL))
      |                                                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~
/home/kiriti/develop/mivisionx-kiriti/MIVisionX/amd_openvx/openvx/ago/ago_interface.cpp:2376:105: warning: result of comparison of constant 2 with expression of type 'vx_direction_e' is always false [-Wtautological-constant-out-of-range-compare]
 2376 |                             (node->parameters[i].direction == VX_INPUT || node->parameters[i].direction == VX_BIDIRECTIONAL))
      |                                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~
/home/kiriti/develop/mivisionx-kiriti/MIVisionX/amd_openvx/openvx/ago/ago_interface.cpp:2405:113: warning: result of comparison of constant 2 with expression of type 'vx_direction_e' is always false [-Wtautological-constant-out-of-range-compare]
 2405 |                         if (data && (node->parameters[i].direction == VX_INPUT || node->parameters[i].direction == VX_BIDIRECTIONAL)) {
      |                                                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~
/home/kiriti/develop/mivisionx-kiriti/MIVisionX/amd_openvx/openvx/ago/ago_interface.cpp:2461:106: warning: result of comparison of constant 2 with expression of type 'vx_direction_e' is always false [-Wtautological-constant-out-of-range-compare]
 2461 |                             (node->parameters[i].direction == VX_OUTPUT || node->parameters[i].direction == VX_BIDIRECTIONAL))
      |

Operating System
ALL
CPU
ALL
GPU
AMD Instinct MI300
Other
No response
ROCm Version
ROCm 6.0.0
ROCm Component
MIVisionX
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

Fixed by #1459

@hansely reopen new pr

source: gharchive/issue

authors: hansely kiritigowda

repo: ROCm/MIVisionX

license: MIT

license_type: permissive

license_source: github-api


text:
Do I need --parallel-kernels option for multi-kernel on multi-device scenario?

Hello,
I am using concurrent kernel execution on multi-GPU system using multi-stream (see code example below).
Example:
for(i = 0; i < GPU_N; i++)
{
....
//Set device
hipSetDevice(i);
launch_addKernel(&A_d[start], &B_d[start], &C_d[start], size, 1, 1, streams[i]);
....
}

I want to collect some performance statistics while these kernels are running concurrently with rocprof. Do I still have to use --parallel-kernels option to ensure concurrent kernel execution?
command with --parallel-kernels
rocprof --parallel-kernels -i in-prof2.txt -o ./output.csv ./vector_add

I believe in this case the kernels will be running concurrently even without "--parallel-kernels" since each kernel run on a separate device. Am I correct? I believe --parallel-kernels is needed when concurrent kernels are running on a single device to avoid serialization. But, in case of, multi-device, it should support concurrent kernels by default since each kernel launched on a sperate device.
If the answer is NO, and I have to use "--parallel-kernels" in case of multi-device, then I have a runtime error when I run on multi-GPU MI210. The error is:
Memory access fault by GPU node-6 (Agent handle: 0xec22d0) on address 0x14ab000. Reason: Unknown.
/usr/bin/rocprof: line 297: 788934 Aborted                 (core dumped)

Any help, please?

@mabdallah89 Apologies for the lack of response. Do you still need assistance with this issue? Thanks!

@mabdallah89 No longer requires assistance on this ticket and agrees to close the ticket. Thanks!

repo: ROCm/rocprofiler


text:
Implement ONNX Operator ConstantOfShape

Needed for some recent model support requests. The original models are from TensorFlow. The tf2onnx tool indicates that the TF Operator "isNAN" has paths that call ONNX Operator ConstantOfShape

we already have support for this

repo: ROCmSoftwarePlatform/AMDMIGraphX


text:
Tidy warning with new version

Warning: boolean expression can be simplified by DeMorgan's theorem [readability-simplify-boolean-expr,-warnings-as-errors]
if(not((padding.size() == stride.size() or (padding.size() / 2) == stride.size()) and
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!=               &&                      !=                ||
Warning: boolean expression can be simplified by DeMorgan's theorem [readability-simplify-boolean-expr,-warnings-as-errors]
if(not(input_size == padding_size / 2 + 2 or input_size == padding_size + 2))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!=                      &&            !=
CMake Error at tidy-target-test_verify-_data_test_verify_test_max_pooling_ceil_3d_cpp.cmake:80 (message):
Clang tidy failed.

This same warning hits many files.


text:
[MLIR] Disable gfx900 from non-xdlops solver

Per request according to https://github.com/ROCmSoftwarePlatform/llvm-project-private/issues/389
I made the following changes:

Bump MLIR commit to the ROCm 5.1 release commit
Disable gfx900 from non-xdlops solvers
Disable gfx900 from ctest

Split MIOPEN_TEST_VEGA to MIOPEN_TEST_GFX900 and MIOPEN_TEST_GFX906
Add GFX900_DISABLED to test_conv_igemm_mlir*

All this is ready for review.
@JehandadKhan Just FYI, this PR needs to be in by Janauary 5th before you are to tune MLIR solvers for ROCm 5.1.

Let's merge this after all PRs necessary for 5.0 are merged in.

source: gharchive/pull-request

authors: atamazov jerryyin

repo: ROCmSoftwarePlatform/MIOpen

license: mit

license_source: bigquery


text:
Split LDS optimization

Furthering #1214's development, this patch boosts performance when DepthULdsDivisor > 1, meaning during accumulation loop you want to split the data intended for writing into LDS by a factor of DepthULdsDivisor

Schedule load instructions in the unroll loop earlier
Improves performance in higher occupancy kernel via s_setpro in appropriate places
Extends support for int8/fp32c/fp64
Fix kernel generation when DepthULdsDivisor = 4

rocblas-test on gfx908 passed

@imcarsonliao please get this peer-reviewed.  Thanks.

CI errors seem to be associated with hw or runtime. Merging.
...
0,0/27,2/19,Contraction_mn_Amijkn_Bmlnk_Cijkl_Dijkl,"(5,3,32,16,120,8)",Cijkl_Amijkn_Bmlnk_S_MT64x128x4_SN_ASEM4_GSU1_K1_PBD0_PSD1,PASSED,862.834,17.0897,,0.00732422,0.5,64,0.234375,0.125,0.5,0.5,86400,30720,35,852,960,945,0,1,2021-06-25 06:21:20.010009
0,0/27,3/19,Contraction_mn_Amijkn_Bmlnk_Cijkl_Dijkl,"(5,3,32,16,120,8)",Cijkl_Amijkn_Bmlnk_S_MT64x128x4_SN_ASEM4_GSU1_K1_PBD1_PSD1,PASSED,863.13,17.0839,,0.00732422,0.125,64,0.9375,0.125,0.125,0.5,86400,30720,35,852,960,945,0,1,2021-06-25 06:21:20.014947
Exception occurred: Error 400(hipErrorInvalidHandle) /tmp/.tensile-tox/py36/lib/python3.6/site-packages/Tensile/Source/client/source/BenchmarkTimer.cpp:213:
hipEventElapsedTime( &enqTime, startEvents->at(i).front(), stopEvents->at(i).back())
hipErrorInvalidHandle

authors: rosenrodt zaliu

repo: ROCmSoftwarePlatform/Tensile


text:
Component system, and Navi10 FP16 non-HPA

This introduces a component system to the code generator.  A component is a piece of code that is chosen among compatible components based on the current hardware capabilities and/or kernel options.
The class hierarchy is automatically used to detect which type of component a given class belongs to.  For example, all the MAC components should inherit from the MAC class.
Most components should be able to get away with defining their requirements via the class properties (e.g.):
class FMA_NonPacked(MAC):
    asmCaps = {"v_fma_f16": True,
               "v_pk_fma_f16": False}
    #archCaps = {}
    kernel = {"ProblemType": {"DataType": DataType(DataType.half),
                              "HighPrecisionAccumulate": False}}

Values in the dictionaries can be lambdas for more advanced logic:
class FMA_HPA_MAD_MIX(MAC):
    asmCaps = {"v_mad_mix_f32": True}
    #archCaps = {}
    kernel = {"ProblemType": {"DataType": DataType(DataType.half),
                              "HighPrecisionAccumulate": True},
              "LocalDotLayout": lambda ldl: ldl > 1
             }

Any more advanced logic should be implemented by overriding the matches() method.
Components are found by calling Component.<subtype>.find(writer) where writer is a KernelWriter object:
    component = Component.MAC.find(self)
    if component:
      return component(self, m, innerUnroll)

    # No component was found, fall back to existing code...

With this fallback mechanism, components can be added one at a time.
Components can be categorized in different files in the Tensile/Components directory.
Feedback is encouraged.  I believe this will help make the KernelWriter files much easier to read and maintain.

I added a [flake8] section to tox.ini, which is another place where it can be configured.

authors: leekillough sdquiring


text:
Dramatic difference in perf between 1080ti and VEGA FE

Hey there,
I'm trialing some code to benchmark my VEGA vs a colleagues 1080ti.
I've noticed some very peculiar differences in time to fit per epoch, I'm guessing I'm messing up in some way.
For one epoch on AMD 2990WX ~400 seconds
For one epoch on 1080ti  < 100s
For one epoch on VEGA FE > 40 minutes

Hi @Dekken , could you help fill the issue template so we can understand the issue better?
https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/blob/develop-upstream/.github/ISSUE_TEMPLATE/00-bug-performance-issue.md

Have I written custom code: yes
OS Platform and Distribution: Linux Ubuntu 18
TensorFlow installed from source
TensorFlow version: ROCm dev
Python version: 3.7
Bazel version: .21
GCC/Compiler version 8.2
ROCm/MIOpen version: latest from xenial repo
GPU model and memory: VEGA FE 16GB
== cat /etc/issue ===============================================
Linux ws156 4.18.0-15-generic #16-Ubuntu SMP Thu Feb 7 10:56:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
VERSION="18.10 (Cosmic Cuttlefish)"
VERSION_ID="18.10"
VERSION_CODENAME=cosmic

== are we in docker =============================================
No

== compiler =====================================================
c++ (Ubuntu 8.2.0-7ubuntu1) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

== uname -a =====================================================
Linux ws156 4.18.0-15-generic #16-Ubuntu SMP Thu Feb 7 10:56:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

== check pips ===================================================
numpy                    1.16.1
numpydoc                 0.8.0
protobuf                 3.6.1
tensorflow               1.12.0
tensorflow-estimator     1.13.0rc0

== check for virtualenv =========================================
False

== tensorflow import ============================================
Limited tf.compat.v2.summary API due to missing TensorBoard installation
tf.VERSION = 1.12.0
tf.GIT_VERSION = merge-190218-2-gd5532be4
tf.COMPILER_VERSION = merge-190218-2-gd5532be4
Sanity check: array([1], dtype=int32)

== env ==========================================================
LD_LIBRARY_PATH is unset
DYLD_LIBRARY_PATH is unset

== nvidia-smi ===================================================
./sys.sh: line 105: nvidia-smi: command not found

== cuda libs  ===================================================

Thanks @Dekken , first I'd suggest is to try our docker image, the goal is to isolate the issue to either user-bit configurations or kernel drivers/firmware.
Can you refer to the following comment and get us the perf results of resnet50?
https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/issues/173#issuecomment-465871004

I'd rather not install docker if it's ok
TF_ROCM_FUSION_ENABLE=1 python3 tf_cnn_benchmarks.py --num_gpus=1 --batch_size=128 --model=resnet50

Done warm up
Step    Img/sec total_loss
1       images/sec: 207.5 +/- 0.0 (jitter = 0.0)        7.972
10      images/sec: 207.0 +/- 0.2 (jitter = 1.1)        7.856
20      images/sec: 206.8 +/- 0.2 (jitter = 0.5)        7.914
30      images/sec: 206.8 +/- 0.2 (jitter = 0.5)        7.734
40      images/sec: 206.8 +/- 0.1 (jitter = 0.6)        7.969
50      images/sec: 206.7 +/- 0.1 (jitter = 0.5)        8.025
60      images/sec: 206.7 +/- 0.1 (jitter = 0.6)        7.896
70      images/sec: 206.8 +/- 0.1 (jitter = 0.6)        7.991
80      images/sec: 206.8 +/- 0.1 (jitter = 0.6)        7.816
90      images/sec: 206.8 +/- 0.1 (jitter = 0.5)        7.799
100     images/sec: 206.7 +/- 0.1 (jitter = 0.6)        7.821
----------------------------------------------------------------
total images/sec: 206.71
----------------------------------------------------------------

TF_ROCM_FUSION_ENABLE=1 python3 tf_cnn_benchmarks.py --num_gpus=1 --batch_size=128 --model=resnet50 --use_fp16
Step    Img/sec total_loss
1       images/sec: 198.6 +/- 0.0 (jitter = 0.0)        7.878
10      images/sec: 198.8 +/- 0.3 (jitter = 1.1)        7.958
20      images/sec: 199.3 +/- 0.2 (jitter = 0.6)        7.949
30      images/sec: 199.3 +/- 0.2 (jitter = 0.6)        7.948
40      images/sec: 199.4 +/- 0.1 (jitter = 0.7)        7.967
50      images/sec: 199.4 +/- 0.1 (jitter = 0.7)        7.706
60      images/sec: 199.4 +/- 0.1 (jitter = 0.7)        7.923
70      images/sec: 199.4 +/- 0.1 (jitter = 0.6)        7.849
80      images/sec: 199.4 +/- 0.1 (jitter = 0.5)        7.969
90      images/sec: 199.3 +/- 0.1 (jitter = 0.5)        7.810
100     images/sec: 199.3 +/- 0.1 (jitter = 0.6)        7.785
----------------------------------------------------------------
total images/sec: 199.25
----------------------------------------------------------------

Hmm, the perf numbers look normal for Vega FE workstation card.
Can we have scripts/steps to repro your perf issue?

my test case is about 30GB, I'll see if I can minimize it, it's not mine

for sake of completeness, there's a 6GB archive available here https://hephaistos.lpp.polytechnique.fr/data/jeandet/dekken.tgz
extract and run test.py
CPU only runs into segfaults mind yuou

Thanks @Dekken , let me try it out.

mine with i76950x
CUDA_VISIBLE_DEVICES="" python3 test.py
Epoch 1/10
/home/philix/.local/lib/python3.7/site-packages/keras/engine/training_utils.py:481: UserWarning: Found both `sample_weight` and `class_weight`: `class_weight` argument will be ignored.
  warnings.warn('Found both `sample_weight` and `class_weight`: '
2019-02-21 22:28:37.008764: E tensorflow/stream_executor/rocm/rocm_driver.cc:1020] could not retrieve ROCM device count: HIP_ERROR_NoDevice
10229/10229 [==============================] - 205s 20ms/step - loss: 0.0491 - val_loss: 0.0161
Epoch 2/10
10229/10229 [==============================] - 204s 20ms/step - loss: 0.0383 - val_loss: 0.0141
Epoch 3/10
10229/10229 [==============================] - 204s 20ms/step - loss: 0.0348 - val_loss: 0.0137
Epoch 4/10
10229/10229 [==============================] - 203s 20ms/step - loss: 0.0330 - val_loss: 0.0123
Epoch 5/10
10229/10229 [==============================] - 203s 20ms/step - loss: 0.0317 - val_loss: 0.0118
Epoch 6/10
 7636/10229 [=====================>........] - ETA: 49s - loss: 0.0307Segmentation fault (core dumped)

@Dekken , can you post the log without CUDA_VISIBLE_DEVICES=""?
The environment variable works similarly to HIP_VISIBLE_DEVICES, with that being set, tensorflow-rocm won't be able to see or use any GPUs.

the normal log is what takes 40+ minutes per epoch - so I'd rather not do that completely
2019-02-21 23:01:58.296943: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1673] Adding visible gpu devices: 0, 1
2019-02-21 23:01:58.296970: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1084] Device interconnect StreamExecutor with strength 1 edge matrix:
2019-02-21 23:01:58.296978: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1090]      0 1
2019-02-21 23:01:58.296986: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1103] 0:   N N
2019-02-21 23:01:58.296993: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1103] 1:   N N
2019-02-21 23:01:58.297052: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1220] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 15306 MB memory) -> physical GPU (device: 0, name: Vega 10 XTX [Radeon Vega Frontier Edition], pci bus id: 0000:03:00.0)
2019-02-21 23:01:58.314591: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1220] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:1 with 15306 MB memory) -> physical GPU (device: 1, name: Vega 10 XTX [Radeon Vega Frontier Edition], pci bus id: 0000:0c:00.0)
2019-02-21 23:02:03.002830: I tensorflow/core/kernels/conv_grad_input_ops.cc:997] running auto-tune for Backward-Data
2019-02-21 23:02:03.078605: I tensorflow/core/kernels/conv_grad_filter_ops.cc:886] running auto-tune for Backward-Filter
2019-02-21 23:02:03.164291: I tensorflow/core/kernels/conv_grad_input_ops.cc:997] running auto-tune for Backward-Data
2019-02-21 23:02:03.262944: I tensorflow/core/kernels/conv_grad_filter_ops.cc:886] running auto-tune for Backward-Filter
2019-02-21 23:02:03.310904: I tensorflow/core/kernels/conv_grad_filter_ops.cc:886] running auto-tune for Backward-Filter
  222/10229 [..............................] - ETA: 40:30 - loss: 0.0836

Okay, I can repro your issue now.
Looks like the GPUs were under very light loads during training. Next step would be to profile the workloads on ROCm and the other targets, and look into the device placement of each ops, please stay tuned.

Did you confirm CPU segfault by any chance?

Hi @Dekken , the CPU segfault was not observed on my local system.
While we look into the issue, can you share a bit background of the case? e.g. is it based on a public project? Or are there any similar public models we can try as well?

It's not my project so I'm asking to get others in.
I'm going to see if I can get a colleague in.

pinging @gautiernguyen @nicolasaunai

I think my segfault was to OOM

My colleagues are currently on vacation but this is a part of a PhD in the plasma physics department around "Earth's magnetopause detection from in situ satelites measurements with ML"
not that I know what this means

Made a bit of progress week.  Turns out we were using some non-optimal reduction code due to some stale ROCm-related ifdefs.  We have some local changes that show significant improvements.
Here's where the (initial) bottleneck occurs:
https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/blob/develop-upstream/tensorflow/core/kernels/reduction_gpu_kernels.cu.h#L713-L736
Btw - thanks for reporting this issue.

@parallelo can’t wait for your PR J

@whchung
Currently wrapping up some mods.  It is running now, and it appears to be converging (as best I can tell).
There's always room for more improvement, but the initial reduction kernel bottleneck appears to be fixed  :-)

with #344 merged, should we be good?
if I compile "develop-upstream" myself I should be able to confirm?

Hi @Dekken - Worth another try now.  Please check and report back here.

there's certainly a differnce
we're at 300 seconds an epoch

should we in theory be on par (or better) than a 1080ti with a VEGA FE?

Hi @Dekken , the TF-ROCm 1.14 release includes the PR #344. Can you check it there and let us know if it's okay to close this issue?

is there somewhere to continue to assess the performance vs a 1080ti?
it's a bit disappointing still

is there somewhere to continue to assess the performance vs a 1080ti?

@Dekken , one path is to profile your workload using RPT:
https://scchan.github.io/hcc/md__home_scchan_code_hcc_doc_markdown_hcc_profile.html
And then cross-compare the nvprof results from 1080ti. With that, we might be able to figure out if there's any other avenue or low hanging fruit to improve the performance.

authors: Dekken parallelo sunway513 whchung


text:
[XLA] add new XLA_AMDGPU device class

Per discussion in upstream PR: https://github.com/tensorflow/tensorflow/pull/20845 , register a new device class XLA_AMDGPU. Submit to develop-upstream branch first. Will revise the upstream PR after that.

testing on ROCm CI node shows the same issue with #68 where lld is not found. need to add logic to locate it properly.

Superseded by #204


text:
Fix broken legend icon when requesting image through a proxy

The URL to the legend icons in MapLoom break when requesting the image from GeoServer through a proxy. Using the 'server.virtualServiceUrl' property fixes this issue.

Merged in f0698e3.

authors: darinacosta garnertb

repo: ROGUE-JCTD/MapLoom


text:
[Suggestion] open search results

Hello.
What about "opening" search results that are displayed on screen ?
Linked to other suggestion #770 ;)

I'm not sure I understand your request. Do you mean to automatically show parameters of all bridges that match the current search term? (like when searching for 'Facebook' I get two bridges and the parameters for both bridges should be displayed?)
I think that makes it hard to navigate and get a quick overview of the available bridges. My answer to #770 also applies to this issue.

Yes, it was the point to automatically open search results.
Same answer :)

repo: RSS-Bridge/rss-bridge

license: unlicense


text:
ci: add github-action dependabot version update

GitHub Actions のモジュール更新をチェックする dependabot 設定を追加
発行される PR のラベルを修正

Checked.


text:
awss_start is not built in the libiot_sdk.a in iotkit version 2.3.0

A message showed that linker can't find the symbol awss_start when I comment out FEATURE_WIFI_PROVISION_ENABLED=y in the make.settings, I searched it in the libiot_sdk.a and there is indeed no such symbol in the library. If I uncomment the feature, namely keep it enabled, the symbol is back and build works fine.
Please help to check whether it's expected as WIFI_PROVISION is supposed to be an independent feature out of all cloud services.

ali-iotkit 这个仓库是经过修改后的非官方仓库，使用了 Scons 进行重新构建，而非官方的 make 构建。另外，此仓库中的软件包不需要编译成库文件进行链接。

Thanks, I posted it the wrong place

authors: pansila zhaojuntao

repo: RT-Thread-packages/ali-iotkit


text:
🛑 Schedule (.dev) is down

In 42ef4ed, Schedule (.dev) (https://schedule-rtu.rtuitlab.dev/api/schedule/get_groups) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Schedule (.dev) is back up in 05a19af.

repo: RTUITLab/upptime


text:
Using grid layout with resize

Can we use this repo for the functionality of having a smooth drag drop functionality with grid sizing.

Dazzle meant to a dashboard framework. If you are looking for something more generic like a grid system, I would highly recommend looking into react-grid-layout.

authors: Jeevan-Kishore Raathigesh

repo: Raathigesh/dazzle


text:
Upgraded solution for ODR895

Sunny reported in ODR 895 we still have issue for iDRAC firmware update with 2.1.x branch release.
This is an upgraded solution for ODR-895 to bypass errors reported when get racadm job status. This is feasible as we have 10 retries to get racadm job status.

@cgx027 @iceiilin @RackHD/corecommitters

@RackHD/corecommitters please review.

repo: RackHD/on-tasks


text:
CDash test failed

@jcfr, it appears the generic module test for slicer radiomics failed. It is complaining about a call to VC with python arguments.
test_widgetRepresentation (qSlicerSlicerRadiomicsModuleGenericTest.qSlicerSlicerRadiomicsModuleGenericTest) ... Traceback (most recent call last):
  File "C:/D/N/E-0/Radiomics-build/inner-build/lib/Slicer-4.9/qt-scripted-modules/SlicerRadiomics.py", line 61, in setup
    self._addCustomizationSection()
  File "C:/D/N/E-0/Radiomics-build/inner-build/lib/Slicer-4.9/qt-scripted-modules/SlicerRadiomics.py", line 295, in _addCustomizationSection
    self.parameterFilePathLineEdit = ctk.ctkPathLineEdit(filters=ctk.ctkPathLineEdit.Files)
ValueError: Calling C++ functions with Python keywords is not supported! Function: ctkPathLineEdit(QWidget parent) Keywords: {'filters': 2}
ok

http://slicer.cdash.org/testDetails.php?test=8615594&build=1191518
Moreove, the unit-tests on windows also appear to be failing, but I don't see any output. The Linux/Mac tests pass, but they are tested using an earlier commit.

Update: I ran the unit test locally on my Linux build, no errors.

Update 2: The error in the generic module test appears to be due to the transition to Qt5/VTK9, I fixed this in 2cf2c9c.

@Radiomics/developers
Some updates on the testing cdash:

Building with the CLI works for all platforms in slicer 4.8, still fails for Mac in nightly build (with Qt5)
All tests are passing on Linux and Mac (with the exception of the nightly build on Mac of course)
Windows generic module tests pass, but the SlicerRadiomicsTest fails, it appears that it can't find the CLI... @jcfr, do you have any suggestions?

repo: Radiomics/SlicerRadiomics


text:
🛑 Buildatscale is down

In 4d7541a, Buildatscale (https://buildatscale.tech) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Buildatscale is back up in 6e00eb8 after 17 minutes.


text:
🛑 Buildatscale is down

In 927c51b, Buildatscale (https://buildatscale.tech) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Buildatscale is back up in 4ca8728.


text:
Broken icons in chrome

RainLoop version, browser, OS:
V 1.11.3
Chrome 61.0.3163.100 64Bit (all extensions disabled)
MacOS High Sierra
Expected behavior and actual behavior:
Expected (screenshot taken from Safari)

Actual (screenshot taken from chrome)

On mouse over icons are showing as expected.

On Chrome/Windows it works correctly so I suspect it's related to High Sierra.

No wait, I'm still on Rainloop 1.11.1 so can't be sure if it's MacOS High Sierra or Rainloop 1.11.3.

@megadr01d You may check here: https://mail.rainloop.net/

@RainLoop Thank you for demo-link. On Chrome it is the same. Icons are broken. On Safari everything is ok.

@RainLoop Doh, forgot about the demo link.
@boblgum So it must be related to MacOS, in general, or High Sierra, specifically (more inclined for High Sierra since Path Finder and Sublime Text recently released updates for High Sierra concerning UI rendering, I believe).
Chrome Version 61.0.3163.100 (Official Build) (32-bit) on Windows 7 is OK.

Google Chrome compatible to macOS 10.13 High Sierra

authors: RainLoop boblgum megadr01d

repo: RainLoop/rainloop-webmail


text:
🛑 RSOS服务控制面板 is down

In e4ce787, RSOS服务控制面板 (https://$US_SITE) was down:

HTTP code: 530
Response time: 298 ms

Resolved: RSOS服务控制面板 is back up in 42a88fd after 11 minutes.

repo: RainThings/uptime


text:
🛑 RSOS服务控制面板 is down

In 7f14983, RSOS服务控制面板 (https://$US_SITE) was down:

HTTP code: 530
Response time: 230 ms

Resolved: RSOS服务控制面板 is back up in 6e4f935 after 11 minutes.


text:
🛑 RSOS服务控制面板 is down

In fe70448, RSOS服务控制面板 (https://$US_SITE) was down:

HTTP code: 530
Response time: 95 ms

Resolved: RSOS服务控制面板 is back up in 5f91b3e after 6 minutes.


text:
Decouple font and size in style

Given this type of style:
let string = try? NSAttributedString.composed(
    ofXML: content,
    baseStyle: .style(
        .font(UIFont(name: "GillSans-Light", size: 20)!),
        .lineHeightMultiple(1.8),
        .color(.darkGray)),
    rules: [
        .style("black", .style(
            .color(.white),
            .backgroundColor(.black),
            .font(UIFont(name: "SuperClarendon-Black", size: 20)!)
            )),
        .style("red", .style(
            .color(.white),
            .backgroundColor(.raizlabsRed),
            .font(UIFont(name: "SuperClarendon-Black", size: 20)!)
            )),
        .style("signed", .style(
            .color(.raizlabsRed),
            .font(UIFont(name: "SuperClarendon-Black", size: 20)!)
            )),
        .enter(element: "racket", insert: racket)
    ]
)

It would be interesting to only specify the font size in the baseStyle, and have the styles specify the font type. That way the same rules could be re-used in difference places with different sizes.

@KingOfBrian do you think that changing this after 4.0 would constitute a breaking change? Or can this be created additively?

authors: KingOfBrian ZevEisenberg

repo: Raizlabs/BonMot


text:
Added Connecting Dot Background

Fixes Issue🛠
Closes #314
Description👨💻
Added Connecting Dot Background
Type of change📄

[X] New feature (non-breaking change which adds functionality)

Checklist✅

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have added demonstration in the form of GIF/video file
[X] I am an Open Source Contributor

Screenshots/GIF📷

Nice, Merged ✨ @GhoshAditi


text:
[Feature] Add new outputs result.

Description
I would like to add new outputs result in the Word Count Calculator. The outputs will be "the shortest word count" showing the shortest word count and, of course, the "longest word count". showing the longest word count.
Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[X] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Proceed @SilviuPe


text:
Add lima provider for macOS

Currently can run basic-test with regional-dr.yaml on macOS.
Needs more work:

[x] move image loading to drenv load command
[x] enable submariner (requires labelling the nodes)
[x] enable cephfs (requires external snapshotter)
[x] enable volsync (requires cephfs and submariner)
[x] enable argocd (fails to parse certificate in PEM format, need investigation)

Temporarily based on #1534
Fixes #1513

Changes in lates version:

Remove kubevirt configuration for containerd - not needed yet
Remove kube-proxy configuration change - not needed
Remove API server change to listen to 0.0.0.0 - not needed
Remove flannel change to use iface lima0 - not need when default route is fixed
Ensure that shared network default route is first route
Refine commit order

Changes in latest version:

Rebase on latest #1534
Log invalid json logs in debug mode

https://github.com/RamenDR/ramen/compare/12e9fb9034ceb18b0390ab9c88bb6742dc228757..9c643f25c57be53e547a2f79bbc27e7d2abbcc98

repo: RamenDR/ramen


text:
Landscape mode

@RamyTalal is there an option for a landscape mode? Thanks!

I think it's the Rotate command (not entirely sure). https://github.com/RamyTalal/Label-Printer/blob/master/src/Command/Rotate.php

@RamyTalal thanks! It worked but the settings on character sizes, alignments, etc. were ignored.

@ubay25 I think you have to set the orientation first then apply your format settings.
Give that a shot.

Just reading the ESC/P Command Reference...
Description

Using this command clears all text.
Before entering text, specify the paper orientation with this command.
When the printer is turned on, the landscape orientation is canceled.

@ubay25 See @ntaylor-86's comment. I'll close this issue for now.

repo: RamyTalal/Label-Printer


text:
Social media embeds do not show in third party services

I have noticed that if a feed article has social media embeds like X or Instagram, and the feed is in a third party service (Feedly, FreshRSS, etc.), the embed shows as text. However, if I use the iCloud option, it shows properly. Is this a bug?

Some third party services strip out all JavaScript, and JavaScript is required for social media embeds to work correctly.

authors: brentsimmons gferreroferri

repo: Ranchero-Software/NetNewsWire


text:
not work for obsidian of version v1.6.3

SYSTEM INFO:
Obsidian version: v1.6.3
Installer version: v1.4.16
Operating system: Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 23.3.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: Blue Topaz v2024040601
Snippets enabled: 1
Restricted mode: off
Plugins installed: 49
Plugins enabled: 49
1: Markmind v1.9.9
2: QuickAdd v1.8.1
3: Thino v2.4.47
4: Templater v2.3.3
5: Remember cursor position v1.0.9
6: Excalidraw v2.2.6
7: Dataview v0.5.66
8: Advanced URI v1.40.1
9: Note Refactor v1.8.2
10: Better Word Count v0.10.1
11: Clear Unused Images v1.1.0
12: Auto Link Title v1.5.4
13: Recent Files v1.4.1
14: Tag Wrangler v0.6.1
15: ExcaliBrain v0.2.15
16: Breadcrumbs v3.6.11
17: Enhancing Export v1.10.5
18: Pandoc Plugin v0.4.1
19: Git v2.24.2
20: Custom Frames v2.4.7
21: Linter v1.24.0
22: ZotLit v1.1.5
23: Editor Syntax Highlight v0.1.3
24: Paste image rename v1.6.1
25: File Explorer Note Count v1.2.2
26: Spaced Repetition v1.12.4
27: Settings Search v1.3.10
28: Commander v0.5.1
29: Whisper v1.5.5
30: Text Generator v0.7.11
31: Smart Connections v2.1.72
32: Update time on edit v2.4.0
33: Obsidian_to_Anki v3.6.0
34: Persistent Links v0.2.0
35: Copy Block Link v1.0.4
36: Homepage v3.8.0
37: BRAT v1.0.1
38: AI Tagger v1.1.6
39: DB Folder v3.5.1
40: Supercharged Links v0.12.1
41: Style Settings v1.0.8
42: Strange New Worlds v2.1.4
43: Emoji Magic v0.2.2
44: Floating Search v3.5.1
45: AttachFlow v0.4.3
46: Image Toolkit v1.4.1
47: Periodic Notes v0.0.17
48: Calendar v1.5.10
49: New Tab + v1.3.0
RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Thanks for the feedback ! I'll try to have a look at it within the week.

Hi ! In version 1.6.5, all features of the plugin works as expected :) I recommend to update Obsidian to latest version.

authors: Raphlette TrillStones

repo: Raphlette/obsidian-new-tab-plus


text:
No accessory to be added in Home app

Hello! Could you, please, guide me on how it
is supposed to add the AC accessory to the Home app? I setup your plugin in Homebridge with the correct AC IP but no additional accessory shows up in Home app, even when I try to add a new accessory using the Homebridge 8 digit code. Thanks!

Hello, can you provide the logs from homebridge?

[10/13/2022, 9:04:54 AM] Loaded plugin: homebridge-daikin-smart-ac@1.0.0
[10/13/2022, 9:04:54 AM] Registering platform 'homebridge-daikin-smart-ac.DaikinSmartAC'
[10/13/2022, 9:04:54 AM] ---
[10/13/2022, 9:05:12 AM] [Suíte Master] Initializing DaikinSmartAC platform...
[10/13/2022, 9:05:12 AM] Loading 41 accessories...
[10/13/2022, 9:05:20 AM] [Suíte Master] Failed to setup Daikin AC (192.168.100.102)

I missed an important part of the log:
[10/13/2022, 9:04:54 AM] Loaded plugin: homebridge-daikin-smart-ac@1.0.0
[10/13/2022, 9:04:54 AM] Registering platform 'homebridge-daikin-smart-ac.DaikinSmartAC'
[10/13/2022, 9:04:54 AM] ---
[10/13/2022, 9:05:12 AM] [Suíte Master] Initializing DaikinSmartAC platform...
[10/13/2022, 9:05:12 AM] Loading 41 accessories...
[10/13/2022, 9:05:20 AM] Homebridge v1.5.0 (HAP v0.10.2) (Homebridge 2628) is running on port 51740.
[10/13/2022, 9:05:20 AM] [Suíte Master] AxiosError: connect ECONNREFUSED 192.168.100.102:80
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1187:16) {
port: 80,
address: '192.168.100.102',
syscall: 'connect',
code: 'ECONNREFUSED',
errno: -111,
config: {
transitional: {
silentJSONParsing: true,
forcedJSONParsing: true,
clarifyTimeoutError: false
},
adapter: [Function: httpAdapter],
transformRequest: [ [Function: transformRequest] ],
transformResponse: [ [Function: transformResponse] ],
timeout: 0,
xsrfCookieName: 'XSRF-TOKEN',
xsrfHeaderName: 'X-XSRF-TOKEN',
maxContentLength: -1,
maxBodyLength: -1,
env: { FormData: [Function] },
validateStatus: [Function: validateStatus],
headers: {
Accept: 'application/json, text/plain, /',
'User-Agent': 'axios/0.27.2'
},
method: 'get',
url: 'http://192.168.100.102/common/basic_info',
data: undefined
},
request: <ref *1> Writable {
_writableState: WritableState {
objectMode: false,
highWaterMark: 16384,
finalCalled: false,
needDrain: false,
ending: false,
ended: false,
finished: false,
destroyed: false,
decodeStrings: true,
defaultEncoding: 'utf8',
length: 0,
writing: false,
corked: 0,
sync: true,
bufferProcessing: false,
onwrite: [Function: bound onwrite],
writecb: null,
writelen: 0,
afterWriteTickInfo: null,
buffered: [],
bufferedIndex: 0,
allBuffers: true,
allNoop: true,
pendingcb: 0,
constructed: true,
prefinished: false,
errorEmitted: false,
emitClose: true,
autoDestroy: true,
errored: null,
closed: false,
closeEmitted: false,
[Symbol(kOnFinished)]: []
},
_events: [Object: null prototype] {
response: [Function: handleResponse],
error: [Function: handleRequestError],
socket: [Function: handleRequestSocket]
},
_eventsCount: 3,
_maxListeners: undefined,
_options: {
maxRedirects: 21,
maxBodyLength: 10485760,
protocol: 'http:',
path: '/common/basic_info',
method: 'GET',
headers: [Object],
agent: undefined,
agents: [Object],
auth: undefined,
hostname: '192.168.100.102',
port: null,
nativeProtocols: [Object],
pathname: '/common/basic_info'
},
_ended: true,
_ending: true,
_redirectCount: 0,
_redirects: [],
_requestBodyLength: 0,
_requestBodyBuffers: [],
_onNativeResponse: [Function (anonymous)],
_currentRequest: ClientRequest {
_events: [Object: null prototype],
_eventsCount: 7,
_maxListeners: undefined,
outputData: [],
outputSize: 0,
writable: true,
destroyed: false,
_last: true,
chunkedEncoding: false,
shouldKeepAlive: false,
maxRequestsOnConnectionReached: false,
_defaultKeepAlive: true,
useChunkedEncodingByDefault: false,
sendDate: false,
_removedConnection: false,
_removedContLen: false,
_removedTE: false,
_contentLength: 0,
_hasBody: true,
_trailer: '',
finished: true,
_headerSent: true,
_closed: false,
socket: [Socket],
_header: 'GET /common/basic_info HTTP/1.1\r\n' +
'Accept: application/json, text/plain, /\r\n' +
'User-Agent: axios/0.27.2\r\n' +
'Host: 192.168.100.102\r\n' +
'Connection: close\r\n' +
'\r\n',
_keepAliveTimeout: 0,
_onPendingData: [Function: nop],
agent: [Agent],
socketPath: undefined,
method: 'GET',
maxHeaderSize: undefined,
insecureHTTPParser: undefined,
path: '/common/basic_info',
_ended: false,
res: null,
aborted: false,
timeoutCb: null,
upgradeOrConnect: false,
parser: null,
maxHeadersCount: null,
reusedSocket: false,
host: '192.168.100.102',
protocol: 'http:',
_redirectable: [Circular *1],
[Symbol(kCapture)]: false,
[Symbol(kNeedDrain)]: false,
[Symbol(corked)]: 0,
[Symbol(kOutHeaders)]: [Object: null prototype]
},
_currentUrl: 'http://192.168.100.102/common/basic_info',
[Symbol(kCapture)]: false
}
}
[10/13/2022, 9:05:20 AM] [Suíte Master] Failed to setup Daikin AC (192.168.100.102)

Does the AC appear on router connected devices and can you provide a image with the wifi adapter?

@edugrt Does the iOS app require any password for it to work?

Oh, yes, it does

I think that is the issue, the plugin is made to work the the local versions and with remote control disabled, if you can disable the remote control (for security) and get rid of the password, the plugin it will work

authors: RaresAil edugrt

repo: RaresAil/homebridge-daikin-smart-ac


text:
Add rasa x --config CONFIG

Proposed changes:

Add rasa x --config CONFIG

Status (please check what you already did):

[x] made PR ready for code review
[x] modified existing test for the functionality
[ ] updated the documentation
[x] updated the changelog
[x] reformat files using black (please check Readme for instructions)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

IMO this is ready to be merged.
Regarding testing: an ideal test would first create an empty project with rasa init, then change the config.yml file's name to foobar.yml (for example), then try running rasa x --config foobar.yml, which should load the config file properly. This would need to be done without actually launching Rasa X. Ideally we would use the run fixture in tests/cli/conftest.py but then we wouldn't be able to mock the launching of Rasa X because run starts a separate process.
Also I believe we should merge this first, do a Rasa release and then update the Rasa X dependency. What I'm not sure is if this should go in Rasa 1.5 or in the next 1.4 patch.

Also I believe we should merge this first, do a Rasa release and then update the Rasa X dependency. What I'm not sure is if this should go in Rasa 1.5 or in the next 1.4 patch.

Good question. I suggest to be strict about it. It's a new feature (though it's a small change) and hence should go into 1.5

Regarding testing: an ideal test would first create an empty project with rasa init, then change the config.yml file's name to foobar.yml (for example), then try running rasa x --config foobar.yml, which should load the config file properly. This would need to be done without actually launching Rasa X. Ideally we would use the run fixture in tests/cli/conftest.py but then we wouldn't be able to mock the launching of Rasa X because run starts a separate process.

Yeah, it's tricky since it's right at the edge between rasa / rasa-x. For me it would be okay, to not add another test in rasa and maybe just adding a unit test in rasa-x for _configure_for_local_server

@ArjaanBuijk can you take another look at this so we can move this forward?

authors: ArjaanBuijk CLAassistant federicotdn tmbo wochinge

repo: RasaHQ/rasa


text:
Initial implenemtation of NLU YAML parser

Part of #5983
Proposed changes:

Created new YAML parser
Extracted common parts for YAML and MD to the separate classes
Added unit tests

Things to address in the next PRs

Update the docs
Split loaders for Core and NLU files

Status (please check what you already did):

[x] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog (please check changelog for instructions)
[x] reformat files using black (please check Readme for instructions)

I started testing this by using an old folder I had initialized with rasa init --no-prompt (on master). Then, I changed nlu.md to nlu.yml, and adapted the contents to YAML. I checked the validity of the YAML just in case. I also deleted nlu.md.
However, after running rasa train there seems to be a problem when stories.md is loaded. An exception is raised:
Traceback (most recent call last):
  File "/home/fede/Workspace/rasa/env/bin/rasa", line 11, in <module>
    load_entry_point('rasa', 'console_scripts', 'rasa')()
  File "/home/fede/Workspace/rasa/rasa/__main__.py", line 108, in main
    cmdline_arguments.func(cmdline_arguments)
  File "/home/fede/Workspace/rasa/rasa/cli/train.py", line 77, in train
    nlu_additional_arguments=extract_nlu_additional_arguments(args),
  File "/home/fede/Workspace/rasa/rasa/train.py", line 52, in train
    nlu_additional_arguments=nlu_additional_arguments,
  File "uvloop/loop.pyx", line 1456, in uvloop.loop.Loop.run_until_complete
  File "/home/fede/Workspace/rasa/rasa/train.py", line 88, in train_async
    config, domain, training_files
  File "/home/fede/Workspace/rasa/rasa/importers/importer.py", line 81, in load_from_config
    config, config_path, domain_path, training_data_paths
  File "/home/fede/Workspace/rasa/rasa/importers/importer.py", line 139, in load_from_dict
    RasaFileImporter(config_path, domain_path, training_data_paths)
  File "/home/fede/Workspace/rasa/rasa/importers/rasa.py", line 36, in __init__
    training_data_paths
  File "/home/fede/Workspace/rasa/rasa/data.py", line 96, in get_core_nlu_files
    path
  File "/home/fede/Workspace/rasa/rasa/data.py", line 117, in _find_core_nlu_files_in_directory
    if is_nlu_file(full_path):
  File "/home/fede/Workspace/rasa/rasa/data.py", line 145, in is_nlu_file
    return loading.guess_format(file_path) != loading.UNK
  File "/home/fede/Workspace/rasa/rasa/nlu/training_data/loading.py", line 184, in guess_format
    content = io_utils.read_yaml_file(filename)
  File "/home/fede/Workspace/rasa/rasa/utils/io.py", line 209, in read_yaml_file
    return read_yaml(read_file(filename, DEFAULT_ENCODING))
  File "/home/fede/Workspace/rasa/rasa/utils/io.py", line 124, in read_yaml
    return yaml_parser.load(content) or {}
  File "/home/fede/Workspace/rasa/env/lib/python3.7/site-packages/ruamel/yaml/main.py", line 343, in load
    return constructor.get_single_data()
  File "/home/fede/Workspace/rasa/env/lib/python3.7/site-packages/ruamel/yaml/constructor.py", line 111, in get_single_data
    node = self.composer.get_single_node()
  File "_ruamel_yaml.pyx", line 703, in _ruamel_yaml.CParser.get_single_node
  File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event
ruamel.yaml.scanner.ScannerError: while scanning an alias
  in "<unicode string>", line 2, column 1
did not find expected alphabetic or numeric character
  in "<unicode string>", line 2, column 2

It appears to be a problem with _is_nlg_story_format, which is not detecting stories.md as a Markdown stories file for some reason. But that's strange since this PR does not modify that function (or the regexp it uses).

A simple way to reproduce: on master, run rasa init --no-prompt, then switch to this branch and do rasa train (no YAML needed).

@federicotdn thanks for spotting that!
I think locally I only tried the rasa train --nlu. Problem fixed, but I also need to make sure that situation is covered with a test 😄
Also, there's a bunch of test failing in the test_train.py, I'll check that.

@ricwo @federicotdn Thanks a lot for your patience and the detailed code review! I know there were obvious issues with missing docstrings and other stuff 😞 I was in a bit of hurry to get this thing working asap, sorry!

When making YAML syntax errors

@ricwo I have a plan to verify both NLU and Core YAML files against a schema. It will print a proper message like "Unexpected key..". I want to do that in a separate PR not to make this one even bigger.

provide lists instead of a multiline string

The latest decision we made was to be strict and support only multiple strings. Thanks for spotting that, I'll adjust the code and the tests.

authors: degiz federicotdn


text:
Internationalization

[ ] Code changes to support native internationalization.
[ ] API to add languages manually.

[x] find german translator

Tracking in RationalCoding/multihack-brackets#21

authors: RationalCoding tweakimp

repo: RationalCoding/multihack-web


text:
bboxes example only works if fill is None or has transparency < 1.0

In draw_bboxes.rs line 45 rtree.root().append_kind(usvg::NodeKind::Path(usvg::Path ...) the fill is set to None because otherwise the fill overlays everything. This makes sense as it is appended as a child to the tree. I could not find documentation in usvg to "prepend" to a Tree or to append one Tree to another. Is there some other way to generate a background as the actual background without overlaying on top of all the other elements from the file?
I recognize this might be more of a usvg question, but the repository does not take issues and I'm not certain it is in active development.

I guess you're looking for something like this:
    /// ...

    for bbox in bboxes {
        let node = usvg::Node::new(usvg::NodeKind::Path(usvg::Path {
            id: String::new(),
            transform: usvg::Transform::default(),
            visibility: usvg::Visibility::Visible,
            fill: Some(usvg::Fill {
                paint: usvg::Paint::Color(usvg::Color::black()),
                opacity: usvg::Opacity::new(0.2),
                rule: usvg::FillRule::default(),
            }),
            stroke: stroke.clone(),
            rendering_mode: usvg::ShapeRendering::default(),
            data: Rc::new(usvg::PathData::from_rect(bbox)),
        }));

        rtree.root().prepend(node);
    }

    /// ...

See rctree documentation for details.
usvg is part of resvg. They are developed in parallel.

Thank you so much. That is perfect. I missed the documentation that said usvg::Node is an "Alias for rctree::Node."

authors: RazrFalcon stevensonmt

repo: RazrFalcon/resvg


text:
Fix  #685

I spent some time in the debugger and here is my understanding of what is going on / why the issue exists:

First, we determine the filter bbox, since this is the area where the filter should be contained. Nothing should exceed this.
We then create a pixmap with the size of the filter bbox, which will contain all of the graphics that are part of the filter. Since the pixmap starts at (0, 0), we need to shift everything we render to account for the x/y of the filter area.

If we take the following SVG:
<svg width="200" height="200" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect width="200" height="200" fill="#ffdd88"/>

  <defs>
    <rect fill="#ff0000" opacity="1" id="rect" width="100" height="100"/>
    <filter id="colorful-image" >
      <feImage xlink:href="#rect" href="#rect" x="40" y="60"
        result="feImageResultnode" />
      <feMerge>
        <feMergeNode in="feImageResultnode" />
      </feMerge>
    </filter>
  </defs>
  <rect x="30" y="50" width="100" height="100" fill="#1e1705" filter="url(#colorful-image)"/>
  <rect x="30" y="50" width="100" height="100" stroke="#00f" fill="none"/>
</svg>

The filter bbox would be x=20, y=40, width=120, height=120, so we translate everything by (-20, -40). As a result, the actual x and y of the feImage in the filter pixmap should be 20, 20. However, when rendering the filter onto the pixmap, we aren't accounting for this shift anywhere, meaning that the image will start at (0, 0) instead of (20, 20). As a result of this, the rect won't be positioned accordingly, and as another side effect the clipping algorithm will clip parts of the rectangle that shouldn't be clipped.
All I did was add a transformation that accounts for the x/y position of the subregion. I also added some test cases to reflect that it works as intended now.
However, I have to admit that even after spending hours in the debugger, I haven't completely understood the whole logic of the filter rendering part. 😅 In particular, I'm unsure whether the translation should be preconcatenated or postconcatenated to the scaling (I haven't even figured out why that's needed), so I would appreciate your input on that.

I'm unsure whether the translation should be preconcatenated or postconcatenated to the scaling

I don't blame you. Affine transforms are not very intuitive.
And yes, you code is correct here. You can easily check it by adding --zoom 2 to resvg.

I haven't completely understood the whole logic of the filter rendering part

I don't blame you. x2
SVG filters are ridiculously complicated and badly documented. That's why no one really supports them. It took me months to someone understand them.
I've tried my best to make the code as simple as possible, but it's hard. Especially if we remember that filters is a very performance sensitive part of the renderer.
PS: please make sure all new SVG tests do not have lines longer than 100 characters. And make sure all elements have an id attribute.

I've tried my best to make the code as simple as possible, but it's hard. Especially if we remember that filters is a very performance sensitive part of the renderer.

I can imagine, no worries! I'm still in awe that you managed to write this library (including its dependencies) all by yourself.

Thanks!
Yes, it was and still is an interesting project. It took around 3 years full time to get to this point. And back then I had a lot of free time, but not anymore.

authors: LaurenzV RazrFalcon


text:
curve control points should not extend bboxes

Expected:
The glyph below should have a bbox  y_max of 439.
More precisely: 438.90, which would round up to 438.90906.
Anyway, it's greater than the y=438 on-curve point at the start of the contour.
Actual
The bbox y_max is 548.
Analysis
This appears to be the result of expanding the bbox
I have a glyph that looks like this:

It's made from an SVG that looks like this (the expected/actual y_max values above are based on the TTF coordinate grid, where y=448 would be the top of "view box", equivalent to y=0 on this SVG coordinate grid):
<svg  xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
  <path d="M10 10q 30 290 180 90t 20 40 40 60 60 80z"/>
</svg>

This is one of my test cases in another project. The test case exercises multiple Smooth Quadratic Curve with relative parameters, following a quadratic curve.
Here's a view of the resulting TrueType glyph in the FontForge UI:

The red arrow shows that the control point for a quadratic curve lands way outside the glyph's "view box" (red arrow), while the rendered curve remains inside the glyph's box (green arrow).
When computing the bbox of the glyph outline, I think the control point should not be used to expand the bbox. The control point is not within the bounding box, is it?
But currently, the code does extend the glyph's bbox with that quadratic curve control point:
https://github.com/RazrFalcon/ttf-parser/blob/396e9fcf678cf2b67c94cab27505f4d04ccb6d6c/src/tables/glyf.rs#L68
As a result, the y_max for the bbox is 548--it's been extended way out there to include that (off-curve) control point.
It does the same in the cubic curve handling for the CFF table:
https://github.com/RazrFalcon/ttf-parser/blob/master/src/tables/cff/mod.rs#L61-L62
Isn't it the case that we should only expand the bbox by a point that's actually on the curve?
In these cases, it seems to require that we compute the extrema of the curve, such as those pointed at by the green arrow above. Those points would be neither the control point, nor the end points of the quadratic curve, so they will not be provided to the quad_to() function. They'd have to be computed, like these quadratic and cubic bezier extrema calculations in the kurbo crate, wouldn't they?

The linked PR #96 includes a test case that reproduces the issue.

When computing the bbox of the glyph outline, I think the control point should not be used to expand the bbox. The control point is not within the bounding box, is it?

That's a good question. I don't know. I don't think this is documented anywhere. We have to simply check what other implementations do. And afaik, at least stb_truetype, freetype and harfbuzz do the same.
Also, calculating the real/tight bbox would be extremely expensive.

From https://docs.microsoft.com/en-us/typography/opentype/spec/glyf#glyph-headers:

Note that the bounding rectangle from each character is defined as the rectangle with a lower left corner of (xMin, yMin) and an upper right corner of (xMax, yMax). These values are obtained directly from the point coordinate data for the glyph, comparing all on-curve and off-curve points. Phantom points computed by the rasterizer are not relevant. Note that the bounding box defined by control points is guaranteed to contain the outline, but might not be tight to the outline.

@khaledhosny Thanks!

Wow, it's right there in the spec! Thanks, @khaledhosny. It's been too long since I read that section.
Now you that you point it out, it makes sense to me that at this low level, the bbox would be defined so loosely, for the sake of efficiency. But at some point, the price has to be paid to lay it out correctly, doesn't it?
Where I encountered the problem was when trying to rasterize it. I was using ab-glyph which depends on this crate to rasterize it, and then trying to get it positioned correctly on the 512x512 space that I know is the original viewBox. My goal is to compare the rendered SVG to the rendered font glyph.
So it seems that in order to lay it out correctly, that tighter bbox must be calculated eventually, so you're not positioning the rendered glyph with respect to some control point that's way outside the viewBox.
I recognize that this is no longer an issue with this crate, so I'll close this issue. But if you know of any more tips to point me in the direction for solving my problem, I'd appreciate it.

Well, you can calculate a tight bbox quite easily. I wrote this crate for resvg and here is how it calculates the bbox (you would probably have to add the quad curve case).
Since it's quite expensive and requires a third-party dependency, it will not be part of ttf-parser.
I'm not sure about the glyph positioning itself. I haven't needed this before. In resvg, rustybuzz (aka harfbuzz) positions glyphs for me. I just outline them and place where needed. The "real" bounds doesn't really matter for me.
Overall, ttf-parser is trying to be a good parser abstraction. It doesn't really do any post-processing (like let's say freetype). So any additional features should be implemented separately. Like this.

I think I had an aha! moment and solved my problem well enough for now. This conversation was a key ingredient for shifting my perspective to see the solution, so thank you!
I do have tight bbox calculation implementation in my code, which I could use--if I had the absolute coordinate points of the original bezier curves as inputs. And that was my first guess: if ttf-parser and ab-glyph won't give me horizontal/vertical metrics based on the tight bbox, then I'd compute the tight bbox myself. But ab-glyph also doesn't seem to provide those points of the bezier curve that I would need in order to compute the tight bbox. This was another clue that I was still maybe trying to fit a square peg into a round hole.
Upon closer examination, I realized that what ab-glyph does provide APIs for are the global font metrics like ascent.
So the solution that's working for my set of cases now involves only a few simple subtraction operations using what metrics are provided in the ab-glyph API: especially calculating the difference between the font's ascent and a glyph's y_min from the bounds rect provided by ab-glyph's px_bounds(). I was able to use similar horizontal properties from px_bounds() to get the horizontal position right as well.
So all of my test cases are now working as expected, which includes some re-positioning vertically (both up and down) and horizontally (both left and right). It has not required computing any tight bboxes.
This makes me think that perhaps this is what harfbuzz and the others are up to when they're doing shaping. (I have very little familiarity with shaping, per se. This conversation has been eye-opening). I can appreciate that solving for positioning like this in the general case of all possibilities involving various horizontal and vertical metrics encoded in a font would be much more complicated. Fortunately, my particular use cases are much more constrained, so these simple calculations seem to be doing all of the shaping and/or positioning necessary at the moment.
Thanks again.

Glad to hear. rustybuzz is 20 KLOC (+12.5 KLOC of ttf-parser), so it's much more complicated than simply doing a few "subtraction operations".
As for ascent, ab-glyph simply calls ttf-parser method here, afaik. Which in itself is famously a nightmare. It can be defined in three different places in the font, two of which are affected by variation axes (in case of a variable font).
Once again, I'm not sure what is your goal, but for getting glyph metrics you can look into: ascender, descender, glyph_hor_advance and glyph_hor_side_bearing methods of the Face type. The last two are optional.

In my case, what I'm testing is my own font builder. So one of my test expectations is that the font builder has encoded that ascent in a way that will work reliably. If I found that these tests were breaking because of something strange happening with resolving that ascent from the font, such as by ab-glyph's call into ttf-parser, I think it might point toward a bug in how the font builder encoded it in the font being tested, which would be a valuable test failure pointing toward a bug in the font builder under test.

authors: RazrFalcon khaledhosny mlwilkerson

repo: RazrFalcon/ttf-parser


text:
Card Collection Data incorrect from recent events

Describe the bug
I was about to start drafting this weekend and wanted to see my before/after collection for the new set Throne of Eldraine.
I have roughly 30-40 cards from the set, as I have not opened any packs or anything yet. I only have the daily ICR cards and cards rewarded from the Brawl event.
Yet, it shows I have 116/287 singles and 201/1148 of the entire playset.
Looking through the cards displayed in my collection on MTGArena.Pro, it appears that it has grabbed all of the Brawl Decks from the Brawl Event a couple of weeks ago.
Since we were "temporarily" given the Brawl Decks during the event only, it appears that it captured that as actually being in my Collection. I certainly don't have any of these cards when looking in Arena.
There doesn't appear to be a way to remove cards from my MTGArena.Pro collection either, or even a "resync" just my collection data (I don't want to nuke my entire account).
The Collection manager has a "manual edit" option (left-click to remove, right-click to add), but right clicking only brings up the web browser menu, and left clicking tries to open the individual card's info page, which usually just crashes (RETRY/STOP/Reload Page error).
I tried this with both Firefox and Chrome (both latest versions)

Thanks for noticing this, patch have been applied. With next card gained collection will update to actual state.

Bug have been resolved.

Wow, I wasn't expecting a response back. I was just doing due diligence and
reporting issues.
Awesome work! Everything looks great. Much respect for you as a developer
who cares about your work.
I've been using your tracker since I started playing again earlier this
year and have found it to be the most powerful for pure data. Nothing else
really comes close.
On Sat, Oct 12, 2019 at 4:01 AM Razviar notifications@github.com wrote:

Thanks for noticing this, patch have been applied. With next card gained
collection will update to actual state.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Razviar/mtga-pro-tracker/issues/529?email_source=notifications&email_token=AFNCDTSFXEHPHUIDWOHK4PLQOF755A5CNFSM4I74NIBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBZAXQ#issuecomment-541298782,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNCDTQBSCULUPCJVIEMVTLQOF755ANCNFSM4I74NIBA
.

authors: Razviar corvettejoe

repo: Razviar/mtga-pro-tracker


text:
🛑 CellSol is down

In 2b20f4f, CellSol (https://www.f3.to/cellsol) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CellSol is back up in 97afeed after 11 minutes.

repo: RbtsEvrwhr-Riley/upmonitor


text:
Ambiguous reference to member 'subscribe'

Hello
I am using ReSwift in a Watchkit Extension and whenever I try to subscribe to mainStore I get the following error
"Ambiguous reference to member 'subscribe'"
my subscription code looks like
mainStore.subscribe(self)
I have created the mainStore the same way as recommended in the docs
let mainStore = Store<ReAppState>(     reducer: WatchReducer,     state: nil ) as Store
Except because this is a Watchkit App it is created in ExtensionDelegate.swift
Its strange because I have another watch app that is using ReSwift just fine and have been attempting to compare the two but don't see anything different so i think I might be missing something obvious.

Solved the problem.
This is not an issue with ReSwift.
I previously created an object in my source code that I named AppState and i had earlier renamed ReSwifts AppState to ReAppState.

Thanks for the update, @NickJorgensen, I'm glad you were able to solve the problem :)

authors: NickJorgensen mjarvis

repo: ReSwift/ReSwift