Automatic reverse mode autodiff testing (Issue #993)

Summary
This is my first take at implementing the automatic testing described in issue #993.
This only tests reverse mode autodiff. I want to make the interface on this feature complete first, because I think testing fvars and fvar<var>s will be much the same.
I discussed with Bob and decided not to force the test all argument combos things on people. The interface is basically:
test_autodiff(functor, arg1, arg2, ...);

Where the arguments are passed in as non-autodiff types (int, double, std::vector<int>, std::vector<double>, Eigen::VectorXd, Eigen::RowVectorXd, and Eigen::MatrixXd)
The test code will test reverse mode autodiff with all valid combos of autodiff and non-autodiff types on the calling function against finite difference approximations.
It checks that when the function called with non-autodiff types throws, the autodiff versions throw as well. It tries to verify that the exception types are the same, but it cannot guarantee it.
It checks that the returned values from the autodiff and non-autodiff implementations match.
A complete set of reverse mode autodiff tests for a function should just be calling:
test_autodiff(functor, arg1, arg2, ...);

With all combinations of prim-types for arg1, arg2, etc. Since this will have already been done for the prim tests, presumably this is just some copy and paste so it's easy. The rest can be handled by test_autodiff.
Tests
The main features can be tested with
./runTests.py test/unit/math/rev/mat/util/test_autodiff_test.cpp

The various extra bits and pieces I added can be tested with
./runTests.py test/unit/math/prim/scal/fun/promote_double_to_T_test.cpp
./runTests.py test/unit/math/prim/mat/fun/promote_double_to_T_test.cpp
./runTests.py test/unit/math/rev/mat/fun/promote_double_to_T_test.cpp
./runTests.py test/unit/math/prim/mat/fun/variable_adapter_test.cpp
./runTests.py test/unit/math/prim/scal/functor/apply_test.cpp
./runTests.py test/unit/math/prim/scal/functor/call_all_argument_combos_test.cpp
./runTests.py test/unit/math/rev/mat/fun/adj_jac_apply_test.cpp // I'm actually not sure what this change is about, but it seems fine

Checklist

[x] Math issue #993

[x] Copyright holder: Columbia University
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

+1

Thanks!  I can talk to Ben about this early next week and review it.

@bbbales2, I'm sorry it's taken so long to review. I've run into a slight problem -- I can't compile it on my local machine. When I run
./runTests.py test/unit/math/rev/mat/util/test_autodiff_test.cpp

I get a compiler error novel:
clang++ -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.66.0 -isystem lib/sundials_3.1.0/include -std=c++1y -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused-function -Wno-uninitialized -Wno-unknown-warning-option -Wno-tautological-compare -Wsign-compare -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe  -c -o test/unit/math/rev/mat/util/test_autodiff_test.o test/unit/math/rev/mat/util/test_autodiff_test.cpp
In file included from test/unit/math/rev/mat/util/test_autodiff_test.cpp:1:
In file included from ./test/unit/math/rev/mat/util/test_autodiff.hpp:4:
In file included from ./stan/math/rev/mat.hpp:4:
In file included from ./stan/math/rev/core.hpp:4:
In file included from ./stan/math/rev/core/autodiffstackstorage.hpp:4:
In file included from ./stan/math/memory/stack_alloc.hpp:10:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/sstream:174:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/ostream:138:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/ios:216:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__locale:15:
/Library/Developer/CommandLineTools/usr/include/c++/v1/string:1887:5: error: no matching member function for call to '__init'
    __init(__first, __last);
    ^~~~~~
./test/unit/math/rev/mat/util/test_autodiff.hpp:288:48: note: in instantiation of function template specialization 'std::__1::basic_string<char, std::__1::char_traits<char>,
      std::__1::allocator<char> >::basic_string<std::__1::basic_string<char> >' requested here
    std::vector<std::string> argument_types = {{type_as_string(args)...}};
                                               ^
./test/unit/math/rev/mat/util/test_autodiff.hpp:329:11: note: in instantiation of function template specialization 'stan::math::test::test_var<(lambda at
      test/unit/math/rev/mat/util/test_autodiff_test.cpp:75:15), int, double>' requested here
          test_var(f, 1e-4, relative_tolerance, absolute_tolerance, args...);
          ^
test/unit/math/rev/mat/util/test_autodiff_test.cpp:77:37: note: in instantiation of function template specialization 'stan::math::test::test_autodiff<(lambda at
      test/unit/math/rev/mat/util/test_autodiff_test.cpp:75:15), int, double>' requested here
  EXPECT_NO_THROW(stan::math::test::test_autodiff(func, 1e-9, 1e-9, 1, 1.0));
                                    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/string:1373:10: note: candidate function not viable: no known conversion from 'std::__1::basic_string<char>' to 'const
      std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::value_type *' (aka 'const char *') for 1st argument
    void __init(const value_type* __s, size_type __sz);
         ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/string:1375:10: note: candidate function not viable: no known conversion from 'std::__1::basic_string<char>' to
      'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size_type' (aka 'unsigned long') for 1st argument
    void __init(size_type __n, value_type __c);
         ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/string:1384:5: note: candidate template ignored: requirement '__is_exactly_input_iterator<basic_string<char> >::value' was not
      satisfied [with _InputIterator = std::__1::basic_string<char>]
    __init(_InputIterator __first, _InputIterator __last);
    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/string:1393:5: note: candidate template ignored: requirement '__is_forward_iterator<basic_string<char> >::value' was not satisfied
      [with _ForwardIterator = std::__1::basic_string<char>]
    __init(_ForwardIterator __first, _ForwardIterator __last);
    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/string:1371:10: note: candidate function not viable: requires 3 arguments, but 2 were provided
    void __init(const value_type* __s, size_type __sz, size_type __reserve);
...

I'll try to hunt it down.

So weird... this fails to compile with clang++ on Mac with the error message above:
$ clang++ -v
Apple LLVM version 10.0.0 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

This compiler compiles, but has runtime errors:
$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.2.0/libexec/gcc/x86_64-apple-darwin18.0.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin18.0.0
Configured with: ../configure --build=x86_64-apple-darwin18.0.0 --prefix=/usr/local/Cellar/gcc/8.2.0 --libdir=/usr/local/Cellar/gcc/8.2.0/lib/gcc/8 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC 8.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-nls --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
gcc version 8.2.0 (Homebrew GCC 8.2.0)

It has a bunch of these messages:
[ RUN      ] AgradRevMatrix.test_autodiff_scalar_bad
test/unit/math/rev/mat/util/test_autodiff_test.cpp:208: Failure
Expected equality of these values:
  1
  count_matches("does not match the value from the reverse mode call", e.what())
    Which is: 0
expected message: does not match the value from the reverse mode call
found message:
[  FAILED  ] AgradRevMatrix.test_autodiff_scalar_bad (0 ms)

But before I get too much further into debug mode, I'm going to take a look at the design and how you intend for it to be used.

@bbbales2, I was mistaken. It compiles and runs fine with g++-8. I had some local changes on my branch as I was trying to debug why it was failing.

For whatever reason, it's still not compiling on my machine. I'm using the stock XCode clang++ compiler on Mac, though. Is there any reason this wouldn't work on that? (I'll try to find a workaround anyway.)

