Parameterized tests, parameterized suites (parameters for tests)

As discussed in the pull request #124, I proposed my implementation of parameterized tests but the PR was rejected. This means I have to improve ;)
For me the usage is really simple and convenient, you have some examples in the tests file but everyone has it own point of view so please feel free to make suggestions or give ideas to make it better.
The goal is to make the feature to be accepted :)

The first things I would like to understand are:

What precisely is meant by "parameterized tests"?
What is the use case for this feature?

I think I understand but I had a hard time figuring it out from the tests, so let me see if I have it right. The goal is to have the ability for:

The same test to run on multiple data sets, or
The same suite to run against multiple data sets

Is this correct?
Once I understand this, it will be easier to reason about.

You are right, for me it is too clear but I did not explained it well.
The goal is to be able to execute the same test with different values, from one or several user defined data sets. I call these data sets parameter for test. There is no relation with suites, they are usable only inside tests which use a parameter.
The execution behavior is only changed for the tests that use one (or several) parameter, they will be executed one time with each of its value. If several are used, the test will be executed for each combinaison.
Here is a use case :
// File: MyParameters.h
// Note: I recommand prefix your parameter name with "pz"
class ClientAbstract
{
	//...
	int interestingMethod(int value) { return value * 3; }
	virtual bool alwaysTrue() { return true; }
	//...
}

SET_TEST_PARAMETER(ClientAbstract*, pzClient, {
    values.push_back(new RPCClient());
    values.push_back(new JsonRestHttpClient());
});

SET_TEST_PARAMETER(int, pzCriticalValues, {
    values.push_back(INT_MIN / 3);
    values.push_back(-1000);
    values.push_back(0);
    values.push_back(1000);
    values.push_back(INT_MAX / 3);
});

// File: MyTests.cpp
TEST(InterestingMethod_WithCriticalValues_OnEachClient_GivesExpectedResult)
{
	ClientAbstract* client = pzClient();
	int value = pzCriticalValues();
	int result = client->call("interestingMethod", value);
	CHECK_EQUAL(result * 3, result);
}

TEST(AlwaysTrue_OnEachClient_IsTrue)
{
	ClientAbstract* client = pzClient();
	bool result = client->call("alwaysTrue");
	CHECK(result);
}

Short version
I think the concept of parameterized TESTs (or perhaps, parameterized blocks of CHECKs -- a seemingly minor but significant difference) is a sound one, as long as it can be done in a way that:

Addresses real problems with existing methods of testing against sets of data (see below)
Is more consistent with the "look & feel" of the rest of UnitTest++
Relies mostly on extension, and less on modification, of the core behavior (in other words, people shouldn't pay for this feature if they don't use it)

