dump-ast example program hits assertion: `!PA.isArgIdent(Idx)' failed.

I read about pasta on your blog post and decide to play with it. I am not familiar with the internals of libclang or llvm, so this issue may be user error.
I successfully built pasta and was able to run the demo programs. When I tried the dump-ast example on a toy example it worked as expected. However, when I tried it against my real project, it hits an assert. In particular, when I run it against this project: https://github.com/XRPLF/rippled using the following command line:

./dump-ast /home/swd/apps/clang-latest/bin/clang++ -DBOOST_ASIO_DISABLE_HANDLER_TYPE_REQUIREMENTS -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_CONTAINER_FWD_BAD_DEQUE -DBOOST_COROUTINES_NO_DEPRECATION_WARNING -DBOOST_FILESYSTEM_DEPRECATED -DBOOST_STACKTRACE_ADDR2LINE_LOCATION=\\\"/usr/bin/addr2line\\\" -DBOOST_STACKTRACE_USE_ADDR2LINE -DBOOST_STACKTRACE_USE_BACKTRACE -DBOOST_STACKTRACE_USE_NOOP -DCARES_STATICLIB -DDATE_HEADER_ONLY -DDEBUG -DENABLE_TESTS -DGIT_COMMIT_HASH=\\\"ed9064ce3f6de6da6b63417e59f3100c8e6c4c6d\\\" -DHAS_UNCAUGHT_EXCEPTIONS=1 -DOPENSSL_NO_SSL2 -D_DEBUG -I/home/swd/projs/ripple/mine/src/ed25519-donna -I/home/swd/projs/ripple/mine/src/secp256k1/include -I/home/swd/projs/ripple/mine/src -isystem /home/swd/.conan/data/boost/1.82.0/_/_/package/f81afbcfa21cf6994cf0e45c1b11229c01c767a7/include -isystem /home/swd/.conan/data/openssl/1.1.1u/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/.conan/data/libarchive/3.6.2/_/_/package/d9fea6983af2a77bcbe3f0b088cea5aef9308bd7/include -isystem /home/swd/.conan/data/lz4/1.9.3/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/projs/ripple/mine/cur_build/proto_gen_grpc -isystem /home/swd/.conan/data/grpc/1.50.1/_/_/package/d156c58fd512defbc1155e665684d7875e800ba9/include -isystem /home/swd/.conan/data/abseil/20220623.0/_/_/package/e84b6d643e7f97d33bf72700134618fbae8bbbf6/include -isystem /home/swd/.conan/data/c-ares/1.19.0/_/_/package/ed86cef4487c6b9ce327a03d24ced8142000e8b9/include -isystem /home/swd/.conan/data/re2/20230301/_/_/package/e84b6d643e7f97d33bf72700134618fbae8bbbf6/include -isystem /home/swd/.conan/data/zlib/1.2.13/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/.conan/data/protobuf/3.21.9/_/_/package/681b3b1dffc7e4dc6f5551cdb6e1fe56bdda3e85/include -isystem /home/swd/projs/ripple/mine/cur_build/proto_gen -isystem /home/swd/projs/ripple/mine/cur_build/proto_gen/src/ripple/proto -isystem /home/swd/.conan/data/soci/4.0.3/_/_/package/dc82e3681e64ed36c447531c9e4883a5c616a774/include -isystem /home/swd/.conan/data/bzip2/1.0.8/_/_/package/5e357164f23f7c4e38ebe87433827878dbe1a74c/include -isystem /home/swd/.conan/data/libbacktrace/cci.20210118/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/.conan/data/sqlite3/3.42.0/_/_/package/ae0e146c4c82ac1e46c279d15c964c80fedbdf5f/include -isystem /home/swd/.conan/data/nudb/2.0.8/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include -isystem /home/swd/.conan/data/date/3.0.1/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include -m64 -stdlib=libstdc++ -Wall -Wdeprecated -Wextra -Wno-unused-parameter -g -std=c++20 -fPIE -frtti -Wnon-virtual-dtor -Wno-sign-compare -Wno-char-subscripts -Wno-format -Wno-unused-local-typedefs -fstack-protector -o CMakeFiles/rippled.dir/src/ripple/app/ledger/impl/LedgerReplay.cpp.o -c /home/swd/projs/ripple/mine/src/ripple/app/ledger/impl/LedgerReplay.cpp

It hits the following assert:

dump-ast: /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaType.cpp:8299: void HandleUnkownTypeAttrAsAnnotateTypeAttr({anonymous}::TypeProcessingState&, clang::QualType&, const clang::ParsedAttr&): Assertion `!PA.isArgIdent(Idx)' failed.
[1]    313418 IOT instruction (core dumped)  ./dump-ast /home/swd/apps/clang-latest/bin/clang++           -DCARES_STATICLI

I attempted to debug this. I built the debug version of the libraries and went into gdb and attempted to try to find the offending code so I could create a minimal repro, but unfortunately my unfamiliarity with llvm is an obstacle. Two things we may be able to use as staring points.
In SemaType.cpp:8299
p Str
$8 = {
  Data = 0x5555a3a89598 "__access__",
  Length = 10
}

So the offending attribute is called "access".
In ParseDeclCXX.cpp:2107
p PP.getSourceManager().getPresumedLoc(StartLoc,true)
$6 = {
  Filename = 0x5555a18575d0 "<pasta-input>",
  ID = {
    ID = 851074
  },
  Line = 1716508,
  Col = 1,
  IncludeLoc = {
    ID = 0
  }
}