So... I tracked down one failure. @bbbales2, thank you for unit testing these. It's really making it much easier to figure out what's going on.
I'm inside the prim version of promote_double_to_VectorXd test and I just found that using the default compiler on Mac, that test fails. This line doesn't pass: EXPECT_EQ(1, std::tuple_size<decltype(y)>::value);. And the awesome / unawesome thing is that when it fails, instead of it being a runtime error, it spits out an awful compiler novel. That's what I've been seeing.
So... it turns out that the version of libc++ that comes with the default clang++ implements this differently and promote_double_to<float>(std::make_tuple(Eigen::VectorXf))) returns something of length 0 (and that's known at compile time!).
There's still more digging to do to see what's going on.

There’s definitely some weirdness in the implementation. The latest is coming from Windows. I’ll keep at it.
But before I get too deep into implementation details, I wanted to talk about some of the design aspects.
First, I think the overall abstraction is great. It would be nice to test autodiff in this way. Some things I’d like to get your take on:

renaming test_autodiff to something like test_rev_ad or test_reverse_ad or something like that? I don’t think this one function is supposed to test it all? Or is that the intention?
mind if I change some of the doc that’s supposed to face the developer? I see what you’re trying to do, but I think it’s not as clear as it could be.
the PR doc is off; this version has tolerances.
I think maybe we have default tolerances and then a different function to set tolerances? Like test_rev_ad_tol?

How are the test errors shown? Do we want to run through admins collect errors or do we want to quit at the first error? What’s being done now?

This function doesn't test everything yet.  There is a design question about whether to have different tests for every autodiff level or just have one top-level call.  I sort of did both in the other test frameworks.
Tolerances need to be set on a function-by-function basis.  Would it be possible to just have a tolerance argument with a default that could be set in specific cases.  That's what I did for other tests like this.

On Dec 19, 2018, at 12:11 AM, Daniel Lee<EMAIL_ADDRESS>wrote:
There’s definitely some weirdness in the implementation. The latest is coming from Windows. I’ll keep at it.
But before I get too deep into implementation details, I wanted to talk about some of the design aspects.
First, I think the overall abstraction is great. It would be nice to test autodiff in this way. Some things I’d like to get your take on:
• renaming test_autodiff to something like test_rev_ad or test_reverse_ad or something like that? I don’t think this one function is supposed to test it all? Or is that the intention?
• mind if I change some of the doc that’s supposed to face the developer? I see what you’re trying to do, but I think it’s not as clear as it could be.
• the PR doc is off; this version has tolerances.
• I think maybe we have default tolerances and then a different function to set tolerances? Like test_rev_ad_tol?
How are the test errors shown? Do we want to run through admins collect errors or do we want to quit at the first error? What’s being done now?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

renaming test_autodiff to something like test_rev_ad or test_reverse_ad or something like that

Sounds good. I like test_rev_autodiff, but I'll go with whatever.

mind if I change some of the doc that’s supposed to face the developer?

By all means

the PR doc is off; this version has tolerances.

Good catch!

I think maybe we have default tolerances

I don't like how I did the tolerances now. After actually using this,
I think one argument should be a generic tolerance (assuming absolute
tolerance == relative tolerance) and the other argument should be the
delta for the finite difference.
I can make this change.
I don't think we should add any state to the testing apparatus or
it'll just get confusing. It's annoying but not too annoying to just
add a couple extra arguments to the end of everything.

instead of it being a runtime error, it spits out an awful compiler novel

Yeah, that's the tragedy of doing testing like this :P. I'll leave the
Mac fix for you, or I'll be back around Macs in early January and can
futz with it then.
On 12/18/18, Daniel Lee<EMAIL_ADDRESS>wrote:

There’s definitely some weirdness in the implementation. The latest is
coming from Windows. I’ll keep at it.

But before I get too deep into implementation details, I wanted to talk
about some of the design aspects.

First, I think the overall abstraction is great. It would be nice to test
autodiff in this way. Some things I’d like to get your take on:

renaming test_autodiff to something like test_rev_ad or
test_reverse_ad or something like that? I don’t think this one function is
supposed to test it all? Or is that the intention?

mind if I change some of the doc that’s supposed to face the developer? I
see what you’re trying to do, but I think it’s not as clear as it could be.

the PR doc is off; this version has tolerances.

I think maybe we have default tolerances and then a different function to
set tolerances? Like test_rev_ad_tol?

How are the test errors shown? Do we want to run through admins collect
errors or do we want to quit at the first error? What’s being done now?

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/stan-dev/math/pull/1021#issuecomment-448471622

Looks like we're on the same page.
Re: design of different tests for autodiff. There are two things that makes me think they should be separate:

having runtime errors masked because the traits are instantiated for mixed mode and that somehow interacts with how it'll run in reverse-mode only. We can fix this if we really locked down the traits and got that really solidly tested, but we're far from that and I think we're going to see some hard-to-diagnose problems before we lock all of that down.
compilation time and issues. On the old g++ for Windows, we'd run into problems compiling mixed mode. They were terrible failures; silent failures that just didn't run. I don't know what the status is on the new compiler. But beyond that, we'll essentially be instantiating everything with mixed mode to get it done. Maybe that's ok, I'd just want to evaluate it before dismissing this concern.

Tolerances: I agree.

@bbbales2, thanks. Agreed with everything, including test_rev_autodiff.
Question: what state were you thinking of? I wasn't thinking about adding state, but now I'm curious what you thought I was suggesting.
and also... thanks! I'm really looking forward to having a version of this in. This would make life so much easier.

On Dec 19, 2018, at 10:09 AM, Daniel Lee<EMAIL_ADDRESS>wrote:
@bbbales2, thanks. Agreed with everything, including test_rev_autodiff.
Question: what state were you thinking of? I wasn't thinking about adding state, but now I'm curious what you thought I was suggesting.

It sounded to me like you were suggesting a stateful set-tolerance.

It sounded to me like you were suggesting a stateful set-tolerance.

Yup, this was with respect to the tolerances. I like just being
verbose with the arguments in this situation.
On 12/19/18, Bob Carpenter<EMAIL_ADDRESS>wrote:

On Dec 19, 2018, at 10:09 AM, Daniel Lee<EMAIL_ADDRESS>wrote:
@bbbales2, thanks. Agreed with everything, including test_rev_autodiff.
Question: what state were you thinking of? I wasn't thinking about adding
state, but now I'm curious what you thought I was suggesting.

It sounded to me like you were suggesting a stateful set-tolerance.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/stan-dev/math/pull/1021#issuecomment-448629407

It sounded to me like you were suggesting a stateful set-tolerance.

Maybe? I was thinking of this (in pseudocode that isn't going to work in any language):
test_reverse_autodiff_with_tolerances(f, rel_tol, abs_tol, ...);

test_reverse_autodif(f, ...) {
    test_reverse_autodiff_with_tolerances(f, 1e-8, 1e-8, ...);
}

(Sorry, read back through the comments. Yeah, my bad; I wasn't careful with how I stated what I intended.)

@bbbales2, I like the level of abstraction.
Re: design. I think we should separate out testing of exceptions from the values and gradients. I think by autodetecting whether the prim throws and using that as a baseline for the autodiff can mask programmer error. If a function throws when it's not supposed to, but it throws consistently (for both prim and rev), then this gets masked. I think the way to solve this is to split out the testing of exceptions. By doing this, I think we can make the testing of the exceptional case more precise and provide the developer with better tooling. Here are the two things we can add: 1) the type of the exception (and indicate if it isn't properly throwing the correct exception) 2) checking for error messages. The error messages are part of the user experience, both for the math library, but we know it trickles through to users of Stan. We should care what it looks like. It might be too ambitious to have regular expressions for the message, but ideally, we should check that the messages look the way we expect it to look.
Re: implementation. I think the nested autodiff is at the wrong level. I can help clean that up. It'll just take a little bit of time. I'm seeing things like the value test and the exception test not having nested calls. I think we should nest, then add things to the stack, then remove leaving the stack as we found it at the end of each test. (We might have to assume that they're actually on the unnested stack, but that's an implementation detail. We could always add functionality to zero out the stack above.)

What's the advantage of running the tests in a nested config?  Is it to test the nested autodiff?
Do the autodiff versions ever throw their own exceptions?  If they delegate to the double version, they just get the domain checks there and the messages are automatically consistent.  Are there cases where autodiff version of function should throw different exceptions for the same input value as the double version?
Automatically catching the type and checking for it is tricky.  There's a hack I put into the language for rethrow_located that tries to enumerate all possible exception types that are known---but the list is technically open ended so you need cleanup anyway.

What's the advantage of running the tests in a nested config? Is it to test the nested autodiff?

There isn't an advantage, as far as I can tell.
The way this implementation works is that it calls a function call_all_argument_combos() that promotes all the doubles to stan::math::var s before ever calling the function. That's why nesting is necessary. We can't clean out the whole autodiff stack or else we lose the promoted variables on the stack. I don't know if that made sense... it doesn't have to be done this way, but that's what the current implementation does.

Do the autodiff versions ever throw their own exceptions? If they delegate to the double version, they just get the domain checks there and the messages are automatically consistent. Are there cases where autodiff version of function should throw different exceptions for the same input value as the double version?

Since we can write custom specializations for templated functions (and we do), it's possible that the specialized versions are not written consistently. This would be programmer error and I think we just want to prevent that. Especially if someone makes a change to one instantiation and not the other.
There should be no cases where the autodiff version should throw a different exception as the double version. I can imagine it happening where in computing the gradient we throw an exception (maybe through Boost).... I'm not sure what we should do if we can't compute the gradient for parameters that are valid.

Automatically catching the type and checking for it is tricky. There's a hack I put into the language for rethrow_located that tries to enumerate all possible exception types that are known---but the list is technically open ended so you need cleanup anyway.

Yes. In this implementation, it just checks to see that an exception was thrown. The types are ignored.

I think the nested autodiff is at the wrong level
What's the advantage of running the tests in a nested config?

It's quite likely I got it all wrong. I don't think it's necessary (or
desirable). I wouldn't mind if we just axed it.

I think by autodetecting whether the prim throws and using that as a baseline for the autodiff can mask programmer error
Automatically catching the type and checking for it is tricky.