If you have any interest in the future of this feature please chime in on this discussion!
Perfect world scenario -- this is implemented with no changes to existing UnitTest++ code -- then we can decide whether to incorporate it into the core or make it externally available.
Long version
Okay. I think the idea here is a useful one, so let's get more concrete.
The way I've typically seen testing w/ multiple inputs done today looks something like this; I'm choosing to use fixtures with the data but it can of course just be set as a file-level global if you like (I don't):
   class TestData
   {
   public:
      TestData()
      : evens({2,4,6})
      , odds({1,3,5})
      {}

      std::vector<int> odds;
      std::vector<int> evens;
   };

   bool is_odd(int x) { return ((x & 1) == 1); }
   bool is_positive(int x) { return (x > 0); }

   TEST_FIXTURE(TestData, OddDetection)
   {
      for (size_t idx = 0; idx < odds.size(); ++idx)
      {
         CHECK(is_odd(odds[idx]));
      }
   }
   // ...
   // Imagine more tests re evens, etc.
   // ...
   TEST_FIXTURE(TestData, PositiveDetection)
   {
      std::vector<int> odds_and_evens = odds;
      odds_and_evens.insert(odds_and_evens.end(), evens.begin(), evens.end());
      for (size_t idx = 0; idx < odds_and_evens.size(); ++idx)
      {
         CHECK(is_positive(odds_and_evens[idx]));
      }
   }

The good part about this is that it's simple C++; it's clear what the tests are doing, once they understand TEST_FIXTURE, to even a novice developer. The down-sides as I see them, at a glance, are:

Repeating the TEST_FIXTURE(TestData, part over and over is a bit obnoxious
Error messages aren't very good in this case.

To illustrate item 2, let's say I add the negative forms -1, -3, and -5 to the odds vector without thinking about the positive test case. Now I get output like this (MSVC):
  C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\tests\TestCheckMacros.cpp(548): error : Failure in PositiveDetection: is_
positive(odds_and_evens[idx]) [C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\builds\vs2015\TestUnitTest++.vcxproj]
  C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\tests\TestCheckMacros.cpp(548): error : Failure in PositiveDetection: is_
positive(odds_and_evens[idx]) [C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\builds\vs2015\TestUnitTest++.vcxproj]
  C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\tests\TestCheckMacros.cpp(548): error : Failure in PositiveDetection: is_
positive(odds_and_evens[idx]) [C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\builds\vs2015\TestUnitTest++.vcxproj]

Every failure looks the same. Of course in most cases I'll know what I just changed to make something like this happen, but it won't always be so obvious. Note that an implementation of [custom messages] (https://github.com/unittest-cpp/unittest-cpp/pull/75#issuecomment-142170444) would make this less problematic, because the value under test could be streamed into the output.
So, we have a concrete reason for improvement, and a potential alternative (custom messages) to your approach. But let's look more closely at your approach.
The SET_TEST_PARAMETER macro you have defined doesn't "look like" other UnitTest++ macros. What does that mean?
All of the other UnitTest++ macros that take a block of code look like:
    MACRO(parameter)
    {
       // block of code
    }

The block of code isn't passed as a parameter, it comes after the macro.
The SET_TEST_PARAMETER macro also modifies global state in a way that UT++ macros generally don't (at least without cleaning up after themselves, using RAII or the like).
Working at previous jobs, I would often "add features" to UnitTest++ by creating new macros and working from the outside in. (For example, I made a macro that let me use fixtures that required parameters in their constructor.)  I don't know if that's possible here, but that would be my approach if I were to tackle this.
Personally, I would like to see this feature take a form that looks a little bit more like a loop, since that's in essence what it is. Maybe something like this:
   std::vector<int> odds({1,3,5});
   std::vector<int> evens({2,4,6});

   USING(value, odds) // for each value in odds
   {
      TEST(OddDetection)
      {
         CHECK(is_odd(value));
      }
      // Imagine more tests onthis data set...
   }

   std::vector<int> odds_and_evens = odds;
   USING(param, odds_and_evens)
   {
      TEST(PositiveDetection)
      {
         CHECK(is_positive(param));
      }
      // Imagine more tests on this data set...
   }

I could also see the USING (or whatever we want to call it) directive being inside the test, around a CHECK or block of CHECKs, a la REQUIRE. That might be easier to implement, but would require more repetition.
I would definitely like to hear more from the community before anybody goes down any of these roads, though.

Hi John,
Thank you for your review and the time taken.
Short version
I totally understand what you are pointing to, I would ask the same questions. But everything has a reason, I forced myself to respect 2 constraints :

Small and easy code usage (developer does not want to be annoyed with implementation details)
Flexibility (not a single way to use, compatible with C++ < 11)

John: People shouldn't pay for this feature if they don't use it
I think the parameterized tests was (and is still) missing in UnitTest++ and it is an important lack.
Long version
Point 1
The parameters do not have to be global in a dedicated file, they also can be defined locally, I wrote the example that way for show it is possible. The compatibility of a local/global implementation was not that trivial, in a previous version I declared instances like struct Foo { } fooInstance; but depending if you declare it in *.h or *.cpp you might have several real instances instead of a single one. This is why I had to create a static instance but anyway the constructor has no effect.
Point 2
std::vector<int> odds({1,3,5});
TEST(OddDetection) { ... }
...

Yes, I really would like to do this way but this kind of inline vector declaration is not possible before C++11. As you can see in these examples I tried to find a flexible declaration, with just a single macro. This is the reason why the macro SET_TEST_PARAMETER does not look like standard ones.
If you are using C++ < 11 :
SET_TEST_PARAMETER(int, odds,
{
	values.push_back(1);
	values.push_back(3);
	values.push_back(5);
});

If you are using C++ >= 11
SET_TEST_PARAMETER(int, odds, values = {1,3,5});

std::vector<int> evensValues({2,4,6});
SET_TEST_PARAMETER(int, evens, values = evensValues);

What do you think about writing 2 versions ?
SET_TEST_PARAMETER(int, odds, {1,3,5}); // For C++ 11 users

INIT_TEST_PARAMETER(int, odds) // For non C++11 users
{
	values.push_back(1);
	values.push_back(3);
	values.push_back(5);
}

Point 3
USING(value, odds)
{
	TEST(OddDetection) { ... }
}

In Java it is common to see the parameters of test in the test header but in our case I think it not ideal :

You still have to declare the vectors somewhere with painful global initializations, so it requires more code
How do you proceed if you need multiple parameters ?
How do you manage the tests organization in the file if you have several tests which must use several parameters but in a different manner ? (see example below)

USING(value, odds)
{
	USING(value2, foo)
	{
		TEST(OddDetection) { ... }
	}
}

USING(value3, bar)
{
	USING(value4, foo)
	{
		USING(value, odds)
		{
			TEST(BiduleDetection) { ... }
		}
	}
}

Personally I think that the only interest is that the intention of parameters usage is explicit.
The way I propose is so simple to use, if you need a new or existing parameter in a test somewhere you just have to call it by its name. Here is the same tests declaration, much simpler :
TEST(OddDetection)
{
	int a = odds();
	int b = foo();
}

TEST(BiduleDetection)
{
	int a = bar();
	int b = foo();
	int c = odds();
}

One of the other advantages is that you also can call a parameter from a function so you can cover several case even if you don't know its real implementation when you call it :
Message* generateFakeMessage()
{
	Message* m = new Message();
	m->set_action( pzMessageAction() ); // <- here is a parameter
	return m;
}

TEST(SerializationDeserialization_GiveSameData)
{
	Message* original = generateFakeMessage()
	char[] messageSerialized = original->serialize();
	Message* result = Message::deserialize(messageSerialized);
	CHECK_EQUAL(pzMessageAction(), result->action());
	CHECK_EQUAL(pzMessagesColors(), result->color());
}

TEST(AnyUsageTest)
{
	Message* m = generateFakeMessage();
	// Other usage of "m"
}

[ Trivia note: My name is Patrick; see https://github.com/pjohnmeyer ]

Let me get a few smaller points out of the way before getting to the meat of my reply in the next comment.

People shouldn't pay for this feature if they don't use it

I think I may have been unclear in my statement. What I meant by "paying" for a feature is in runtime and memory cost. By implementing the feature based on extension over modification, users that don't utilize this new feature won't be adversely effected.

... this kind of inline vector declaration is not possible before C++11 ...

I am aware I used C++11 in my example, that was for brevity. I don't want the conversation to be bogged down by language semantics at this stage, those are implementation details that can be worried about if / when we come to conceptual agreement.

Hi Patrick,
Sorry about your name, I deduced it from your pseudo.
My English level is medium so maybe I understand too literally what you meant.
Ok I understand better what you mean about performances. Maybe we can minimize performance impact with the following idea, what do you think about it ? :)
// 1. Declare parameter(s)
SET_TEST_PARAMETER(int, odd, {2,4,6});
SET_TEST_PARAMETER(int, even, {1,3,5});

//2. Enable the parameterized feature with macro (no params)
PARAMETERIZED
{
    TEST(Foo)
    {
        int a = odd();
    }
    TEST(Bar)
    {
        int b = even();
    }
}

TEST(Baz)
{
    int b = even(); // Compilation error
}

Research material from other C++ test libs for our reference:

Google Test - Value Parameterized Tests
Boost Test - Data-driven test cases
Catch doesn't appear to have anything

A few more quick answers. I'm still pondering a bit on the bigger picture, and hoping some additional community members will weigh in.

What do you think about writing 2 versions ?

I would find that confusing.
Regarding the USING construct above

You still have to declare the vectors somewhere with painful global initializations, so it requires more code

This is a detail we can attempt to address in the design, certainly, and something your design does address to a degree.

How do you proceed if you need multiple parameters ?

An array etc of objects to extract the parameters from.

How do you manage the tests organization in the file if you have several tests which must use several parameters but in a different manner ?

Good question. This is probably one reason Google Test and Boost Test support generator functions, although I can't say that for certain.

How do you proceed if you need multiple parameters ?

An array etc of objects to extract the parameters from.

I am not sure to understand your idea. You would put all your different parameters in an array of wrappers, like the example below ?
struct ParamsWrapper
{
    int odd;
    int even;
    IClient* client;
};

If yes, it is not multi-parameters, it is still single-parameter. To do real multi-parameters with this approach (for testing each client with each odd and each even values) you will have to explicit all combinaisons ([3 odds] * [3 even] * [2 clients] = 18 wrappers instances to write). And again, how to proceed if a test requires different combinaisons of parameters, you will have to create a new wrapper class and explicit again...
I think my proposal of this message is a good compromise (I edited it a little bit).

How do you proceed if you need multiple parameters ?

An array etc of objects to extract the parameters from.

I am not sure to understand your idea. You would put all your different parameters in an array of wrappers, like the example below? ... If yes, it is not multi-parameters, it is still single-parameter.

Not if you flatten the combinations out into a single array of ParamsWrapper. This can be done in advance, or using a stateful generator function if the cost of generation is too great (or the data is in a file, or...).

Having thought about this and the examples above more, my three pain points stand, and I'll add a 3b from @killoctal's notes and a 4th of my own.

Repeating the TEST_FIXTURE(TestData, part over and over is a bit obnoxious
Error messages aren't very good in this case.
The odds and evens vectors are either:
a. constructed for every test, or
b. subject to "painful global initializations"
The developer has to "manually" write loops in each test

In this comment I aim to address all of these issues, having spent more time mulling over them.
Items 1 and 3a are addressed by, in cases such as this one in which the same test data is used over and over, by just not doing it that way. This leaves us with 2 and 3b.
Personally, I just don't find these "painful global initializations" that painful. To take my previous example and address this, I would do something like this:
   namespace
   {
      const std::vector<int>& odds()
      {
         static const std::vector<int> values = {1,3,5};
         return values;
      }

      const std::vector<int>& evens()
      {
         static const std::vector<int> values = {2,4,6};
         return values;
      }
   }

   bool is_odd(int x) { return ((x & 1) == 1); }
   bool is_positive(int x) { return (x > 0); }

   TEST(OddDetection)
   {
      for (size_t idx = 0; idx < odds().size(); ++idx)
      {
         CHECK(is_odd(odds()[idx]));
      }
   }
   // ...
   // Imagine more tests re evens, etc.
   // ...
   TEST(PositiveDetection)
   {
      for (size_t idx = 0; idx < odds().size(); ++idx)
      {
         CHECK(is_positive(odds()[idx]));
      }

      for (size_t idx = 0; idx < evens().size(); ++idx)
      {
         CHECK(is_positive(evens()[idx]));
      }
   }

Now yes, the developer has to write for loops to check all inputs (issue 4 above) -- but at least that's a basic skill, and it's immediately obvious what is happening to the reader.
Lets turn then to issue 2. If we create an implementation of custom messages, we can get rid of this. Imagine for a moment that you can do something like this:
   int val_under_test = odds()[idx];
   CHECK(is_positive(val_under_test)) << " value is " << val_under_test;

and that in our aforementioned failure case, you now saw this:
  C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\tests\TestCheckMacros.cpp(548): error : Failure in PositiveDetection: is_positive(val_under_test); value is -1 [C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\builds\vs2015\TestUnitTest++.vcxproj]
  C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\tests\TestCheckMacros.cpp(548): error : Failure in PositiveDetection: is_positive(odds_and_evens[idx]); value is -3 [C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\builds\vs2015\TestUnitTest++.vcxproj]
  C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\tests\TestCheckMacros.cpp(548): error : Failure in PositiveDetection: is_positive(odds_and_evens[idx]); value is -5 [C:\Users\pjohn\code\pjohnmeyer\unittest-cpp\builds\vs2015\TestUnitTest++.vcxproj]

Now it's incredibly clear what is happening. It's a little gross here that we're duplicating val_under_test, but remember this is an academic example. In a more complex example, the user can output the most meaningful thing to them for that particular CHECK without outputting the entire parameter set. This is arguably a good duplication because it's giving the user full control of the output.
For my money, I think the bang for the buck is in supporting custom messages over parameterized testing. But, I definitely see the value of being able to wrap a set of tests without having to repeat the loops.
The thing that I just can't get past about your proposed implementation is this: it doesn't look like C++. It's a cool implementation -- call these functions and you implicitly get test repetition. But "normal" C++ doesn't behave like this. Looping is explicit. Wrapping the TEST in a PARAMETERIZED block helps, but it still, in my opinion, hides too much.
I'm going to see if I have time to spend on an alternate prototype implementation or two to throw out there, but if somebody else wants to tackle this I'd love to see others' ideas.
P.S. I've decided I don't like the name USING because, while clearly a macro, it's the same word as the C++ keyword using.

It doesn't look like C++. It's a cool implementation (...) But "normal" C++ doesn't behave like this. Looping is explicit. Wrapping the TEST in a PARAMETERIZED block helps, but it still, in my opinion, hides too much.

So why not simply rename this macro FOR_EACH_PARAMETER ? If not, what do you propose ?
SET_TEST_PARAMETER(int, odd, {2,4,6});
SET_TEST_PARAMETER(int, even, {1,3,5});

FOR_EACH_PARAMETER
{
    TEST(Foo)
    {
        int a = odd();
    }
    TEST(Bar)
    {
        int b = even();
    }
}

PS: About USING, I

I think this would feel more like C++ and UnitTest++ if it looked more like one of the following. I think option 1 is easier to implement (and in fact I wrote a very dumb version of it locally to test out the concept, with all of the new logic in the TEST_EACH macro). Option 2 of course would result in less repetition in cases where the same test data is used repeatedly, but would, I believe, be significantly harder to write.
Thanks to @bgbarcus who helped me iron some of this out the other day. He and I discussed that providing the start and end of each collection might even be desirable, but in the end I'm erring on the side of simple interface over flexible interface.
Thoughts?
Option 1: TEST_EACH
   #define TEST_EACH(CollectionExpression, Name) // impl...

   // example
   TEST_EACH(odds(), OddDetection)
   {
      CHECK(is_odd(input));
   }

where:

CollectionExpression is an expression that results in an STL container that supports forward iteration, a C array, or a generator object that behaves like a STL container that supports forward iteration
Name is the name of the test, e.g. OddDetection
input is the dereferenced "iterator"

Optionally the name for input might be another argument to the macro.
Option 2: WITH_EACH
   #define WITH_EACH(CollectionExpression) // impl...

   // example
   WITH_EACH(odds())
   {
      TEST(OddDetection)
      {
         CHECK(is_odd(input));
      }
   }

where:

CollectionExpression is an expression that results in an STL container that supports forward iteration, a C array, or a generator object that behaves like a STL container that supports forward iteration
Name is the name of the test, e.g. OddDetection
input is the dereferenced "iterator"

Again, optionally, the name for input might be another argument to the macro.

Use iterators is a great suggestion.
It still miss the ability of having more than 1 collection iterated in the same time. These macro WITH_EACH and TEST_EACH are still the same than :
// I wrote C++11 for simplicity
for(auto input : odds() )
    CHECK(is_odd(input));

But user should be able to do it but with N collections :
for(auto input1 : foos() )
    for(auto input2 : odds() )
    {
        CHECK(is_odd(input2));
        CHECK(is_special(input1 * input2));
    }

Another thing, I think we should not introduce the new keyword "with" for specify a loop, "for" is more C++ like. So I propose to do use this syntax :
FOR_EACH( odds(), foos() )
{
    TEST(OddDetection)
    {
        CHECK(is_odd(input));
    }
}


Integration with bidi is required

This is an elaboration of the kind of issue I describe in https://github.com/tc39/proposal-intl-segmenter-v2/issues/8:

Browsers’ text engines have a close interrelationship between font fallback, bidi processing, line breaking, and shaping, which cannot be matched using this API proposal.

Here's an example. Consider this string:

He said "אבא שלי ואני קנינו iPhone אתמול" while skiing.

This string has LTR inside RTL inside LTR.
On a single line, it would be rendered like this:

The reading order is this ("1" means "read this first" and "5" means "read this last"):
He said "אבא שלי ואני קנינו iPhone אתמול" while skiing.
[  1  ]  [ 4 ] [ 3  ] [------ 2 ------]  [---- 5 ----]

Now, let's imagine we're laying this string out in some available width. Let's say that the first five words fit on the first line, the next 3 words fit on the next line, and the remaining 2 words fit on the last line.
It should be rendered like this:

Here's the reading order:
He said "אבא שלי ואני
[  1  ]  [--- 2 ----]

אתמול iPhone קנינו"
[ 5 ] [ 4  ] [ 3 ]

while skiing.
[---- 6 ----]

However, if you naively chop up the string into lines and render each line independently, you'd get this incorrect rendering:

(Notice the middle line in particular.)
This is because, if you render each line independently, that middle line loses the context from the first line. From the text engine's perspective, the middle line would look like 3 separate sibling phrases, rather than one big RTL phrase with a single LTR word inside it.
In order to solve this problem, the line layout code needs to have knowledge of the bidi state around each line, which Intl.Segmenter v2 does not include.

Line-breaking bidi text is not easy for sure, but it's implementable as a library, and it adds trivial amounts of extra payload.
Finding the directionality of substrings inside a string could be relevant. Unicode Bidi_Class data needed by the bidi algorithm seems to compress well. Quick check: the plain text file compresses to 24 KB, but removing the unnecessary text can probably compress it even more (guessing something under 10 KB). Adding it won't save much in size, but it may be convenient if as part of segmenting a string for line breaking purposes the segmenter also proactively attached bidi information.

I addressed the bidi issue in slide 31 of my 2022-Jan Stage 2  slides

I agree with you that bidi resolution is needed and the context from the previous line need to be passed to the rendering of the next line to properly layout the line. How the context to be passed in to the rendering context will be hugely depended by the support of the target rendering context.


refactor: list all commands in commands.json

This also changes the order of commands in the docs, due to how I changed
the doc-generating script.
Let me know if you think we should enforce some sort of order on the list of commands. I just mostly kept the order from before.
This should be safe to put in master. I've tested to make sure that the files attribute is properly updated.

I think it would be helpful to alphabetize them , especially because the readme is generated from that list.

Done


Added awesome badge

Added awesome badge at the top with link back to all awesome lists

Duplicate of #436


Performance issue with postgres citext queries

Bug description
There appears to be an issue with query performance of citext columns
Some kind of casting (or lack of casting) is happening that is preventing the use of citext indexes
Here is an example we observed in our app:
User.publicAddress is a citext column. This is doing a simple findMany with filter query. Adding mode: 'insensitive' seems to improve it.
await prisma.user.findMany({
  where: {
    publicAddress: {
      in: lowercaseAddresses,
    },
  },
})

Performance screenshots from our app: https://github.com/prisma/prisma/issues/14935#issuecomment-1790219310
How to reproduce

Add a table with an indexed citext column.
Do a prisma findMany query on it.
Observe the slow performance relative to an indexed query directly on db.
Note that adding mode: 'insensitive' seems to improve the query performance

Expected behavior
findMany queries leverage citext indexes
Casting is done to citext type, or not casted at all
Prisma information

model User {
  id        String   @id @default(dbgenerated("gen_random_uuid()")) @db.Uuid
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  publicAddress   String  @unique @db.Citext

  @@unique([createdAt, id])
}

await prisma.user.findMany({
  where: {
    publicAddress: {
      in: lowercaseAddresses,
    },
  },
})

Environment & setup

OS: macOS
Database: PostgreSQL
Node.js version: v18.17.0

Prisma Version
prisma                  : 4.14.1
@prisma/client          : 4.14.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine d9a4c5988f480fa576d43970d5a23641aa77bc9c (at node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli d9a4c5988f480fa576d43970d5a23641aa77bc9c (at node_modules/.pnpm/@prisma+engines@4.14.1/node_modules/@prisma/engines/migration-engine-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.14.0-67.d9a4c5988f480fa576d43970d5a23641aa77bc9c
Default Engines Hash    : d9a4c5988f480fa576d43970d5a23641aa77bc9c
Studio                  : 0.484.0

Thanks for the report @vigneshka
I see you are using an older version 4.14.1, did you happen to try and reproduce the same behavior with a more recent version? For example, with 5.5.2

I just hit the same issue on prisma 5 (indexed citext column, index wasn't being used).
When adding the insensitive mode from the OP, I also saw significant improvements.
The mode changed the query from
SELECT <...> WHERE "public"."user_addresses"."address" IN ($1,$2,$3,$4,$5,<...>
to
SELECT <...> WHERE LOWER("public"."user_addresses"."address") IN (LOWER($1),LOWER($2),LOWER($3),LOWER($4),LOWER($5),<...>

When printing the query plan of the query that was used, I was getting sequential scan each time, whether insensitive is set or not. The choice of sequential scan could have been due to other factors, but just another data point.


Unable to test, error in state_dict

Hello,
I am trying to test the code on a wav file. But I receive the following message:
RuntimeError: Error(s) in loading state_dict for VoiceFixer:
Missing key(s) in state_dict: "f_helper.istft.ola_window".
Unexpected key(s) in state_dict: "f_helper.istft.reverse.weight", "f_helper.istft.overlap_add.weight".
Which seemed to be caused by the following line in the code:
self._model = self._model.load_from_checkpoint(os.path.join(os.path.expanduser('~'), ".cache/voicefixer/analysis_module/checkpoints/epoch=15_trimed_bn.ckpt"))
Do you have an idea on how to resolve this issue?

It looks like torchlibrosa version you use is not 0.0.7. Please check your version of torchlibrosa.

Thanks. That fixed it.


set up CreateAccount General Information and Weekly Information pages

Set up pages for creating a new account.

/cib 18-set-up-create-account-general-weeklyinfo-pages

Branch 18-18-set-up-create-account-general-weeklyinfo-pages created!


Add .tfignore file to the yo spfx generator

Category

[ ] Question
[ ] Typo
[ ] Bug
[x] Enhancement / Suggestion
[ ] Additional article idea

Suggestion
Add to the Yo generator a .tfignore file. I believe the most of the developers are coming with a TFS instance as a code repo.

Please don't muddy up the generated projects with this stuff. There's already too much stuff in the root that's not necessary to have in every single project such as:

.npmignore
.yo-rc.json
.gitattributes
.editorconfig

If anything, add flags to include these in the generator. PLEASE don't force a .tfignore file on us. The OP's assumption that "most of the developers are coming with a TFS instance as a code repo" is a HUGE (and IMHO flawed) assumption.

@andrewconnell

If anything, add flags to include these in the generator.

This will be much better - thanks for the input. I will update my original suggestion.

We've added this to our backlog. Thanks for the suggestion.


python3Packages.pyftdi: 0.52.0 -> 0.52.9

Motivation for this change
Update to latest upstream release 0.52.9
Change log:
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 109278 run on x86_64-linux 1

12 packages built:

python37Packages.alarmdecoder
python37Packages.pyftdi
python37Packages.pyi2cflash
python37Packages.pyspiflash
python38Packages.alarmdecoder
python38Packages.pyftdi
python38Packages.pyi2cflash
python38Packages.pyspiflash
python39Packages.alarmdecoder
python39Packages.pyftdi
python39Packages.pyi2cflash
python39Packages.pyspiflash

Result of nixpkgs-review pr 109278 run on x86_64-linux 1

12 packages built:

python37Packages.alarmdecoder
python37Packages.pyftdi
python37Packages.pyi2cflash
python37Packages.pyspiflash
python38Packages.alarmdecoder
python38Packages.pyftdi
python38Packages.pyi2cflash
python38Packages.pyspiflash
python39Packages.alarmdecoder
python39Packages.pyftdi
python39Packages.pyi2cflash
python39Packages.pyspiflash

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 109278 run on x86_64-darwin 1

12 packages built:

python37Packages.alarmdecoder
python37Packages.pyftdi
python37Packages.pyi2cflash
python37Packages.pyspiflash
python38Packages.alarmdecoder
python38Packages.pyftdi
python38Packages.pyi2cflash
python38Packages.pyspiflash
python39Packages.alarmdecoder
python39Packages.pyftdi
python39Packages.pyi2cflash
python39Packages.pyspiflash

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 109278 run on x86_64-darwin 1

12 packages built:

python37Packages.alarmdecoder
python37Packages.pyftdi
python37Packages.pyi2cflash
python37Packages.pyspiflash
python38Packages.alarmdecoder
python38Packages.pyftdi
python38Packages.pyi2cflash
python38Packages.pyspiflash
python39Packages.alarmdecoder
python39Packages.pyftdi
python39Packages.pyi2cflash
python39Packages.pyspiflash

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 109278 run on x86_64-linux 1

12 packages built:

python37Packages.alarmdecoder
python37Packages.pyftdi
python37Packages.pyi2cflash
python37Packages.pyspiflash
python38Packages.alarmdecoder
python38Packages.pyftdi
python38Packages.pyi2cflash
python38Packages.pyspiflash
python39Packages.alarmdecoder
python39Packages.pyftdi
python39Packages.pyi2cflash
python39Packages.pyspiflash

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 109278 run on x86_64-linux 1

12 packages built:

python37Packages.alarmdecoder
python37Packages.pyftdi
python37Packages.pyi2cflash
python37Packages.pyspiflash
python38Packages.alarmdecoder
python38Packages.pyftdi
python38Packages.pyi2cflash
python38Packages.pyspiflash
python39Packages.alarmdecoder
python39Packages.pyftdi
python39Packages.pyi2cflash
python39Packages.pyspiflash


wait_pc_connection error job_request.accept

I am testing agents and everything has been working fine until today when I started getting wait_pc_connection error thrown in the async def job_request_cb(job_request: agents.JobRequest):
await job_request.accept(
I am also seeing this in the logs, which I am not sure if is related:
2024-04-12 11:09:44,964 - ERROR - livekit_api::signal_client::signal_stream:171:livekit_api::signal_client::signal_stream - unhandled websocket message Err(Protocol(ResetWithoutClosingHandshake))
2024-04-12 11:09:44,965 - DEBUG - livekit::rtc_engine::rtc_session:455:livekit::rtc_engine::rtc_session - received leave request: LeaveRequest { can_reconnect: false, reason: DuplicateIdentity }
I tried upgrading all the of the livekit python libraries but no luck.
Any ideas?

Hey, it seems like you're using the same identity for multiple participants?
2024-04-12 11:09:44,965 - DEBUG - livekit::rtc_engine::rtc_session:455:livekit::rtc_engine::rtc_session - received leave request: LeaveRequest { can_reconnect: false, reason: DuplicateIdentity }
The server disconnects you because a participant with this identity already exists (DuplicateIdentity)

Agreed, I saw that and thought the same but I am only testing & running the agent from my local pc. I  bounced my laptop to ensure a rogue process wasn't running. And it just started today. I even change the identity string on the job_request.accept and it still happens. I will try some different things but I thought it was worth asking to see if anything might have changed.

I am unable to get my agent to connect and stay connected to my livekit project any longer. This had been working fine for a week+. Participants can connect fine, only the agent is unable to stay connected. I decided to try a 2nd LiveKit project and now the agent connects without issue. This means that the LiveKit hosted project is corrupted in some fashion. I am just testing and doing poc for my company. I have the agent only running on my local laptop and it has been connecting & disconnecting many times during testing and poc work. I am only mentioning this in hopes that it helps you debug the issue.

Hey, is the agent the only participant connected to the room? If so, the server will automatically closes the room. Maybe this is what you're seeing?

No. The scenario is this. A non agent participant joins a room. Then job_request_cb is called in my local agent.  The agent connects for a few seconds and then disconnects. The non agent participant is still in the room. This doesn't happen on the new hosted project.

Can you send me the project id? I'll investigate in the logs

p_2uj2u38l5g9

Hey, we found the cause of this issue, we're working on a fix and this should be deployed in the next few days.

Hey, the patch is now deployed on all region, feel free to reopen the issue if you're still experiencing this issue


Work Analytics Workspace workbooks?

looking over the workbooks in the log analytics workspace, two work, but a third doesn't appear to ..
Is this something I need to set and haven't seen in the documentation because I am silly?
This query could not run because some parameters are not set.
Please set: SelectedPerspective, SelectedPerspectiveId

Actually, the documentation needs to be improved. You're not the first one reporting this (duplicate of #44). Please let me know if the answer in the duplicate issue helps. Thanks!

Thanks for the update.  This then is about time and waiting for the data to build, and such I imagine.  I have less than 30 days of data built up from the scheduling, I will just have to wait at this point, but I know the time frame issue at this point.


Return an error from GetSinkURI if DomainInternal is empty

A Sinkable with an empty DomainInternal value should not be considered to have a valid sink URI. Before this change, an empty sink URI from an unready Sinkable would be passed to the ContainerSource deployment, (which can't interpret an empty sink URI).
/cc @vaikas-google @n3wscott

/lgtm
/approve


[8.1.0] Using setDataAtRowProp on prop not on table issue

Description
Hello,
Been using handsontable for almost a year now and I have a usecase where my data is an array of objects and I don't want to display some feilds on the table but I want to edit them.
Note: I don't want to use hidden columns as I need to show some hidden columns when exporting to csv and don't want those to appear.
I was able to do that prior to V8.0.0 & V8.1.0
I was also able to that in V8.0.0-beta.1
Demo
Simplified version of my usecase:
Working version 7.4.2 demo https://jsfiddle.net/0z5kvbxd/
Working version 8.0.0-beta.1 https://jsfiddle.net/0z5kvbxd/1/
Broken version 8.1.0 demo https://jsfiddle.net/eafbtj1r/
Your environment

React wrapper version: 4.0.0
Handsontable version: 8.1.0
Browser Name and version: Chrome
Operating System: Windows 10

Update:
Fails at
function validateChanges (line 392840)
----> var cellProperties = instance.getCellMeta(row, col);
Error: Assertion failed: Expecting an unsigned number.
in 8.0.0-beta.1 var cellProperties = priv.cellSettings[physicalRow][physicalColumn];

@RanaOsamaAwadallah To modify source data that is not displayed you should use setSourceDataAtCell.

@wojciechczerniak Tried using it but I need to use the source as well.
So I tried setSourceDataAtCell(arrOfChanges, source)
What I get in setSourceDataAtCell is an undefined source

Thats because source is the 4th argument: setSourceDataAtCell(arrOfChanges, undefined, undefined, source)

I see, I was able to do that with setDataAtRowProp so assumed it'd be the same.
Thanks for the help, all seems good now.

No problem, thanks for reporting the inconsistency
@AMBudnik Can you investigate this? The feature is in the code, but not documented. Although, it's defined in d.ts
https://github.com/handsontable/handsontable/blob/b7618fc4213d3b2ab32ba62ff6f1d57cd1af6c49/handsontable.d.ts#L121-L126
Maybe a feature request for API consistency? And should we fix the docs? CC @scarletfog


theme/liquidprompt: lint and use $THEME_CLOCK_FORMAT

Description
Use $THEME_CLOCK_FORMAT instead of hard-coding it, and lint the whole file, and move the checked-out repository under the vendor tree.
Motivation and Context
Just cleaning up.
How Has This Been Tested?
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the code style of this project.
[x] If my change requires a change to the documentation, I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
[ ] I have added tests to cover my changes, and all the new and existing tests pass.

Cloning the theme seems pretty wild, never actually stumbled upon this code.. wow
Maybe we should just vendor it normally? does it weight much?

It's definitely pretty wild. Previously, it checked out the repo directly into the theme folder!
The question to vendor it or not, imo, is whether we want to be on the train of updating it. I have no idea if it's an active project or not. Do we want to be distributing other projects? What about things like gitstatus or nvm.sh?
It makes way more sense to me, for example, to vendor the jBoss completions because what we're bundling is specifically one or two files, which don't change often, from a large external project. Or, like preexec, where we directly depend on it so we need it inside our repo.

I think we can clone it at user request so long as we don't bundle it, but I'm alsö ok with just telling the user how to install it and make it not our responsibility.

I prefer to just instruct the user to do it, no need to do it ourselves


Customize ranking of GeoTiffs #1

Customize ranking of GeoTiffs #1

by a custom function
by customizing the roles

Is this enough or did you think about something else, @tschaub?
Also fixes a bug for assets where multiple relevant roles where included.

I need this myself, so merging.

Looks good, @m-mohr.  Will probably have more constructive feedback after trying it out.


feat: add shaped area light helper

I manage to add the new visibleSurface value, but I couldn't find a way to render the texture as helper. So I believe I need some help here. I should have to modify the src/shader/sampling/light_sampling_functions.glsl.js in order to access to the src/materials/pathtracing/PhysicalPathTracingMaterial.js
(now is just adding it to the alpha channel hideous just to prove that it reach the value, of course also tried to move in other locations like using the state.firstRay, but didn't find the right one to render a texture as helper)

btw, I'll be off a couple of days, so if this is not priority, with your help we can solve it :)

I'll contribute this pkg differently.
I'm working on a version for Tres library, soon available.
Thanks for the guide


support for shadows and halos

Having a shadow on dragged items seems (lately) to be a common request.  It's used in Area Builder, Expression Exchange, and now Equality Explorer to make a dragging Node visually "pop"; that is, to make it look like it's "in front" of other things, and to distinguish it from the things behind it.
A variation of the shadow is the "halo" found in Expression Exchange and (now) Equality Explorer, where a halo (yellow in those sims) appears around 2 overlapping terms that sum to zero.
In Equality Explorer, I've had to use a variety of techniques for the shadow, including custom artwork.  And trying to reproduce the Expression Exchange halo for non-circular objects has been time consuming.
If this is indeed a feature that will be present in many sims, then PhET should consider adding common-code support.

Relevant Slack developer channel discussion:

@jonathanolson If the “shadow” thing becomes more common, it is a potential Scenery-level feature (as SVG has specific support for shadowing, and it can be done in Canvas too, somewhat more manually).

@pixelzoom We can confirm with designers, but my impression is that it’s already a common feature, applied to a dragged items to distinguish it from things behind it, and to make it look like it’s “forward” of other things.

@jonathanolson Yes, for SVG, see the "Drop shadow example" near the bottom of https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feGaussianBlur

@pixelzoom List of sims that currently use shadows? ExEx, EqEx, Area Builder, … others?

@jonathanolson fractions-intro kind of has shadows on things

@jonathanolson May want to do a more-general concept of filter in Scenery (as we've now had more cases of wanting to "grayscale" things)

@jbphet If this is done in a general way and includes the implementation of a 2D gradient, that could be used to simplify things like the button shading code.

Function Builder and Units Rates could also have benefited from having a shadow on dragged objects.
Assigning to @amanda-phet @arouinfar @ariel-phet to confirm that this is a feature this we'll be incorporating into more sims.

Also related: https://github.com/phetsims/scenery/issues/158 (color filters).
This has been a half-planned anticipated feature, but it just hadn't come up much before.

Confirmed, definitely likely to continue to come up.

I definitely think shadows will continue to come up. Halos, maybe, but I can't think of more instances where we will want to indicate "combining" the way we did in ExEx and EqEx, but it's not out of the question.

I agree with @ariel-phet and @amanda-phet -- shadows are going to come up in future sims.

Current proposal for the primitives necessary for shadows/halos and other higher-priority effects
I'll edit this to be up-to-date with changes.
Low-level features
Two filters would be added currently (others could be added in the future):

Gaussian blur (specifies a standard deviation in the local coordinate frame). Uses feGaussianBlur for SVG. For Canvas/WebGL, if there is no asymmetric scale or shear applied (on an ancestor), the separable convolution can be applied (or if large enough, the 3-box-blur approximation). Otherwise, a full kernel (given the transform) would be required. See https://www.w3.org/TR/filter-effects/#feGaussianBlurElement
Color matrix multiplication (specifies a 5x5 affine matrix, multiplies a RGBA1 vector). Uses feColorMatrix for SVG and per-pixel Canvas implementation. See https://www.w3.org/TR/filter-effects/#feColorMatrixElement

Control over compositing would be added. Determines the resulting alpha and color proportion. Would use SVG's supported subset of Porter-Duff operators (source-over, source-in, source-atop, source-out, xor, possibly named as in SVG as over, in, atop, out, xor). Would use feComposite for SVG (and globalCompositeOperation for Canvas). See https://www.w3.org/TR/filter-effects/#feCompositeElement and https://www.w3.org/TR/compositing-1/#advancedcompositing
Control over blending would be added. Determines the color from two sources. Would use SVG's supported options (e.g. normal, multiply, screen and a number of others). Would use feBlend for SVG (and a combination of globalCompositeOperation and per-pixel operations for Canvas). See https://www.w3.org/TR/filter-effects/#feBlendElement and https://www.w3.org/TR/compositing-1/#blending
Compositing/blending would be implemented similarly to SVG (particularly since it helps reduce effort to render in SVG, and it's a good model), see https://svgwg.org/svg2-draft/render.html#Grouping. Notably, we'd need to borrow the concept of isolated groups. A group would be "isolated" if forced (the proposed forceIsolation option, mirroring the isolation property, https://www.w3.org/TR/compositing/#isolation), if it has opacity/clipping/filters/blending/compositing (would trigger an SVG isolated group, see https://www.w3.org/TR/compositing/#csscompositingrules_SVG) or a performance flag indicating this might happen (e.g. usesOpacity/cssTransform). This would operate similarly to stacking contexts in HTML (https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context), as stacking contexts would also force isolated groups on the SVG rendering side. https://mdn.mozillademos.org/en-US/docs/Web/CSS/mix-blend-mode$samples/mix-blend-mode?revision=1322989 and https://www.w3.org/TR/compositing/#isolationblending show the effects of an SVG group (effectively a Node in this case) being isolated.
Plan to defer:

Dilation/erosion (specifies a radius in the local coordinate frame). Uses feMorphology for SVG.
General convolution. Very resolution-dependent (unless the client provides a function that can generate a kernel given an arbitrary affine transform, which is more trouble than it's worth right now). SVG doesn't have a great solution for resolution-independence that doesn't force pixelation sometimes.

Low-level feature API
My preferred proposal would be to provide the mutator keys (options) for Node:
{
  blend: 'normal', // {string} - blending mode as noted above
  composite: 'over', // {string} - compositing mode as noted above
  forceIsolation: false, // {boolean} - forces an isolated node, see notes above
  gaussianBlur: 0, // {number} - standard deviation, 0 means no blur applied
  colorMatrix: null // {Array.<number>|null} - The top 4 rows in row-major order (same as SVG spec order), if provided
}

but this would need to assume an order of filter application (in this case, since only blurring and color matrix would be supported, we would presumably apply the color matrix first). This may be an inconvenience if we wanted to apply the filters in a different order (particularly if we add more filters in the future).
Instead of gaussianBlur and colorMatrix, it would be possible to instead specify an array of filters, e.g.:
{
  filters: [ new GaussianBlur( standardDeviation ) ]
}

The gaussianBlur parameter would presumably affect bounds computation. While a true "gaussian" would push the bounds to infinity, we would presumably increase the bounds of the affected node based on the 3-box-blur SVG approximation (using d = floor(stdDev * 3 * sqrt(2 * π) / 4 + 0.5) for # of view units affected in one of the blurs, so presumably dilating bounds by d * 3 / 2).
In addition, an isIsolated()/isolated getter would be available.
High-level feature API
In scenery or scenery-phet, we would add a DropShadow Node subtype that would apply the filters and offsets (given whatever parameters we decide on) to create a drop shadow (and either include the node itself). For example:
/**
 * @param {Node} content
 * @param {Object} [options]
 */
{
  // lower-level options
  offset, // {Vector2}
  standardDeviation, // {number}
  color, // {paint}

  // higher-level options
  lightOrientation, // {Vector2} - common across sims
  displacement, // {number} - Larger values increase both offset (in the orientation) and blur
}

Additionally, helper functions for things like colorMatrix would be available. Notably, SVG provides the following:

brightness {number}: 0 - colors turn to black, 1 - unchanged
contrast {number}: 0 - gray, 1 - unchanged, >1 increased contrast
grayscale {number}: 0 - unchanged, 1 - fully grayscale
hueRotate {number}: presumably use radians for consistency, rotates the hues
invert {?}: ability to invert colors
saturate {number}: 0 - completely unsaturated, 1 - unchanged --- opposite of grayscale, would only include one
sepia {number}: 0 - unchanged, 1 - fully sepia

of which we'd be able to include any that we like. I've long wished for grayscale/saturate (great for disabled looks, we've had to work around that) and brightness (had to make things darker manually before).

Marking for feedback during developer meeting. @pixelzoom, @jbphet and @samreid, any feedback before then would be appreciated.
Changes since brief discussion about thoughts:

Scrapped erode/dilate/convolution
Reworked how compositing and blending would work, based on SVG specs and constraints based on practical implementation.

Self-assigning so I remember to review.

I reviewed the proposal in https://github.com/phetsims/scenery/issues/707#issuecomment-342715882. Lots of info there, and I'm not confident that I've totally wrapped my head around it.
@jonathanolson Could you provide (pseudo)code examples of:
(1) How to create a shadow for a Path, like this (with and without feathered edge):

(2) How to create a shadow for an Image, like this (with and without a feathered edge):

(3) How to create a holo, like this:

Using the low-level API, you'd need a (what would probably have helper functions) colorMatrix that replaces the color (and if it has alpha, multiplying), e.g.:
function replaceColor( color ) {
  return [ 0, 0, 0, 0, color.red,
           0, 0, 0, 0, color.green,
           0, 0, 0, 0, color.blue,
           0, 0, 0, color.alpha, 0 ]
}

Then for all of your cases, you would have:
var shadow = new Node( {
  children: [ content ],
  colorMatrix: replaceColor( shadowColor ),
  gaussianBlur: blurAmount,
  translation: offsetVector
} );

where blurAmount controls the blurring (if any, 0 for none), shadowColor is the color of the shadow (in your semi-transparent case above, something like 'rgba(0,0,0,0.5)', and for the halo, just 'yellow'), and offsetVector handles the displacement off-center (zero for the halo case).
You can place the shadow behind (and have a movable node) with:
var contentWithShadow = new Node( { children: [ shadow, content ] } );

Presumably we'd have a higher-level API (as of yet undecided) to help with this, so it wouldn't be duplicated every time.

If it helps, replaceColor basically is function( currentColor, replacementColor ) { return replacementColor.withAlpha( currentColor.alpha * replacementColor.alpha ); }

So blending and compositing are not needed to create shadows?  Can you provide some use-cases where blending and compositing would come in handy?  Same question for forceIsolation.

In fractions intro, the pieces that are dragged cast a shadow. In addition, the pieces can be rotated and the shadow is adjusted such that it is casted from the same perspective (say upper right corner).  (See fractions intro with pieces of a circle for an example.) The support for shadows should handle the translation AND rotation of an object.

@veillette said:

The support for shadows should handle the translation AND rotation of an object.

In 11/9/17 dev meeting, @jonathanolson said that his proposal should address this.

11/8/17 dev meeting notes:
• @jonathanolson estimate is a couple days for investigation, ~1 week for scenery
• @ariel-phet don't start until after chipper:2.0
• @pixelzoom will bring this up in January 2017
• will not be ready for use in equality-explorer, so need to decide what to do in phetsims/equality-explorer#17

Assigned to me to bring this issue up in January 2018.

Useful links from notes (so I can see this in the future sometime):
https://svgwg.org/svg2-draft/render.html#Grouping
https://www.w3.org/TR/filter-effects
https://www.w3.org/TR/compositing-1/ (or https://www.w3.org/TR/compositing/)
https://caniuse.com/#feat=css-mixblendmode
https://mdn.mozillademos.org/en-US/docs/Web/CSS/mix-blend-mode$samples/mix-blend-mode?revision=1322989

10/27/20 Zoom call:
@jonathanolson @ariel-phet and I discussed this as a possible way to add a grayscale option for sun buttons, which was lost in the refactor in https://github.com/phetsims/sun/issues/644.
@ariel-phet mentioned that this may have a11y benefits, for high-contrast features.
@jonathanolson said that just the grayscale option might be possible if this turns out to be a lot of work.  This is needed for publishing sims that are coming up.
@ariel-phet asked @jonathanolson to make this top priority so we can wrap up sun buttons.  Spend 2 days to investigate and see how far he gets.

Current status:

CSS-style filters that only affect color should generally be at an acceptable level, and I'll be maintaining those for production
CSS-style filters that include blur (DropShadow/GaussianBlur) I've marked as experimental, and will need additional work. The SVG filter regions (which would potentially need to be adjusted on the fly) and the transform complications will need to be figured out before use.
Blending across blocks doesn't look possible, so there is no easy way to guarantee "proper" visuals in a high-performance way, so I've opted for now to not implement it.
Compositing is not supported by the DOM, so there is no fallback, and it wouldn't work in many situations.

If we ever go WebGL-only, I'll have all the flexibility and ease in the world to support all of this (so blending/compositing would presumably need to wait until that).
Reducing priority for the remaining blur/shadow work.


Add support for hash-based CSP with strict-dynamic.

It's not trivial to combine a strict CSP (a CSP based on nonces/hashes and 'strict-dynamic') with a Polymer application. Since Polymer apps are usually static (no backend) they're by nature incompatible to CSP nonces.
To make Polymer apps compatible with strict CSP, I added an option to Crisper that loads the externalized script through a loader (inline-)script instead of sourcing the script via src. Inline-scripts can be hashed (and therefore allowed in CSP).

Thank you for taking a look Daniel! I'll let @usergenic do the merge and publishing.

Is there anything else I can do to get this pr merged in?


Add docs

Reference #38

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.IgnisDa seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

The .gitignore I added earlier is the default one provided by github when starting python projects. I removed as many of them as I could (and should).
Removed autopep8 and flake8 from requirements-dev.txt but the last one remains since its a dependency of selenium.
I tried to do this, following this but it doesn't work. Maybe open a new issue for it?

Hello @mherrmann, it has been a week since our last interaction. Can I get an update if you are planning to merge the PR?

Thank you very much. Next step is to host this documentation somewhere. I recommend readthedocs since it's the standard that python community uses to host documentation. But it's up to you to choose what you would like to use. Github pages is another one.

Thank you. I've set it up at ReadTheDocs now: https://selenium-python-helium.readthedocs.io/en/latest/.  Is your username there also IgnisDa?

Yes my username is IgnisDa there. I propose that we add a installation.rst which would get new users started. Additionally, we have to provide a relevant section on the README and then optionally cut down the README to something smaller. I can submit a PR for this.

Sounds good, thank you. I've added you as a maintainer on Readthedocs. I think we should also have the Cheatsheet there.


"Pick" module missing in requirements.txt.

First time installing audiosnatch and I'm new to python modules in general.
On first boot I got an error saying it couldn't find the "Pick" module.
Not sure how to add the link, but it probably wouldn't hurt to add it.
It's a small thing, but I wasn't sure if you were aware of it.

feel free to pr


[BugFix] Fix unstable ut for disk simulation

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[x] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #SR-12336
Problem Summary(Required) ：

New code introduce the new logic that Version GC is executed every PseudoBackend.tabletCheckIntervalMs, so we also need to sleep that extra time to wait for versions really got GCed. Also add some debug information in case that it shows again.
Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

run starrocks_fe_unittest

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

run starrocks_fe_unittest

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

run starrocks_admit_test


undefined: sqlite3.Error issue

When create a hello project, the CLI trows this error to me
⬢[abdyek@toolbox Go]$ bud create hello
| Created: go.mod
| Created: package.json
| Created: .gitignore
| Created: public/favicon.ico
| Installed: go modules
| Installed: node modules
# github.com/livebud/bud/internal/dag
../../../../go/pkg/mod/github.com/livebud/bud@v0.2.8/internal/dag/sqlite.go:345:27: undefined: sqlite3.Error
../../../../go/pkg/mod/github.com/livebud/bud@v0.2.8/internal/dag/sqlite.go:349:47: undefined: sqlite3.ErrReadonlyDbMoved
| exit status 1

Hmm, that's odd. What OS are you running on? Did you try running go mod tidy?
I sense it's related to: https://github.com/mattn/go-sqlite3/issues/384

this err shows on windows，I use intel Mac is ok

I am still experiencing this issue.

I tried to use go mod tidy as @matthewmueller pointed out. But this did not work as well.
Env: Linux/Mint

I've manged to identify the problem.
This is related to CGO.
For more information you can check about static builds on google.
TLDR Fix:
saurav@saurav:~/Workspace/livebud/gandaki$ go env -w CGO_ENABLED=1

I think we should look more into this. As ideally it would be better if works irrespective of CGO_ENABLED=1/0.


Event-Driven SD: does not perform save sys config (write to disk)

ISSUE TYPE

Bug Report

AS3 BUILD/ VERSION

{"version":"3.14.0","release":"4","schemaCurrent":"3.14.0","schemaMinimum":"3.0.0"}
{
  "release": "4",
  "schemaCurrent": "3.14.0",
  "schemaMinimum": "3.0.0",
  "version": "3.14.0"
}

BIGIP VERSION

Sys::Version
Main Package
  Product     BIG-IP
  Version     <IP_ADDRESS>
  Build       0.0.4
  Edition     Point Release 2
  Date        Thu Oct 11 15:32:21 PDT 2018

SUMMARY

event-driven SD does not do a "sys sys config" to write the change to disk.
STEPS TO REPRODUCE

Declaration 1

{
    "schemaVersion": "3.9.0",
    "class": "ADC",
    "Tenant": {
        "class": "Tenant",
        "Application": {
            "class": "Application",
            "template": "generic",
            "pool": {
                "class": "Pool",
                "monitors": ["http"],
                "members": [
                    {
                        "addressDiscovery": "event",
                        "servicePort": 80
                    }
                ]
            }
        }
    }
}

Update to SD task
[
    {
        "id": "newNode1",
        "ip": "<IP_ADDRESS>"
    },
    {
        "id": "NewNode2",
        "ip": "<IP_ADDRESS>"
    }
]

TMSH output
ltm pool Application/pool {
    members {
        NewNode2:80 {
            address <IP_ADDRESS>
            session monitor-enabled
            state down
        }
        newNode1:80 {
            address <IP_ADDRESS>
            session monitor-enabled
            state down
        }
    }
    min-active-members 1
    monitor min 1 of { /Common/http }
    partition Tenant
}

Contents of bigip.conf
# cat /config/partitions/Tenant/bigip.conf
#TMSH-VERSION: <IP_ADDRESS>

ltm pool /Tenant/Application/pool {
    min-active-members 1
    monitor min 1 of { /Common/http }
}

EXPECTED RESULTS

pool member saved to disk (or have an option to specify)
ACTUAL RESULTS

not written to disk

Have you tried forcing  "persist": true, ?

Thank you for your feedback. I have created internal product backlog item AUTOTOOL-970 to track this issue.

Do you think that persisting to disk on an interval (e.g. every 5 minutes) would be sufficient? I am worried that persisting on any event driven update could have an impact on performance.

that gets a little bit confusing. What do the other SD mechanisms do?  Having an additional parameter to specify the interval when creating the event SD pool member would be one possibility to introduce it without “breaking” existing behavior. Some might consider the current implementation a “feature”.

The other SD mechanisms will just rediscover the nodes, so they do not really need to persist the nodes. Similarly, if a user was frequently posting to the event driven nodes, they would not really need persistence either. I think a persistInterval setting on event driven service discovery would make sense.

If you are still looking for a fix, please reach out to us at<EMAIL_ADDRESS>


[chore] Move otel.* attributes to registry

Related to https://github.com/open-telemetry/semantic-conventions/issues/407
Changes
Move otel.* attributes to the registry
Merge requirement checklist

[x] CONTRIBUTING.md guidelines followed.
[ ] Change log entry added, according to the guidelines in When to add a changelog entry.

If your PR does not need a change log, start the PR title with [chore]

[ ] schema-next.yaml updated with changes to existing conventions.

For completeness, do you think it makes sense to also document the deprecated attributes otel.library.name and otel.library.version?

You mean add to the .md file I introduced? Sure, that makes sense!

FYI I have updated deprecated attributes already here https://github.com/open-telemetry/semantic-conventions/pull/898/files#diff-b5f1aa4a7db2ccf61cb0d32d75c9c916f13a3f5733dd804d368fc725b3347a72R2


Fix: URL Handling and Branch Detection to get package.json

📄 What I've done
You can import package.json even when the repository's default branch is master.
🙋 Review Points
I have tested some GitHub repository links and found that I couldn't access when default branch is master. (Whether the link is a public repository or an Organization repository)
The issues are as follows:
For public repository links:

Only if the default branch is main,  we can get the package.json.
It is not possible for the master branch.

Improved URL handling to differentiate between mono and multi-repositories.
Removed trailing slashes at the end of the links for consistency.
The changes allow access regardless of the branch name.
🤔
Discussion link I posted

tested links
https://github.com/msdio/stackticon
https://github.com/msdio/Tamago/tree/main/client
https://github.com/52org/garden-of-the-heart
https://github.com/g2hhh2ee/jihee-image-search-engine-project
https://github.com/evollhhan/mobxplus
https://github.com/Tech-Squad-Community/techsquad-community-website/tree/react/tscomm
everything is working perfect! thank you for contribution 🙌


Style/HashSyntax still consider not safe when autocorrect with -a

When we have a following file.
def foo(operator)
  send_notify users, operator: operator
end

It will be autocorrect to following code when save.
def foo(operator)
  send_notify users, operator:
end

Yes, it correct, no syntax error, but when we add a line code after it, like this:
def foo(operator)
  send_notify users, operator:
                       puts 'ok'                   # <= indent error, in fact, syntax too.
end

As you can see, puts 'ok' even can not be indent correctly by emacs builtin ruby-mode on emacs 28.1
That is because this cause syntax error:
syntax error, unexpected string literal, expecting `do' or '{' or '('
                       puts 'ok'

so, i consider Style/HashSyntax should not do above changes, another solution is, add parenthesis too. like this:
def foo(operator)
  send_notify(users, operator:)
  puts 'ok'
end

thank you.
rubocop 1.27.0
ruby 3.1.0

I came here to file the same issue. This cop is performing unsafe autocorrection on arguments that are not wrapped in parentheses. This happened to me in real-world code such as the following:
get enrollments_path start_date: start_date, end_date: end_date
assert_response :ok

Which autocorrected to:
get enrollments_path start_date:, end_date:
assert_response :ok

#=> syntax error, unexpected symbol literal, expecting `do' or '{' or '(' (SyntaxError)
#=> assert_response :ok
#=>                 ^

RuboCop 1.36.0
Ruby 3.1.2

As you can see, puts 'ok' even can not be indent correctly by emacs builtin ruby-mode on emacs 28.1
That is because this cause syntax error:

Hm, this is related to the following current Ruby syntax issue:
https://bugs.ruby-lang.org/issues/18396
Maybe, an ideal solution would be for ruby-mode to be able to make sense of correct indentation to the hash omission.

get enrollments_path start_date: start_date, end_date: end_date
assert_response :ok

By updating to the latest RuboCop (currently 1.41.1) , auto-correction will add parenthesis.
get enrollments_path(start_date:, end_date:)
assert_response :ok


Introduce GOMEMLIMIT and new resource limit configurations to all components

As a result of https://github.com/kyma-project/telemetry-manager/issues/771 we identified that setting the GOMEMLIMIT will only have positive effects and should be done for all of the components we are running
Criterias

All components are having the GOMEMLIMIT setting applied

trace-gateway
metric-gateway
metric-agent
telemetry-manager
self-monitor

All components have a validated resource footprint
Adjust otel-collector settings to leverage queue in the backpressure scenario
Document decision criterias for performce test results, add comment column in case you continue with numbers which are violating criterias

Tasks

Apply GOMEMLIMIT to the Trace and Metric gateway and metric agent based on findings from docs/contributor/pocs/gomemlimit-telemetry-memory.md
Setup new resource limits for Trace gateway similar to the Metric gateway
Setup and test new memory limiter configuration based on new GOMEMLIMIT configuration to allow less aggressive memory limiter
Apply GOMEMLIMIT to the telemetry-operator and the system log collector setup

GOMEMLIMIT environment variable and as value %80 of memory limit of trace gateway, metric gateway, metric agent, telemetry module, and self-monitor added
Trace gateway, metric gateway, and metric agent memory_limiter processor configuration updated accordingly new GOMEMLIMIT configuration
New load test results added with GOMEMLIMIT configuration


helm chart.tgz files should put the Chart.yaml inside a folder - see https://github.com/kubernetes/helm/pull/1172

LGTM [merge]


Microsoft Detours

Please add https://github.com/Microsoft/Detours to vcpkg
https://github.com/Microsoft/Detours/issues/22

Would be great to see you submit a PR for this!


feat: Implement V2 API to query readings by name and time range

Close: #3519
PR Checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/master/.github/Contributing.md.
What is the current behavior?

Issue Number: #3519
What is the new behavior?
Implement V2 API to query readings by resourceName and specified time range
Does this PR introduce a breaking change?

[ ] Yes
[x] No

New Imports

[ ] Yes
[x] No

Specific Instructions
Are there any specific instructions or things that should be known prior to reviewing?
Other information

Opened PR to add API route constant https://github.com/edgexfoundry/go-mod-core-contracts/pull/635

this is for v2.0.1, so hold this PR until v2.0.0 released

@weichou1229 please rebase this PR and use the new contract version

Rebased and upgraded the contract version to v2.0.1-dev.1

Codecov Report

Merging #3577 (63bdb5d) into main (54f03fb) will decrease coverage by 0.02%.
The diff coverage is 46.15%.

@@            Coverage Diff             @@
##             main    #3577      +/-   ##
==========================================
- Coverage   47.29%   47.27%   -0.03%
==========================================
  Files         111      111
  Lines        9013     9048      +35
==========================================
+ Hits         4263     4277      +14
- Misses       4380     4401      +21
  Partials      370      370

Impacted Files
Coverage Δ

internal/pkg/infrastructure/redis/client.go
0.00% <0.00%> (ø)

internal/pkg/infrastructure/redis/reading.go
10.48% <0.00%> (-0.39%)
:arrow_down:

internal/core/data/application/reading.go
67.27% <11.11%> (-12.73%)
:arrow_down:

internal/core/data/controller/http/reading.go
83.01% <100.00%> (+3.24%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 54f03fb...63bdb5d. Read the comment docs.


plz add data format supportting, thx

hi this ext is very usful, and it will be better for add format support，
for example:
I want to convert dec-hex;
10-->0xA
350--0x15E
I want this ext can provide the option that we can specify the "Length", like:
10--->0x00A
350-->0X15E
so that I can  align my code easier. thx

Sure, I can add it in as a configuration option.  I've shown an example of the two below:
Length of 2 would always add 2 zeros:
10--->0x00A
350-->0X0015E
Padding of 3 would pad every number out to 3 digits:
10--->0x00A
350-->0X15E
I'm assuming you want padding but I just want to make sure.

Sure, I can add it in as a configuration option.  I've shown an example of the two below:
Length of 2 would always add 2 zeros:
10--->0x00A
350-->0X0015E
Padding of 3 would pad every number out to 3 digits:
10--->0x00A
350-->0X15E
I'm assuming you want padding but I just want to make sure.

thx a lot， and  i think padding is better  to align code, The user can enter a determined number to confirm the length of the hex dec and bin. like 10-->0x000A, means that 4 digits, and 10-->0x0000000A means 8 digits.

Released version 1.0.2 with this feature. Let me know if you have any issues.

hi I have update to 1.0.2, and thx for your job.
now we can see an option in settings named “Pad To Length”,but Most of the time we convert data, The pad-number depends on the context. not a fixed number. so that I thinks it would be better to determind the pad-number when we are converting,Popuping a  window and inputing the pad-number may be more suitable for the scene and context. :D

Alright, I think I understand. Just to clarify, you basically want the ability to alter the padding on each text conversion you do?

Alright, I think I understand. Just to clarify, you basically want the ability to alter the padding on each text conversion you do?

yes,  thanks a lot 👍

I added a variable padding option in 1.0.3. When enabled, the extension will prompt the user to provide a padding value each time they convert a selection.