What I'm trying to do here is find the name of the file that contains the offending code. Some searching pointed me to getPresumedLoc, but clearly <pasta-input> isn't useful to find the offending code. Perhaps you have a suggestion to find the code?
Also, I should mention I was only playing with pasta. Pasta obviously works and it's very possible I'm "holding it wrong". I'm not expecting help here, but thought I'd report the issue in case it was a possible bug in pasta (and will help trying to debug it after regular work hours if it's helpful to you).

<pasta-input> is a synthetic input file that clang's parser operates on. PASTA first runs an instrumented preprocessor on the input, and in the process of this, forms <pasta-input>, which is just a very large std::string in memory. Each unique token is rendered onto a different line of this input file, so that a source location's line number acts as a kind of side-channel for a token index. Previously, I had attempted to patch Clang to embed more information into SourceLocations, but this became problematic as the underlying integral representation of SourceLocations is often stored directly in AST nodes. In retrospect, I regret the choice to use line numbers as a side-channel, as SourceLocations are basically byte offsets, and so I could have just used the byte offset itself with a list of "end of token by offsets", and then some binary searching. Oh well.
Anyway, probably you aren't holding it wrong. The reality is just that PASTA does some sketchy things to achieve its goals. Here's how I would proceed:
Patch the following code into lib/Compile/Run.cpp, around line 353:
  auto fd = open("/tmp/source.cpp", O_TRUNC | O_CREAT | O_WRONLY, 0666);
  write(fd, ast->preprocessed_code.data(), ast->preprocessed_code.size());
  close(fd);

Then build and run, and attach /tmp/source.cpp here. Another thing that could help is seeing the backtrace.

Thanks for the explanation and next steps. The "source.cpp" is too large to paste here, so I created a repo here: https://github.com/seelabs/pasta-debugging/tree/main. "source.cpp" is here: https://github.com/seelabs/pasta-debugging/blob/main/source.cpp and the gdb transcript is here: https://github.com/seelabs/pasta-debugging/blob/main/gdb.txt with both bt full and bt. I'll paste bt here since it's small:
#0  HandleUnkownTypeAttrAsAnnotateTypeAttr (State=..., CurType=..., PA=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaType.cpp:8299
#1  0x0000555559ed322d in processTypeAttrs (state=..., type=..., TAL=TAL_DeclName, attrs=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaType.cpp:8413
#2  0x0000555559ec608b in GetFullTypeForDeclarator (state=..., declSpecType=..., TInfo=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaType.cpp:5810
#3  0x0000555559ec6d41 in clang::Sema::GetTypeForDeclarator (this=0x5555a18ddbf0, D=..., S=0x55556d734890) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaType.cpp:5935
#4  0x000055555909d929 in clang::Sema::HandleDeclarator (this=0x5555a18ddbf0, S=0x55556d734890, D=..., TemplateParamLists=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaDecl.cpp:6304
#5  0x00005555591ed58d in clang::Sema::ActOnCXXMemberDeclarator (this=0x5555a18ddbf0, S=0x55556d734890, AS=clang::AS_public, D=..., TemplateParameterLists=..., BW=0x0, VS=..., InitStyle=clang::ICIS_NoInit) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Sema/SemaDeclCXX.cpp:3510
#6  0x00005555589d2f3c in clang::Parser::ParseCXXInlineMethodDef (this=0x55559f6c1e60, AS=clang::AS_public, AccessAttrs=..., D=..., TemplateInfo=..., VS=..., PureSpecLoc=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseCXXInlineMethods.cpp:42
#7  0x0000555558a18a29 in clang::Parser::ParseCXXClassMemberDeclaration (this=0x55559f6c1e60, AS=clang::AS_public, AccessAttrs=..., TemplateInfo=..., TemplateDiags=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:2956
#8  0x0000555558a1ac52 in clang::Parser::ParseCXXClassMemberDeclarationWithPragmas (this=0x55559f6c1e60, AS=@0x7fffffff8598: clang::AS_public, AccessAttrs=..., TagType=clang::TST_struct, TagDecl=0x5555a64f2098) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:3391
#9  0x0000555558a1baee in clang::Parser::ParseCXXMemberSpecification (this=0x55559f6c1e60, RecordLoc=..., AttrFixitLoc=..., Attrs=..., TagType=25, TagDecl=0x5555a64f2098) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:3595
#10 0x0000555558a1506a in clang::Parser::ParseClassSpecifier (this=0x55559f6c1e60, TagTokKind=clang::tok::kw_struct, StartLoc=..., DS=..., TemplateInfo=..., AS=clang::AS_private, EnteringContext=true, DSC=clang::Parser::DeclSpecContext::DSC_class, Attributes=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:2107
#11 0x00005555589ee713 in clang::Parser::ParseDeclarationSpecifiers (this=0x55559f6c1e60, DS=..., TemplateInfo=..., AS=clang::AS_private, DSContext=clang::Parser::DeclSpecContext::DSC_class, LateAttrs=0x7fffffff9540, AllowImplicitTypename=clang::ImplicitTypenameContext::Yes) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDecl.cpp:4220
#12 0x00005555589cc6cb in clang::Parser::ParseDeclarationSpecifiers (this=0x55559f6c1e60, DS=..., TemplateInfo=..., AS=clang::AS_private, DSC=clang::Parser::DeclSpecContext::DSC_class, LateAttrs=0x7fffffff9540) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/include/clang/Parse/Parser.h:2421
#13 0x0000555558a18209 in clang::Parser::ParseCXXClassMemberDeclaration (this=0x55559f6c1e60, AS=clang::AS_private, AccessAttrs=..., TemplateInfo=..., TemplateDiags=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:2803
#14 0x0000555558a1ac52 in clang::Parser::ParseCXXClassMemberDeclarationWithPragmas (this=0x55559f6c1e60, AS=@0x7fffffffa8c8: clang::AS_private, AccessAttrs=..., TagType=clang::TST_class, TagDecl=0x5555a64eae48) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:3391
#15 0x0000555558a1baee in clang::Parser::ParseCXXMemberSpecification (this=0x55559f6c1e60, RecordLoc=..., AttrFixitLoc=..., Attrs=..., TagType=26, TagDecl=0x5555a64eae48) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:3595
#16 0x0000555558a1506a in clang::Parser::ParseClassSpecifier (this=0x55559f6c1e60, TagTokKind=clang::tok::kw_class, StartLoc=..., DS=..., TemplateInfo=..., AS=clang::AS_none, EnteringContext=true, DSC=clang::Parser::DeclSpecContext::DSC_top_level, Attributes=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:2107
#17 0x00005555589ee713 in clang::Parser::ParseDeclarationSpecifiers (this=0x55559f6c1e60, DS=..., TemplateInfo=..., AS=clang::AS_none, DSContext=clang::Parser::DeclSpecContext::DSC_top_level, LateAttrs=0x0, AllowImplicitTypename=clang::ImplicitTypenameContext::Yes) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDecl.cpp:4220
#18 0x00005555589cc6cb in clang::Parser::ParseDeclarationSpecifiers (this=0x55559f6c1e60, DS=..., TemplateInfo=..., AS=clang::AS_none, DSC=clang::Parser::DeclSpecContext::DSC_top_level, LateAttrs=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/include/clang/Parse/Parser.h:2421
#19 0x00005555589c11f8 in clang::Parser::ParseDeclOrFunctionDefInternal (this=0x55559f6c1e60, Attrs=..., DeclSpecAttrs=..., DS=..., AS=clang::AS_none) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/Parser.cpp:1119
#20 0x00005555589c18e6 in clang::Parser::ParseDeclarationOrFunctionDefinition (this=0x55559f6c1e60, Attrs=..., DeclSpecAttrs=..., DS=0x0, AS=clang::AS_none) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/Parser.cpp:1226
#21 0x00005555589c0c1f in clang::Parser::ParseExternalDeclaration (this=0x55559f6c1e60, Attrs=..., DeclSpecAttrs=..., DS=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/Parser.cpp:1041
#22 0x0000555558a0cfe8 in clang::Parser::ParseInnerNamespace (this=0x55559f6c1e60, InnerNSs=..., index=0, InlineLoc=..., attrs=..., Tracker=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:261
#23 0x0000555558a0cc6e in clang::Parser::ParseNamespace (this=0x55559f6c1e60, Context=clang::DeclaratorContext::File, DeclEnd=..., InlineLoc=...) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDeclCXX.cpp:238
#24 0x00005555589e4dad in clang::Parser::ParseDeclaration (this=0x55559f6c1e60, Context=clang::DeclaratorContext::File, DeclEnd=..., DeclAttrs=..., DeclSpecAttrs=..., DeclSpecStart=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/ParseDecl.cpp:1807
#25 0x00005555589c070a in clang::Parser::ParseExternalDeclaration (this=0x55559f6c1e60, Attrs=..., DeclSpecAttrs=..., DS=0x0) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/Parser.cpp:957
#26 0x00005555589bfa16 in clang::Parser::ParseTopLevelDecl (this=0x55559f6c1e60, Result=..., ImportState=@0x7fffffffc6c8: clang::Sema::ModuleImportState::NotACXX20Module) at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/Parse/Parser.cpp:743
#27 0x00005555562df830 in pasta::CompileJob::Run[abi:cxx11]() const (this=0x555561541be0) at /home/swd/projs/common/pasta/lib/Compile/Run.cpp:425
#28 0x0000555555ef7b59 in main (argc=81, argv=0x7fffffffcd38) at /home/swd/projs/common/pasta/bin/DumpAST/Main.cpp:135

I also looked at source.cpp around line 1716508. Here's what appears there:
struct
_Stop_state_ref
{
_Stop_state_ref
(
)
=
default
;
[
[
__gnu__
::
__access__
(
__none__
,
2
)
]
]

@pgoodman I found a simple way to reproduce the error.

Create a file called "repo.cpp" with one line #include <stop_token>
run ./dump-ast g++ -std=c++20 repo.cpp This will hit the assert above
run ./dump-ast g++ repo.cpp This will work as expected (note: no `-std=c++20)

So the culprit is -std=c++20.

Okay this is a bug in one of our patches: HandleUnkownTypeAttrAsAnnotateTypeAttr.
We've made this patch with the intent of implicitly converting things like __attribute__((hello_world("a"))) into __attribute__((annotate("hello_world", "a"))), though there are clearly some corner cases that are triggering assertions. I don't have the spare hours right now to fix this bug in our patches. Can you try mitigating it with the following change: Change this true to false: https://github.com/trailofbits/pasta/blob/master/lib/Compile/Run.cpp#L242-L244

Thanks! I made the suggested change and that successfully ran against the minimal repro. I then tried against my real codebase and got:
A clang diagnostic or uncompilable error was produced when trying to get an AST due to error: /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/include/xmmintrin.h:136:19 use of undeclared identifier '__builtin_ia32_addss'

I don't know if that's related to disabling the "unknown attribute" patch or not. (I know you don't have time to dig into this now, I just thought I'd report it anyway).

The missing builtin looks to be a GCC-specific intrinsic that Clang doesn't seem to have. There are a number of others that are related, and could be harvested from this list. Fixing this involves adding entries into this file. This mirrors how Clang adds them, but we do it retroactively and in a slightly hacky way that generally gets the job done without having to patch Clang.
Could you try making the following additions to our BuiltinsX86.h file, and testing them out?  I modified the file pasta/lib/Compile/BuiltinsX86.h by adding the code above, recompiled, and re-ran. I also did a "make clean" and recompiled to double check. (as a dummy-check, here's my edited file as a gist: https://gist.github.com/seelabs/9a63d38260caf1ddce7bf7cdf043f8ae)

Oh I'm a dummy. I shouldn't have wrapped all those builtin names with double quotes. Can you try with this?

UNREACHABLE executed at /home/swd/projs/common/cxx-common-debug/vcpkg/buildtrees/llvm-16/src/org-16.0.5-90a3d25b70.clean/clang/lib/AST/ASTContext.cpp:11250!

I went into gdb and looked at the offending Str parameter to DecodeTypeFromStr. It was: ", i". So it's choking on the ,. I don't have time to dig into this right now, but I'll try to look later and see if I can locate the offending code.

From our dumped source.cpp, it's pointing to this as the culprit:
extern
__inline
__m128
__attribute__
(
(
__gnu_inline__
,
__always_inline__
,
__artificial__
)
)
_mm_cvtsi32_ss
(
__m128
__A
,
int
__B
)
{
return
(
__m128
)
__builtin_ia32_cvtsi2ss
(
(
__v4sf
)
__A
,
__B
)
;
}

The actual line it's pointing at is the one with __builtin_ia32_cvtsi2ss, but given the value of Str I'm guessing we should be looking at:
__m128
__A
,
int

Try this?
 I'm having trouble finding the documentation I need for these missing functions (the gcc manual doesn't seem to have them) and also the correct strings for the types. I'll spend time after work to poke at this, but it may be a while before I'm able to make a patch (but hopefully I'll learn something along the way).

Oh I'm making a script for this! I'll be bulk grabbing them from CBMC, which has a lot of forward declarations. It turns out there is some other stuff in the Python API that has required fixing in order for me to make the script, so it's taking me a bit of time :-)

My in-progress work is in this branch.

Here's what I mean from taking the declarations from CBMC. The idea is to auto-generate the TARGET_BUILTIN macros from the declarations in a few of these header files.

Yep, progress, but it looks like we're still missing some:
A clang diagnostic or uncompilable error was produced when trying to get an AST due to error: /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/include/xmmintrin.h:827:1 definition of builtin function '_mm_getcsr'

Hi @seelabs, I've updated the previously linked BuiltinsX86.h file, can you try this new one?

I still get an error, but a different one. It's not complaining about _m_empty
A clang diagnostic or uncompilable error was produced when trying to get an AST due to error: /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/include/mmintrin.h:70:1 definition of builtin function '_m_empty'

I may need to patch clang if I want to generically handle (re)definitions of possible intrinsics. This will take deeper investigation.

Note to self: Try adding a check for FD->getBuiltinID() in this function from SemaDecl.cpp:
/// canRedefineFunction - checks if a function can be redefined. Currently,
/// only extern inline functions can be redefined, and even then only in
/// GNU89 mode.
static bool canRedefineFunction(const FunctionDecl *FD,
                                const LangOptions& LangOpts) {
  return ((FD->hasAttr<GNUInlineAttr>() || LangOpts.GNUInline) &&
          !LangOpts.CPlusPlus &&
          FD->isInlineSpecified() &&
          FD->getStorageClass() == SC_Extern);
}

@pgoodman Just a quick note that I'll be traveling Thursday afternoon-Sunday and will be AFK.

Alright I've recently been making progress on this issue. I've been moving our various clang patches into our pasta branch of trail-of-forks/llvm-project. This has been going on as I port things over to Clang 17.

Alright, the llvm17 branch of PASTA now works with #include <stop_token> when using g++ as the compiler. This branch of PASTA now has a much simpler build process, and left to its own devices, will build a vendored LLVM (with all of our requisite patches) and nanobind (for Python bindings). I hope to have it merged soon.

@seelabs if you have the time, can you test the master branch?

@pgoodman Nice! I'll test this after work today.

@pgoodman I built the master branch and ran the following command (similar to what I ran before, but using print-ast instead of dump-ast, which I don't see anymore):
./print-ast /home/swd/apps/clang-latest/bin/clang++ -DBOOST_ASIO_DISABLE_HANDLER_TYPE_REQUIREMENTS -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_CONTAINER_FWD_BAD_DEQUE -DBOOST_COROUTINES_NO_DEPRECATION_WARNING -DBOOST_FILESYSTEM_DEPRECATED -DBOOST_STACKTRACE_ADDR2LINE_LOCATION=\\\"/usr/bin/addr2line\\\" -DBOOST_STACKTRACE_USE_ADDR2LINE -DBOOST_STACKTRACE_USE_BACKTRACE -DBOOST_STACKTRACE_USE_NOOP -DCARES_STATICLIB -DDATE_HEADER_ONLY -DDEBUG -DENABLE_TESTS -DGIT_COMMIT_HASH=\\\"ed9064ce3f6de6da6b63417e59f3100c8e6c4c6d\\\" -DHAS_UNCAUGHT_EXCEPTIONS=1 -DOPENSSL_NO_SSL2 -D_DEBUG -I/home/swd/projs/ripple/mine/src/ed25519-donna -I/home/swd/projs/ripple/mine/src/secp256k1/include -I/home/swd/projs/ripple/mine/src -isystem /home/swd/.conan/data/boost/1.82.0/_/_/package/f81afbcfa21cf6994cf0e45c1b11229c01c767a7/include -isystem /home/swd/.conan/data/openssl/1.1.1u/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/.conan/data/libarchive/3.6.2/_/_/package/d9fea6983af2a77bcbe3f0b088cea5aef9308bd7/include -isystem /home/swd/.conan/data/lz4/1.9.3/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/projs/ripple/mine/cur_build/proto_gen_grpc -isystem /home/swd/.conan/data/grpc/1.50.1/_/_/package/d156c58fd512defbc1155e665684d7875e800ba9/include -isystem /home/swd/.conan/data/abseil/20220623.0/_/_/package/e84b6d643e7f97d33bf72700134618fbae8bbbf6/include -isystem /home/swd/.conan/data/c-ares/1.19.0/_/_/package/ed86cef4487c6b9ce327a03d24ced8142000e8b9/include -isystem /home/swd/.conan/data/re2/20230301/_/_/package/e84b6d643e7f97d33bf72700134618fbae8bbbf6/include -isystem /home/swd/.conan/data/zlib/1.2.13/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/.conan/data/protobuf/3.21.9/_/_/package/681b3b1dffc7e4dc6f5551cdb6e1fe56bdda3e85/include -isystem /home/swd/projs/ripple/mine/cur_build/proto_gen -isystem /home/swd/projs/ripple/mine/cur_build/proto_gen/src/ripple/proto -isystem /home/swd/.conan/data/soci/4.0.3/_/_/package/dc82e3681e64ed36c447531c9e4883a5c616a774/include -isystem /home/swd/.conan/data/bzip2/1.0.8/_/_/package/5e357164f23f7c4e38ebe87433827878dbe1a74c/include -isystem /home/swd/.conan/data/libbacktrace/cci.20210118/_/_/package/06b9cd1c4dccbb163a99056eda646b0e168548fc/include -isystem /home/swd/.conan/data/sqlite3/3.42.0/_/_/package/ae0e146c4c82ac1e46c279d15c964c80fedbdf5f/include -isystem /home/swd/.conan/data/nudb/2.0.8/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include -isystem /home/swd/.conan/data/date/3.0.1/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include -m64 -stdlib=libstdc++ -Wall -Wdeprecated -Wextra -Wno-unused-parameter -g -std=c++20 -fPIE -frtti -Wnon-virtual-dtor -Wno-sign-compare -Wno-char-subscripts -Wno-format -Wno-unused-local-typedefs -fstack-protector -o CMakeFiles/rippled.dir/src/ripple/app/ledger/impl/LedgerReplay.cpp.o -c /home/swd/projs/ripple/mine/src/ripple/app/ledger/impl/LedgerReplay.cpp

I get the following error:
A clang diagnostic or uncompilable error was produced when trying to get an AST due to error: /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include/xmmintrin.h:827:1 definition of builtin function '_mm_getcsr'

Excellent. It seems I didn't sufficiently patch clang. I thought I had covered this "definition of builtin function" error but didn't. This gives me something to go on :-)

That should be fine :-) And things are still broken in the same way? If so, can you confirm that vendor/llvm-project/src is at or after 4ab1f8b?

vendor/llvm-project/src is at 4783e3a13333 Bug fix. So maybe this is the problem?

I just now re-pulled and confirmed that vendor/llvm-project/src is at 4ab1f8b9f449 Don't error on redefinition of some builtins Let me rebuild with this and I'll report back.

I just recompiled and re-ran. I'm still seeing the error:
A clang diagnostic or uncompilable error was produced when trying to get an AST due to error: /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include/xmmintrin.h:827:1 definition of builtin function '_mm_getcsr'

Alright, I'm finally reproducing this:
./vendor/pasta/build/bin/PrintAST/print-ast clang -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/12/include -isystem /usr/local/include -isystem /usr/include/x86_64-linux-gnu -isystem /usr/include/x86_64-linux-gnu -isystem /usr/include /tmp/test.c
A clang diagnostic or uncompilable error was produced when trying to get an AST due to error: /usr/lib/gcc/x86_64-linux-gnu/12/include/xmmintrin.h:824:1 definition of builtin function '_mm_getcsr'

With:
#include <xmmintrin.h>

Alright, I think that one issue is that _mm_getcsr is a defined builtin by Clang.
TARGET_HEADER_BUILTIN(_mm_getcsr, "Ui", "nh", XMMINTRIN_H, ALL_LANGUAGES, "sse")

I'm leaning in the direction of totally disabling the diagnostic in Clang, rather than making it conditional on something being  a pasta builtin.

Urgh, __builtin_shuffle is the next thing handle, and it's annoying because its return type varies based on the parameter types.

Nice! I'm glad you're able to repro this locally, that's a big step for sure.

Dealing with __builtin_shuffle is going to be a larger effort, and require a different approach than the other builtins. I can't project a timeline for that fix atm. The best remediation for the time being is to run pasta on clang-based compile commands, and probably compile pasta with a version of clang from your package manager (e.g. clang-15 or clang-16).


Weird behaviour with uint64

[X] I am using the latest released version of Numba (most recent is visible in
the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[X] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

There is some weird overflow magic going on.
With numba:
import numba
@numba.njit(numba.uint64(numba.uint64, numba.uint64, numba.uint64))
def foo(a, b, x):
    return (a * x + b) %<PHONE_NUMBER>23837

foo(2744776747,<PHONE_NUMBER>,<PHONE_NUMBER>)

The result is<PHONE_NUMBER>21829, which is incorrect.
Correct one should be:<PHONE_NUMBER>03616.
(C++ gets it right: https://ideone.com/u50a7Q)

Thanks for the report. I think what you are seeing is because the integer constant<PHONE_NUMBER>23837 is considered an int64 (CPython default integer type is signed) which then has an impact on the modulo operation as the overflowed result of (a * x + b) is interpreted as signed. The following works as expected, note the use of .inspect_types() at the end to look at the type Numba inferred for each variable:
import numba

@numba.njit(numba.uint64(numba.uint64, numba.uint64, numba.uint64))
def foo(a, b, x):
    return (a * x + b) % numba.uint64(515024571323837)

args =<PHONE_NUMBER>,<PHONE_NUMBER>,<PHONE_NUMBER>)
print(foo.py_func(*args)) # this is the result from the interpreter
print(foo(*args))         # this is the result from compiled code
assert foo.py_func(*args) == foo(*args)

foo.inspect_types()

Oh and C++ get's it right because the const is specified as<PHONE_NUMBER>23837ull, the above does the equivalent.

@stuartarchibald thanks for reply.
Btw C++ gets it right even without ull annotation. https://ideone.com/CwdbAi

hmm, that's interesting. I think this just comes down to Numba deciding that the const is signed, which is default, and as a result it "infects" the modulo. Seems like, from the disassembly, that C++ doesn't suffer from this.

That's a potential enhancement we can do.  The inspect types shows:
def foo(a, b, x):

    # --- LINE 5 ---
    #   a = arg(0, name=a)  :: uint64
    #   b = arg(1, name=b)  :: uint64
    #   x = arg(2, name=x)  :: uint64
    #   $0.3 = a * x  :: uint64
    #   del x
    #   del a
    #   $0.5 = $0.3 + b  :: uint64
    #   del b
    #   del $0.3
    #   $const0.6 = const(int,<PHONE_NUMBER>23837)  :: Literal[int](515024571323837)
    #   $0.7 = $0.5 % $const0.6  :: int64
    #   del $const0.6
    #   del $0.5
    #   $0.8 = cast(value=$0.7)  :: uint64
    #   del $0.7
    #   return $0.8

    return (a * x + b) %<PHONE_NUMBER>23837

Where the modulo operator is seeing $const0.6 as a Literal[int] type.  The modulo (and all binary arithmetic-operators) can be modified to cast any Literal type to the type of the other operand (if non-Literal).

The whole problem comes from the (a * x + b) part resulting in a number that takes all 64-bit (MSB set).  But, Numba prefers to use a signed modulo (vs C/C++ prefers unsigned) when the operands have differing signedness.  This causes the result of (a * x + b) to be implicitly casted to signed int64 and misinterpreting the MSB as sign-bit.

I'm closing this issue since it can be resolve by forcing a uint64 modulo by explicitly casting the RHS.


createBranch API params

The API in the documentation for Repository.createBranch is written as : repository.createBranch(name, commit, force)
But in the example over here: https://github.com/nodegit/nodegit/blob/master/examples/create-branch.js,  it is used as:
return repo.createBranch(
  "new-branch",
  commit,
  0,
  repo.defaultSignature(),
  "Created new-branch on HEAD");

What are the 4th and 5th parameters given to the function? Am I missing something / looking at the wrong documentation or example?

I think the example is out of date. We'll need to update that example!

If it's just adjusting the example in 'create-branch.js' to match the current documentation, I can take care of that when I get home in a few.

So here is the updated code within the create-branch.js file. Let me know if I need to change anything, otherwise, I can submit a PR as soon as someone gives me the green light on the update.

Yes, I believe that looks correct. The parameters are name of branch, commit to create branch at, and force (overwrite branch if it exists).

Yes, I left the original first three parameters as they were. I simply removed the 4th and 5th parameters. PR created, thanks @implausible

Closed by https://github.com/nodegit/nodegit/pull/1552

Thanks for the quick fix!


env_file is incorrectly used by compose for variable interpolation

According to the response from the Docker developers:

env_file is not used for variable interpolation in the container specification used by compose to create containers, but passed to the docker API as runtime definition for the process runing inside the container.
...

So docker-compose.yaml in 8895b742384181ad8abc6234029f5f95bfedbcc7 uses an undefined behavior to construct itself, which may have unintended effects on some systems. (In fact, as mentioned in the issue above, this doesn't work properly on Windows. Such as fauxpilot-windows)
I noticed this was already the second bug in #49 and @dslandry said he didn't finish the check, should we completely re-evaluate and check this PR?

I rechecked this PR as best I could and tried to fix some issues.
And sorry that my commits were so fragmented, it's due to my computer being broken, so I was forced to use web editing.😿

#73 should have fixed this and will be testing on Windows later.

Done.


Feature/item disabled flag

KEYWORD #45

Merged latest patch's develop branch

Looking into fixing the issue of the decompiled data containing 1/0, true/false, and 'true'/'false'

Looking into fixing the issue of the decompiled data containing 1/0, true/false, and 'true'/'false'

Fixed! Decompiled data is one of [True, False, 'true', 'false'] for some reason.


Error when running bash inside container

[vagrant@localhost buildah]$ git rev-parse HEAD
2048c74819df152877183be35ab9358ec4fff534
[vagrant@localhost buildah]$ sudo buildah from centos:7
Getting image source signatures
Copying blob sha256:343b0936103607602d236363460c0368a1cad0ef58a534d5a5c2ecd9f8c2f3dd
 67.12 MiB / 67.26 MiB [=======================================================]
Copying config sha256:8140d0c64310d4e290bf3938757837dbb8f806acba0cb3f6a852558074345348
 0 B / 1.79 KiB [--------------------------------------------------------------]
Writing manifest to image destination
Storing signatures
centos-working-container
[vagrant@localhost buildah]$ sudo buildah containers
CONTAINER ID IMAGE ID     IMAGE NAME CONTAINER NAME
cc12d1d03918 1ac05484924e centos:7   centos-working-container
[vagrant@localhost buildah]$ sudo buildah run cc12d1d03918 /bin/sh
json: cannot unmarshal object into Go value of type []string

Which version of runc do you have installed (runc --version)?  We use it to handle run commands and RUN instructions in Dockerfiles, and the format of the configuration that we create for it had some not-backward-compatible changes land in the last few versions.  The version of the runtime spec that buildah currently uses is 1.0.0-rc5.

I do not appear to have runc installed. It's not part of any of the install instructions. Should it be?

Yeah, it should be.

[root@localhost ~]# buildah from fedora:25
Getting image source signatures
Copying blob sha256:691bc14ee27487db536172a1fcdbbf956f460d1e1e1b201828e3a2bab81c5ec8
 72.10 MiB / 72.22 MiB [=======================================================]
Copying config sha256:15895ef0b3b2b4e61bf03d38f82b42011ff7f226c681705a4022ae3d1d643888
 0 B / 2.29 KiB [--------------------------------------------------------------]
Writing manifest to image destination
Storing signatures
fedora-working-container
[root@localhost ~]# buildah containers
CONTAINER ID IMAGE ID     IMAGE NAME CONTAINER NAME
832c55b9ab39 4742dd78929d fedora:25  fedora-working-container
[root@localhost ~]# buildah run 832c55b9ab39 /bin/sh
json: cannot unmarshal object into Go value of type []string
[root@localhost ~]# rpm -q runc
runc-1.0.0-5.rc2.gitc91b5be.fc25.x86_64

So fc25 doesn't have the version of runc needed?

If this helps...
[root@localhost ~]# buildah --debug run 832c55b9ab39 /bin/sh
INFO[0000] [graphdriver] using prior storage driver "overlay2"
DEBU[0000] using "/tmp/buildah016828953" to hold bundle data
DEBU[0000] config = {"ociVersion":"1.0.0-rc5","platform":{"os":"linux","arch":"amd64"},"process":{"terminal":true,"consoleSize":{"height":0,"width":0},"user":{"uid":0,"gid":0},"args":["/bin/sh"],"env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","TERM=xterm","DISTTAG=f25docker","FGC=f25","FBR=f25"],"cwd":"/","capabilities":{"bounding":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"effective":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"inheritable":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"permitted":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"],"ambient":["CAP_CHOWN","CAP_DAC_OVERRIDE","CAP_FSETID","CAP_FOWNER","CAP_MKNOD","CAP_NET_RAW","CAP_SETGID","CAP_SETUID","CAP_SETFCAP","CAP_SETPCAP","CAP_NET_BIND_SERVICE","CAP_SYS_CHROOT","CAP_KILL","CAP_AUDIT_WRITE"]},"rlimits":[{"type":"RLIMIT_NOFILE","hard":1024,"soft":1024}]},"root":{"path":"/var/lib/containers/storage/overlay2/d6067a338586d8ca292021e8ebb75167c0e8ec5315fee028924d75865d296ba0/merged"},"hostname":"mrsdalloway","mounts":[{"destination":"/proc","type":"proc","source":"proc"},{"destination":"/dev","type":"tmpfs","source":"tmpfs","options":["nosuid","strictatime","mode=755","size=65536k"]},{"destination":"/dev/pts","type":"devpts","source":"devpts","options":["nosuid","noexec","newinstance","ptmxmode=0666","mode=0620","gid=5"]},{"destination":"/dev/shm","type":"tmpfs","source":"shm","options":["nosuid","noexec","nodev","mode=1777","size=65536k"]},{"destination":"/dev/mqueue","type":"mqueue","source":"mqueue","options":["nosuid","noexec","nodev"]},{"destination":"/sys","type":"sysfs","source":"sysfs","options":["nosuid","noexec","nodev","ro"]},{"destination":"/etc/hosts","type":"bind","source":"/etc/hosts","options":["rbind","ro"]},{"destination":"/etc/resolv.conf","type":"bind","source":"/etc/resolv.conf","options":["rbind","ro"]}],"linux":{"resources":{"devices":[{"allow":false,"access":"rwm"}]},"namespaces":[{"type":"pid"},{"type":"ipc"},{"type":"uts"},{"type":"mount"}],"seccomp":{"defaultAction":"SCMP_ACT_ERRNO","architectures":["SCMP_ARCH_X86_64","SCMP_ARCH_X86","SCMP_ARCH_X32"],"syscalls":[{"names":["accept","accept4","access","alarm","bind","brk","capget","capset","chdir","chmod","chown","chown32","clock_getres","clock_gettime","clock_nanosleep","close","connect","copy_file_range","creat","dup","dup2","dup3","epoll_create","epoll_create1","epoll_ctl","epoll_ctl_old","epoll_pwait","epoll_wait","epoll_wait_old","eventfd","eventfd2","execve","execveat","exit","exit_group","faccessat","fadvise64","fadvise64_64","fallocate","fanotify_mark","fchdir","fchmod","fchmodat","fchown","fchown32","fchownat","fcntl","fcntl64","fdatasync","fgetxattr","flistxattr","flock","fork","fremovexattr","fsetxattr","fstat","fstat64","fstatat64","fstatfs","fstatfs64","fsync","ftruncate","ftruncate64","futex","futimesat","getcpu","getcwd","getdents","getdents64","getegid","getegid32","geteuid","geteuid32","getgid","getgid32","getgroups","getgroups32","getitimer","getpeername","getpgid","getpgrp","getpid","getppid","getpriority","getrandom","getresgid","getresgid32","getresuid","getresuid32","getrlimit","get_robust_list","getrusage","getsid","getsockname","getsockopt","get_thread_area","gettid","gettimeofday","getuid","getuid32","getxattr","inotify_add_watch","inotify_init","inotify_init1","inotify_rm_watch","io_cancel","ioctl","io_destroy","io_getevents","ioprio_get","ioprio_set","io_setup","io_submit","ipc","kill","lchown","lchown32","lgetxattr","link","linkat","listen","listxattr","llistxattr","_llseek","lremovexattr","lseek","lsetxattr","lstat","lstat64","madvise","memfd_create","mincore","mkdir","mkdirat","mknod","mknodat","mlock","mlock2","mlockall","mmap","mmap2","mprotect","mq_getsetattr","mq_notify","mq_open","mq_timedreceive","mq_timedsend","mq_unlink","mremap","msgctl","msgget","msgrcv","msgsnd","msync","munlock","munlockall","munmap","nanosleep","newfstatat","_newselect","open","openat","pause","pipe","pipe2","poll","ppoll","prctl","pread64","preadv","prlimit64","pselect6","pwrite64","pwritev","read","readahead","readlink","readlinkat","readv","recv","recvfrom","recvmmsg","recvmsg","remap_file_pages","removexattr","rename","renameat","renameat2","restart_syscall","rmdir","rt_sigaction","rt_sigpending","rt_sigprocmask","rt_sigqueueinfo","rt_sigreturn","rt_sigsuspend","rt_sigtimedwait","rt_tgsigqueueinfo","sched_getaffinity","sched_getattr","sched_getparam","sched_get_priority_max","sched_get_priority_min","sched_getscheduler","sched_rr_get_interval","sched_setaffinity","sched_setattr","sched_setparam","sched_setscheduler","sched_yield","seccomp","select","semctl","semget","semop","semtimedop","send","sendfile","sendfile64","sendmmsg","sendmsg","sendto","setfsgid","setfsgid32","setfsuid","setfsuid32","setgid","setgid32","setgroups","setgroups32","setitimer","setpgid","setpriority","setregid","setregid32","setresgid","setresgid32","setresuid","setresuid32","setreuid","setreuid32","setrlimit","set_robust_list","setsid","setsockopt","set_thread_area","set_tid_address","setuid","setuid32","setxattr","shmat","shmctl","shmdt","shmget","shutdown","sigaltstack","signalfd","signalfd4","sigreturn","socket","socketcall","socketpair","splice","stat","stat64","statfs","statfs64","symlink","symlinkat","sync","sync_file_range","syncfs","sysinfo","syslog","tee","tgkill","time","timer_create","timer_delete","timerfd_create","timerfd_gettime","timerfd_settime","timer_getoverrun","timer_gettime","timer_settime","times","tkill","truncate","truncate64","ugetrlimit","umask","uname","unlink","unlinkat","utime","utimensat","utimes","vfork","vmsplice","wait4","waitid","waitpid","write","writev"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["personality"],"action":"SCMP_ACT_ALLOW","args":[{"index":0,"value":0,"valueTwo":0,"op":"SCMP_CMP_EQ"},{"index":0,"value":8,"valueTwo":0,"op":"SCMP_CMP_EQ"},{"index":0,"value":4294967295,"valueTwo":0,"op":"SCMP_CMP_EQ"}],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["chroot"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["clone"],"action":"SCMP_ACT_ALLOW","args":[{"index":0,"value":2080505856,"valueTwo":0,"op":"SCMP_CMP_MASKED_EQ"}],"comment":""},{"names":["arch_prctl"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""},{"names":["modify_ldt"],"action":"SCMP_ACT_ALLOW","args":[],"comment":""}]}}}
json: cannot unmarshal object into Go value of type []string
DEBU[0000] error running runc [/bin/sh]: exit status 1
DEBU[0000] error running [/bin/sh] in container "fedora-working-container": exit status 1

Okay, upgraded to rc5 and it worked. Leaving this open in the case you want to use it as an opportunity to version-check dependencies, make error message more informative, or add documentation of the requirement. Thanks!


Support mechanism to provide external zookeeper-server list to build global/configuration zookeeper

Fixes #268
Motivation
Right now, chart dynamically creates zk cluster with zk pods initialized in the same namespace. However, for global/configuration zookeeper, user requires to build zk clusters with pods deployed in different namespaces. Therefore, user needs a mechanism to pass an external list of zk-servers to the chart and build zk-cluster with pods across different namespaces.
Modification

Chart should be considering zk-value's configuration for external zookeeper and generate zk-configuration file with appropriate zk-server list and unique id of that zookeeper.

This PR sets ZOOKEEPER_SERVERS value provided by user and also sets override-value flag which will be used by generate-zookeeper-config.sh to override external zk list in config file and assign appropriate id to the host.
https://github.com/apache/pulsar/pull/15987 fixes generate-zookeeper-config.sh changes.
Result

User can add ZOOKEEPER_SERVERS string into zookeeper.configData in Values.yaml file to override external zk-server list.

I missed a minor detail with how the feature is configured. I proposed a fix here https://github.com/apache/pulsar-helm-chart/pull/308.


gender strings not in code system -> other

tested locally
strings not in FHIR administrative gender code system are converted to "other"


testing: fuzzer doesn't timeout infinite loops

What version of Go are you using (go version)?

$ go version
go version devel go1.18-d4139083204 Fri Sep 24 07:22:13 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/stevie/.cache/go-build"
GOENV="/home/stevie/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/stevie/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/stevie/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/stevie/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/stevie/sdk/gotip/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.18-d4139083204 Fri Sep 24 07:22:13 2021 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/stevie/code/go/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2423746336=/tmp/go-build -gno-record-gcc-switches"

What did you do?

func FuzzInfinite(f *testing.F) {
	f.Fuzz(func(t *testing.T, a int) {
		if a > 1000 {
			for {
			}
		}
	})

}

gotip test -fuzz=FuzzInfinite
warning: starting with empty corpus
fuzz: elapsed: 0s, execs: 0 (0/sec), interesting: 0
fuzz: elapsed: 3s, execs: 24 (8/sec), interesting: 1
fuzz: elapsed: 6s, execs: 24 (4/sec), interesting: 1
fuzz: elapsed: 9s, execs: 24 (3/sec), interesting: 1
fuzz: elapsed: 12s, execs: 24 (2/sec), interesting: 1
fuzz: elapsed: 15s, execs: 24 (2/sec), interesting: 1
fuzz: elapsed: 18s, execs: 24 (1/sec), interesting: 1
fuzz: elapsed: 21s, execs: 24 (1/sec), interesting: 1
fuzz: elapsed: 24s, execs: 24 (1/sec), interesting: 1
fuzz: elapsed: 27s, execs: 24 (1/sec), interesting: 1

...
fuzz: elapsed: 1h11m48s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h11m51s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h11m54s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h11m57s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h12m0s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h12m3s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h12m6s, execs: 24 (0/sec), interesting: 1
fuzz: elapsed: 1h12m9s, execs: 24 (0/sec), interesting: 1

What did you expect to see?
I'd expect to see a limit on how long the function under test is allowed to run. Finding accidental infinite loops (or even accidentally quadratic functions) is expected of a fuzzer e.g. these from the go-fuzz trophies:
https://github.com/lytics/confl/issues/6
https://github.com/rasky/go-lzo/commit/22d79fde8006d605b307e3d58b775d9c1f756d52
https://github.com/buger/jsonparser/issues/179
https://github.com/cronokirby/saferith/commit/d39f5a274f7c3b8c8d60456b1525cce26ffacfe7
Ideally, the fuzzer would timeout the worker and store the input as a crasher in the corpus. FWIW go-fuzz seems to set the timeout at 10s.
What did you see instead?
Runs for over an hour without timing out.

Duplicate of #48591. We definitely need this though.
The main blocker is deciding the API/CLI to set the timeout. #48157 is a proposal for per-test timeouts, and the interface would be shared between tests and fuzzing.


"Letca" , "Ciula" , "Cozla" , "Cuciulat" , "Lemniu" , "Purcăreț" , "Șoimușeni" , "Toplița" , "Vălișoara" are listed in the drop-down menu

The villages are listed in the drop-down menu alongside its corresponding county and city, according to the law
Preconditions : the  website is up and runing. After every step delete the text you typed from the search bar.

Step 1
Write in the search bar "Letca"

Expected results
The location appears in the drop-down menu as "Sat Letca, SĂLAJ (Letca)"

Step 2
Write in the search bar "Ciula"

Expected results
The location appears in the drop-down menu as "Sat Ciula, SĂLAJ (Letca)"

Step 3
Write in the search bar "Cozla"

Expected results
The location appears in the drop-down menu as "Sat Cozla, SĂLAJ (Letca)"

Step 4
Write in the search bar "Cuciulat"

Expected results
The location appears in the drop-down menu as "Sat Cuciulat, SĂLAJ (Letca)"

Step 5
Write in the search bar "Lemniu"

Expected results
The location appears in the drop-down menu as "Sat Lemniu, SĂLAJ (Letca)"

Step 6
Write in the search bar "Purcăreț"

Expected results
The location appears in the drop-down menu as "Sat Purcăreț, SĂLAJ (Letca)"

Step 7
Write in the search bar "Purcăreț"

Expected results
The location appears in the drop-down menu as "Sat Purcăreț, SĂLAJ (Letca)"

Step 9
Write in the search bar "Vălișoara"

Expected results
The location appears in the drop-down menu as "Sat Vălișoara, SĂLAJ (Letca)"


[improve][misc] Upgrade Netty to 4.1.85.Final and Netty Tcnative to 2.0.54.Final

Motivation

Netty 4.1.85 includes an important fix to FlowControlHandler that is used in Pulsar, see release notes https://netty.io/news/2022/11/09/4-1-85-Final.html

Modifications

Upgrade Netty to 4.1.85.Final
Update Netty Tcnative to 2.0.54.Final
Remove versions from pom.xml that are handled by netty-bom
Upgrade netty-iouring.version to 0.0.16.Final which is compatible with 4.1.85.Final

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository: https://github.com/lhotari/pulsar/pull/103

Codecov Report

Merging #18599 (8084010) into master (cd85a67) will decrease coverage by 10.28%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master   #18599       +/-   ##
=============================================
- Coverage     47.39%   37.10%   -10.29%
+ Complexity    10479     1966     -8513
=============================================
  Files           698      209      -489
  Lines         68070    14414    -53656
  Branches       7279     1573     -5706
=============================================
- Hits          32264     5349    -26915
+ Misses        32228     8480    -23748
+ Partials       3578      585     -2993

Flag
Coverage Δ

unittests
37.10% <ø> (-10.29%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...apache/pulsar/client/impl/AutoClusterFailover.java
70.00% <0.00%> (-6.12%)
:arrow_down:

.../pulsar/client/impl/ControlledClusterFailover.java
58.87% <0.00%> (-3.74%)
:arrow_down:

.../org/apache/pulsar/client/impl/ConnectionPool.java
37.43% <0.00%> (-1.03%)
:arrow_down:

...e/pulsar/broker/service/EntryBatchIndexesAcks.java

...d/jcloud/impl/BlobStoreManagedLedgerOffloader.java

.../org/apache/pulsar/broker/cache/BundlesQuotas.java

...e/pulsar/broker/stats/metrics/AbstractMetrics.java

...g/apache/bookkeeper/mledger/ManagedLedgerInfo.java

...ar/broker/service/persistent/ShadowReplicator.java

...apache/pulsar/broker/admin/v1/SchemasResource.java

... and 483 more

There's an odd StackoverflowError in the build now. Attempts to fix are PRs #18604 and #18602

Simple instructions to reproduce the issue:
git clone https://github.com/apache/pulsar
cd pulsar
# checkout PR 18599 in detached mode
git fetch origin pull/18599/head && git checkout FETCH_HEAD
mvn -Pcore-modules,-main -T 1C clean install -DskipTests -Dspotbugs.skip=true
# run test in a loop until it fails
while mvn -DredirectTestOutputToFile=false -DtestRetryCount=0 test -pl pulsar-broker -Dtest=PatternMultiTopicsConsumerTest#testNotifications; do echo "Rerunning..."; done

Now downgrade Netty version to 4.1.84.Final
perl -i -p -e 's/4.1.85.Final/4.1.84.Final/g' $(git grep -l 4.1.85.Final)
# run test in a loop, it doesn't fail with 4.1.84.Final
while mvn -DredirectTestOutputToFile=false -DtestRetryCount=0 test -pl pulsar-broker -Dtest=PatternMultiTopicsConsumerTest#testNotifications; do echo "Rerunning..."; done

This proves that changes in https://github.com/netty/netty/pull/12888 are the source of the regression in Pulsar:
# revert any changes (like downgrade to 4.1.84.Final)
git reset --hard HEAD
pushd
# patch netty-common-4.1.85.Final.jar file
cd ~/.m2/repository/io/netty/netty-common/4.1.85.Final
cp -p netty-common-4.1.85.Final.jar netty-common-4.1.85.Final.jar.orig
unzip ../4.1.84.Final/netty-common-4.1.84.Final.jar 'io/netty/util/HashedWheelTimer*'
zip netty-common-4.1.85.Final.jar io/netty/util/HashedWheelTimer*.class
rm -rf io/

# go back to the checkout directory
popd
# run test in a loop, it doesn't fail with 4.1.85.Final patched with HashedWheelTimer class from 4.1.84.Final
while mvn -DredirectTestOutputToFile=false -DtestRetryCount=0 test -pl pulsar-broker -Dtest=PatternMultiTopicsConsumerTest#testNotifications; do echo "Rerunning..."; done

Although the Netty upgrade makes the problem appear in Pulsar, it might be a bug in Pulsar that causes the problem. @andrasbeni Do you have any ideas why PatternMultiTopicsConsumerTest fails with Netty 4.1.85? (there's instructions to reproduce in https://github.com/apache/pulsar/pull/18599#issuecomment-1327794984)

Although the Netty upgrade makes the problem appear in Pulsar, it might be a bug in Pulsar that causes the problem. @andrasbeni Do you have any ideas why PatternMultiTopicsConsumerTest fails with Netty 4.1.85? (there's instructions to reproduce in https://github.com/apache/pulsar/pull/18599#issuecomment-1327794984)

@andrasbeni you can ignore the previous comment. This has been confirmed to be caused by a bug in Netty. I'm expecting that the fix will be available in the next Netty 4.1.x release 4.1.86 .

Netty 4.1.85.Final released
A potential memory leak bug has been fixed in the pooled allocator (#12897)
Nice. I encountered the memory leak problem in Pulsar.


Fixing Project Plan

We need to fix our project plan according to the feedback.

[x] Move Dockerization to the period before milestone 1. We already deployed our project. We just need to fix the plan for documentation's sake.
[x] Assign tasks to resources(team members)
[x] Add milestone 2 and 3

The new Project plan is ready.


[release-4.13] OCPBUGS-15774: autoscaling balance similar groups

What this PR does / why we need it:
Cherry picks https://github.com/openshift/hypershift/pull/2769
and https://github.com/openshift/hypershift/pull/2784
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/lgtm


ZoHo AuthToken being replaced 1st March 2021 by OAuth

Are there plans to update this solution to reflect the recently announced switch from ZoHo's own authtokens to an oAuth based token system?
If there are when do you anticipate there being a beta version as we only have about 5 weeks to complete the switch over?

@s6521d  - Do you have details or link to this announcement and more details I can refer to?
While I wait for you to share more info that I can read, as far as I know - OAuth Token or Custom token - both should work in the same way - i.e. we are expected to send the token in Header as Bearer <oauth-token>

@s6521d  - Do you have details or link to this announcement and more details I can refer to?
While I wait for you to share more info that I can read, as far as I know - OAuth Token or Custom token - both should work in the same way - i.e. we are expected to send the token in Header as Bearer <oauth-token>

Here's the announcement with links to the migration process:
https://help.zoho.com/portal/en/community/topic/authtoken-deprecation-for-zoho-subscriptions-apis

Here's the announcement with links to the migration process:
https://help.zoho.com/portal/en/community/topic/authtoken-deprecation-for-zoho-subscriptions-apis

@s6521d - Do you have details or link to this announcement and more details I can refer to?
While I wait for you to share more info that I can read, as far as I know - OAuth Token or Custom token - both should work in the same way - i.e. we are expected to send the token in Header as Bearer <oauth-token>

Here's the announcement with links to the migration process:
https://help.zoho.com/portal/en/community/topic/authtoken-deprecation-for-zoho-subscriptions-apis

@s6521d - Do you have details or link to this announcement and more details I can refer to?
While I wait for you to share more info that I can read, as far as I know - OAuth Token or Custom token - both should work in the same way - i.e. we are expected to send the token in Header as Bearer <oauth-token>

Here's the announcement with links to the migration process:
https://help.zoho.com/portal/en/community/topic/authtoken-deprecation-for-zoho-subscriptions-apis

Hi Jaspalsinh,
I've posted the details on GitHub
Kind regards
Steve
------ Original Message ------
From: "Jaspalsinh Chauhan"<EMAIL_ADDRESS>To: "teference/zoho-dotnet"<EMAIL_ADDRESS>Cc: "s6521d"<EMAIL_ADDRESS>"Mention"
<EMAIL_ADDRESS>Sent: Monday, 25 Jan, 21 At 07:30
Subject: Re: [teference/zoho-dotnet] ZoHo AuthToken being replaced 1st
March 2021 by OAuth (#24)
@s6521d https://github.com/s6521d   - Do you have details or link to
this announcement and more details I can refer to?
While I wait for you to share more info that I can read, as far as I
know - OAuth Token or Custom token - both should work in the same way -
i.e. we are expected to send the token in Header as Bearer
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/teference/zoho-dotnet/issues/24#issuecomment-766610028
, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7H7CUBIUOBLZDFUJQAJPLS3UMZZANCNFSM4WPZCOPQ
.

Hi Jaspalsinh,
I've posted the details on GitHub
Kind regards
Steve
------ Original Message ------
From: "Jaspalsinh Chauhan"<EMAIL_ADDRESS>To: "teference/zoho-dotnet"<EMAIL_ADDRESS>Cc: "s6521d"<EMAIL_ADDRESS>"Mention"
<EMAIL_ADDRESS>Sent: Monday, 25 Jan, 21 At 07:30
Subject: Re: [teference/zoho-dotnet] ZoHo AuthToken being replaced 1st
March 2021 by OAuth (#24)
@s6521d https://github.com/s6521d   - Do you have details or link to
this announcement and more details I can refer to?
While I wait for you to share more info that I can read, as far as I
know - OAuth Token or Custom token - both should work in the same way -
i.e. we are expected to send the token in Header as Bearer
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/teference/zoho-dotnet/issues/24#issuecomment-766610028
, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7H7CUBIUOBLZDFUJQAJPLS3UMZZANCNFSM4WPZCOPQ
.

@s6521d Thanks for sharing. I read on it and seems like the way we add token to the HTTP client call in the code for this SDK NuGet code has not changed.
Here is are the two lines of code that does it: https://github.com/teference/zoho-dotnet/blob/master/source/Zoho.Api/Internals/InternalExtensions.cs#L47-L48
So what they are changing is how you "obtain" is token. Previously it was a fixed static token you generate from their portal vs now they are moving to OAuth based standard way of getting Access Token (and refresh token to renew your Access Token) going forward.
Note this SDK does not cover the OAuth or Legacy way of getting or generating token. As far as I know, OAuth is a standard and if Zoho has implemented it as a standard then you should be able to use any OIDC or OAuth client SDK/NuGet package to handle the part of getting a token.
Here is a NuGet that I have used in my past work: https://www.nuget.org/packages/IdentityModel.OidcClient/
Thanks!

@s6521d Thanks for sharing. I read on it and seems like the way we add token to the HTTP client call in the code for this SDK NuGet code has not changed.
Here is are the two lines of code that does it: https://github.com/teference/zoho-dotnet/blob/master/source/Zoho.Api/Internals/InternalExtensions.cs#L47-L48
So what they are changing is how you "obtain" is token. Previously it was a fixed static token you generate from their portal vs now they are moving to OAuth based standard way of getting Access Token (and refresh token to renew your Access Token) going forward.
Note this SDK does not cover the OAuth or Legacy way of getting or generating token. As far as I know, OAuth is a standard and if Zoho has implemented it as a standard then you should be able to use any OIDC or OAuth client SDK/NuGet package to handle the part of getting a token.
Here is a NuGet that I have used in my past work: https://www.nuget.org/packages/IdentityModel.OidcClient/
Thanks!

Hi,
The code you've highlighted shows :
httpClient.DefaultRequestHeaders.Add("authorization",
string.Format(CultureInfo.InvariantCulture, "Zoho-authtoken {0}",
authToken));
The API documentation now shows the Authorization header as:-H
"Authorization: Zoho-oauthtoken
1000.41d9f2cfbd1b7a8f9e314b7aff7bc2d1.8fcc9810810a216793f385b9dd6e125f"
The header has changed from Zoho-authtoken to Zoho-oauthtoken
Kind regards,
Steve
------ Original Message ------
From: "Jaspalsinh Chauhan"<EMAIL_ADDRESS>To: "teference/zoho-dotnet"<EMAIL_ADDRESS>Cc: "s6521d"<EMAIL_ADDRESS>"Mention"
<EMAIL_ADDRESS>Sent: Monday, 25 Jan, 21 At 08:49
Subject: Re: [teference/zoho-dotnet] ZoHo AuthToken being replaced 1st
March 2021 by OAuth (#24)
@s6521d https://github.com/s6521d  Thanks for sharing. I read on it
and seems like the way we add token to the HTTP client call in the code
for this SDK NuGet code has not changed.
Here is are the two lines of code that does it:
https://github.com/teference/zoho-dotnet/blob/master/source/Zoho.Api/Internals/InternalExtensions.cs#L47-L48
https://github.com/teference/zoho-dotnet/blob/master/source/Zoho.Api/Internals/InternalExtensions.cs#L47-L48
So what they are changing is how you "obtain" is token. Previously it
was a fixed static token you generate from their portal vs now they are
moving to OAuth based standard way of getting Access Token (and refresh
token to renew your Access Token) going forward.
Note this SDK does not cover the OAuth or Legacy way of getting or
generating token. As far as I know, OAuth is a standard and if Zoho has
implemented it as a standard then you should be able to use any OIDC or
OAuth client SDK/NuGet package to handle the part of getting a token.
Here is a NuGet that I have used in my past work:
https://www.nuget.org/packages/IdentityModel.OidcClient/
https://www.nuget.org/packages/IdentityModel.OidcClient/
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/teference/zoho-dotnet/issues/24#issuecomment-766655258
, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7H7CQSTS3G4K476BCVJK3S3UWBNANCNFSM4WPZCOPQ
.

Hi,
The code you've highlighted shows :
httpClient.DefaultRequestHeaders.Add("authorization",
string.Format(CultureInfo.InvariantCulture, "Zoho-authtoken {0}",
authToken));
The API documentation now shows the Authorization header as:-H
"Authorization: Zoho-oauthtoken
1000.41d9f2cfbd1b7a8f9e314b7aff7bc2d1.8fcc9810810a216793f385b9dd6e125f"
The header has changed from Zoho-authtoken to Zoho-oauthtoken
Kind regards,
Steve
------ Original Message ------
From: "Jaspalsinh Chauhan"<EMAIL_ADDRESS>To: "teference/zoho-dotnet"<EMAIL_ADDRESS>Cc: "s6521d"<EMAIL_ADDRESS>"Mention"
<EMAIL_ADDRESS>Sent: Monday, 25 Jan, 21 At 08:49
Subject: Re: [teference/zoho-dotnet] ZoHo AuthToken being replaced 1st
March 2021 by OAuth (#24)
@s6521d https://github.com/s6521d  Thanks for sharing. I read on it
and seems like the way we add token to the HTTP client call in the code
for this SDK NuGet code has not changed.
Here is are the two lines of code that does it:
https://github.com/teference/zoho-dotnet/blob/master/source/Zoho.Api/Internals/InternalExtensions.cs#L47-L48
https://github.com/teference/zoho-dotnet/blob/master/source/Zoho.Api/Internals/InternalExtensions.cs#L47-L48
So what they are changing is how you "obtain" is token. Previously it
was a fixed static token you generate from their portal vs now they are
moving to OAuth based standard way of getting Access Token (and refresh
token to renew your Access Token) going forward.
Note this SDK does not cover the OAuth or Legacy way of getting or
generating token. As far as I know, OAuth is a standard and if Zoho has
implemented it as a standard then you should be able to use any OIDC or
OAuth client SDK/NuGet package to handle the part of getting a token.
Here is a NuGet that I have used in my past work:
https://www.nuget.org/packages/IdentityModel.OidcClient/
https://www.nuget.org/packages/IdentityModel.OidcClient/
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/teference/zoho-dotnet/issues/24#issuecomment-766655258
, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7H7CQSTS3G4K476BCVJK3S3UWBNANCNFSM4WPZCOPQ
.

I have a workaround for this  (not yet tested with a ZoHo oAuth id):
httpClient.ConfigureForZoHo( GetZoHoClient() );
Where:
GetZoHoClient is a method that creates an ZoHoClient initialised with the correct ZoHo data centre url, organization id and oAuthCode
ConfigureForZoHo is an extension to HttPClient:
using Legeris.Office365.ServiceInterface;
using System.Globalization;
using System.Net.Http;
using Teference.Zoho.Api;
namespace Legeris.Shared.Office365
{
public static class HttpClientExtensions
{
public static void ConfigureForZoHo(this HttpClient httpClient, ZohoClient client)
{
httpClient.Configure( client.Configuration.ApiBaseUrl, client.Configuration.OrganizationId, client.Configuration.AuthToken );
httpClient.DefaultRequestHeaders.Remove( "Authorization" );
httpClient.DefaultRequestHeaders.Add( "authorization", string.Format( CultureInfo.InvariantCulture, "Zoho-authtoken {0}", client.Configuration.AuthToken ) );
//httpClient.DefaultRequestHeaders.Add( "authorization", string.Format( CultureInfo.InvariantCulture, "Zoho-oauthtoken {0}", client.Configuration.AuthToken ) );
}
}
}

I have a workaround for this  (not yet tested with a ZoHo oAuth id):
httpClient.ConfigureForZoHo( GetZoHoClient() );
Where:
GetZoHoClient is a method that creates an ZoHoClient initialised with the correct ZoHo data centre url, organization id and oAuthCode
ConfigureForZoHo is an extension to HttPClient:
using Legeris.Office365.ServiceInterface;
using System.Globalization;
using System.Net.Http;
using Teference.Zoho.Api;
namespace Legeris.Shared.Office365
{
public static class HttpClientExtensions
{
public static void ConfigureForZoHo(this HttpClient httpClient, ZohoClient client)
{
httpClient.Configure( client.Configuration.ApiBaseUrl, client.Configuration.OrganizationId, client.Configuration.AuthToken );
httpClient.DefaultRequestHeaders.Remove( "Authorization" );
httpClient.DefaultRequestHeaders.Add( "authorization", string.Format( CultureInfo.InvariantCulture, "Zoho-authtoken {0}", client.Configuration.AuthToken ) );
//httpClient.DefaultRequestHeaders.Add( "authorization", string.Format( CultureInfo.InvariantCulture, "Zoho-oauthtoken {0}", client.Configuration.AuthToken ) );
}
}
}


Add tiangolo to maintainers

Hi @tiangolo! I've opened this PR in case you would like to be added as a maintainer of the conda-forge package?
The process is mostly automated but it would mean you would get notifications from the bot when new packages are published. The conda-forge community is happy to take care of this but if you don't mind the notifications and would like to be added as a maintainer just give this issue a thumbs up and i'll go ahead and merge it...

Oops, I didn't see this one before my patch.
Thanks! I have to clean my inbox from GitHub notifications, I'm missing these things :grimacing:
Thanks for the help! :cake: :tada:


[add-resource] New Plugin

I would like to add a plugin to the Grav Repository.
Here are the project details: https://github.com/dimitrilongo/grav-plugin-image-color
The Grav Image Color Plugin for Grav CMS : This plugin get the color palette from an image and Calculating Color Contrast. You can also get the dominant color for a given image.
Thanks

Added to GPM.


How long does it take for convert an image (png) to SMILES?

I have successfully installed the app on my macbook air, and launch it properly. I copied a benzene molecule picture from PubChem and I am sure that the benzene png is in my clipboard (by opening up the clipboard in Finder).
Then I clicked the "convert clipboard to SMILES", but nothing happens after 5 mins.... I wonder how long should it take for converting an image to SMILES in generally?
I've turned on the notification too.
Thank you! This is a really cool app and helpful one if I figure out how to properly use it!

Same here. However, the converted smiles shows up in the "Copy SMILES from History" for me


Rework code after ensmean data was added to main data catalog

Just had to modify the code a bit to account for the ensemble mean data now being available in our main data catalog. This required me to add simulation as a parameter to app.select, such that app.explore.tmy could select for just the ensmean data, and app.select could ignore the ensmean data (and not return it as an additional simulation).
I realize the explanation is a bit confusing. Feel free to add questions here for additional clarity and I will respond and try to clear up any confusion.
Once this PR is approved, I will merge it as the same time as the amy_cached_data branch
To test: Just try running app.retrieve() for different datasets. Also try running app.explore.amy(). Thanks!
Note to self: Need to confirm that this doesn't cause any issues with the notebooks in cae-notebooks before merging as well.

Hmm, I am still seeing ensmean after app.retrieve but after app.explore.tmy is called.

Hmm, I am still seeing ensmean after app.retrieve but after app.explore.tmy is called.

Going straight to app.select + app.retrieve works...

Hmm, now not seeing this. Maybe the code wasn't loading in the first notebook...

Hmm, I am still seeing ensmean after app.retrieve but after app.explore.tmy is called.

Going straight to app.select + app.retrieve works...

Hmm, now not seeing this. Maybe the code wasn't loading in the first notebook...

So if you call app.select after app.explore.amy() and don't change anything you get the ensmean only that was used for amy. Do we need some sort of reset to defaults for app.select?

If someone uses app.select or app.retrieve after the very specific amy code we want it to return the other simulations right

Actually, no! The AMY requires an ensemble mean at present :) The original calculation was computing ensemble mean on the fly, and now this switches in the ensemble mean cached product instead. Presumably, in the future someone might want to calculate AMY for each individual model and compare, but that's not necessary atm

So if you call app.select after app.explore.amy() and don't change anything you get the ensmean only that was used for amy. Do we need some sort of reset to defaults for app.select?

You are absolutely right that the defaults need to be reset. Thank you so much for catching this!

GUIs are tricky!! (And should be avoid like the plague lol)

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

I'm now getting the all the simulations including ensmean if I do app.select (don't touch anything) + app.retrieve after amy. Is that what we want?

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

I'm now getting the all the simulations including ensmean if I do app.select (don't touch anything) + app.retrieve after amy. Is that what we want?

No... not the desired behavior... darn. Will fix now.

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

I'm now getting the all the simulations including ensmean if I do app.select (don't touch anything) + app.retrieve after amy. Is that what we want?

Can't seem to get it to replicate this. Can you check one more time? This is such a frustrating bug!

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

I'm now getting the all the simulations including ensmean if I do app.select (don't touch anything) + app.retrieve after amy. Is that what we want?

Can't seem to get it to replicate this. Can you check one more time? This is such a frustrating bug!

You read my mind. I was about to check this again as I'm wondering if the codebase didn't update. Annoying when it does that!

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

I'm now getting the all the simulations including ensmean if I do app.select (don't touch anything) + app.retrieve after amy. Is that what we want?

Can't seem to get it to replicate this. Can you check one more time? This is such a frustrating bug!

You read my mind. I was about to check this again as I'm wondering if the codebase didn't update. Annoying when it does that!

Sweet let me know what you find!

GUIs are tricky!! (And should be avoided like the plague lol)

I think I fixed the issue with my most recent commit!

I'm now getting the all the simulations including ensmean if I do app.select (don't touch anything) + app.retrieve after amy. Is that what we want?

Can't seem to get it to replicate this. Can you check one more time? This is such a frustrating bug!

You read my mind. I was about to check this again as I'm wondering if the codebase didn't update. Annoying when it does that!

Sweet let me know what you find!

Ok, my bad. Works as you designed! I need to remember to load it twice on the HUB I guess. Silly!

No worries thanks for checking that again!

No ensmeans to be found on my end (with app.retrieve), but works as should for amy!


Fix crash on no feature indices

If no feature indices are detected, clasifier will panic
   9:     0x56419f61951b - <core::option::Option<T>>::unwrap::hd8b8ff2812a12642
                               at /checkout/src/libcore/macros.rs:20
  10:     0x56419f61206a - rustlearn::trees::decision_tree::FeatureIndices::new::h713ea4d48acd865b
                               at /home/rico/.cargo/git/checkouts/rustlearn-1ee86889f45d433e/2ef4de2/src/trees/decision_tree.rs:58
  11:     0x56419f613345 - <rustlearn::trees::decision_tree::DecisionTree as rustlearn::traits::SupervisedModel<&'a rustlearn::array::dense::Array>>::fit::hcc2df1c85dd330cc
                               at /home/rico/.cargo/git/checkouts/rustlearn-1ee86889f45d433e/2ef4de2/src/trees/decision_tree.rs:323
  12:     0x56419f603adf - <rustlearn::ensemble::random_forest::RandomForest as rustlearn::traits::SupervisedModel<&'a rustlearn::array::dense::Array>>::fit::hba6d79b944d21aa4
                               at /home/rico/.cargo/git/checkouts/rustlearn-1ee86889f45d433e/2ef4de2/src/ensemble/random_forest.rs:119

Does this algorithm even make sense when there are no indices? Maybe it would be preferable to return an error.

You're right !
It's done


Still some problems with Android GL20 strict mode violations

Hi!
I'm working on an Android app that uses scene2d. Everything is working fine on desktop and my relatively new Android 10 -equipped phone, but when uploading an app bundle to the Google Play Console, I'm getting some crashes in their testing, as well as unsupported library usage related to java.nio.Buffer. This is related to #5485 however I am using the latest version of libgdx, 1.9.10.
Steps to reproduce:

Initialize a scene2d Stage.
Run on some Android phone (funnily enough the only ones that are crashing are Android 7, according to Google's testing).
Crash?

StrictMode policy violation: android.os.strictmode.NonSdkApiUsedViolation: Ljava/nio/Buffer;->_elementSizeShift:I 	at android.os.StrictMode.lambda$static$1(StrictMode.java:407) 	at android.os.-$$Lambda$StrictMode$lu9ekkHJ2HMz0jd3F8K8MnhenxQ.accept(Unknown Source:2) 	at android.opengl.GLES20.glGetShaderiv(Native Method) 	at com.badlogic.gdx.backends.android.AndroidGL20.glGetShaderiv(AndroidGL20.java:362) 	at com.badlogic.gdx.graphics.glutils.ShaderProgram.loadShader(ShaderProgram.java:214) 	at com.badlogic.gdx.graphics.glutils.ShaderProgram.compileShaders(ShaderProgram.java:188) 	at com.badlogic.gdx.graphics.glutils.ShaderProgram.<init>(ShaderProgram.java:171) 	at com.badlogic.gdx.graphics.g2d.SpriteBatch.createDefaultShader(SpriteBatch.java:162) 	at com.badlogic.gdx.graphics.g2d.SpriteBatch.<init>(SpriteBatch.java:126) 	at com.badlogic.gdx.graphics.g2d.SpriteBatch.<init>(SpriteBatch.java:80) 	at com.badlogic.gdx.scenes.scene2d.Stage.<init>(Stage.java:100) 	at me.datafox.foxxoland.FoxxoLand.create(FoxxoLand.java:40) 	at com.badlogic.gdx.backends.android.AndroidGraphics.onSurfaceChanged(AndroidGraphics.java:310) 	at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1557) 	at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1272)

I'd guess that the code in GLES20.glGetShaderiv is the problem.
That means that googles code is violating strict mode on older android versions.
Is strict mode mandatory for apps?

Strict Mode isn't strictly mandatory, but this strict mode violation means that some Android phones don't have the libraries for java.nio.Buffer. I'm also flabbergasted at the fact that the code runs without any problems on as early Android versions as 4.3, the only ones that crashed in Google's testing were Android 7 or 7.1.
If this is a problem with Android's GLES20 implementation, I should probably look for answers from Google's side.

As I said, I'd assume that google maybe forgot to whitelist these apis for their own use?
The relevant GLES20 source code hasn't been changed for like 5 years.

Is that a Google Play prelaunch report? Those crash reports are very unreliable and throw a lot of false positives. I haven't seen those crash reports on any live app which use Scene 2D (with high number of daily users). I wouldn't worry unless you get them on a live app.

After further investigation, the crashes are unrelated. As @obigu said, it's most likely a false positive in the testing, as even adding extensive logging to my application, I couldn't link it into anything related to my code or libgdx itself. Closing the issue.


Need a way to remove printf()

On the nRF51822 platform I'm compiling for, having printf() in the code anywhere (even if it is never called) forces the compiler to include some library that also happens to include fclose(), which then conflicts with my implementation of the filesystem functions. Currently I've commented out

printQuery
printTuple
printRowSeparator
printtoken

and set DB_CTCONF_SETTING_FEATURE_ERROR_MESSAGES to 0. It would be nice to have a #define that lets me remove all printf()s from compiling.

Did commenting out that code / disabling error messages remove all references to printf?

Yes.

Hi @graemedouglas,
could you assign this one to me, please?
Thanks,
Andrii

@kupleva The best way to do this is through the pull request API. That is GitHub's intended usage pattern.
If you fork this repository and point your local repo's origin to your fork, and push their, you can initiate a pull request through GitHub's UI.
Thanks for the interest!

@graemedouglas
Done. Please, see the pull request #9 .
Thank you.

Hi @graemedouglas,
did you have a chance to review my pull request #9 that aims to fix this issue?

Not yet, I'm sorry, I've been pretty busy of late. Start/end of contracts and publication deadlines coming up. I have done a code review and don't see anything objectionable to my eye, though. My apologies for the delay!

@graemedouglas,
it's ok.
i thought you'd avandoned this project. now i see it's not the case.
of course this has lower priority than work/studies.

Fixed in pull request #9.
@graemedouglas,
many thanks for giving it a look!


RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0!

Hi @mjq11302010044,
I was successfully able to train the model, using the code in the repository. But , when I run Test.sh script, I have following error:
"RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking argument for argument weight in method wrapper_slow_conv_transpose2d)".
I spent almost more than 2 days debugging it, but cannot get past this error.  Can you please help me resolve the issue if you have solution for this?

Regards,
Nakul

Hi，there.  If you read the code in the eval and test sections carefully, you will find that the author only modified the code in the eval section. And use "if iters % cfg.VAL.valInterval == 0 or self.args.go_test:". Replaced test with eval. If you want to use the test method to test, you need to add label_vecs to the model, like this: "images_sr = model(images_lr,label_vecs_final)". The author code has a lot of unneeded test code, making the code difficult to read. Hope it can help you.


Registry mounting configurations are missing in Cluster Docs

The cluster doc [1] does not contain registry mounting configurations which are required to mount the registry for the cluster setup.
[1] https://docs.wso2.com/display/IS540/Clustered+Deployment

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


docs: k8s + CoreOS + Cilium Stack building with Ansible

first pull

Thanks for sending the pull request. I tried rendering the page but looks like it's not linked properly so had to manually direct to it. The existing files have several examples, please compare them to your own and make appropriate changes.

@kubebc This looks great, thanks a lot for doing this! Will have a look soon.


Unable to find a matching configuration of project :react-native-google-signin

I have installed the react-native-google-signin module and followed all the steps given. On iOS I have completed the installation,  able to run the app and did the login with google.
On Android I am able to run the app once but then facing the following issue,

What went wrong:
Could not determine the dependencies of task ':app:mergeDebugAssets'.

Could not resolve all task dependencies for configuration ':app:debugRuntimeClasspath'.
Could not resolve project :react-native-google-signin.
Required by:
project :app
Unable to find a matching configuration of project :react-native-google-signin:
- None of the consumable configurations have attributes.

Environment
Please provide

react-native "0.61.5",
@react-native-community/google-signin version
"@react-native-community/masked-view": "^0.1.7",
"react-native-google-signin": "^2.1.1",

Hi there! Sorry you're having an issue. As the issue template explains, we require that you provide a runnable example that reproduces your issue (see the issue template). The reason is that maintainers do not have time to try reproduce bugs themselves. Please try to minimize the superfluous code and focus only on reproducing the bug.
please create a new issue with this and we'll be happy to review it!


"az logic workflow create" overwrites existing resource instead of giving duplication error

Related command

az logic workflow create
Is your feature request related to a problem? Please describe.

When existing resource name is used for following command, it overwrites (updates) the resource.
az logic workflow create
Describe the solution you'd like

Feature request to give out duplication error if existing resource name is used for following commands, instead of overwriting (updating) existing resources:
az logic workflow create
Describe alternatives you've considered

Giving option to ovewrite or not
Additional context

https://learn.microsoft.com/en-us/cli/azure/logic/workflow?view=azure-cli-latest#az-logic-workflow-create

Thank you for opening this issue, we will look into it.


Add initial UI (dashboard + service info)

Orbiter UI built with React, Next.js and Semantic UI
For development purpose it uses a mock API

Let's start to have it in! :+1:


Train with Shapenet

Thanks for the wonderful work.
As you mentioned in the training process, the shapenet is not an option since the mesh are not in closed triangles. However, it there any way that I could convert the mesh in shapenet to closed triangle mesh?
Thank you so much for your time!

Sorry, I do not know a way to convert the meshes in ShapeNet to closed triangle meshes while keeping the sharp geometric features.
If you are okay with re-meshing (gives you smoothed shapes), you can try https://github.com/davidstutz/mesh-fusion.

Sure, I will give it a try,
Thank you for your time!


apacheGH-30622: [GAC-45] Initial Version of FlightSQL Readme

Rationale for this change
Non existent FlightSQL readme file

What changes are included in this PR?
The initial version of FlightSQL readme file

Are these changes tested?
N/A

Are there any user-facing changes?
N/A

I updated title so it would be picked up by Arrow community's searches for the ODBC github issue


Setup httpyac in Test explorer  #140

I have been working on it all weekend, it's a version 1, so I would love your opinion and feedback.
#140
Future improvements
There are a couple of TODO's and future improvements

[ ] Folder support in test explorer
[ ] adoc files are recognized, and show up on initial load, the on changed is not triggered for adoc files.

Demo
Note: The code-workspace file is not required if you have a .vscode folder.
Open Explorer
First we open the test explorer, the handler will look up all the tests in the workspace.
We look for the following files (.http,.md,.adoc).

Run All
From here, we can click the run all button to run all the found tests.
Look at the top of the explorer, it lists all the run total succeeded and failed tests.

Show children HTTP regions
Then we open one file in the explorer to see all the HTTP regions that have been run.
You see that some tests have failed, succeed or skipped.
Tests that have been skipped have no tests within the region.

Go to Test
Let's take a look at a test that has succeeded.

Show test fail reason
And let's have a look at a failed test.
This test has 2 assertions. 1 of them fails. Here you see the output of a test:

Give test a name
There are also a couple of file hooks implemented here we change the name of the HTTP region it immediately gets reflected to the explorer, the same goes for tests.

Create File
And we want to create and delete files, when we do the explorer should react to it:
On Creation:

And on delete:
Delete File

Hi I like your idea. I did not know about test explorer API. Great improvement 👍.  I will have a look at it after my vacation

@BramManuel Awesome. I think the idea is great. I am currently review the code and also read the documentation of the api. I would also have a few improvements, for example to improve the performance. I will simply add notes to this PR. Is it ok with you, if I commit code directly into your pull request?

Yea, off course you can commit to the pr! I am here to learn, and typescript is new for me 😉 if I can help with something, let me know!

Thanks again for the PR and the tip about the interface. I will merge the PR as it is. My changes I will convert only afterwards, because I still want to implement the lazy loading.

https://github.com/AnWeber/vscode-httpyac/issues/140#issuecomment-1200333447


Error message when close the game.

Confirmed.

Seconded:

Seconded:

Did you behave different in any way when you were using Totsugeki before this error occurred?


update the rule generator

Links to https://github.com/hmrc/interest-forecasting/pull/343

If you add a duplicate entry in
https://github.com/hmrc/debt-transformation-stub/blob/02a1cc2402724e29d107a0d3d62626f29898d9c9/test/uk/gov/hmrc/debttransformationstub/utils/ifsrulesmasterspreadsheet/InterestForecastingRulesGeneratorSpec.scala#L93
A test will break, why?


Numerical Representation Issue

Dears,
I am having something that looks to me as numerical representation problems.
Here's and hopefully self explanatory example.
In essence I am trying to evaluate the same function in three different ways, and il looks like torchTT is provides a divergent value.
Please let me know if I am getting something wrong.
best,
NC

Hi,
thank you for reaching out. I cannot open the link because it seems to point on a local file
BR,
Ion

Gosh, my bad, I updated the link it should work now.
best,
N

Hi, I had a look at the script and the issue is that calling tn.Tensor with a fp64 numpy array as an argument returns a tensor that is fp32 (run tn.Tensor(f1d.reshape(1,-1,1)).dtype). How I would do is using the factory method tn.tensor. This returns the same precision as the input numpy array and moreover it can also change the representation using the dtype argument. I would change the cell to
f_tt = tntt.TT([tn.tensor(f1d.reshape(1,-1,1), dtype=tn.float64),tn.tensor(f1d.reshape(1,-1,1), dtype=tn.float64)])
f_tt = f_tt.numpy()

Now the machine precision can be observed insted of 1e-8 which corresponds to truncating to fp32.
I had this kind of issue when I started to work with torch and it was leading to funny results and convergence plots.
I'll add a small remark in the documentation and in the examples and close the issue.
PS: tntt.rank1TT() can be used to represent rank1 tensors or the ** operator for the kron product between tntt.TT objects.


Only one thing to report on

I only see one thing to report on, should I be seeing more?

Now I see 0

Have all markets loaded when you see 1 or 0 to report on?  (In the console,
is there a "all markets and logs successfully loaded" message?)
On Mar 20, 2016 9:57 PM, "Joseph Krug"<EMAIL_ADDRESS>wrote:

Now I see 0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/AugurProject/augur/issues/510#issuecomment-199125013

Yes they have.  After waiting on the reporting page for ~30 sec. they appeared


Update mypy.ini

Fixes # .
Changes proposed in this pull request:

Change 1
Change 2
Change 3

Weird, I don't understand that error


[CI] Test out new comment trigger workflow

/deploy

Codecov Report

Merging #1102 (dba5770) into main (5afe9e8) will decrease coverage by 31.23%.
The diff coverage is n/a.

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

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main    #1102       +/-   ##
===========================================
- Coverage   85.11%   53.89%   -31.23%
===========================================
  Files          86       85        -1
  Lines        8305     8251       -54
===========================================
- Hits         7069     4447     -2622
- Misses       1236     3804     +2568

see 42 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

/deploy

/deploy


introduce yaw update from RC

Main Changes

Re-introduced yawReferenceRad updates

Associated Issues

Addresses #66

Tests
None yet

Moved to #71


docs: add instructions for creating custom dashboards in Grafana

Fix: #1705

@mowies  check it

Should we have a link to this file from the main documentation?  This seems like interesting information that could be in the main doc set but at least it would be nice to have a link to it

@StackScribe
Yes, I think it would be a good idea to have a link to this file from the main documentation. The information in the file is interesting and could be helpful to users. It would also be a good way to promote the file and make it more visible.

I think you can easily fix those markdownlint errors by running make markdownlint-fix on your local branch then pushing a commit with those changes

Hello @Nitishupkr are you working on this PR actively ? I see that the linked issue was already closed
Thank you!

The linked issue was closed as not planned, closing this PR as well


Bug: No text box next to "Tell us about who you are" question

“Tell us about who you are and why you are running. Include your core values and vision.” question doesn’t have a text box to answer

Per the draft questionnaire doc, this is one question, in two paragraphs. Do we want to split it in two?

Oh that's right. Can we just make this one paragraph then?

We sure can, but I think with the addition of question numbers it's not confusing any more. Concur?

Concur. Let's close this issue.


[Need Help] With DNSCrypt server with vultr.com

So i been trying to get DNSCrypt server with vultr.com to work but cannot get it to communicate from dnscrypt-proxy to the dnscrypt server.
maybe it's a firewall issue but i'm not sure.
@bitbeans maybe you could help?

@evilvibes yes you are right! script needs an update, the firewall is blocking.
Workaround so long:
 systemctl stop iptables
i will will update it as soon i have some time :)

I would but i have no idea what to update it too. The cmd did the trick Thanks.


Hide Search filters for features that aren't enabled (and can't be searched)

Problem: While we only show the card filter if a member has cards actually assigned to them, we don't do the same for category, tags, and tax. This inconsistency overcomplicates the product and leads to a confusing search experience, since we're allowing members to search for things that can't be searched.
Solution: Let's only show filters if members actually have those features enabled on the workspace. Again, we already do this for Card, so simply make things consistent and do the same for Category, Tag and Tax rate.

@Kicu @SzymczakJ @289Adam289 would either of you wanna work on this issue?

It looks like this issue is the same as Issue #50564. @luacmartins suggested those changes in this comment. I've also shared : My Proposal. Now waiting for @fedirjh to choose the best solution.

Oh ok. So @luacmartins should we go ahead and close this one out?

I read parts of the discussion on the other issue and they seem long and overly complex.
This is how we don't display Card advanced filter: https://github.com/Expensify/App/blob/ab40264dff9a6c21372617c8744b1013c22dd2d2/src/pages/Search/AdvancedSearchFilters.tsx#L318
There is a function that iterates over static filters array and computes the display data. We can run a simple if check to see whether we want this filter or not.
Feels to me (without digging too deep into this) that we could apply quite similar logic to all the other filters that you mentioned @JmillsExpensify
I don't want to randomly barge in into the conversation on the other issue, but I'm sure one of us in SWM could take this and provide some not-too-complex solution. This specific filters code was something that @289Adam289 worked on.

@Kicu I agree. I commented on the issue. I'm gonna close this one in favor of https://github.com/Expensify/App/issues/50564. Can you please leave a comment so I can assign it to you?

Closing since @Kicu is assigned to https://github.com/Expensify/App/issues/50564


Error on WSL

When I run serve . on WSL (Ubuntu 18.04.1 on Windows 10 with the kernel v4.4.0), I get this output:
ERROR: Cannot copy to clipboard: Command failed: xsel --clipboard --input
xsel: Can't open display: (null)
: Connection refused

I tried setting DISPLAY=localhost:0 but that doesn't help.

serve automatically copies the local address to the clipboard
it looks like this automatic feature is failing on your machine
you can supply the -n flag to tell serve to skip the clipboard step, which may help you
try:
serve -n

let us know if this solves the issue for you :wave:

It does indeed ignore that but it doesn't solve per se.

@Berkmann18 I also run serve from WSL, and it is not an operation-critic feature, as chase-moskal said, you can run the -n flag so that it doesn't try to put on the clipboard.

Same issue here, but the root cause is actually here.

@adriangabardo True, it's not an operation-critic thing but noisy and which leaves room for (potential) bugs (especially as the solution is just a workaround).


[Bug/Glitch] creative menu does not act like console edition did

Legacy4J Version
1.21-1.7.2
Mod Loader Version
Quilt Loader 0.26.3
Bug/Glitch Occurrence Context
gamepad usage in creative inventory
Crash Report
No response
What happened wrong?
if you open the creative inventory:

if you're holding an item in the cursor and close the inventory, the item is not deleted
if you press west to clear the quick select while hovering an item, it picks up one, which is inconsistent with the button hint. if you are holding an item, it clears the quick select then places it back down.
the "What's this?" hint overlaps the creative inventory

This is a suggestion, not an issue, and no, I will not remove features from vanilla just to have 100% parity with LE.

what feature would you be removing? that doesn't make sense

what feature would you be removing? that doesn't make sense

You want it to work identical to LE, right? Obviously if it's identical, there won't be the ability to place 1 item or take half

i didn't want you to remove it, i wanted you to not make the button hint incorrect for the action it performs


fix(payment): INT-3408 added masterpass SRC experiment

What?
Added masterpass SRC experiment
Why?
Added masterpass SRC experiment
Dependencies
1-  Bigcommerce #40008
2- checkout-sdk-js #1094
3- Checkout-js #540
Testing / Proof

@bigcommerce/checkout @bigcommerce/apex-integrations

💚 Tested
QA Details: I ran a regression for migration from master pass to SRC, to check new buttons and the checkout process still working in Stripe and Stripe V3, all this down an experiment.