Not checking that the autodiff version throws in the same places the
prim does masks programming errors too. If there is some sort of
function that breaks this assumption, then we'd just have to test that
the old school way.
My first try at this had fancier error checking, but it became clear
pretty quickly (from talking to Bob and coding with it) that being
specific was more confusing.
There's real limitations to the error checking stuff. The idea is that
someone can take all the error-check tests they wrote for prim (which
don't use this framework), copy paste them over to their rev tests,
and just wrap em' up in these calls.
I guess we could ask them to specify what error should be thrown as
well and that wouldn't be any harder? I might be forgetting something.
The difficult thing this is handling is instantiating all the
different autodiff types and shuffling around test values, but I guess
they all should be throwing the same error. So maybe splitting of the
error checking is fine in that regard? I could be forgetting
something.
On 12/21/18, Bob Carpenter<EMAIL_ADDRESS>wrote:

What's the advantage of running the tests in a nested config?  Is it to test
the nested autodiff?
Do the autodiff versions ever throw their own exceptions?  If they delegate
to the double version, they just get the domain checks there and the
messages are automatically consistent.  Are there cases where autodiff
version of function should throw different exceptions for the same input
value as the double version?
Automatically catching the type and checking for it is tricky.  There's a
hack I put into the language for rethrow_located that tries to enumerate all
possible exception types that are known---but the list is technically open
ended so you need cleanup anyway.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/stan-dev/math/pull/1021#issuecomment-449434781

...

The way this implementation works is that it calls a function call_all_argument_combos() that promotes all the doubles to stan::math::var s before ever calling the function.

I see.  That's unfortunate, because it leads to this kind of problem. Can it be done lazily?

That's why nesting is necessary. We can't clean out the whole autodiff stack or else we lose the promoted variables on the stack. I don't know if that made sense... it doesn't have to be done this way, but that's what the current implementation does.

I get it.  I don't think we want to be abusing the autodiff stacks this
way.  At least that wasn't what I intended them for.  I really meant it
to be literally used in a nested way, not for variables on the nested
stack to point out of the nested stack.  We should be careful about what
we are guaranteeing for nested autodiff.  I think Sebastian may be running
into similar testing issues.

Do the autodiff versions ever throw their own exceptions? If they delegate to the double version, they just get the domain checks there and the messages are automatically consistent. Are there cases where autodiff version of function should throw different exceptions for the same input value as the double version?
Since we can write custom specializations for templated functions (and we do), it's possible that the specialized versions are not written consistently. This would be programmer error and I think we just want to prevent that. Especially if someone makes a change to one instantiation and not the other.

I was trying to ask if there were cases where we want different answers.  Otherwise we can
test that the autodiff versions match the throws of the double versions.  That's what
I did for the basic operator testing framework.  I was not testing type of exception or
message, though.

There should be no cases where the autodiff version should throw a different exception as the double version. I can imagine it happening where in computing the gradient we throw an exception (maybe through Boost).... I'm not sure what we should do if we can't compute the gradient for parameters that are valid.

Right---that's the case I was thinking about.  It didn't come up
for the basic arithmetic.

Automatically catching the type and checking for it is tricky. There's a hack I put into the language for rethrow_located that tries to enumerate all possible exception types that are known---but the list is technically open ended so you need cleanup anyway.
Yes. In this implementation, it just checks to see that an exception was thrown. The types are ignored.

That's probably OK.  At least it's what I did for the operator tests.

I think the nested autodiff is at the wrong level What's the advantage of running the tests in a nested config?
It's quite likely I got it all wrong. I don't think it's necessary (or desirable). I wouldn't mind if we just axed it.

Thanks. I don't think it's that far off. I feel like this is going to be one of those things where we each make improvements until it looks good enough. What you've done is really neat. I think I can take a pass and make some changes that take care of the nesting, etc. And if that isn't good enough (which it probably won't be), then hopefully someone can make improvements to that.
Having the ability to write in C++11 and on is awesome. I wish we had this when we started the project.

On Fri, Dec 21, 2018 at 8:06 PM Bob Carpenter<EMAIL_ADDRESS>wrote:

...

The way this implementation works is that it calls a function
call_all_argument_combos() that promotes all the doubles to stan::math::var
s before ever calling the function.

I see. That's unfortunate, because it leads to this kind of problem. Can
it be done lazily?

Yes, it can.
Instead of expanding the arguments by promoting double to vars, we can just
expand the types of the arguments and within each call, promote if
necessary. (This is so hard to talk about, but instead of the having a
double variable x be put into a tuple as tuple<double, var>(x, var(x)), we
could pass all the args and a type list.)

That's why nesting is necessary. We can't clean out the whole autodiff
stack or else we lose the promoted variables on the stack. I don't know if
that made sense... it doesn't have to be done this way, but that's what the
current implementation does.
I get it. I don't think we want to be abusing the autodiff stacks this
way. At least that wasn't what I intended them for. I really meant it
to be literally used in a nested way, not for variables on the nested
stack to point out of the nested stack. We should be careful about what
we are guaranteeing for nested autodiff. I think Sebastian may be running
into similar testing issues.

Agreed.

Do the autodiff versions ever throw their own exceptions? If they
delegate to the double version, they just get the domain checks there and
the messages are automatically consistent. Are there cases where autodiff
version of function should throw different exceptions for the same input
value as the double version?
Since we can write custom specializations for templated functions (and
we do), it's possible that the specialized versions are not written
consistently. This would be programmer error and I think we just want to
prevent that. Especially if someone makes a change to one instantiation and
not the other.

I was trying to ask if there were cases where we want different answers.
Otherwise we can
test that the autodiff versions match the throws of the double versions.
That's what
I did for the basic operator testing framework. I was not testing type
of exception or
message, though.

I don't think so. The only place that I know where we violate this is in
the fvar with the nan check. But creating these things with nans is usually
a user error and we're not really supporting forward and mixed mode yet.

Closing for now. Not getting rid of the branch.


'Live' popup repeats continuously

Checklist:

[x] I updated to the latest version available
[x] I cleared the cache of my browser

Release with the issue: v4.0
**Last working release (if known):**v3.0
Browser and Operating System:

Description of problem:

Javascript errors shown in the web inspector (if applicable):

Additional information:
https://user-images.githubusercontent.com/42767976/192262726-7af90132-bbce-4b0b-b8f3-cc2c58c98092.mov

Interesting! Can you hold down the Frigate menu button and paste the diagnostics? Are you using card_mod or anything else that may impact the normal rendering?

PS: You can turn off the title popups temporarily from the card edit window, as that's pretty annoying.

I don't seem to be able to find the setting to turn off the title popup ?

PS: You are specifying webrtc-card as your live provider, but have not specified any webrtc card configuration, which is not a valid combination (either choose a different live provider, or include the details required for the webrtc-card provider). Not suggesting this is the trigger for the bug, but it could be:-)

Thanks.  I have specified the web-rtc card config now and it has made no change.

I have the same issue now and again. Is it at all possible to just disable those message-toasts altogether? I never liked them in my use-case and often get in the way when you want to watch a recording and fullscreen it straight away, ie have to wait till the floating message goes away before being able to click fullscreen/volume etc on the player bar.

Hi Sarah, if you see the post above you will see where to disable the pop ups, I have done this for the moment.

@cwelsh1812  Mind answering this one:

Are you using card_mod or any other integrations that may impact rendering?
Does this happen on initial load, or do you do anything to trigger it?

@cwelsh1812 One more: Can you try the HA live provider and see if it still happens?

@dermotduffy Yes I have card-mod installed though I have not made any changes to the frigate card.
It does not happen with the HA live provider.

@dermotduffy Ok, after deleting the cards and creating new ones, it's now not happening, although it does still happen on the preview of the card configuration page.

@cwelsh1812 Thanks! Would it be possible to remove card_mod temporarily and see if it still happens? My guess is that it is related.

It does not happen with the HA live provider.

So just webrtc-card then? Thanks, this narrows it down a lot.

@cwelsh1812 Thanks! Would it be possible to remove card_mod temporarily and see if it still happens? My guess is that it is related.

It does not happen with the HA live provider.

So just webrtc-card then? Thanks, this narrows it down a lot.

Sorry for the delay, I have removed card-mod and it still happens, although it is inconsistent, sometimes I can get it to happen on the live display in the dashboard, other times it only happens on the card preview.

I'm experiencing the same issue, also webrtc-card. It happens immediately after reload. Let me know if I can provide any other details.

Whilst working on #861 I found a bug that causes the image view to proclaim new media has been loaded repeatedly, which causes these toast messages to repeatedly show up. This is now fixed in code.
My theory is that this is responsible for the behavior we are seeing here, under the following conditions:

The users webrtc installation is somehow broken such that it does not render.
The user has live.show_image_during_load set to true (the default).

... in this case, since the webrtc element doesn't render, the card shows a static image waiting for it to load. That image refreshes every 1 seconds, and with the above bug (now fixed, but not in a build yet) that causes the toast message to repeatedly appear.
To confirm this theory, please try either:

Setting this value to false:

live:
  show_image_during_load: false

... (if my theory is correct you'll just see a forever spinning 'Waiting for WebRTC card to load' message.

OR: Just create a 'native' WebRTC Card (i.e. not a Frigate card) on your dashboard, and see if it works -- as this theory requires it to not work.

You are correct, forever spinning message !

Thanks @cwelsh1812! So I think I'll mark this as fixed, since the underlying image component will now no longer exhibit this behavior from the next build (but you still have a separate webrtc problem that is not related to Frigate!).
Feel free to re-open if you / anyone thinks I've missed something here!

I dont use webrtc and the spining message its my problem too.


Download from arbitrary HTTP URLs with digest verification

Context
Today sget can fetch content from OCI registries, but not from arbitrary HTTP URLs.
Importantly, sget's OCI fetching never allows content to be downloaded without content verification. The OCI resource must either be signed and verified, or its digest must be specified by the user.
Proposal
As a first step, let's ensure that HTTP downloads are supported only if the user provides an expected digest for the retrieved content. Until sget supports signature verification for HTTP retrievals, providing a digest should be required. Furthermore, sget should verify that the retrieved content's digest matches the user-provided digest before sharing the content with the user.
(This is Phase 0 from the project Roadmap.)
Proposed syntax:
$ sget https://sh.rustup.rs --digest 'sha256:a3cb081f88a6789d104518b30d4aa410009cd08c3822a1226991d6cf0442a0f8'

Open questions

Should sget allow HTTP downloads without TLS? And what about with invalid TLS? With a MITM attack, the content provided to the user would need to match the provided digest, even if the content was intercepted by a malicious actor, or else sget would prevent the user from receiving the content. However, there are other concerns left unaddressed.

So what comes to mind here, is how will users know the correct digest to use?
Another factor is this labours a degree of maintenance on to the user. Right now they can just run curl $site now they need to check what is the correct digest for the very latest release and update their automation scripts.
I guess my point is, if you want folks to pivot away from curl , then adding on extra steps to manage is not likely going to convince them to change. Ideally you would want to be able to have users run `alias curl="sget" and have a seamless migration.

That's a good point, @lukehinds. This feature is intended to be one incremental step toward better security, but not representative of the eventual solution that we hope lures users away from curl.

how will users know the correct digest to use?

Sometimes they won't know, in which case this feature doesn't help. But sometimes users would be able to simply copy an sget ... command from the software maintainer, such as on a GitHub README.md. We think this scenario will actually be somewhat common. In this situation, the user may feel comfortable trusting the README content, in which case they can ensure that the content they're retrieving hasn't been modified (maliciously or otherwise) since the time when the content existed on the maintainer's environment.
For cases where the user doesn't want to trust the command, this feature wouldn't be valuable.
So tl;dr: this is an incremental step, not a comprehensive solution.

Sometimes they won't know, in which case this feature doesn't help. But sometimes users would be able to simply copy an sget ... command from the software maintainer, such as on a GitHub README.md. We think this scenario will actually be somewhat common. In this situation, the user may feel comfortable trusting the README content, in which case they can ensure that the content they're retrieving hasn't been modified (maliciously or otherwise) since the time when the content existed on the maintainer's environment.

That should really be avoided, as a compromise of the repository means someone swaps out a nefarious release with a nefarious digest [0] as both attack vectors are stored on the same medium. Also copy/paste operations can also very hazardous [1]
[0] https://micahflee.com/2016/02/backdoored-linux-mint-and-the-perils-of-checksums/
[1] https://thejh.net/misc/website-terminal-copy-paste
I would recommend you skip this phase as it has a low effort attack surface and can provide users with a false sense of security (which if it happens, damages the sigstore name).


Added configurable retry attempts

Hello,
Firstly, thank you for this library :)
I needed to kill the goroutine responsible for the initial connection retry if the server was unreachable. Hopefully this PR is clean (i've tested in my Kumis application).
Thanks,
Mo

+1

+1

Perhaps it's worth integrating this mechanism in the calling "func (c *Conn) loop()" method. That already has code for various retries, code for quitting the loop on connection closing, etc.
My scenario is about caller giving up and calling conn.Close(). In other words I'm ok with infinite looping as long as conn.Close hasn't been called.


[tests-only][full-ci]send X-Request-Id in header of every request

Description
This PR includes the use of X-Request-Id header in each API requests. The X-Request-Id header consists the line reference of the scenario, for example: apiComments/editComments.feature:26-28. This will make easier to track the server logs as this reference will be logged if any of the test scenario fails.
Related Issue

https://github.com/owncloud/ocis/issues/7022

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[ ] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

Please, add the example log in the PR description from the oCIS server logs which contain the requiest-id defined by the tests


masked_multihead_attention_kernel got incorrectly output bug with params.masked_tokens defined

Branch/Tag/Commit
v5.1.1
Docker Image Version
custom linux cuda docker-image with cudnn-11.4
GPU name
Tesla 2080Ti
CUDA Driver
470.63.01
Reproduced Steps
I am an fresher of GPU programe, now i am encoutering an problem with incorrect fasttrransformer output with FtDecoder module.
The code here:
https://github.com/NVIDIA/FasterTransformer/blob/release/v5.1.1/src/fastertransformer/kernels/decoder_masked_multihead_attention/decoder_masked_multihead_attention_template.hpp#L1219
seems to implement the same logic of masking like onmt.modules.multi_headed_attn.MultiHeadedAttention here:
https://github.com/OpenNMT/OpenNMT-py/blob/master/onmt/modules/multi_headed_attn.py#L233
I want to call this function with a mask like the onmt.modules.multi_headed_attn.MultiHeadedAttention does, so i modified the fasttransformer code and added a parameter: enc_mask like this:

Line: https://github.com/NVIDIA/FasterTransformer/blob/release/v5.1.1/src/fastertransformer/models/decoder/Decoder.cc#L253 add the input tensor with enc_mask:

std::vector<Tensor> cross_attention_input_tensors{
            Tensor{MEMORY_GPU, data_type, {batch_size, hidden_units_}, normed_self_attn_output_},
            input_tensors->at(1),  // encoder_output [B, seqlen, EbedDim]
            input_tensors->at(2),  // encoder_sequence_length [B]
            input_tensors->at(3),  // finished [B]
            input_tensors->at(4),  // step [1]
            enc_mask,  // enc_mask [B, 1, seqlen]
        };

Add a line before: https://github.com/NVIDIA/FasterTransformer/blob/release/v5.1.1/src/fastertransformer/layers/attention_layers/DecoderCrossAttentionLayer.cu#L498

        params.masked_tokens = enc_mask;

        cross_multihead_attention(params, stream);

Add a print log after do cross_attention_dispatch here: FasterTransformer/DecoderCrossAttentionLayer.cu at release/v5.1.1 · NVIDIA/FasterTransformer (github.com)

    cross_attention_dispatch<T>(q_buf_,
                                attention_weights->query_weight.bias,
                                key_mem_cache,
                                attention_weights->key_weight.bias,
                                value_mem_cache,
                                attention_weights->value_weight.bias,
                                memory_sequence_length,
                                context_buf_,
                                finished,
                                batch_size,
                                batch_size,
                                head_num_,
                                size_per_head_,
                                step,
                                mem_max_seq_len,
                                is_batch_major_cache_,
                                q_scaling_,
                                enc_mask,   // here add enc_mask parameter
                                output_attention_param,
                                stream_);
    sync_check_cuda_error();

    if (step <= 2) {
        FT_LOG_INFO("------------->>>>>>>decoder-layer cross-attn before finnal linear  step: %d, shpae: [B,1,%d]", step, hidden_units_);
        printMatrix((T*)context_buf_, batch_size, std::min(16, (const int)hidden_units_), hidden_units_, true);
        printf("\n");
    }

Now the code is prepared, and when i passed the enc_mask parameter with a tensor like this:
# mask: [10, 1, 55], here 10 is batch, 55 is max_seq_len
[
 [[[False, False, False, False, False, False, False, False, False, False,
           False, False, False, False, False, False, False, False, False, False,
           False, False, False, False, False, False, False, False, False, False,
           False, False, False, False, False, False, False, False, False, False,
           False, False, False, False, False, False, False, False, False, False,
           False, False, False, False, False]]],
 ..., # another same 4 tensor as the above one
 [[[True,  True,  True,  True,  True,  True,  True,  True,  True,  True,
            True,  True,  True,  True,  True,  True,  True,  True,  True,  True,
            True,  True,  True,  True,  True,  True,  True,  True,  True,  True,
            True,  True,  True,  True,  True,  True,  True,  True,  True,  True,
           False, False, False, False, False, False, False, False, False, False,
           False, False, False, False, False]]],  # the last 15 tokens is effectived
 ..., # another same 4 tensor as the above one
]

the output of print log is:

Now, you can see the first 5 rows is correct, but the last 5 rows is wrong. As the mathmatic is this:
$$masked(Softmax(\frac {QK^T}{\sqrt {d}}))* V$$
it shoud not be zero on the previous columns of the last 5 rows.

The shape of the mask is [bs, seq_len], which means that it is only used when q, k and v have same length.
But in cross attention, q and k/v have different length. So, your results are wrong.

@byshiue
Thanks for your reply.  Firstly, i must apologise for the mistake of the QKV formula: the wrong order of Softmax and masked, the correct formula should be:
$$Softmax(masked(\frac {QK^T}{\sqrt {d}}))* V$$
For your answer, i don't understand what your mean: "A mask with shape: [bs, seq_len] is only used when q,k,v have same shape."
Here let me take an example:
For a K, V with shape: [bs, h_num, seq_len, h_size], and the Q with a shape: [bs, h_num, 1, h_size].
So the result of the following formula should be: [bs, h_num, 1, seq_len]
$$\frac {QK^T}{\sqrt {d}}$$
Now a mask with shape: [bs, 1, 1, seq_len] can worked to this formula before calculate the Softmax and got a masked result with shape of [bs, h_num, 1, seq_len]:
$$masked(\frac {QK^T}{\sqrt {d}})$$
And the finnal result of QKV should be a shape: [bs, h_num, 1, h_size]
$$Softmax(masked(\frac {QK^T}{\sqrt {d}}))* V$$
So, a mask with shape: [bs, seq_len] can totally no problem worked when q,k,v have the same shape.

@byshiue

The shape of the FT's mask is [bs, seq_len], which means that it is only used when q, k and v have same length. It is different to mask of OpenNMT. In cross attention, q and k/v have different length. So, your results are wrong.

And i want to know whether i am miss understand the role of the parameter: params.masked_tokens of cross_multihead_attention?  Or how can i get the same result like the onmt's multiheadattention with an mask specified when using the cross_multihead_attention cuda kernel?
Thanks.

The parameter masked_tokens is only used in self attention, where the sequence length of q, k and v are same.
For cross attention, please refer the DecoderCrossAttentionLayer.cu about how to apply it on cross attention.

The parameter masked_tokens is only used in self attention, where the sequence length of q, k and v are same.
For cross attention, please refer the DecoderCrossAttentionLayer.cu about how to apply it on cross attention.

Thanks, i understand what your means to masked_tokens here.
But i still can not found any information about how to use the mask to the cross attention from the DecoderCrossAttentionLayer.cu file, and the masked_multihead_attention_kernel() in https://github.com/NVIDIA/FasterTransformer/blob/release/v5.1.1/src/fastertransformer/kernels/decoder_masked_multihead_attention/decoder_masked_multihead_attention_template.hpp#L774 is too complicate for me to understand what's wrong when the mask_tokens is specified.
So, may you give me more help? This problem havs stuck with me for serveral weeks, thanks.

In cross attention, we skip the elements by params.memory_length_per_sample, which implies the length of K/V. So, we don't use mask.
If your cross attention is standard, you can refer DecoderCrossAttentionLayer.cu to understand how to set the parameters for cross attention.

In cross attention, we skip the elements by params.memory_length_per_sample, which implies the length of K/V. So, we don't use mask. If your cross attention is standard, you can refer DecoderCrossAttentionLayer.cu to understand how to set the parameters for cross attention.

@byshiue OK, i seet what your means and i will try to check this,  thanks!

@byshiue I have checked your idea, thank you, and now i'll close this issue.


Obsolete

Please write a note in README of this repo that webkit is in openembedded-core/meta/recipes-sato/webkit - that's a maintained one.
Thanks.

https://github.com/openembedded/openembedded-core (this is the main RO mirror with better bandwidth, GitHub is not used for PullRequests)

Hi, there is already a note about this on the README file:
The name of the recipe is the same than the one available in oe-core (master), so you should select which version of webkitgtk you want to build in your local.conf

Although I agree the note can be a bit clearer. I will improve it.
Also, this meta layer is mainly meant for the following purposes:

Allowing people to build WebKit2GTK+ on older branches of Yocto/OE (for example: fido, etc).
Allowing people to build WebKit4Wayland (there is no recipe for this in oe-core).

Clarified in 7b8f1226ae1116265e9102dd565c2c49c8e2c6b9


feat: usage of local evnvvar in func cfg file

User now can use syntax like:
envVars:
  SOME_SECRET: {{env.API_KEY}}

Signed-off-by: Matej Vasek<EMAIL_ADDRESS>

resolves #234

What is good place to put documentation about this?

Good question @matejvasek. I suppose we could actually start filling in some of the blanks in the docs stubs here. Maybe add something to the "cookbook" here: https://github.com/boson-project/func/blob/main/docs/functions_cookbook.md. It might end up being moved somewhere else, but that's probably as good a place as any for now.

Yeah agree and other good place to document this would be in the section describing the "spec" of the cfg file.

Yeah agree and other good place to document this would be in the section describing the "spec" of the cfg file.

I've just started to add docs to https://github.com/openshift-knative/docs since this is where everything lives for dev preview and I was just thinking yesterday that those docs needed a func.yaml configuration reference doc. That's probably a bigger task than just documenting this particular feature though. I don't want this PR to be held up by something that big. How about we land this and track the documentation here: https://github.com/openshift-knative/docs/issues/51

Uhh nevermind. Put that doc here, I suppose.

I think the best place for Docs for this feature is the (unfortunately not yet existing) Guide mentioned in this PR: https://github.com/boson-project/functions/pull/35/files#diff-406771b961705379986973d48ea9957ca8e1408fde7f33a320ac791b4c98c9edR22

@lance can I merge this now?

@lance may I merge this now?

Yes - please!


Update the launcher executables fetching script

Closes #159

sigh The script no longer works.

Whelp, looks like the executables on bitbucket weren't updated when the ones in distlib were updated. :/

Whelp, looks like the executables on bitbucket weren't updated when the ones in distlib were updated. :/

if I understand it correctly, the executables are built from the files in the repo. maybe we could build them ourselves using GH Actions runner?

Superseded by #212


Locating term-tracker for imported modules

Description of the issue
term tracker items added in PR #1086 (all related to imported ontologies) are located in the oeo.omn-file and not in the defining ontology. As these are the only ones located there, this grew my suspicion.
How does the general policy concerning term tracker items and imported ontologies look like?
Have there been any similar situations in the past?

Discussions are moved to follow-up issue https://github.com/OpenEnergyPlatform/ontology/issues/1154
(This topic touches also other areas not covered in this issue.
So, information are collected in one place (https://github.com/OpenEnergyPlatform/ontology/issues/1154) for reworking the import process)


Null check in the nodeImage attribute to allow nodes without images

Hi!
Great work! This (very) small change will allow having a node without the nodeImage attribute. I think this is the intention after having code like this in other places:
if (d.data.nodeImage && d.data.nodeImage.width) {
                    imageWidth = d.data.nodeImage.width
                };

Cheers!

Thank you, I modified your PR a bit, merging this

Thank you, I modified your PR a bit, merging this

Good catch, JS is not my daily language... I think you meant && instead? (because of the "short circuiting") That way a null on any of nodeImage or nodeImage.url will accomplish the same.

Good catch, thank you


How to connect Stanford Core NLP Server and view output?

I am trying to use Stanford NLP for.NET. I am very new to this.
I am able to connect Stanford core NLP server using below code.
How to print NER?
Is I am doing it correct way, can anyone provide some example code to do this
Thanks
  ```
        var props = new Properties();
        props.setProperty("annotators", "tokenize, ssplit, pos, lemma, ner");

        StanfordCoreNLPClient pipeline = new StanfordCoreNLPClient(props, "http://localhost", 9000, 2);
        var text = "Kosgi Santosh sent an email to Stanford University. He didn't get a reply.";
        var annotation = new edu.stanford.nlp.pipeline.Annotation(text);
        pipeline.annotate(annotation);

Hi,I am getting sentences as null in the below line..Can someone help?
var sentences = document.get(sentencesAnnotationClass) as java.util.AbstractList;


Ending on docs seems out of place

To me the last header section in the markdown are unnecessary

END Microsoft Specific

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2b02cc93-0d7c-d1bf-64ab-e6111525c809
Version Independent ID: 5a9af828-31a5-9042-d997-e662928753bf
Content: #include directive (C/C++)
Content Source: docs/preprocessor/hash-include-directive-c-cpp.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

Ahh, I can see multiple files contain this end statement such as #undef as well, I assume there is a reason for this then?

@jonaslagoni
You've discovered an artifact of history. Many of our articles have sections bracketed by
Microsoft Specific

Microsoft-specific content goes here.

END Microsoft Specific
This convention dates back to our printed documentation days. It doesn't translate as well on the web. It's been migrated through several versions of content management systems. Sometimes it's been translated into an H2 or H3 header, and sometimes it just has bold formatting. When we touch a file with these markers, we'll often use a different, more subtle way to call out content that's specific to the Microsoft compiler or library implementation, or the Windows platform. Still, this form appears 339 times in 333 articles, by my count, so there's not much point in addressing it piecemeal. We'll come up with a global solution eventually. For now, it's just an object of curiosity.


orientdb does not support systemd startup notification

OrientDB Version, operating system, or hardware.

v2.0 SNAPSHOT[ ] - .18[ ] .17[ ] .16[ ] .15[ ] .14[ ] .13[ ] .12[ ] .11[ ] .10[ ] .9[ ] .8[ ] .7[ ] .6[ ] .5[ ] .4[ ] .3[ ] .2[ ] .1[ ] .0[ ]
v2.1 SNAPSHOT[ ] - .16[ ] .15[ ] .14[ ] .13[ ] .12[ ] .11[ ] .10[ ] .9[ ] .8[ ] .7[ ] .6[ ] .5[ ] .4[ ] .3[ ] .2[ ] .1[ ] .0[ ]
v2.2 SNAPSHOT[ ] - .rc1[ ] .beta2[ ] .beta1[ ]

Operating System

[x] Linux
[ ] MacOSX
[ ] Windows
[ ] Other Unix
[ ] Other, name?

Expected behaviors and actual behavior
For systemd orientdb is active when the startup command is executed and not when it is ready for accepting connections. When you run a dependent service which is dependent on orientdb, it is properly that this service fails as orientdb is not yet to accept connections.
If orientdb would support systemd notification, it could notify systemd of the current status.

systemd-notify may be called by daemon scripts to notify the init system about status changes. It can be used to send arbitrary information, encoded in an environment-block-like list of strings. Most importantly, it can be used for start-up completion notification.

https://www.freedesktop.org/software/systemd/man/systemd-notify.html
https://www.freedesktop.org/software/systemd/man/sd_notify.html
Steps to reproduce the problem
Use systemd example file of development branch

Orientdb can be started in many different (bash, docker, systemd) ways and it is written in Java. I will explore the way of integrating with systemd more deeply and keep you posted on this issue.

Hi Roberto, thank you very much for your feedback.
My quick research showed that there are some lib for java which implements systemd notification, but my Java knowledge is a bit rusty. For sure the implementation should not impact the portability of oriented.
https://github.com/faljse/SDNotify
https://gist.github.com/hanikesn/568882f96d543758e7b2

Sorry for our delay, we will not implement this feature. Note that we should run on many different OS (linux/win/bsd) with or without systemd. Adding such a dependency and management will increase complexity.


Always require token when user has an old cookie

For security purpose because the old cookie wasn't account specific. See #58

Thanks @Gasparila and @MikeRogers0, I merged your PRs.
I did a little change when user has an old cookie with the remember device option. I hope tomorrow or this week I'm going to release a new gem version.


Stopped notifications. Then. Loading Forever.

The client from Google Play runs for a while on Samsung Galaxy Note 4 with Android 6.0. But leaving the app, after a while I stopped receiving notifications. When I run the app again I realized that there is an ongoing notification that says "Riot is listening to events".

I realized that after connecting to wifi, all that suddenly stopped and riot.im was working as usual again. How much bandwidth does Riot.im need to stay stably connected and send/receive messages?
Could it really be just a bad network connection? I wonder about this because before I connected to wifi I could send messages through Facebook Messenger and WhatApp, but not riot.im.

"Listening for events" means that the GCM registration failed : it is the fallback mode.
It might happen when there is a bad network connection or a server issue.
Open the application again triggers another GCM registration if it failed.
Without a bug report, i cannot tell what was wrong.


As a user, App analytics and Visualizations should reliably (TEST/REFACTOR) work for all viz types

https://github.com/orgs/opensearch-project/projects/71/views/1?visibleFields=["Title"%2C21663448%2C"Assignees"%2C"Status"%2C21663291%2C"Linked+pull+requests"%2C"Labels"]&groupedBy[columnId]=21663448


User is not able to adjust slider properly via keyboard

A team member will update this issue with more details soon.

This is your friendly Microsoft Issue Bot. I created this issue automatically as requested by a team member.


[BUG] "import" is not supported

Summary
Not sure why but I noticed the following line is commented out and thus import is not supported.
https://github.com/Sublime-Instincts/BetterTwig/blob/a005af78f06d17cd91e4800905e68e70a2dfecd7/resources/syntax/Twig.sublime-syntax#L58
Problematic Twig template.
https://twig.symfony.com/doc/3.x/tags/import.html
{% import '_macro/handsontable.html.twig' as handsontable_macro %}

Expected Behaviour
I simply un-comment it and get the following

Actual Behaviour

Environment

Sublime Text build: 4090
BetterTwig version: v1.0.3
Twig version: v3.1.1

Thanks for the report. Currently, I am working on a bunch of improvements and this is on the list, now that I have a better idea of how to scope imports (At that time, I had some confusion so I left it commented out). This will be fixed in v1.0.4

This should be fixed as of v1.0.4


compiling on SunOS x86_64 fails

I'd like to get several witnesses running on SmartOS. Unfortunately, the compilation is failing.
See here https://bitsharestalk.org/index.php/topic,21053.0.html
I'd like to port graphene to pkgsrc (it will then be available for NetBSD and SmartOS) and need to get past this. Any help welcomed.

It seems the issue in the linked thread is that the C++ library for the compiler you're using may #define int8_t char instead of typedef int8_t char, which makes the compiler complain that providing template overrides for both char and int8_t is wrong (since by the time it gets to template processing the preprocessor's changed int8_t to char).  Or maybe the compiler doesn't allow different template overrides for a typedef'd alias.  You may be able to get past this particular error if you simply #ifdef out one of these two overrides in typename.hpp
I'm not sure if stdlib / compiler that does this is C++11 compliant, if your compiler does not support C++11 then this port is almost surely doomed (unless you want to re-write large parts of Graphene).  If you need compiler specific command line options to enable C++11 (for example g++ uses  -std=c++11) you may have to modify CMakeLists.txt to provide these flags.
As none of the core developers have SunOS machines, and it is very much a niche platform in 2016, we can't officially support it.  But good luck with this port!

It's not as niche as it might seem :) SmartOS is and has been under heavy development for the last years, the Illumos (https://en.wikipedia.org/wiki/Illumos) project is alive and well, and thousands of virtual machines run solaris at https://www.joyent.com/public-cloud and elsewhere.
I reached the same conclusion as you regarding int8_t being the same as char, it may be a perk of the solaris platform. My programming skills are limited though, and I'm unsure how to best fix it.
The problem (almost) surely isn't the compiler, it's g++ (GCC) 4.9.3.
Later today I may have some time to try and fix this, but regardless, if you'd like shell access to this instance, I'd be more than happy to provide login credentials.

bump


Future plans for versioneer

I have projects that use versioneer after finding out that xarray and dask used it. However, it seems the project is no longer actively maintained with the last commit happening almost 2 years ago:
https://github.com/warner/python-versioneer
There are two issues I've found with versioneer:

Wheels do not have a valid version number. They get 0+unknown unless an sdist is built first to populate the egg info. Building sdist is not something that is always done by CI environments like travis. This also happens if someone installs the package from github pip install git+https://github.com/pydata/xarray.git. At least these are my findings with my satpy library.
versioneer.py has some style issues:

versioneer.py:941:-13592: W605 invalid escape sequence '\s'
versioneer.py:941:-13408: W605 invalid escape sequence '\s'
versioneer.py:941:-13228: W605 invalid escape sequence '\s'
versioneer.py:941:-11196: W605 invalid escape sequence '\d'
versioneer.py:941:-8162: W605 invalid escape sequence '\d'

This was worked around in xarray by adding a noqa to the top of the module.
So my question is, do the xarray devs (or dask devs) see this as a problem? What are your plans for the future? Have you enjoyed using versioneer?
I guess I should probably CC @warner on this too in case they are still active on github.

I'm really happy with https://pypi.org/project/setuptools-scm/ in other projects, especially as its usage is normally a single line in setup.py.

Ditto @xhochy re setuptools-scm (though my experience is internally only, with more narrow requirements than a public project)
Our setup.pys contain only:
    install_requires=['setuptools_scm'],
    use_scm_version=dict(version_scheme='post-release'),

I believe this has been fixed by moving to setuptools-scm in #3714.


Dreame d9 max White Version

Device model
dreame.vacuum.r2312
Device name
Dreame d9 max White Version (not same as black one in your list)
Does the device require a MiCloud connection?
No
Anything special about the device?
You have already added support for black version dreame.vacuum.p2259 but white one is different and doesnt work

Did you already try to add the device using this plugin? What issues are you facing?

Did you already try to add the device using this plugin? What issues are you facing?

Yes, and devices was added to homekit but doesnt response

Are you sure that the token is correct and that you entered the correct ip? What does the debug log say?

[22/06/2024, 23:40:06] [miot] [Dreame D9 Max] Using module class for device type RobotCleaner, indentified by miot spec!   Initiating property polling!
Also when i try to run vacuum
[22/06/2024, 23:42:55] [Homebridge UI] [homebridge-config-ui-x] Failed to check registry.npmjs.org for updates: "Cannot read properties of undefined (reading 'length')" - see https://homebridge.io/w/JJSz6 for help.

That actually looks good. You would need to post a log from when you try to control the device. The error which you posted seems unrelated...

i have logs on status page, should i see logs anywhere else?

That actually looks good. You would need to post a log from when you try to control the device. The error which you posted seems unrelated...

[23/06/2024, 00:37:41] [Homebridge UI] [homebridge-config-ui-x] Failed to check registry.npmjs.org for updates: "Cannot read properties of undefined (reading 'length')" - see https://homebridge.io/w/JJSz6 for help.
it shows me this

The error does not seem to come from the miot plugin but from the Homebridge Ui plugin. You should re-check that.

The error does not seem to come from the miot plugin but from the Homebridge Ui plugin. You should re-check that.

It appears when i try to use accessory from plugin, all other accessories work well but this doesnt

It still does not help me in any way to identify the potential issue... Hence i am saying that you would need to re-check your settings and configuration.

Sorry for very late answer, but can the issue be that im using Dreame app instead of Mi home?

Ok i think i found reason,
The white version has a different device ID (r2312) compared to the older black version (p2259)
You support only black one, is it possible to add white one too?


Nested sortable elements cause conflict

I have a list of grouped components. I can sort them just fine with the plugin.
But inside my components I have some lists that also use the same plugin. So a sortable inside a sortable. This conflicts with the parent groups. For example, if I have 3 sortable groups, the first 3 list items inside each group conflict with the parents because they share the same index. Once I get to four or five in any list, they sort fine.
I tested setting the index in the nested sortable list to index+10 and it works without conflict, but of course causes other problems because is the wrong index.
Will work on an example showing the problem.

Hey @stahlmanDesign, if you can share some code, that would be helpful. Also, what do you mean by conflicts? You'll need to implement the onSortEnd logic differently for the nested sections for it to work, but besides that it should work out of the box.
Here's a quick example I put together of how nested sorting can be implemented: https://jsfiddle.net/8tw72bgy/

Thank you for the excellent support for this plugin. Your example showed me the way to solve my problem.

I fixed it! Your fiddle example now sorts items correctly
https://jsfiddle.net/stahlmandesign/8tw72bgy/10/ https://jsfiddle.net/stahlmandesign/8tw72bgy/10/
Before:
onSectionSortEnd(sectionIndex, {oldIndex, newIndex}) {
const section = this.state.sections[sectionIndex];
arrayMove(section.items, oldIndex, newIndex)
this.setState({
sections: this.state.sections
});
}
After:
onSectionSortEnd(sectionIndex, {oldIndex, newIndex}) {
let copiedSections = Object.assign([],this.state.sections);
let section = copiedSections[sectionIndex];
section.items = arrayMove(section.items, oldIndex, newIndex)
this.setState({
sections: copiedSections
});
}

Le 2016-09-17 à 08:13, Claudéric Demers<EMAIL_ADDRESS>a écrit :
Hey @stahlmanDesign https://github.com/stahlmanDesign, if you can share some code, that would be helpful. Also, what do you mean by conflicts? You'll need to implement the onSortEnd logic differently for the nested sections for it to work, but besides that it should work out of the box.
Here's a quick example I put together of how nested sorting can be implemented: https://jsfiddle.net/8tw72bgy/ https://jsfiddle.net/8tw72bgy/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/clauderic/react-sortable-hoc/issues/55#issuecomment-247766134, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7YBAQwPxPMKc4s3n7tt6SaI6-b8iv_ks5qq9lQgaJpZM4J_fUa.

I was able to get my items to sort without the drag handle (it still always detaches and floats on touch, and I can't figure out why except maybe a dependency on parent like you mention in common problmes)
But my secondary list (items A1, A2, A3 etc.) doesn't sort correctly.
When I went back to your fiddle I noticed it doesn't sort correctly there either (it always reverts to the A1, A2, A3 order no matter what).
I have been trying to figure it out and will continue since I got it to sort correctly with drag handle (except on touch), but wanted to let you know your example has that problem for items, in case you use it as a tutorial for other people.
Thanks and let me know if you see a quick fix. The error is not obvious to me.

Le 2016-09-17 à 08:13, Claudéric Demers<EMAIL_ADDRESS>a écrit :
Hey @stahlmanDesign https://github.com/stahlmanDesign, if you can share some code, that would be helpful. Also, what do you mean by conflicts? You'll need to implement the onSortEnd logic differently for the nested sections for it to work, but besides that it should work out of the box.
Here's a quick example I put together of how nested sorting can be implemented: https://jsfiddle.net/8tw72bgy/ https://jsfiddle.net/8tw72bgy/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/clauderic/react-sortable-hoc/issues/55#issuecomment-247766134, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7YBAQwPxPMKc4s3n7tt6SaI6-b8iv_ks5qq9lQgaJpZM4J_fUa.

Yeah sorry, about that, arrayMove no longer mutates the original array as of 0.0.10. See this thread for more details: https://github.com/clauderic/react-sortable-hoc/issues/61
I've updated the fiddle with the new usage https://jsfiddle.net/8tw72bgy/12/
(The only changed line is line 79)

I guess I don’t understand const in ES6. This looks like you are mutating state AND a const
const section = this.state.sections[sectionIndex];
section.items = arrayMove(section.items, oldIndex, newIndex);  // <— how can section be changed if it is a const, unless that doesn’t apply to objects referenced in dot notation
also it is essentially the same as:
this.state.sections[sectionIndex] = arrayMove(section.items, oldIndex, newIndex); // this seems like mutating react state
I know these comments are out of scope for your component, just curious if you have any insight. Thanks again

Le 27 oct. 2016 à 12:06, Claudéric Demers<EMAIL_ADDRESS>a écrit :
Yeah sorry, about that, arrayMove no longer mutates the original array as of 0.0.10. See this thread for more details: #61 https://github.com/clauderic/react-sortable-hoc/issues/61
I've updated the fiddle with the new usage https://jsfiddle.net/8tw72bgy/12/ https://jsfiddle.net/8tw72bgy/12/
(The only changed line is line 79)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/clauderic/react-sortable-hoc/issues/55#issuecomment-256690805, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7YBCJ7NcIX__1tghvx9qWFyotY-QmZks5q4MwfgaJpZM4J_fUa.

From MDN:

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, just that the variable identifier cannot be reassigned. For instance, in case the content is an object, this means the object itself can still be altered.

@clauderic hello; I was interested in your example but i might lack understanding to take it further
From what i can see,

index is just not passed as a prop through the components
this.state can't get reached in onSectionSortEnd
would a workaround seem obvious to some ?

sectionIndex is undefined, Can you please look into it? @clauderic

I'm trying to make it without  a locked axis but it doesn't work

I'm trying to do that with an array of arrays but it doesn't work:
https://codesandbox.io/s/vibrant-bas-fr9su

sectionIndex is undefined

Replace this parts with code below:
class SectionContainer extends React.Component {
  render() {
    const { section, index, sectionIndex, items, onSortEnd } = this.props;

    return (

Section: {section}

        <SortableItemList
          items={items}
          sectionIndex={sectionIndex}
          onSortEnd={onSortEnd.bind(this, sectionIndex)}
        />

    );
  }
}

const SortableSection = SortableElement(
  ({ section, index, sectionIndex, items, onSortEnd }) => (
    <SectionContainer
      section={section}
      index={index}
      sectionIndex={sectionIndex}
      items={items}
      onSortEnd={onSortEnd}
    />
  )
);

const SortableSectionList = SortableContainer(
  ({ sections, onSectionSortEnd }) => (

      {sections.map(({ section, items }, index) => (
        <SortableSection
          collection="section"
          key={`item-${section}`}
          section={section}
          index={index}
          sectionIndex={index}
          items={items}
          onSortEnd={onSectionSortEnd}
        />
      ))}

  )
);


DET sequences probability for custom multivariate distribution

This issue is to describe the information to be extracted from RAVEN in order to post process DET sequences probabilities when custom multivariate distributions are used.
It needs:

For each threshold, the value of the cdf (marginal) evaluated in that point.
For each sequence, the value of the N-dimensional cdf evaluated in the N-dim sample.
The distribution used is customized and input in RAVEN with the inverseWeight node.

What did you expect to see happen?
NA
What did you see instead?
NA
Do you have a suggested fix for the development team?
NA
Please attach the input file(s) that generate this error.  The simpler the input, the faster we can find the issue.

For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.

[ ] 1. Is it tagged with a type: defect or improvement?
[ ] 2. Is it tagged with a priority: critical, normal or minor?
[ ] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[ ] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[ ] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.

[ ] 1. If the issue is a defect, is the defect fixed?
[ ] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.)
[ ] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[ ] 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
[ ] 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

archived


Do not assume FormData is JSON. Allow it to be passed in directly to XHR...

... so it can be serialized properly.
Fixes #13

Make sense. Unfortunately it will break the node.js support because FormData is not defined in Node. Also I think this will also break on old IE version (Qajax supports IE6+).
I'm wondering what is the best way to fix that.
I suggest to pass in (window.FormData || function(){}) from https://github.com/gre/qajax/blob/master/src/browser.js. The https://github.com/gre/qajax/blob/master/src/node.js version would just pass a function(){}.
(this empty function ensure that FormData is not undefined: foo instanceof (function(){}) will always be false)

this should be fixed in 1.3.0

keep your PR open because I'll likely take your cool test :) (I quickly fixed it recently because I also needed the feature)

I've updated the PR so it's rebased from HEAD and contains just the specs. Should be good to merge.

cool thanks


A bunch of error detection for iOS onboarding flow

Fixes #10886
Fixes #12892
Partly reverts and moves #12911 because it was in the wrong place.

Check for locked phone
Check for incompatible Xcode
Check for unregistered phone
Check for conflicting certificates

Unfortunately tests needs a much bigger refactor in the installation flow.


Fullscreen exits when calling loadUrl, 0.25.2 on Windows

It appears there was a bug introduced in 0.25.2 with the BrowserWindow class.
With the following code:
@window.loadUrl(targetUrl);
@window.setFullScreen(true);
@window.show();

The call to loadUrl will always exit the window out of fullscreen mode. If you call setFullScreen before loadUrl, the window will enter fullscreen mode for a moment and then also exit out. Without a loadUrl call, the window stays in fullscreen mode.
This behavior was noted on Windows using electron-ia32 on 0.25.2 and above - have looked into changes introduced in 0.25.2 and have not noticed anything obvious that would cause this.

I'm merging this to #1598.


Type errors in dart_console-0.6.1 on Dart VM version: 2.9.0-17.0.dev.flutter-7e72c9ae7e

Probably caused by https://github.com/timsneath/dart_console/commit/ed52d5b722d7a1bcc52bc35d030a0ef381b7754f , though I'm not sure why the type of FillConsoleOutputCharacter changed.
../../../../../.pub-cache/hosted/pub.dartlang.org/dart_console-0.6.1/lib/src/ffi/win/termlib-win.dart:90:58: Error: The argument type 'Pointer<Uint32>' can't be assigned to the parameter type 'Pointer<Int32>'.
 - 'Pointer' is from 'dart:ffi'.
 - 'Uint32' is from 'dart:ffi'.
 - 'Int32' is from 'dart:ffi'.
        outputHandle, ' '.codeUnitAt(0), consoleSize, 0, pCharsWritten);
                                                         ^
../../../../../.pub-cache/hosted/pub.dartlang.org/dart_console-0.6.1/lib/src/ffi/win/termlib-win.dart:95:63: Error: The argument type 'Pointer<Uint32>' can't be assigned to the parameter type 'Pointer<Int32>'.
 - 'Pointer' is from 'dart:ffi'.
 - 'Uint32' is from 'dart:ffi'.
 - 'Int32' is from 'dart:ffi'.
        outputHandle, bufferInfo.wAttributes, consoleSize, 0, pCharsWritten);

Actually on windows, I'm getting the opposite type error on 0.6.0. 🤦

Hmm... I tightened a couple of the types to indicate their unsigned status in the parent win32 package, but I thought I'd fixed the downstream versions appropriately. I don't have a ton of tests for this hobby project, but I've just uploaded 0.6.2, which bumps the minver for the win32 dependency.
Could you give that a try?

Yeah, I managed to work around this by pinning to win32: 1.6.3, I will check out the new 0.6.2 version

Seems to be fixed, thanks @timsneath !


[Speedtest] ...

Extension
https://www.raycast.com/tonka3000/speedtest
Description
There should be an option to open the result link directly.
Who will benefit from this feature?
No response
Anything else?
No response

Hi @kyellareddy 👋
This is already possible when the test is done, hit  ⌥+enter


Relative index.html

I don't know if the feature is available, but I would like to use the app-router not from the root of my domain.
Ex.
www.mydomain.com/sub/folder/index.html as root
When I use it now, it automatically search for the index.html in the root (www.mydomain.com/index.html)

I just added a new feature in version 2.4.0 that will solve this issue. Now you can use globstars ** to match zero-to-many path segments, and you can use relative routes to ignore the path prefix.
For example:
<app-router>
  <app-route path="approuter" import="pages/home-page.html"></app-route>
  <app-route path="approuter/demo/:pathArg1" import="pages/demo-page.html"></app-route>
  <app-route path="approuter/notes" import="pages/notes-page.html"></app-route>
  <app-route path="*" import="pages/not-found-page.html"></app-route>
</app-router>

which is the same as
<app-router>
  <app-route path="/**/approuter" import="pages/home-page.html"></app-route>
  <app-route path="/**/approuter/demo/:pathArg1" import="pages/demo-page.html"></app-route>
  <app-route path="/**/approuter/notes" import="pages/notes-page.html"></app-route>
  <app-route path="*" import="pages/not-found-page.html"></app-route>
</app-router>

https://erikringsmuth.github.io/app-router/#/api#path


Restart Graph from Failure [#574]

Purpose
We currently can't rerun a graph from a failed node, our only choice is to attempt to run a completely new privacy request.
If a node in the graph fails a certain number of times, we continue with graph execution, just passing in empty values downstream to dependent nodes.  This is problematic for a couple of reasons: we may not have properly retrieved/masked data on the failed collection, or downstream collections.  Second, if we want to run another privacy request to rectify this, we may no longer be able to execute the graph because data has been destroyed.
Changes
Raise an exception when a graph node fails (instead of ignoring after "x" retries), and cancel remaining graph tasks.    Sending a POST request to /privacy-request/{privacy_request_id}/retry will restart the graph, only running remaining graph tasks.
Note

This doesn't yet expose to the frontend which node is the "failed" node; that will be in follow-up #570
This still preserves the "retry" behavior, except after "x" retries we re-raise an exception and exit, instead of continuing on.

Checklist

[x] Update CHANGELOG.md file

[x] Merge in main so the most recent CHANGELOG.md file is being appended to
[x] Add description within the Unreleased section in an appropriate category. Add a new category from the list at the top of the file if the needed one isn't already there.
[x] Add a link to this PR at the end of the description with the PR number as the text. example: #1

[x] Applicable documentation updated (guides, quickstart, postman collections, tutorial, fidesdemo, database diagram.
If docs updated (select one):

[x] documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
[ ] documentation issue created (tag docs-team to complete issue separately)

[x] Good unit test/integration test coverage
[ ] This PR contains a DB migration. If checked, the reviewer should confirm with the author that the down_revision correctly references the previous migration before merging
[ ] The Run Unsafe PR Checks label has been applied, and checks have passed, if this PR touches any external services

Ticket
Fixes #574

@ethyca/docs-authors minor edit to guide added here

Thanks @pattisdr, I just have that one product level question re: the webhooks


Package proposal: scdbg.vm

Package Name
scdbg
Tool Name
scdbg
Package type
ZIP_EXE
Tool's version number
12.7.22
Category
Debuggers
Tool's authors
Paul Baecher, Markus Koetter, David Zimmer
Tool's description
scdbg is an emulation based shellcode API logger and debugger
Download URL
https://github.com/dzzie/VS_LIBEMU/releases/download/12.7.22/VS_LIBEMU_12_7_22.zip
Download SHA256 Hash
521130E34CC0A30587FF99D030633B9D124CCAC779A213E15025535171B4113D
Why is this tool a good addition?
scdbg is an easy to use emulation based shellcode API logger and debugger. It supports a large number of windows API and can support working with file format exploits as well as network interactions (if enabled with command line options)
More can be found on the tool homepage: http://sandsprite.com/blogs/index.php?uid=7&pid=152
ps I would suggest another tool category for shellcode

plus one for this one to bring the new installer up to spec with PMAT 😄

is this a request to switch the distribution from zip to installer exe? whats PMAT?

@dzzie PMAT is a malware analysis course that I instruct that teaches how to analyze shellcode with scdbg.


Output Window Commands - Paths Containing Spaces Aren't Quoted

Hello Power Query SDK Team,
Congratulations on the first public preview release of the new SDK! Yay and thank you!!
Playing around with it today, one thing I noticed is that, in the Output window, when a command-line statement is rendered, paths that contain spaces are not surrounded with double quotes. If I try to copy one of these statements out of Output and run it from a command prompt, the attempt will fail because of the missing quotes.
Output Example:

c:\Users\ben\.vscode\extensions\powerquery.vscode-powerquery-sdk-0.1.3\.nuget\Microsoft.PowerQuery.SdkTools.2.109.6\tools\pqtest.exe run-test --extension c:\Users\ben\Desktop\TestConnector\BenTest\bin\AnyCPU\Debug\BenTest.mez --queryFile c:\Users\ben\Desktop\TestConnector\BenTest\Ben Test.query.pq --prettyPrint

In the above, I believe that:
--queryFile c:\Users\ben\Desktop\TestConnector\BenTest\Ben Test.query.pq
should instead be represented as:
--queryFile "c:\Users\ben\Desktop\TestConnector\BenTest\Ben Test.query.pq"

Thank you!


I have learned how to execute code from vs code to the console.

must figure out how to resolve conflicts

still trying to figure out how to get up to date on commits

hopefully I figured out the conflict


Add unit tests generated by Diffblue Deeptest

The test cases contained in this PR were automatically generated by Diffblue's Deeptest software.
Diffblue is an Oxford-based start-up that aims to automate traditional coding tasks to increase developer productivity. One of our missions is to provide useful tests to open source projects. In return, we would appreciate your feedback about our tests to help us further improve our tool.
Results for various open source projects can be viewed at:
http://diff.blue/demo
We welcome any feedback you have on these tests.
We have sent signed individual & coprporate CLAs via email.

Thanks for your request. We don't accept such automated stuff just to increase test coverage. This does not make sense as test code is code too and needs to be maintained.
If you instead find bugs with your software this would be valuable.


[Won't Fix] PAI Integration: Show PAI job link in NNI trial section

Dependency is not supported, closing it for now.


Store variables as Kubernetes Secrets

This PR introduces an alternate backend to store variable in kubernetes secrets.
It addresses these two feature requests
https://github.com/langflow-ai/langflow/issues/2151
https://github.com/langflow-ai/langflow/issues/2150
@ogabrielluiz
This implementation stores both Credential and Generic variables in Kubernetes secrets when setting_service.variable_store = "kubernetes"
Or the second option is to only store the variable type is Credential to Kubernetes secrets while the rest Generic still are stored in db. For that we can introduce a flag setting_service.credential_store
Let me know which one is more appropriate.

This PR introduces an alternate backend to store variable in kubernetes secrets. It addresses these two feature requests #2151 #2150
@ogabrielluiz This implementation stores both Credential and Generic variables in Kubernetes secrets when setting_service.variable_store = "kubernetes"
Or the second option is to only store the variable type is Credential to Kubernetes secrets while the rest Generic still are stored in db. For that we can introduce a flag setting_service.credential_store
Let me know which one is more appropriate.

I think have different stores is ideal but I think it would add complexity.
Let's keep it as variable_store for now.
Thanks for this PR, ming. Looks really useful.


Option to randomize shot URLs

At the moment, all shots uploaded are given a number in increasing consecutive order. This would make it trivial to view shots not intended for the recipient by simply changing the number. The direct links are already randomized; perhaps that could be used in place of the consecutive numbering for the viewing page.

Hey @EmberHeartshine, this would definitely be a fairly trivial move to go from auto incrementing IDs to UUIDs, though this would break existing usages of ShotShare (if people have created shots and distributed links to them).
I can see two possible ideas for handling this

Implement some sort of opt-in feature that would change column behavior
Hold off on this till version 2 and issue a warning for updating from 1 -> 2 regarding this

Let me know if you have any additional ideas as to how I could go about this!

I don't know the current logic behind storing what values of shot page correspond to what image, but I imagine there shouldn't be any intersection between UUIDs and numerical shot pages. Would there be any harm to simply changing the way shot page URLs are stored in the database and append? Or are shot pages indexed in such a way that makes that change impossible?

I don't know the current logic behind storing what values of shot page correspond to what image, but I imagine there shouldn't be any intersection between UUIDs and numerical shot pages. Would there be any harm to simply changing the way shot page URLs are stored in the database and continue to append past the existing entries? Or are shot pages indexed in such a way that makes that change impossible?

I have never actually mixed UUIDs & auto incrementing IDs, though they would never intersect. Let me sit on this one for a little bit and dive into any of the UUID helpers that are built into Laravel to make sure mixing these wouldn't break anything.
In MySQL a UUID is not a special datatype (so this column would just shift to a varchar), I would wonder if this would have a negative impact on databases that do possess special data types for UUIDs (I think Postgres has this).

That's fair. My personal greedy side is saying "just implement it ASAP, consequences be damned, I have a personal need for it" but waiting to refractor until v2 is reasonable here I feel.

After thinking about it a little bit more, I will comment that this is a blocking issue for me-- that is, I can't deploy ShotShare in the capacity I need it (without #23 fixed, anyway). If you don't want to do the refactor until 2.0 anyway then I totally get it, but I was a little more flippant with my previous comment than I intended.

After thinking about it a little bit more, I will comment that this is a blocking issue for me-- that is, I can't deploy ShotShare in the capacity I need it (without #23 fixed, anyway). If you don't want to do the refactor until 2.0 anyway then I totally get it, but I was a little more flippant with my previous comment than I intended.
It looks like you have #23 on the roadmap for 1.7.0, however, so this may be a non-issue.

Hey @EmberHeartshine, I have an "opt-in" UUID solution in my working branch, we should see this feature in 1.7.0. You can see that progress here.

This functionality has just been rolled out in 1.7.0; lemme me know if you have any questions!

This is so awesome.
Seriously, you're doing amazing work implementing feature requests from some random schmuck on the internet. You need a tip jar or Patreon or something.


The Analytics pod is too big of a download

The title really says it all - it's one big nasty download and makes installing the project pods stink.
@orta had something in mind already:
https://twitter.com/orta/status/701531215136997376?lang=en

#1191 should fix this


[Logging v2] - Chart version 3.9.000-rc01 fails to install with invalid metadata error

What kind of request is this:
bug
Steps to reproduce:

Install Rancher 2.5-head
Deploy RKE cluster with PSP enabled
Navigate to dashboard and install Logging chart version 3.9.000-rc01

Result:

---------------------------------------------------------------------
--
Wed, Jan 27 2021 11:13:02 am | SUCCESS: helm upgrade --install=true --namespace=cattle-logging-system --timeout=10m0s --values=/home/shell/helm/values-rancher-logging-crd-3.9.000-rc01.yaml --version=3.9.000-rc01 --wait=true rancher-logging-crd /home/shell/helm/rancher-logging-crd-3.9.000-rc01.tgz
Wed, Jan 27 2021 11:13:02 am | ---------------------------------------------------------------------
Wed, Jan 27 2021 11:13:02 am | helm upgrade --install=true --namespace=cattle-logging-system --timeout=10m0s --values=/home/shell/helm/values-rancher-logging-3.9.000-rc01.yaml --version=3.9.000-rc01 --wait=true rancher-logging /home/shell/helm/rancher-logging-3.9.000-rc01.tgz
Wed, Jan 27 2021 11:13:02 am | Release "rancher-logging" does not exist. Installing it now.
Wed, Jan 27 2021 11:13:03 am | creating 16 resource(s)
Wed, Jan 27 2021 11:13:03 am | Error: PodSecurityPolicy.extensions "psp.logging-operator" is invalid: metadata.annotations[seccomp.security.alpha.kubernetes.io/defaultProfileName]: Invalid value: "docker/default,runtime/default": must be a valid seccomp profile

Environment information

Rancher version: v2.5-head (01/27/2021) 2ec02e7
Installation option: HA RKE

Reference: https://github.com/rancher/rancher/issues/30771

Working theory: We are reaching a conflict between #30771's PR and the upstream. When upstream's rbac.psp.enabled is true, it will interfere.

values.yaml
description
default value

rbac.enabled
Create rbac service account and roles
true

rbac.psp.enabled
Must be used with rbac.enabled true. If true, creates & uses RBAC resources required in the cluster with Pod Security Policies enabled.
false

Working theory: We are reaching a conflict between #30771's PR and the upstream. When upstream's rbac.psp.enabled is true, it will interfere.

values.yaml
description
default value

rbac.enabled
Create rbac service account and roles
true

rbac.psp.enabled
Must be used with rbac.enabled true. If true, creates & uses RBAC resources required in the cluster with Pod Security Policies enabled.
false

Rancher version v2.5-head (01/30/2021) 2ae4cf1
Rancher version master-head (01/30/2021) 59ebdc2
Logging chart version 3.9.000-rc02
Fluentd output
Cluster types

RKE EC2 with PSP
RKE EC2 no PSP
EKS
k3s

Validated install is now fixed.

Rancher version v2.5-head (01/30/2021) 2ae4cf1
Rancher version master-head (01/30/2021) 59ebdc2
Logging chart version 3.9.000-rc02
Fluentd output
Cluster types

RKE EC2 with PSP
RKE EC2 no PSP
EKS
k3s

Validated install is now fixed.


Devops workflow ci-iov

Just tested with this branch and works ok. i commented the failing tests.

Merging for testing purposes. Will use another branch for the final set-up.


Suppression groups?

How do I use Sengrid's suppression groups with this?

I would also really like to know if I can use ASM with this transport.


Matching selected value on related records via async

I've been trying to learn x-select and ran across some odd behaviour I'd like to ask about.  Basically records from my api related via async: true are recognized with it's matching record.  When I flip the switch and say async: false, the matching records are recognized.
The record loaded through an async:true relationship is wrapped up in a promise object.  This happens even when records are eager loaded from the api.
So how can I compare related records when they are wrapped up in a promise object?
Here is a contrived example:

models/city.js

export default DS.Model.extend({
    ...
    state: DS.belongsTo('state', {async: true}),
    //false means the matching value is detected in subsequent x-select
});

city.state is different depending on async:true|false
consequently it doesn't match up correctly

            {{#x-select value=city.state}}
                {{#x-option value=null}}Select{{/x-option}}
                {{#each states as |item|}}
                    {{#x-option value=item}}{{item.id}}{{/x-option}}
                {{/each}}
            {{/x-select}}

try this
{{#x-select value=city.state.content}}
https://github.com/thefrontside/emberx-select/issues/20

You are correct sir!


[FR] Stylesheet export?

Thank you so much for Callout Manager! I have an idea to improve the plugin: stylesheet export.
It'd work like this:

Push an Export as Stylesheet button.
The plugin generates CSS code for each callout that meets the following critieria:

The callout does not originate from Obsidian already.
The callout does not originate from a theme.
The callout does not originate from a snippet.

After the processing finishes, a modal pops up with the CSS, which can be copied.

Just an idea that popped into my mind. Thank you again for this amazing plugin and all the work you put into it. God's blessings!

Great idea! It didn't make it in time for the version 1.1.0 release, but the feature is ready for the next release after that.


Use slugify if site has no slug

This "fixes" the following line on Uptime CI checks:
Checking https://DOMAIN
Current status undefined up 2023-06-04T14:49:10.000Z
Result from test 200 0.982486

This can also been seen on the upptime repos action runs:
https://github.com/upptime/upptime/actions/runs/5171412631/jobs/9314941347#step:3:14

Thank you!


UI: Update TextWithIcon

TL;DR
Improved journey card UI components and time formatting for better accessibility and visual consistency.
What changed?

Added singular/plural handling for minute displays (e.g., "1 min ago" vs "2 mins ago")
Enhanced journey card components with semantic merging for better accessibility
Introduced new SmallButton and TextWithIcon reusable components
Standardized padding and spacing in journey card layouts
Improved alert button styling and interaction
Adjusted vertical spacing between journey legs

How to test?

Navigate to the trip planner
Check journey cards in both collapsed and expanded states
Verify time displays correctly handle singular/plural cases
Test alert button interactions
Confirm accessibility features work with screen readers
Verify consistent spacing between journey legs and components

Why make this change?
To improve the user experience by making the journey card more accessible, visually consistent, and grammatically correct. The changes also reduce code duplication through component reuse and make the UI more maintainable.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#324  👈
#323
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ksharma-xyz and the rest of your teammates on  Graphite

Merge activity

Nov 8, 10:00 PM EST: A user merged this pull request with Graphite.


JSON Problems

Dont know how to fix this?

i dont know what to do pls help

I think I might know the issue, you might be using “” instead of "" around everything in the package file. Try and change them and see if it works, it worked for me.