text:
feat: zero support added

Resolves #487

BTW, we later added an explicit = delete; for the zero constructor of quantity_point. I think that'd be nice here too.

I don't think it is needed as in mp-units we do not have a constructor in quantity_point that gets a quantity as  an argument. The only way to create a point is to add quantity to a point origin or use make_quantity_point() factory function.

BTW, we later added an explicit = delete; for the zero constructor of quantity_point. I think that'd be nice here too.

I don't think it is needed as in mp-units we do not have a constructor in quantity_point that gets a quantity as  an argument. The only way to create a point is to add quantity to a point origin or use make_quantity_point() factory function.
As an alternative we could delete operator+(zero_t, quantity) but I am not sure if it is worth it as we never claim that zero is a point origin.

BTW, we later added an explicit = delete; for the zero constructor of quantity_point. I think that'd be nice here too.

I don't think it is needed as in mp-units we do not have a constructor in quantity_point that gets a quantity as an argument. The only way to create a point is to add quantity to a point origin or use make_quantity_point() factory function.

My main motivation for adding it was to communicate clearly to users that yes, we thought about this and no, we don't want to support it.  I was anticipating that users who get "spoiled" by using zero with quantity will be tempted to use it with quantity point.  So I decided to add the = delete; along with a readable comment for users who follow the delete to its source.
I guess I'm trying to head off a misguided feature request before it can happen. :slightly_smiling_face:

So I decided to add the = delete; along with a readable comment for users who follow the delete to its source.

It's more readable if it's a line comment after = delete;,
as Clang and GCC will include parts of it in the error message.
For example, the error of https://cpp2.godbolt.org/z/3fcosGbc4 includes:
main.cpp2:4:8: error: call to deleted constructor of 't'
    4 |   auto y {x};
      |        ^ ~~~
main.cpp2:3:15: note: 't' has been explicitly marked deleted here
    3 |       public: t(t const&) = delete; /* No 'that' constructor, suppress copy */
      |               ^
1 error generated.

I think I would add it as well if we had a constructor from quantity in quantity_point. In our case, the only misleading thing here may be trying to use it as a point origin. For example, zero + 21 * deg_C is a quantity and not a quantity_point.

Unfortunately, we have to get rid of some interfaces for zero so it will be limited in scope. operator-(QuantityPoint, QuantityPoint) can't return zero 😢

Unfortunately, we have to get rid of some interfaces for zero so it will be limited in scope. operator-(QuantityPoint, QuantityPoint) can't return zero 😢

Hmm, that's too bad.  Then again, it's probably just fine to start small and deliver value in a few use cases, then expand later as we're able.
By the way, there's one more non-obvious use case for zero I thought worth mentioning.  It turns out that at least for Au, zero is a really useful result type for the origin displacement between two origins whose values are equal.  If we didn't do this, we wouldn't be able to get the underlying value of a quantity point in its own unit!  (At least, not without some other workaround.)  In case you encounter this problem in mp-units, this could be useful to have in your bag of tricks.
https://github.com/aurora-opensource/au/blob/eb615a60a0588b259b3f341279845249ce7cfd09/au/unit_of_measure.hh#L416-L435

Hmm, that's too bad. Then again, it's probably just fine to start small and deliver value in a few use cases, then expand later as we're able.

I do not think it will be possible. For example the below would compile:
QuantityOf<isq::energy> auto q = isq::width(2 * m) * (mean_sea_level - mean_sea_level);

which would be really problematic, right?

I do not think it will be possible. For example the below would compile:
QuantityOf<isq::energy> auto q = isq::width(2 * m) * (mean_sea_level - mean_sea_level);

which would be really problematic, right?
It is exactly why I removed zero being the result of subtracting same origins in this commit: 0dd28c1.

If we made the result of subtracting an origin from itself zero --- and, if we did not define multiplication operators for zero --- then wouldn't this example not compile?  Specifically, width(...) * zero wouldn't compile (even before we get to the LHS of the assignment).

If we made the result of subtracting an origin from itself zero --- and, if we did not define multiplication operators for zero --- then wouldn't this example not compile? Specifically, width(...) * zero wouldn't compile (even before we get to the LHS of the assignment).

Yes, you are right, but I think making it not compile would be wrong and inconsistent. Why the first one should not compile while others compile fine:
QuantityOf<isq::energy> auto q1 = isq::width(2 * m) * (mean_sea_level - mean_sea_level);
QuantityOf<isq::energy> auto q2 = isq::width(2 * m) * (ground_level - mean_sea_level);
QuantityOf<isq::energy> auto q3 = isq::width(2 * m) * (my_quantity_point - mean_sea_level);

What if I have a generic function like this:
constexpr auto point_diff(const QuantityPointOrPointOrigin& lhs, const QuantityPointOrPointOrigin& rhs)
{
  return lhs - rhs;
}

or something similar. How to explain this to the user that someone a results from such a function would make the following code not compile?

To summarize, I think that if we decide that the subtraction of two points (that typically returns a quantity) in some specific case returns zerothan suchzeroshould be handled by all the code that would acceptquantity(including satisfying aQuantity` concept) which gets really messy... 🥴

Ah --- so in https://github.com/mpusz/mp-units/pull/488#issuecomment-1703903031, you meant to say that it would not compile, and that this is what would be problematic.  Now I understand the argument.  It's a fair point.
(Also, I think you're assigning an area to an energy in all of these examples, but that's a side point. :slightly_smiling_face:)
This is an analogous problem to the decision to return a raw number when units cancel completely.  I think mp-units used to do that, but then stopped.  Au did not use to do that, and we now do --- here's the rationale --- but I'm starting to second-guess that decision.  If I could go back in time, I'd probably advise my past self to prefer consistency and just always return a quantity.
So I'm persuaded to avoid returning zero in this new case, too.

(Also, I think you're assigning an area to an energy in all of these examples, but that's a side point. 🙂)

Fixed the code. Thanks for pointing this out.

Ah --- so in https://github.com/mpusz/mp-units/pull/488#issuecomment-1703903031, you meant to say that it would not compile, and that this is what would be problematic. Now I understand the argument. It's a fair point.

I actually meant both. There is no good solution for that. Either you make it not compile which makes it inconsistent or you make it compile and suddenly zero has to actually satisfy Quantity with all the side effects of such a change which is unfortunate because something that should be a quantity of area would also be able to initialize totally unrelated quantity (i.e. energy).

Ah --- so in #488 (comment), you meant to say that it would not compile, and that this is what would be problematic. Now I understand the argument. It's a fair point.

I actually meant both. There is no good solution for that. Either you make it not compile which makes it inconsistent or you make it compile and suddenly zero has to actually satisfy Quantity with all the side effects of such a change which is unfortunate because something that should be a quantity of area would also be able to initialize totally unrelated quantity (i.e. energy).

Besides the current zero,
a zero that is parameterized on the dimension could solve that.

Besides the current zero, a zero that is parameterized on the dimension could solve that.

I think that would be an overkill of a feature. In order to use it must be simple and universal. It should be usable not only with physical units but also with other numeric libraries.
Today, I sent a question to the SG6 (Numerics) chair, asking if he finds it useful in other use cases. If he is not interested, I am not sure if we will merge it as I see too many issues with this solution compared to the benefits of having it.

I agree: dimension-based zero would be overkill.
I'm surprised we might not merge it if the SG6 chair doesn't already know of other use cases.  I think the units library use cases are enough to justify it.  It's true that we expect zero_t to be useful in other non-units use cases, too, but I wouldn't be surprised if people didn't see the value until they've had a chance to try it out --- I myself underestimated it until I started using it in practice.
For the units library use cases specifically, I think it makes sense to start conservatively with "whatever we can get by making quantity implicitly constructible from zero_t".  This avoids the waterfall of code changes, while delivering on the most compelling use cases, which are initialization and comparison.
I also think it makes sense to think of zero as mostly something we enable end users to write, instead of something we try to look for opportunities to return in our APIs.
Ultimately, though, the decision to include or exclude zero_t is yours.

I'm surprised we might not merge it if the SG6 chair doesn't already know of other use cases. I think the units library use cases are enough to justify it.

I am really puzzled here. It is much easier to add it later (especially as it is already implemented on the branch) when we find it mandatory than remove it later when people will actually start using it, but when we decide it was not a good idea.
I see some use cases where it helps, but I also see some cases where it actually causes lots of confusion. Even such an experienced user with this feature as you, suggested using it for the subtraction of two points because it really feels like it is the right way to do it. But it is not...
And there are more possible confusions coming. I am afraid of GitHub issues asking why the following does not work:
msl_altitude current_ = mean_sea_level + zero

or this one:
for (auto tt = zero; tt <= 50 * ms; ++tt) {
  // ...
}

or this:
auto q1 = 42 * m;
auto q2 = q1 * zero;

All of the above looks like the code that "should" work with a feature zero, and inexperienced users will be making those mistakes and asking for support when it does not compile.

I think it makes sense to start conservatively with "whatever we can get by making quantity implicitly constructible from zero_t". This avoids the https://github.com/mpusz/mp-units/pull/488#issuecomment-1703903841, while delivering on the most compelling use cases, which are initialization and comparison.

Again, despite your long experience with the issue, even the above use case has some issues connected with it:
void foo(quantity<si::metre> q);
void boo(QuantityOf<isq::length> auto q);

foo(zero);  // works
boo(zero); // does not work

And what if someone will be already using zero in the core base and then the interface will be refactored from foo() to boo()?
As I said, there are certainly some cases where it makes the code nicer or more generic, but we may fall into plenty of possible misuses and pitfalls if we add it.
Let's remember that this feature is mostly to write this:
if (v1 - v2 == zero) ...

instead of this:
if (v1 - v2 == 0 * (m/s)) ...

I am not so convinced that it is worth it...

tl;dr: Thanks for collecting these problem cases in one place!  I looked at each, and I didn't find most of them compelling, because I don't believe users would be motivated to write them in the first place.  However, I do think the issue of passing zero to a concept interface is both novel (this doesn't happen in Au) and fascinating, and I don't know the implications.  Overall, if you don't feel confident adding it and decide to delay, then I'll understand your reasons.

I am really puzzled here. It is much easier to add it later (especially as it is already implemented on the branch) when we find it mandatory than remove it later when people will actually start using it, but when we decide it was not a good idea.

That's true.  It's always easier to add later than to remove.

I see some use cases where it helps, but I also see some cases where it actually causes lots of confusion. Even such an experienced user with this feature as you, suggested using it for the subtraction of two points because it really feels like it is the right way to do it. But it is not...

Which comment are you referring to?  Was it this one or some other?
Assuming that's the one, I think it was an oversight on my part that I didn't question the premise of your comment: namely, that we would want operator-(QuantityPoint, QuantityPoint) to be able to return zero.  That's not what Au does, and I don't think it's desirable generally.  When I said "it's too bad" that it wouldn't, I wrote without thinking.
What the rest of that comment refers to is an encapsulated, library-internal implementation detail.  There's a use case when computing origin offsets where we want to use zero instead of the result of operator-(QuantityPoint, QuantityPoint).  That use case might also be relevant for mp-units, although the quantity point interfaces and implementations are different enough that I really couldn't say for sure.

And there are more possible confusions coming. I am afraid of GitHub issues asking why the following does not work:

Thanks for supplying all of these concrete examples in one place!  I'll look at each one in turn, to see how much it motivates me to avoid or defer adding zero.

msl_altitude current_ = mean_sea_level + zero

I'm not fluent with mp-units constructs, so I'll write out my assumptions explicitly.  I assume:

msl_altitude is a quantity point type, whose origin type is mean_sea_level
mean_sea_level is a type that represents a point origin: it represents a point only, and, crucially, has no associated units (although it presumably does have a dimension)

If those assumptions are correct, then mean_sea_level + zero indeed won't compile, because mean_sea_level has no units.  This makes sense.
My question: would we expect this to work without the + zero?  I would assume yes, so I would assume there's no motivation to reach for zero in the first place.

or this one:
for (auto tt = zero; tt <= 50 * ms; ++tt) {
  // ...
}

Here's another use case where I just don't think users are motivated to reach for zero in the first place.  If the unit is easy to write in the second clause, then it's easy enough to write in the first clause.
I think your main point, though, is that if a user does try this, then we might get an annoying bug report.  I don't think we need to worry about this.  The compiler error will mention operator++(zero_t).  It should be straightforward enough that one can't increment a type which is always zero.
In fact, I think the situation is analogous to something we already have with an existing standard type that represents a kind of "zero-ness":
auto foo_ptr = nullptr;
++foo_ptr;

Next issue:

or this:
auto q1 = 42 * m;
auto q2 = q1 * zero;

I concede that if zero exists, it's tempting to add definitions for its multiplicative properties, not just its additive ones.  That said, I think this would be a mistake (not that you were proposing this!).
It's interesting to contrast the additive and multiplicative properties for zero and 0 in the context of quantities:

For additive operations, 0 simply won't work, whereas zero will, and the result type is perfectly clear.
For multiplicative operations, 0 already works just fine, whereas the desired result from using zero is completely unclear: we don't even know the desired dimension!

So, yes: zero may not work for multiplicative use cases, but it's also true that because 0 works great here, users aren't motivated to reach for zero in the first place.  Thus, I'm not really bothered by this use case.

All of the above looks like the code that "should" work with a feature zero, and inexperienced users will be making those mistakes and asking for support when it does not compile.

I think it makes sense to start conservatively with "whatever we can get by making quantity implicitly constructible from zero_t". This avoids the #488 (comment), while delivering on the most compelling use cases, which are initialization and comparison.

Again, despite your long experience with the feature (please don't treat it personally; I just want to make a point here that even experts might be easily confused here), even the above use case has some issues connected with it:

Thanks for clarifying that it's not meant personally.  :slightly_smiling_face:  And don't worry, I haven't taken anything personally, and I understand the point you're making by referencing my experience.  In fact, I think the below use case is really interesting.

void foo(quantity<si::metre> q);
void boo(QuantityOf<isq::length> auto q);

foo(zero); // works
boo(zero); // does not work

And what if someone will be already using zero in the core base and then the interface will be refactored from foo() to boo()?

I think the reason the "implicitly convertible" use cases are such a slam dunk for Au, but have questionable use cases like this for mp-units, is at least in part due to concepts.  Au virtually always deals in concrete types --- and as long as zero knows what it is "impersonating", it's really smooth.  But bring in something like QuantityOf<isq::length>, and you're right, we see some friction.
I don't have a fully satisfying general answer.  In this specific case, if one refactored an interface like this, and if there are many existing callsites using zero, it may be worth adding a zero_t overload either temporarily or permanently.  This won't scale well, though, if we have multiple quantity parameters in a signature that we're refactoring to use concepts.  It's then tempting to treat zero as satisfying the concept, as suggested elsewhere, but I think this would be a big mistake (which I think was the conclusion that we reached there too).
The big takeaway, though, is that "zero has issues with quantity concepts".  That's novel and interesting, and I'm not sure what the full implications are just yet.

Another similar issue with the above-proposed design:
auto q1 = 42 * m;
q1 += zero;          // works
auto q2 = q1 + zero; // does not work

I'm confused: why wouldn't this work?  I assume q2 should have the same type and value as q1.  I just did a sanity check in Au, and indeed this works:
TEST(Zero, CanAddToQuantity) {
    auto q1 = meters(42);
    auto q2 = q1 + ZERO;
    EXPECT_THAT(q2, SameTypeAndValue(q1));
}

The test passes.
That said, even if it didn't, why would users be motivated to add zero to the quantity?

Initially, I thought that zero is a great idea, but the more experience I get with this feature, the more issues like the above I see. I am sure there plenty more that I do not realize as of now as well...
As I said, there are certainly some cases where it makes the code nicer or more generic, but we may fall into plenty of possible misuses and pitfalls if we add it.

I'm persuaded by the argument that it's easier to add than to remove, so if you're feeling uncomfortable about it, then I support your decision to defer.

Let's remember that this feature is mostly to write this:
if (v1 - v2 == zero) ...

instead of this:
if (v1 - v2 == 0 * (m/s)) ...

I am not so convinced that it is worth it...

Well, what are v1 and v2, exactly?  Are they both of type (m/s)?  Let's zoom out a bit.
bool equal(QuantityOf<isq::speed> auto v1, QuantityOf<isq::speed> auto v2) {
    return (v1 - v2 == 0 * (m/s));
}

In this case, we may get an extra unit conversion at runtime, between (m/s) and the common unit of v1 and v2.  zero would pick the correct unit automatically.  (Of course, we have to ignore how contrived the example is, as in real life we'd just write v1 == v2.  :slightly_smiling_face:)
It's also really interesting that in this case, concepts actually strengthen the arguments for zero.  It seems like zero is questionable when passed to an interface using concepts, but it's still really handy inside of the implementation.

Thanks for the detailed comments and answers!
Here are some comments from me:

Which comment are you referring to? Was it https://github.com/mpusz/mp-units/pull/488/#issuecomment-1703845443 or some other?

Yes, this is the one I meant.

My question: would we expect this to work without the + zero? I would assume yes, so I would assume there's no motivation to reach for zero in the first place.

Everything depends on the use case. Let's imagine this:
msl_altitude make_AMSL(auto q)
{
  return mean_sea_level + q;
}

msl_altitude qp1 = make_AMSL(42 * m); // works
msl_altitude qp1 = make_AMSL(zero); // error

I think your main point, though, is that if a user does try this, then we might get an annoying bug report. I don't think we need to worry about this. The compiler error will mention operator++(zero_t). It should be straightforward enough that one can't increment a type which is always zero.

I also think that the user will understand the compiler error but we will get a bug report anyway asking us to make it work 😉 And we will have to explain (possibly multiple times to multiple users) why it can't work and why we won't "fix" it.

The big takeaway, though, is that "zero has issues with quantity concepts"

It is not only about concepts but also about plain auto (or typename T) that people love to write in generic code.

I'm confused: why wouldn't this work? I assume q2 should have the same type and value as q1. I just did a sanity check in Au, and indeed this works:

Through the years of doing mp-units, I have learned that op+(lhs, rhs) for quantities should not allow implicit conversions because there are cases where we end up with either the ODR violation or with a lack of commutative property of addition (a + b and b + a yield different types or sometimes even only one of them compiles). This is why the op+ is implemented as follows:
https://github.com/mpusz/mp-units/blob/d7261c8f7624fc2a3dc4d0f9cb704556a5369b6d/src/core/include/mp-units/quantity.h#L340-L346
The above does not allow any implicit conversions. However, the compound assignment is different. It can't change the LHS type, and in the case of self-addition it means that the  RHS must be of the same type. This means that we can allow implicit conversions here:
https://github.com/mpusz/mp-units/blob/d7261c8f7624fc2a3dc4d0f9cb704556a5369b6d/src/core/include/mp-units/quantity.h#L236-L245
This difference was not a big issue for now, but adding implicit conversion from zero will make them more visible (as described in my previous examples).

That said, even if it didn't, why would users be motivated to add zero to the quantity?

The zero may be just an argument of some parent function (like in the make_AMSL case above) so at the point of doing arithmetic you do not really know what is the type and value there.

In this case, we may get an extra unit conversion at runtime, between (m/s) and the common unit of v1 and v2. zero would pick the correct unit automatically

This is true, and I see this as the biggest benefit of this feature. Otherwise, we need something like this:
bool foo(QuantityOf<isq::speed> auto v1, QuantityOf<isq::speed> auto v2)
{
  const auto q = v1 - v2;
  return (q == q.zero());
}

to prevent additional conversions. This is a bit inconvenient but not that terrible IMHO.
As I wrote before, I really liked the idea of zero at the beginning and encouraged you to come forward and propose it for addition here. I even hoped a bit for a PR 😉, which I would probably accept immediately. But it actually was a good thing that I implemented it by myself because I got enough experience with this feature to understand related issues that might appear.
I see the benefits of this feature but I just don't know for now how to make it work in an easy-to-understand way. In this commit https://github.com/mpusz/mp-units/pull/488/commits/0dd28c13dde4a183ee95f47b967c1b308eaaa3cf I already removed subtraction of points, and addition and subtraction of a quantity and zero. Maybe also removing the implicit construction from zero (or making it explicit if it makes any sense) will make the remaining code consistent, easy to use, and understand? But in the end, what is left is just explicit support of zero for:

op==
op<=>
op= (although I am not sure if that will not also cause some issues when we look closer at this use case).

Is it enough to justify the addition of a new feature?
Please let me know your thoughts.

I'm confused: why wouldn't this work? I assume q2 should have the same type and value as q1. I just did a sanity check in Au, and indeed this works:

Through the years of doing mp-units, I have learned that op+(lhs, rhs) for quantities should not allow implicit conversions because there are cases where we end up with either the ODR violation or with a lack of commutative property of addition (a + b and b + a yield different types or sometimes even only one of them compiles). This is why the op+ is implemented as follows:
https://github.com/mpusz/mp-units/blob/d7261c8f7624fc2a3dc4d0f9cb704556a5369b6d/src/core/include/mp-units/quantity.h#L340-L346

Interesting... I see that this is implemented as a nonmember function.  Au takes a different approach.  We haven't seen ODR violations or lack of commutativity, but maybe we have those problems and just haven't encountered them!
Our main approach to implementing quantity/quantity addition is twofold.  First, we use the hidden friend idiom for same-quantity-type addition:
https://github.com/aurora-opensource/au/blob/eb615a60a0588b259b3f341279845249ce7cfd09/au/quantity.hh#L310-L312
Next, we use a nonmember function for adding two different quantity types:
https://github.com/aurora-opensource/au/blob/eb615a60a0588b259b3f341279845249ce7cfd09/au/quantity.hh#L618-L621
(There are two other overloads, but they cover the cases for corresponding quantities --- so, adding an Au quantity with one from nholthaus or the chrono library, say.  I'm glossing over them for now.)
This setup has worked well so far.  It preserves commutativity.  It also allows us to use one-way implicitly convertible types such as ZERO.  But if there are pitfalls I haven't seen, I'd like to know about it!

As I wrote before, I really liked the idea of zero at the beginning and encouraged you to come forward and propose it for addition here. I even hoped a bit for a PR 😉, which I would probably accept immediately. But it actually was a good thing that I implemented it by myself because I got enough experience with this feature to understand related issues that might appear.
I see the benefits of this feature but I just don't know for now how to make it work in an easy-to-understand way. In this commit 0dd28c1 I already removed subtraction of points, and addition and subtraction of a quantity and zero. Maybe also removing the implicit construction from zero (or making it explicit if it makes any sense) will make the remaining code consistent, easy to use, and understand? But in the end, what is left is just explicit support of zero for:

op==
op<=>
op= (although I am not sure if that will not also cause some issues when we look closer at this use case).

Is it enough to justify the addition of a new feature?
Please let me know your thoughts.

On reflection, I think implicit conversion is really important to get good usability.  I still feel zero is worthwhile if we have it, even though it can't be passed to "generic quantity" interfaces: I guess I just value the benefits more than I worry about these costs.  But if we didn't have the implicit conversions, it would be harder enough to use that I'm not confident it would be worth it.

Interesting... I see that this is implemented as a nonmember function. Au takes a different approach. We haven't seen ODR violations or lack of commutativity, but maybe we have those problems and just haven't encountered them!

I tried making them hidden friends a few times already, but I always failed every single time because of some corner and surprising cases connected to implicit conversions of quantities.

I thought a lot about zero in the past few days. I do not think that implicit construction from zero is a good idea for the reasons specified above. So the last one standing is the usage of zero with comparison functions.
I think we have two options here:

We keep the support for zero and provide dedicated overloads for op== and op<=> like in the current implementation of this PR. This has some potential issues of people trying to do more with it like construction or assignment from zero or adding zero and complaining that it does not work and probably should. We will have to provide the arguments mentioned above of why it is not a good idea every single time.
Usage example:
if (q == zero) // ...

We provide named non-member functions (e.g. is_eq_zero(q), is_gt_zero(q), ... similar to the interface introduced with the three-way comparison)  to do the work in an efficient way.
Usage example:
if (is_eq_zero(q)) // ...

This is a bit more verbose but makes it clear that the feature is meant only for comparison. Having this as a non-member function allows it to work in a generic with other abstractions as well, which I find really nice. For example:
template<typename T>
  requires requires { T::zero() -> std::equality_comparable_with<T>; }
[[nodiscar]] constexpr bool is_eq_zero(T v) { return v == T::zero(); }

the above would work with std::chrono::duration right away.

authors: JohelEGP chiphogg mpusz

repo: mpusz/mp-units


text:
Bug with chaining Request.filter

Request(...).filter(...).filter

applies NSPredicate only from last filter, it is a bug. We should

deny chaining .filter.filter
add those chaning options

Request(...).filter(...).or(...)
Request(...).filter(...).and(...)

or and and

connected a bit to #1

source: gharchive/issue

repo: mrdekk/DataKernel

license: mit

license_type: permissive

license_source: bigquery


text:
Shared Logger

I have two TS applications with shared packages:

A frontend bundled for the browser with react-scripts
A nodejs backend

I'd like to move from console.log to log4j-style logging across both projects including the shared modules. Ideally, I would create a log package that determines the runtime context, and initialize the logger accordingly. Then, each module (node, frontend, or shared) would import the logger in the same manner:
import log from 'common-logger';
// This should just work because the logger is configured in the common-logger package
log.info('foo');

Is this a valid design and are there examples of such implementation with typescript-logging?

That's exactly what I was looking for. Thanks!

repo: mreuvers/typescript-logging


text:
Use a different method for finding the SSDT on x64

See commit message. I don't have the 6.3.9600.18438 kernel from your last commit, but I'm relatively certain it should work on that as well.

Looks great, thanks!

source: gharchive/pull-request

authors: Mattiwatti mrexodia

repo: mrexodia/TitanHide


text:
fix(mfi-ui): refresh lendbox after action

The other actionboxes refresh their state when they open up, but the borrowlend box on the homepage doesnt open/close after a transaction, so refetching the selectedBanks triggers to recalculate the maxAmount. We should keep this in mind for future actionbox usage, but it doenst affect any other action boxes atm cause they are all within a dialog.

Do we also need this for looping & repay w/ collat?

repo: mrgnlabs/mrgn-ts

license_source: github-api


text:
Template file

Why do I need a template file? I just want to create an empty sheet without a template.

Unlike csv that is one file, xlsx is actually lots of files internally, and its a lot of stuffing around to create all of them.
If you or someone else would like to add this to the project that would be great.


text:
Issues with upcoming 1.18 (extended build height)

If an area is saved in a world running 21w39a or up, the area won't render properly in the viewer. The biome will show up as either unknown or ocean, and the blocks will show up as minecraft:air. This is best illustrated if the player loads in far away from world spawn:

This might have to do with the new negative y coordinates.

Mojang did change the storage format again . . .

Now Biomes are not stored anymore per Chunk, put per Section. They also have a Palette that has to be decoded.
BlockState is still stored in the same manner as before (with Palette), but the NBT keys have changed name and structure.

@AndrewIsOffline did you check, that the version number you provided is exactly the very first snapshot showing this behavior?

The change notes for 21w39a indicate the modified Biomes, so it should be ok for the moment.

Some intermediate status:

I'm able to render latest snapshot again, will publish the changes soon
more Biome data (now per Section) and more Sections will lead to about double of memory usage, so we will only be able to show half sized maps compared to now

Everything is working for 1.18, the release is out and finally also Minecraft released 1.18 today.
@BlaCoiso: As I did extended build height implementation twice during the this year, the second time I prepared everything to render arbitrary world height. So in principle it will work with your strange dimensions. The only step missing is to detect the availability of custom dimensions.
Could you please provide some test worlds with your custom dimensions?

I do not have the time to prepare these custom worlds.
But I need them to figure out how to detect a custom dimension and how to detect build height for that dimension.

I've found an issue with the search for block feature where it ignores blocks at Y=0; about the custom dimensions, I'll look at the current format for specifying them and try to generate them again, I'll send the new world with those dimensions once I have them ready

continue in #269

authors: AndrewIsOffline BlaCoiso EtlamGit

repo: mrkite/minutor


text:
run demo with custom image+radar data

Dear Authors,
I would like to test your code with my own data gathered from a combination of camera and radar.
Could you please enlighten me how to preprocess the data and arrange the arguments of demo.py or test.py?
Thanks a lot!

hi, how is your work going?

Dear Authors,
I would like to test your code with my own data gathered from a combination of camera and radar. Could you please enlighten me how to preprocess the data and arrange the arguments of demo.py or test.py?
Thanks a lot!

Hello，Do you Success? I meet the same problem!

Hello @LongfeiDE, @ryontang Have you found the solution to your probelm to test the code on personal camera radar dataset? Any help would be appreciable.
Thank you.

authors: LongfeiDE UmangBDhanani ryontang stanny880913

repo: mrnabati/CenterFusion

license: MIT


text:
How to get coordinates and confidence information from yolo 8 model

The above is the model properties, there should be one float32 output. However, after executing model.runSync([data]). The output is

I have no idea about how to get the detection result from this model. Anyone can help?

Sorry but this is not really related to the issue tracker here. I don't know that model, I don't use that model, so I can't help you.
Ask in the yolo support channel

I have the same question, if anyone has figured it out, please write.

authors: MarcoHuixxx dsshard mrousavy

repo: mrousavy/react-native-fast-tflite


text:
Support for include

I saw that moxy is based on scriban (https://github.com/scriban/scriban)
I tried to use the include function to be able to factorize stuff between my templates.
Unfortunately this isnt working:
2>Grp1.mixin(8,4): Error MOXY0003 : /home/kevin/dev/Spice86/src/Spice86.Core/Emulator/CPU/CfgCpu/ParsedInstruction/Instructions/Mixins/Grp1.mixin(1,4) : error : Unable to include <Test.mixin>. No TemplateLoader registered in TemplateContext.TemplateLoader

I'm not sure how it would be achieved unless there is a hook I can use for resolving.

Maybe that's not what you meant but it looks like you need to hook an TemplateLoader that provides the include text
https://github.com/scriban/scriban/blob/38df14946721238d2f4badc7c0b6e8a1c594e23c/doc/runtime.md#include-and-itemplateloader
I can see from my limited understanding of your code that you create a TemplateContext here https://github.com/mrpmorris/Morris.Moxy/blob/c75846112f83b2d8b5335fb25d9163d9153984ba/Source/Lib/Morris.Moxy/SourceGenerators/ClassSourceGenerator.cs#L125
Maybe a custom loader that would try to find the include file from the current directory of the compiledTemplate object would work for most cases?

authors: kevinferrare mrpmorris


text:
Svelte support?

I did a quick test to try the lib in svelte but getting some errors. Does it have svelte support? Seems to be a 'compile' error. Any tips?
Errors:
[Nollup] Listening on http://localhost:5000
preferring built-in module 'events' over local alternative at 'events', pass 'preferBuiltins: false' to disable this behavior or 'preferBuiltins: true' to disable this warning
ParseError: /node_modules/hasura-om/src/hasura/events.js
Error: ENOENT: no such file or directory, open '/Users/xxxx/Develop/routify/node_modules/hasura-om/src/hasura/events.js'
at compileModule (/Users/xxx/Develop/routify/node_modules/nollup/lib/impl/NollupCompiler.js:116:19)
at processTicksAndRejections (internal/process/task_queues.js:93:5)

Hi, I don't really have time to test it with svelte, but it should work with any lib cause it has no dependency on any. I use it with VUE and also on the server-side.

Thanks, no problem, maybe the problem is that I want to use it client-side?

Yes, this could be a reason. Vue uses webpack and it compiles everything fine

authors: mrspartak tombroens

repo: mrspartak/hasura-om


text:
🛑 Dashboard is down

In ffbdb03, Dashboard (https://app.eventnexo.co) was down:

HTTP code: 500
Response time: 2739 ms

Resolved: Dashboard is back up in c41d994.

repo: mrsz-innovate/status


text:
update packages at packagecloud

Can you include .deb files for updated distros like ubuntu:xenial?
regards

Sure! The code that pushes packages is here. If you want to send a PR, I'm happy to merge it. The .debs that are being pushed are all identical at the moment, so the existing ones should work as well. But please open an issue if something is broken there.

authors: felipejfc mrtazz

repo: mrtazz/restclient-cpp


text:
mrb_read_irep missing which accepts a dynamic dump

As far as i can see, mrb_read_irep excepts a memory region which won't get freed as long as the irep exists.
mrb_read_irep_file doesn't have that limitation, it calls read_irep with the FLAG_SRC_MALLOC flag.
How should such a function be named? Would send a PR for it.

Found a solution, etext and edata are different on macOS, will send a PR for it.

repo: mruby/mruby


text:
downgrade jquery to version 2.2.4 as bootstrap need a version lower t…

This will solve #90

You are correct, I never noticed that.
Did you see any issues with using jQuery 3.x?

Yes, every thing related to bootstrap is not working.
On the console you will find an error like this one:
bootstrap.min.js:6 Uncaught Error: Bootstrap's JavaScript requires jQuery version 1.9.1 or higher, but lower than version 3

I never noticed it. Thanks for contributing.

Not at all.

authors: mrvautin ziedmahdi

repo: mrvautin/adminMongo


text:
fmWorkMate: overwrites the current chosen FileMaker when it starts

When fmWorkMate starts, on of the selected FileMakers gets overwritten. (Need to check which one)

Fixed in next version

repo: mrwatson-de/fmWorkMate


text:
DeleteTradeAsync throws {"code":-1102,"msg":"Mandatory parameter 'symbol' was not sent, was empty/null, or malformed."}

TradeResponse testTradeResponse = await binanceApi.LimitOrderAsync("BLZBNB", Binance.NetCore.Entities.Side.BUY, 145, 0.001779M);
CancelTradeParams testCancelTradeParams = new CancelTradeParams()
{
timestamp = testTradeResponse.transactTime,
orderId = testTradeResponse.orderId,
type = testTradeResponse.type.ToString(),
origClientOrderId = testTradeResponse.clientOrderId,
symbol = testTradeResponse.symbol
};
TradeResponse traderesponse =await binanceApi.DeleteTradeAsync( testCancelTradeParams);
The moment I'm trying to call the DeleteTradeAsync method it gives an error that i'm not passing the symbol. Even tough I am
{"code":-1102,"msg":"Mandatory parameter 'symbol' was not sent, was empty/null, or malformed."}

@JelleGeers Did you find any solution, I'm having the same problem.
Thanks.


text:
🛑 Do53 Roost IPv6 TCP is down

In dc68f16, Do53 Roost IPv6 TCP (http://107.189.10.142:9205) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv6 TCP is back up in 9b6aa72 after 9 minutes.

repo: mschirrmeister/upptime-loopx


text:
🛑 Do53 Roost IPv6 UDP is down

In 0bfa548, Do53 Roost IPv6 UDP (http://107.189.10.142:9204) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv6 UDP is back up in 9217132 after 48 minutes.


text:
🛑 Do53 Roost IPv4 UDP is down

In 3f997da, Do53 Roost IPv4 UDP (http://107.189.10.142:9202) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv4 UDP is back up in cff6c60 after 15 minutes.


text:
🛑 Do53 Roost IPv4 UDP is down

In b490d36, Do53 Roost IPv4 UDP (http://107.189.10.142:9202) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Do53 Roost IPv4 UDP is back up in 993831d after 27 minutes.


text:
Unable to obtain LHOTSE Toolbox from  www.kyb.tuebingen.mpg.de/bs/people/seeger/lhotse/

I hope to use the LHOTSE toolbox in Bayesian Inference and Optimal Design for the Sparse Linear Model, but the link is invalid.

Could you share the LHOSTE toolbox  for research?

repo: mseeger/apbsint


text:
Having trouble with login via command line parameters

Hi, I noticed you recently implemented the .token file for stateful logins, but I'm having trouble using the command-line parameters -u and -p. I'm trying this because sampleStreaming.js doesn't seem to work with the .token file (I'll open a separate issue).  If I specify -u and -p for one of the examples, like odometer.js, I get the following output:
F:\projects\teslajs\node_modules\teslajs\Examples\sampleFramework.js:34
        if (result.error) {
                  ^

TypeError: Cannot read property 'error' of null
    at SampleFramework.login_cb (F:\projects\teslajs\node_modules\teslajs\Exampl
es\sampleFramework.js:34:19)
    at Request._callback (F:\projects\teslajs\node_modules\teslajs\TeslaJS.js:18
9:9)
    at Request.self.callback (F:\projects\teslajs\node_modules\teslajs\node_modu
les\request\request.js:186:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:192:7)
    at Request.<anonymous> (F:\projects\teslajs\node_modules\teslajs\node_module
s\request\request.js:1081:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:189:7)
    at IncomingMessage.<anonymous> (F:\projects\teslajs\node_modules\teslajs\nod
e_modules\request\request.js:1001:12)
    at Object.onceWrapper (events.js:291:19)

It looks like login_cb in function SampleFramework. is only expecting (result) as a parameter.
function login however is invoking the callback as:
callback(error, { error: error, response: response, body: body, authToken: authToken });

I'm thinking the line in sampleFramework.js should be
this.login_cb = function (error, result) {

Is this work in progress or do I have something wrong?
I installed the latest from npm but according to package.json I have version 2.1.7.  Thanks.

Additional: I deleted teslajs and reinstalled from npm, and now I have verison 2.1.10.  I thought npm update would have updated it to the latest version?

@TrevorPT npm update will update your dependencies to the latest version following the semver rules in your project's package.json file.  Have you created your own project using npm init followed by npm install teslajs --save?

@TrevorPT I'll take a look at the streaming sample.  It is possible that something that changed with a prior refactoring broke the sample and went unnoticed.

@TrevorPT Thanks for reporting this, I've found an issue with the simpleStreaming sample that was a left-over from migrating to the new sample framework.  I am working on a fix right now and should have this checked in shortly.

@TrevorPT OK, fix checked in 2.1.11.  The .token file to cache the OAuth token has been around from the beginning.  The streaming API works differently than other API's.  It takes a token that is returned from the call to enumerate vehicle information.  This token is used as the "password" and is paired with the username.

@mseminatore - thanks! I'll give it another try with the update and continue with the streaming thread in #61.  Regarding my question about using npm to update, I'm embarrassed to say I should've known as (believe it or not) I've used npm before! I'm still just playing with the examples but I keep thinking of TeslaJS as the project, not as a module, so please excuse the thoughtless questions!

authors: TrevorPT mseminatore

repo: mseminatore/TeslaJS


text:
🛑 Night Tailchat - Server is down

In 281e681, Night Tailchat - Server (https://paw-server-test.moonrailgun.com/api/gateway/health) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Night Tailchat - Server is back up in 167753a.

repo: msgbyte/status


text:
Fix typo in README.md

summariztion -> summarization

What is this?
Not sure what to do with this message.
Sent from my iPhone

On Mar 28, 2024, at 11:04 AM, rajakumar05032000 @.***> wrote:

@rajakumar05032000 approved this pull request.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

authors: JKDALIVE eltociear

repo: mshumer/gpt-author


text:
Menu Rekap Absensi

penambahan laman serta fungsi pada menu rekap absensi, lagi digodok dulu mau model lamannya kek apa

palingan perbulan ditampilinnya


text:
🛑 CoreEM is down

In 6cea36d, CoreEM (https://coreem.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CoreEM is back up in 90f0d5e after 10 minutes.

repo: mswd-io/upptime


text:
fix(ClientRequest): handle Headers without internal symbol

Fixes https://github.com/mswjs/msw/actions/runs/10956113682/job/30421449419?pr=2293

Changes

Add handling for situations when a Headers instance has been constructed before the interceptor started recording the raw headers. Previously, threw this error:

TypeError: inferRawHeaders(...) is not iterable (cannot read property undefined)

We were trying to ...inferRawHeaders() on a Headers instance that had no kRawHeaders symbol set (the recording hasn't started yet).

Released: v0.35.8 🎉
This has been released in v0.35.8!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.

repo: mswjs/interceptors


text:
fix: update regex pattern to allow hyphen(-)

Description
Allow regex pattern to accept hyphen for matchLabels field in monitoring/metricsFederation.

can be closed in favor of #331

repo: mt-sre/managed-tenants-cli


text:
chore: overhauled ESLint config

What type of PR is this? (check all applicable)

[x] ♻ Refactor
[ ] ✨ Feature
[ ] 🐛 Bug Fix
[ ] 👷 Optimization
[ ] 📝 Documentation Update
[ ] 🔖 Release
[ ] 🚩 Other

Description
Resets the ESLint config by:

Having it extend from typescript-eslint's recommended configurations
Disabling any rules that have complaints which would require non-trivial code changes to fix
Fixing remaining violations complaints (most of which were auto-fixable)

Fixes #312
Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 readme
[x] 🙅 no documentation needed

[optional] What gif best describes this PR or how it makes you feel?

@JoshuaKGoldberg did you already run ‘npm run all’ leading up to the commits? I haven’t checked this locally, I’m just curious. Depending on how the compile step handles changes to *.ts, there should be changes in the “dist” directory.

Ah sorry, I forgot that was needed in this repo - done!

Thanks for the PR!

authors: JoshuaKGoldberg mtfoley

repo: mtfoley/pr-compliance-action


text:
Custom taxonomy?

Hello, awesome update, loving the speed!
Not really an issue per se, but I have a hmmscan database that I would like to use preferentially for taxonomy calls. It's not a comprehensive database, so ideally this would be used first, and whatever genomes aren't called by the database should still go through the included databases.
What can I do to make that happen?
Paul

Hi Paul,
Thanks for you kind comments!
What you are asking for sounds like a whole new thing. Currently, taxonomy calls in Cenote-Taker 3 are made by mmseqs2 search (blastp-style) of hallmark genes to a taxonomically-labeled protein database.
Doing a similar task with hmms (presumably from MSAs of several proteins) would be complicated from a taxonomical labelling standpoint.
If you could devise a detailed scheme about how this might work, you could submit a reply here and I could consider it in future updates if I think it would add a lot of value. To be honest, I've gone through a long stretch of adding features and fixing bugs on this tool, and, in the near future, I'm mostly going to be doing updates to fix bugs and update databases.
Sorry I coudn't be more positive at this time.
Mike

Hmm, I'm not stuck on using hmms.
Is it possible to include custom taxonomy through regenerating the mmseqs database by adding my proteins to refseq_virus_prot.fasta and ct3_hallmark_nr_cd90_refseq.prot_taxids.mmseqs_fmt.tsv? I suppose it would be missing another step where taxon id is linked to a taxon name somehow, can't find that file.

Hey Paul,
So, yes, in theory you could add NCBI-derived amino acid sequences to ct3_hallmark_nr_cd90_refseq.faa and the corresponding accession + taxID to ct3_hallmark_nr_cd90_refseq.prot_taxids.mmseqs_fmt.tsv then run these commands and replace the typical database files. I can't officially recommend it:
mmseqs createdb ct3_hallmark_nr_cd90_refseq.faa hallmark_taxdb/ct3_hallmark.taxDB

mmseqs createtaxdb hallmark_taxdb/ct3_hallmark.taxDB tmp --tax-mapping-file ct3_hallmark_nr_cd90_refseq.prot_taxids.mmseqs_fmt.tsv

Keep in mind that only the CT3-identified hallmark genes are queried against the taxDB, and barring some fancy work with taxonkit, you have to use NCBI-derived sequences in order to get associated taxonomy.

I can make that work for now, thanks!


text:
🛑 https://hcie.ps is down

In 24e2f75, https://hcie.ps (https://hcie.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://hcie.ps is back up in 89b7fdd.

repo: mtitservice/site


text:
🛑 https://db.hcys.ps is down

In 50b3224, https://db.hcys.ps (https://db.hcys.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://db.hcys.ps is back up in 9f97cfe.


text:
🛑 https://911.ps is down

In 1092912, https://911.ps (https://911.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://911.ps is back up in 1b2c54d.


text:
🛑 https://reports.mtit.pna.ps is down

In 5d6b574, https://reports.mtit.pna.ps (https://reports.mtit.pna.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://reports.mtit.pna.ps is back up in e43c109.


text:
🛑 https://palpost.ps is down

In 326507c, https://palpost.ps (https://palpost.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://palpost.ps is back up in d23e084.


text:
🛑 https://minfo.ps is down

In f8e7538, https://minfo.ps (https://minfo.ps) was down:

HTTP code: 0
Response time: 0 ms

Resolved: https://minfo.ps is back up in 66c2cc3.


text:
bugfix: MSSQL top-level databases

Fix for  #714.
Only show the database defined in the setup of MSSQL database connection.
This may also be an issue with MySQL.

closing in favor of #938

authors: bherbruck mtxr

repo: mtxr/vscode-sqltools


text:
removed nested directory

Removed the nested empty github directory.

Verified removal of submodule.

authors: AdamG-L pwfreedm


text:
Issue with fixing audio issues in Zorin

Hello,
I'm a newer linux user and I've recently gotten cozy with Zorin. But Zorin 17.1 is based on Ubuntu 22.04 and doesn't come with WirePlumber, it uses PulseAudio. Apparently PipeWire is partially installed on Zorin as it is based. I'm not sure how to get the audio fix to work with Zorin. If anyone could assist me with this I would appreciate it!

Read Archwiki
https://wiki.archlinux.org/title/WirePlumber


text:
Is the project still maintained?

Hi, is the project still under maintenance? There are issues open from 2019 and perfectly reasonable and needed pull requests still waiting to be merged. For example #54 is essential to use clipp in C++20 projects. Is this project still alive?

The original maintainer doesn't seem to have the time to update it, perhaps check out https://github.com/GerHobbelt/clipp which seems more up to date with community fixes.

@muellan: do you intend to pick up maintenance of this library again? if not, i'd propose that @gerhobbelt's fork is used e.g. in vcpkg.

authors: DominikGrabiec nicola-gigante rursprung

repo: muellan/clipp


text:
Performance improvements in SHAPInterpretation

I removed link keyword argument as it wasn't used and was preventing to pass this keyword to SamplingExplainer. T
The new max_train_samples limits train data. Example: Rossmann dataset with 800k rows needs almost 24h to compute 128 shap values. However, if you limit to 100k (default value) takes 82s per test sample (around 2h30) and 10k rows takes 8,2s per test sample (around 20min).

That does sound much more reasonable, thanks!

repo: muellerzr/fastinference


text:
Fix for malformated mobile signing button

the "Sign In" still isn't centered and I couldn't fix that

🤔?

the "Sign In" still isn't centered and I couldn't fix that

its works by displaying center 🤔?

I could not center the <a ...>Sign In inside of the button. Ir you look closely the text itself seems to be more to the left than to the right.

the "Sign In" still isn't centered and I couldn't fix that

its works by displaying center 🤔?

I could not center the <a ...>Sign In</a> inside of the button. Ir you look closely the text itself seems to be more to the left than to the right.

that may be due to the css/scss styles that have been assigned the component which overrides the tailwindcss

authors: grethler muhammad-fiaz

repo: muhammad-fiaz/portfolio


text:
Add SDK/vx.y.z tag for Go package use

For use with Go, an extra tag prefix of SDK is expected by Pulumi for the Go SDK to work.
Example here: https://github.com/pulumi/pulumi-opsgenie/tags

tag for v2.0.0 created
added automated tagging into release pipeline (https://github.com/muhlba91/pulumi-proxmoxve/blob/main/.github/workflows/release.yml#L233)

please verify and close the issue.


text:
Error: Minified React error #44; visit http://facebook.github.io/react/docs/error-decoder.html?invariant=44 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

Environment

Tech
Version

Material-UI
1.0.0-beta.30

React
16.2.0

browser
chrome

Current Bug

In production mode i have this error happening because of the ripple effect on the Buttons. In development mode it's working perfectly.
I thought it was a minifying problem but i checked my webpack configuration for Uglify and it seems to be good:
        new webpack.optimize.UglifyJsPlugin({
            sourceMap: process.env.NODE_ENV === 'production',
            parallel: process.env.NODE_ENV === 'production',
            compress: {
                warnings: false,
                drop_console: false,
            }
        }),

When i click on a Button with the effect i got this error in the console :
Error: Minified React error #44; visit http://facebook.github.io/react/docs/error-decoder.html?invariant=44 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at r (reactProdInvariant.js:29)
    at Object.r [as findDOMNode] (findDOMNode.js:51)
    at t.updateStatus (Transition.js:212)
    at t.componentDidMount (Transition.js:157)
    at commitLifeCycles (react-dom.production.min.js:149)
    at t (react-dom.production.min.js:158)
    at M (react-dom.production.min.js:169)
    at b (react-dom.production.min.js:168)
    at batchedUpdates (react-dom.production.min.js:171)
    at Q (react-dom.production.min.js:54)

I found that Transition.js is the problem and it happens only when i click on a Button, so i deduce that it should be the ripple effect.
If you have questions ?

I had the same problem and i didn't solve it :/ I had to do the ripple effect on myself.

A reproduction example would help.

@squelix out of curiosity, are you using yarn? If you are, try for an experiment: rm -r node_modules; npm install and see if that fixes it.

Tonight I made an attempt to reproduce this tonight with a clean repo, but I failed.
After a lot of experimentation, I isolated the problem down to one library which was pulling in an older version of React, so I had two React versions in my node_modules. I attempted to reproduce this in a clean project by bringing in the same dependency, but couldn't get it to happen. It's something about the way my dependencies are being installed that's causing the issue. Strange.
My solution was to add a resolutions section to my package.json to force a single React version across all my dependencies:
"resolutions": {
  "react": "^16.2.0",
  "react-dom": "^16.2.0"
}

It's a bit of a mystery why I couldn't reproduce this in a separate project.
After all that, I git reset --hard and tried an rm -r node_modules; npm install and that also worked. So I think the conclusion is: multiple React versions bad.

authors: jagregory oliviertassinari squelix

repo: mui-org/material-ui


text:
Add official support for createStyled?

I was wondering if this library could provide (or if it already does) a component that would allow to use styles with a render prop pattern, instead of the withStyles HOC.
I searched for it, and the best I could find was this, but that's not quite what I would've expected. That option would need users of this api to create a new component every time:
import { createStyled } from '???';

const Styled = createStyled({ /* styles go in here */ })

// It is supposed to be used like this:
render() {
  return (
    <Styled>
      {({ classes }) => (
        // render your thing here
      )}
    </Styled>
  );
}

I wonder if it would be a bit better or even possible to have a generic component that receives styles and provides classes, instead of having to create one component tied to specific styles:
// would be something provided by this lib
import Styled from 'material-ui/Styled';

const styles = { /* styles go in here */ }

// Then use it like this:
render() {
  return (
    <Styled styles={styles}>
      {({ classes }) => (
        // render your thing here
      )}
    </Styled>
  );
}

Also, as a side note, even if this suggestion is not accepted, I wonder why the createStyled helper is not provided as an export of this library, just as withStyles is.

@gnapse Is it a duplicate of #7633?

@gnapse Ok thanks. Going back to your suggestion.
I fear the Styled component has to be created outside of the render method so the CSS injection order is correct. It's a technical limitation. I can't think of a simple workaround. You will find styled-components relying on the same solution.

Ok, yes, I totally get it.
Now again, back to my fallback suggestion here: why createStyled (as it appears here) isn't provided by this library out of the box, just as withStyles is?

why createStyled (as it appears here) isn't provided by this library out of the box, just as withStyles is?

@gnapse The initial motivation was: it's working, but it's an extra API to support. Let's document it and see how it's used in the wild. Now, as people start using it and rely on it in production with no issue, I'm more confidence integrating it into the core. I have no real objection to it. It just hasn't been a priority so far. You know, extending the API comes with overhead: documentation, tests, maintaince.

Yes, sure. I get your point. Thanks for your input on this.

@gnapse I'm reopening as it's a good question. I don't have a definitive answer.

@jcoreio Has published the package under https://github.com/jcoreio/material-ui-render-props-styles. Maybe we could document it?

I have added material-ui-render-props-styles of @jedwards1211 in the documentation with #11983. This should do it for now :).

Awesome, thanks!  I guess I don't get notifications for jcoreio for some reason

Let me know if you want to move it to the @material-ui npm organization.

@jedwards1211 Sure, I will let you know if we want to move the project into the npm organization.

This is awesome. Thanks!

Just an FYI - @oliviertassinari we had a createStyled as part of our internal ui lib, reused in several apps.  It presents load order issues, but copying the createStyled.ts to the app src alleviates the issue.  Definitely a tricky one.  I am not sure how the linked project could be making this work - I suspect it will have the same potential problem.

authors: gnapse jedwards1211 oliviertassinari rosskevin


text:
Support Banner Component

Hi,
If I am not mistaken there's no current support for the banner component:
https://material.io/design/components/banners.html#
https://material.io/design/components/banners.html#anatomy
If it is not supported, are you planning to do it?
If it is provided, could you point me to its documentation?
Thanks and keep up the fantastic work!

I just noticed this as well.
Until  a Banner Component is supported, what would be the best "work around" ,
maybe just a  Paper that moves in, and contains some actions?

what would be the best "work around" ,
maybe just a Paper that moves in, and contains some actions?

@AirborneEagle Here is an idea. I hope that help. It's inspired by our custom Grid demo: https://material-ui.com/layout/grid/#complex-grid.

import React from "react";
import PropTypes from "prop-types";
import { withStyles } from "@material-ui/core/styles";
import Grid from "@material-ui/core/Grid";
import CssBaseline from "@material-ui/core/CssBaseline";
import Paper from "@material-ui/core/Paper";
import Avatar from "@material-ui/core/Avatar";
import Divider from "@material-ui/core/Divider";
import SignalWifiOffIcon from "@material-ui/icons/SignalWifiOff";
import Typography from "@material-ui/core/Typography";
import Button from "@material-ui/core/Button";

const styles = theme => ({
  paper: {
    padding: `${theme.spacing.unit * 2}px ${theme.spacing.unit}px ${
      theme.spacing.unit
    }px ${theme.spacing.unit * 2}px`
  },
  avatar: {
    backgroundColor: theme.palette.primary.main
  }
});

function Banner(props) {
  const { classes } = props;
  return (
    <React.Fragment>
      <Paper elevation={0} className={classes.paper}>
        <Grid container spacing={16} alignItems="center">
          <Grid item>
            <Avatar className={classes.avatar}>
              <SignalWifiOffIcon />
            </Avatar>
          </Grid>
          <Grid item>
            <Typography>
              You have lost connection to the internet. This app is offline.
            </Typography>
          </Grid>
        </Grid>
        <Grid container justify="flex-end" spacing={8}>
          <Grid item>
            <Button color="primary">Turn on wifi</Button>
          </Grid>
        </Grid>
      </Paper>
      <Divider />
      <CssBaseline />
    </React.Fragment>
  );
}

Banner.propTypes = {
  classes: PropTypes.object.isRequired
};

export default withStyles(styles)(Banner);

https://codesandbox.io/s/oj1mzjmk06

I had to implement this in one of my projects and couldn't really find anything that fit the material design spec, so I've published the components I made: https://github.com/alexplumb/material-ui-banner

@alexplumb Thanks for sharing.

Do you have to add an example in the documents? It is not clear to me.

@vicasas I have updated my original comment to use v5. As for the best next step, I don't know. It seems trivial to implement with the system.  would propose we close

@oliviertassinari If it is part of material design, shouldn't we have it the same? Even though it can be done with other components, I feel that it should exist as a quick-use component.
Developers will not want to spend time styling according to material design, they will wait for a solution delivered by MUI. As for example in Vuetify https://next.vuetifyjs.com/en/components/banners/

@vicasas There isn't any specific about it

authors: AirborneEagle MastroLindus alexplumb oliviertassinari vicasas


text:
Unable to npm install @material-ui/core on Windows 10

I'm attempting to run npm install @material-ui/core.  The installation is failing.

[x ] This is not a v0.x issue.
[x ] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔
The module should install successfully.
Current Behavior 😯
Attempting to install @material-ui/core on Windows 10, with npm 6.4.1:
D:\gitrepo\clevyr\Edx.Net\Edx.FrontEnd> node -v
v10.15.3
D:\gitrepo\clevyr\Edx.Net\Edx.FrontEnd> npm -v
6.4.1
D:\gitrepo\clevyr\Edx.Net\Edx.FrontEnd> npm install @material-ui/core

> jss@9.8.7 postinstall D:\gitrepo\clevyr\Edx.Net\Edx.FrontEnd\node_modules\jss
> node -e "console.log('\u001b[35m\u001b[1mLove JSS? You can now support us on open collective:\u001b[22m\u001b[39m\n > \u001b[34mhttps://opencollective.com/jss/donate\u001b[0m')"

[eval]:1
console.log('\u001b[35m\u001b[1mLove
            ^^^^^^^^^^^^^^^^^^^^^^^^

SyntaxError: Invalid or unexpected token
    at new Script (vm.js:80:7)
    at createScript (vm.js:274:10)
    at Object.runInThisContext (vm.js:326:10)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at evalScript (internal/bootstrap/node.js:589:27)
    at startup (internal/bootstrap/node.js:265:9)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

Steps to Reproduce 🕹
-Install node v10.15.3 & npm 6.4.1 on Windows 10
-npm init a new project
-npm install @material-ui/core
Context 🔦
I am attempting to install and use @material-ui/core.
Your Environment 🌎
Windows 10
node v10.15.3
npm 6.4.1

Looks like cssinjs/jss#982. If you can't resolve the issue with the help from that issue please open a new one in cssinjs/jss.


text:
Typescript error when setting CardActionArea's component property

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

The CardActionArea component should accept an AdapterLink component in the same way the Button component does, as stated here: https://material-ui.com/components/buttons/#third-party-routing-library
Current Behavior 😯

TypeScript gives the following type error when using the same AdapterLink example from the Button documentation:
main.tsx:10:11 - error TS2322: Type '{ component: ForwardRefExoticComponent<LinkProps & RefAttributes<HTMLAnchorElement>>; }' is not assignable to type 'IntrinsicAttributes & { action?: ((actions: ButtonBaseActions) => void) | undefined; buttonRef?: ((instance: unknown) => void) | RefObject<unknown> | null | undefined; centerRipple?: boolean | undefined; ... 6 more ...; TouchRippleProps?: Partial<...> | undefined; } & { ...; } & CommonProps<...> & Pick<...>'.
  Property 'component' does not exist on type 'IntrinsicAttributes & { action?: ((actions: ButtonBaseActions) => void) | undefined; buttonRef?: ((instance: unknown) => void) | RefObject<unknown> | null | undefined; centerRipple?: boolean | undefined; ... 6 more ...; TouchRippleProps?: Partial<...> | undefined; } & { ...; } & CommonProps<...> & Pick<...>'.

10   return <CardActionArea component={AdapterLink} />
             ~~~~~~~~~~~~~~

Steps to Reproduce 🕹

Link: cardactionarea-type-bug.tar.gz

Decompress the attached example, and
yarn install && yarn test

Context 🔦

I was trying to use a react-router-dom Link as the component for a CardActionArea to create the navigation for my website.
Your Environment 🌎
All the package versions are locked in the yarn.lock file provided in the attachment. For the sake of clarity, I'm replicating the versions from the package.json here:

Tech
Version

@material-ui/core
^4.0.2

@types/node
^12.0.4

@types/react-router-dom
^4.3.3

react-router-dom
^5.0.0

typescript
^3.5.1

Are you wrapping CardActionArea in a higher-order component?

@eps1lon no, the code from the attached example is just the following:
import React from "react"
import { CardActionArea } from "@material-ui/core"
import { Link, LinkProps } from "react-router-dom"

const AdapterLink = React.forwardRef<HTMLAnchorElement, LinkProps>((props, ref) => (
  <Link innerRef={ref as any} {...props} />
));

export function Foo() {
  return <CardActionArea component={AdapterLink} />
}

This was fixed in v4.0.2, basically the Typescript error is not clear, it should say that you are missing the to prop inferred from the Link component that you assign.
<CardActionArea
  component={AdapterLink}
  to='/some-route'
/>

Also, I've started using the Link component directly into component prop and it works fine, although  I am not sure if it is the preferred pattern, for example:
import { Link } from 'react-router-dom'

<CardActionArea
  component={Link}
  to='/some-route'
/>

@eddedd88 Yeah, I was debugging right now and found out that upgrading to 4.0.2 fixed the issue. Thanks!

It’s always nice when we have coincidentally fixed the problem already. 🎉


text:
[next.js] cache.compat = true causing components flick when they are out outside the  in production mode

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

https://github.com/mui-org/material-ui/blob/fd0664449604a390c6cebbcc5693bb3c934be52e/examples/nextjs/pages/_app.js#L11
https://github.com/mui-org/material-ui/blob/fd0664449604a390c6cebbcc5693bb3c934be52e/examples/nextjs/pages/_document.js#L10
this happens when the page starts loading

Expected Behavior 🤔

Steps to Reproduce 🕹

Live example
app.js
const cache = createCache({ key: "css", prepend: true });
cache.compat = true

export default function MyApp(props) {
  const { Component, pageProps } = props;
  return (
    <CacheProvider value={cache}>
      <Head>
        <title>My page</title>
        <meta name="viewport" content="initial-scale=1, width=device-width" />
      </Head>
      <ThemeProvider theme={theme}>
        {/* CssBaseline kickstart an elegant, consistent, and simple baseline to build upon. */}
        <CssBaseline />
        <Paper sx={{ backgroundColor: "limegreen", width: "100%", height: 250 }}> {/* here */}
          <TextField placeholder="test placeholder" />
        </Paper>
        <Component {...pageProps} />
      </ThemeProvider>
    </CacheProvider>
  );
}

Steps:

Clone example nextjs repository
Place any Material-UI component outside the <Component /> in _app.js
Keep clicking on the browser's hit refresh button

Context 🔦
this happens in production mode

Your Environment 🌎
"@material-ui/core": "^5.0.0-alpha.38",
"@emotion/react": "^11.4.0",
"@emotion/server": "^11.4.0",
"@emotion/styled": "^11.3.0",
"next": "^11.0.1",

I encountered this issue a couple days ago. I would recommend changing the _document's getInitialProps to enhance the entire app rather than each page component. This allows CSSBaseline and other component styles that are outside <Component {...pageProps} /> to be rendered on the server as well.
_app.jsx (Remove the Cache Provider)
export default function MyApp(props) {
  const { Component, pageProps } = props;
  return (
    <>
      <Head>
        <title>My page</title>
        <meta name="viewport" content="initial-scale=1, width=device-width" />
      </Head>
      <ThemeProvider theme={theme}>
        {/* CssBaseline kickstart an elegant, consistent, and simple baseline to build upon. */}
        <CssBaseline />
        <Paper sx={{ backgroundColor: "limegreen", width: "100%", height: 250 }}> {/* here */}
          <TextField placeholder="test placeholder" />
        </Paper>
        <Component {...pageProps} />
      </ThemeProvider>
    </>
  );
}

_document.jsx
MyDocument.getInitialProps = async (ctx) => {
  const originalRenderPage = ctx.renderPage;
  const cache = createCache({ key: "css", prepend: true });
  cache.compat = true;
  const { extractCriticalToChunks } = createEmotionServer(cache);

  // Wrap the entire app in the cache provider. This is used
  // instead of enhanceComponent.
  ctx.renderPage = () =>
    originalRenderPage({
      enhanceApp: (App) => (props) =>
        (
          <CacheProvider value={cache}>
            <App {...props} />
          </CacheProvider>
        ),
    });

  const initialProps = await Document.getInitialProps(ctx);
  const emotionStyles = extractCriticalToChunks(initialProps.html);
  const emotionStyleTags = emotionStyles.styles.map((style) => {
    return (
      <style
        data-emotion={`${style.key} ${style.ids.join(" ")}`}
        key={style.key}
        dangerouslySetInnerHTML={{ __html: style.css }}
      />
    );
  });
  return {
    ...initialProps,
    styles: [
      ...React.Children.toArray(initialProps.styles),
      ...emotionStyleTags,
    ],
  };
};

_app.jsx (Remove the Cache Provider)

Removing the CacheProvider from _app.js or cache.compat = true the following error appears on the console:
The pseudo class ":first-child" is potentially unsafe when doing server-side rendering. Try changing it to ":first-of-type".

I get that same error in development too, but only when I use the Tabs component (because it uses :first-child). See this issue. If you aren't using a Tabs component, then I'd report which component is throwing the console error. Either way, this bug is way smaller than the previous one as it only exists in development and this implementation does resolve the layout the thrash.

@ellcrev Agree, it's what we were doing for v4. In v5, we started to diverge:
https://github.com/mui-org/material-ui/blob/14d95615dd0b31c616abb760a29ec30a8fa9005f/examples/nextjs/pages/_document.js#L56-L59

Similar issue reported in https://github.com/mui-org/material-ui/issues/27045
The same changes proposed here are fixing the issue. @oliviertassinari should we also remove cache.compat from the examples we have?

What about this solution? It works ok for me.
_document.js
const getCache = () => {
  const cache = createCache({ key: "css", prepend: true });
  cache.compat = true;

  return cache;
};

export const cache = getCache();

_app.js
import { cache } from "./_document";

@mnajdova The integration example we have with Next.js is indeed wrong. However, it's more wrong than I thought. The first solution I have proposed didn't take into account #27045. This seems to work correctly:
diff --git a/examples/nextjs/pages/_app.js b/examples/nextjs/pages/_app.js
index f668d7dca4..abfe3367ab 100644
--- a/examples/nextjs/pages/_app.js
+++ b/examples/nextjs/pages/_app.js
@@ -11,9 +11,11 @@ const cache = createCache({ key: 'css' });
 cache.compat = true;

 export default function MyApp(props) {
-  const { Component, pageProps } = props;
+  const { Component, disableEmotionCache = false, pageProps } = props;
+  const Wrapper = disableEmotionCache ? React.Fragment : CacheProvider;
+
   return (
-    <CacheProvider value={cache}>
+    <Wrapper {...disableEmotionCache ? {} : { value: cache }}>
       <Head>
         <title>My page</title>
         <meta name="viewport" content="initial-scale=1, width=device-width" />
@@ -23,11 +25,12 @@ export default function MyApp(props) {
         <CssBaseline />
         <Component {...pageProps} />
       </ThemeProvider>
-    </CacheProvider>
+    </Wrapper>
   );
 }

 MyApp.propTypes = {
   Component: PropTypes.elementType.isRequired,
+  disableEmotionCache: PropTypes.bool,
   pageProps: PropTypes.object.isRequired,
 };
diff --git a/examples/nextjs/pages/_document.js b/examples/nextjs/pages/_document.js
index ed1c84b1e1..1e04c81db9 100644
--- a/examples/nextjs/pages/_document.js
+++ b/examples/nextjs/pages/_document.js
@@ -65,10 +65,10 @@ MyDocument.getInitialProps = async (ctx) => {
   ctx.renderPage = () =>
     originalRenderPage({
       // Take precedence over the CacheProvider in our custom _app.js
-      enhanceComponent: (Component) => (props) =>
+      enhanceApp: (App) => (props) =>
         (
           <CacheProvider value={cache}>
-            <Component {...props} />
+            <App disableEmotionCache {...props} />
           </CacheProvider>
         ),
     });

@oliviertassinari With these changes, my styles are still not working properly. If my initial page load is / the next page /a (client rendered) has the proper appearance (style order I'm guessing). If I reload /a the rendered page (server rendered) has an improper appearance. I haven't been able to confirm out of order styles, but the evidence seems to point to this. None of the options from master, canary, or this thread are working.

@paynecodes we can't act on this feedback. We have no reproductions, we can only ignore it.

@oliviertassinari Understood. I'm struggling to reproduce this issue because that app setup is quite complex within a monorepo. In fact, I think this may be the reason it's happening. Emotion's extractCriticalToChunks doesn't appear to be pulling out the style tags in the initialProps.html string as there are <style data-emotion="css someid"> littered all throughout the <body> tag in the static markup build output.
In any case, for now, this is just a clue and further confirmation that next.js / emotion / material-ui is broken in unknown ways.

Is there even documentation for cache.compat on emotions side? We should make sure this is actually a public API that's used as intended.

Is there even documentation for cache.compat on emotions side?

@eps1lon Great point. You are right, it's not documented, and it's useless. emotion turns already automatically the flag to true. We don't need to care.
So we can simplify https://github.com/mui-org/material-ui/issues/26957#issuecomment-877847384 and remove cache.compat everywhere.:
diff --git a/docs/pages/_document.js b/docs/pages/_document.js
index e99d358d82..01fb064c59 100644
--- a/docs/pages/_document.js
+++ b/docs/pages/_document.js
@@ -10,9 +10,7 @@ import { pathnameToLanguage } from 'docs/src/modules/utils/helpers';
 import createCache from '@emotion/cache';

 function getCache() {
-  const cache = createCache({ key: 'css', prepend: true });
-  cache.compat = true;
-  return cache;
+  return createCache({ key: 'css', prepend: true });
 }

 const defaultTheme = createTheme();
diff --git a/docs/src/pages/guides/server-rendering/server-rendering.md b/docs/src/pages/guides/server-rendering/server-rendering.md
index 77853af4c0..f8fb4ec53a 100644
--- a/docs/src/pages/guides/server-rendering/server-rendering.md
+++ b/docs/src/pages/guides/server-rendering/server-rendering.md
@@ -98,9 +98,7 @@ For this, we need to share the same cache configuration for both the client and
 import createCache from '@emotion/cache';

 export default function getCache() {
-  const cache = createCache({ key: 'css' });
-  cache.compat = true;
-  return cache;
+  return createCache({ key: 'css' });
 }
 ```

diff --git a/examples/nextjs/pages/_document.js b/examples/nextjs/pages/_document.js
index e562aeec4a..e712dc012e 100644
--- a/examples/nextjs/pages/_document.js
+++ b/examples/nextjs/pages/_document.js
@@ -72,6 +72,8 @@ MyDocument.getInitialProps = async (ctx) => {
     });

   const initialProps = await Document.getInitialProps(ctx);
+  // This is important. It prevents emotion to render invalid HTML.
+  // See https://github.com/mui-org/material-ui/issues/26561
   const emotionStyles = extractCriticalToChunks(initialProps.html);
   const emotionStyleTags = emotionStyles.styles.map((style) => (
     <style

authors: DmitryScaletta Lonest90 ellcrev eps1lon mnajdova oliviertassinari paynecodes


text:
[TablePagination] Fix style issue with rpp select

increase padding-right on the Select of the Rows Per Page

closes #14546

[x] I have followed (at least) the PR section of the contributing guide.

@oliviertassinari This is against next, should it be applied to master, too?

@leMaik We keep master for import bug fixes.

authors: antokara leMaik oliviertassinari


text:
[Tabs] Remove unnecessary wrapper from Tab

BREAKING CHANGE

[Tabs] Remove unnecessary wrapper from Tab (#26926) @siriwatknp
span element that wraps children has been removed. wrapper classKey is also removed. More details about this change.
<button class="MuiTab-root">
- <span class="MuiTab-wrapper">
    {icon}
    {label}
- </span>
</button>

WHY the wrapper is removed
button > span > children exists as a workaround for flex container bug on button BUT not anymore, so this PR remove the span.

✅ Chrome 83+ (latest 90)
✅ Safari 11+ (latest 14)
✅ Edge
✅ Firefox 63 (latest 89)

https://github.com/philipwalton/flexbugs#flexbug-9

[x] I have followed (at least) the PR section of the contributing guide.

Preview: https://deploy-preview-26926--material-ui.netlify.app/components/tabs/#icon-tabs

Overall, the changes look good to me 👍

In the realease v5.0.0-beta, you have removed no longer necessary span wrapper in tab buttons. The problem is that the missing span with the MuiTab-wrapper class results in insufficient spacing.
v5.0.0-beta.1 => https://codesandbox.io/s/tab-buttons-v5-nv6c1
v4.12.2 => https://codesandbox.io/s/n5uch

@jmgomezdev This change doesn't lead to any visual change. Aren't you looking for #26458 instead? In any case, it's expected.

Yes, you're right

authors: jmgomezdev mnajdova oliviertassinari siriwatknp


text:
[Joy][Chip] onClick is not working

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Steps:

Go to https://codesandbox.io/s/winter-cloud-2it1xn?file=/demo.js
Try to click on the chip. Nothing happens.
Try to click on the button. It worked.

Current behavior 😯
The handler "onClick" is not triggered when the user clicks on the chip.
Expected behavior 🤔
The handler should be called
Context 🔦
No response
Your environment 🌎

npx @mui/envinfo
 System:
    OS: macOS 12.6
  Binaries:
    Node: 16.13.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 8.1.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 105.0.5195.125
  npmPackages:
    @emotion/react: ^11.10.0 => 11.10.0
    @emotion/styled: ^11.10.0 => 11.10.0
    @mui/base:  5.0.0-alpha.94
    @mui/core-downloads-tracker:  5.10.6
    @mui/icons-material: ^5.10.2 => 5.10.2
    @mui/joy: ^5.0.0-alpha.46 => 5.0.0-alpha.46
    @mui/lab: ^5.0.0-alpha.96 => 5.0.0-alpha.96
    @mui/material: ^5.10.5 => 5.10.5
    @mui/private-theming:  5.10.6
    @mui/styled-engine:  5.10.6
    @mui/styles: ^5.9.3 => 5.9.3
    @mui/system:  5.10.6
    @mui/types:  7.2.0
    @mui/utils:  5.10.6
    @mui/x-data-grid:  5.17.3
    @mui/x-data-grid-pro: ^5.17.3 => 5.17.3
    @mui/x-date-pickers: ^5.0.0-beta.7 => 5.0.0-beta.7
    @mui/x-date-pickers-pro: ^5.0.0-beta.7 => 5.0.0-beta.7
    @mui/x-license-pro: ^5.16.0 => 5.17.0
    @types/react:  18.0.17
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    styled-components: ^5.3.5 => 5.3.5
    typescript:  4.7.4

Even the official example in the doc is not working:
https://mui.com/joy-ui/react-chip/#clickable-and-deletable
Clicking on the delete icons works, but not on the chip itself.

Looks like a bug to me.

authors: olivierkastel siriwatknp

repo: mui/material-ui


text:
Alert severity change doesnt reflect on the styling, the class is applied but no style changes applied

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Steps:

import Alert from MUI
Apply severity
See no changes to the look and feel, inspect element, css-classes applied, however no look and feel changes

Current behavior 😯
When you change the severity of the Alert, it should change the text color, background color, border color. I see the classes being applied .MuiAlert-outlinedInfo, however no styles are applied.
Expected behavior 🤔
When changing the severity, classes should be applied and the required styles.
Context 🔦
I cant complete the customizing of the Alert component for my Design System due to this issue,.
Your environment 🌎
System:
OS: macOS 12.4
Binaries:
Node: 14.17.1 - /usr/local/bin/node
Yarn: 1.22.11 - /usr/local/bin/yarn
npm: 6.14.13 - /usr/local/bin/npm
Browsers:
Chrome: 99.0.4844.84
Edge: Not Found
Firefox: Not Found
Safari: 15.5
npmPackages:
typescript: ^4.4.4 => 4.7.3

@jeshals You tell about a design system: Maybe you're trying to apply a custom theme?
On my side, I have this working, at least for the "root":
const theme = createTheme({
  components: {
    MuiAlert: {
      styleOverrides: {
        root: ({ ownerState }) => ({
          ...(ownerState.severity === "error" &&
            ownerState.variant === "standard" && {
              backgroundColor: "#FCEBE9",
              color: "#751A0C",
            }),
          ...(ownerState.severity === "warning" &&
            ownerState.variant === "standard" && {
              backgroundColor: "#FFF6E5",
              color: "#93541B",
            }),
          ...(ownerState.severity === "info" &&
            ownerState.variant === "standard" && {
              backgroundColor: "#E5F3FB",
              color: "#004B6F",
            }),
          ...(ownerState.severity === "success" &&
            ownerState.variant === "standard" && {
              backgroundColor: "#E6F9ED",
              color: "#006730",
            }),
        }),
        icon: ({ ownerState }) => ({
          ...(ownerState.severity === "error" &&
            ownerState.variant === "standard" && {
              color: "grey",
            }),
          ...(ownerState.severity === "warning" &&
            ownerState.variant === "standard" && {
              color: "#FFAD00",
            }),
          ...(ownerState.severity === "info" &&
            ownerState.variant === "standard" && {
              color: "#008EDB",
            }),
          ...(ownerState.severity === "success" &&
            ownerState.variant === "standard" && {
              color: "#0EC54F",
            }),
        }),
      },
    }
  }
}

But still got an issue:
The "icon" prop gets overriden by .MuiPaper-root-MuiAlert .MuiAlert-icon

As far as I investigated, it seems that .MuiPaper-root-MuiAlert .MuiAlert-icon is calculated based on the palette.
The only way I found was to add a ".MuiAlert-icon" section inside the root, but it feels dirty:
//[...]
      styleOverrides: {
        root: ({ ownerState }) => ({
          ...(ownerState.severity === "error" &&
            ownerState.variant === "standard" && {
              backgroundColor: "#FCEBE9",
              color: "#751A0C",
              /** 🤮 🤮 🤮  **/
              ".MuiAlert-icon": {
                color: "grey",
              },
// [...]

Hope it'll help

Please provide a CodeSandbox reproducing the issue. The issue template is a good starting point. If the issue is reproduced, we can re-open it.

authors: Boimb ZeeshanTamboli jeshals


text:
[material-ui][Table] slots and slotProps documented properties are not exposed in package

Steps to reproduce
Link to live example: (required)
Steps:

install @mui/material-ui@5.15.10
read the TablePagination API documentation for this version and note that slots and slotProps props have a lot of properties e.g. nextButtonIcon

use the TablePagination component in JSX or override style with theme.components.MuiTablePagination.defaultProps properties
note that only actions or select properties are available

Current behavior
only actions or select properties are available on slots and slotProps props (on TablePagination component)
Expected behavior
nextButtonIcon or previousButtonIcon properties are available on slots and slotProps props (on TablePagination component) as mentioned in the web documentation
Context
e.g. override theme.components.MuiTablePagination.defaultProps.slots.nextButtonIcon
Your environment

npx @mui/envinfo
    System:
    OS: Linux 5.10 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
  Binaries:
    Node: 18.18.0 - ~/.nvm/versions/node/v18.18.0/bin/node
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.0/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 120.0.6099.129
  npmPackages:
    @emotion/react: ^11.11.3 => 11.11.3
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.36
    @mui/core-downloads-tracker:  5.15.10
    @mui/material: ^5.15.10 => 5.15.10
    @mui/private-theming:  5.15.9
    @mui/styled-engine:  5.15.9
    @mui/system:  5.15.9
    @mui/types:  7.2.13
    @mui/utils:  5.15.9
    @types/react: ^18.2.48 => 18.2.48
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^5.3.3 => 5.3.3

Search keywords: TablePagination slots slotProps

cc @DiegoAndai should we have another umbrella to take care of the completeness of slots and slotProps as a follow-up from the deprecation? I can own this if you'd like.

Hey @quibaritaenperdresatrompe, thanks for the report! The button icon's slots are under the action slots, as they're slots of the TablePaginationActions component. So you can access them through, for example, MuiTablePagination.defaultProps.slots.actions.nextButtonIcon. Here's an example: https://stackblitz.com/edit/stackblitz-starters-5rgtos?file=src%2FApp.tsx.
I would mark this issue as expected by design.
For context, this was introduced in https://github.com/mui/material-ui/pull/39353.

cc @DiegoAndai should we have another umbrella to take care of the completeness of slots and slotProps as a follow-up from the deprecation? I can own this if you'd like.

@siriwatknp Yes, I think we should have an issue for that 🙌🏼 the goal would be to add any missing slots and slotProps that were not added due to a deprecation. Could you create that issue?
I'm also curious about what you think about the sidenote in https://github.com/mui/material-ui/pull/33797#issuecomment-1850696082:

I realized that we made a mistake in that PR. It should be slotProps.actions.slotProps.firstButton.

For deep slots, what should be the usage? I'm thinking

slots.<slot> to override one-level slots
slotProps.<slot> to override one-level slot's props
slotProps.<parentSlot>.slots.<childSlot> to override two-level slots
slotProps.<parentSlot>.slotProps.<childSlot> to override two-level slot's props
slotProps.<grandparentSlot>.slotProps.<parentSlot>.slots.<childSlot> to override three-level slots
...

I don't know if we have any more of these. If we go with that, then the current TablePagination implementation is incorrect as it shouldn't allow slots.actions.nextButtonIcon, the correct path should be slotProps.actions.slots.nextButtonIcon.

For deep slots, what should be the usage? I'm thinking

Make sense to me for the time being but in v7, we should consider restructuring components to not have nested slots.

I think we should close this issue as expected and create a new one to remove nested slots in the future; what do you think?

I think we should close this issue as expected and create a new one to remove nested slots in the future; what do you think?

Sounds good. The new issue could be an umbrella one that covers all existing components that contain nested slots.

I created the follow up issue, closing this one.


text:
[code-infra] Optimize @testing-library/user-event

See this thread
I've seen this reduce the time of running userEvent.keyboard by an order of magnitude, eliminating the motivation to avoid using this library. It comes at the cost of slightly changed semantics. But even with these different semantics, we'd be better off compared to the way we currently test.
It's would be best for us to primarily optimize our tests for refactorability. Tests that require updates on every implementation detail change miss the mark. We should aim at tests that maximize interfacing with public API and minimize reliance on implementation details. Therefore, unless we specifically want to test an implementation detail, we should prefer userEvent.

Can this break MUI X tests?

Technically yes, but unlikely. We could try it out before merging.

Do we need to release this in a way that allows some tests to configure this behavior?

We could add a parameter to createRenderer, but you can also just set up your own const user = userEvent.setup() instance and use that for a specific test. IMO over time we should work towards moving things out of createRenderer and make the wrapper unnecessary.

🙂 Yep, trying this in X breaks the tests, but looks like it's not caused by this change, see https://github.com/mui/mui-x/pull/14671


text:
Deleting component doesn't work when just added to the page

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
I have to unselect/reselect to have the Backspace key delete the component.
Expected behavior 🤔
I can press the Backspace key as soon as I add the component to remove it.
Steps to reproduce 🕹
https://user-images.githubusercontent.com/3165635/183259732-7c0478ad-2eba-4360-8755-596bee610bca.mov
Context 🔦
I systematically confuse the TextField with the Typography component. Hopefully, #598 would fix this. This is how I found the bug.
I'm only reporting it to collect upvotes, to not fix yet.

I think it makes sense to at least look into what's going on here. And fix now only if it's straightforward

hopefully should be a quick one, i can take a look

authors: Janpot apedroferreira oliviertassinari

repo: mui/mui-toolpad


text:
Part 2: Update queries docs

Partial of https://github.com/mui/mui-toolpad/issues/1132

Are these generated using playwright?

No, I'm capturing them manually so we can have update docs faster, then I can look into automation


text:
Bruteforce protection

Right now accounts can be bruteforced, there should be a limit to the number of failed attempts.

This was left out by design because the service is meant to be behind some kind of http proxy that will handle those things.
For example this can be achieved easily with nginx: https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/

authors: mujx vycdev

repo: mujx/hakatime

license: Unlicense


text:
Fix sort countries

Fix for https://github.com/mukeshsolanki/country-picker-android/issues/60

not needed as we have reworked the country picker and have fixed this

authors: mukeshsolanki rmunk

repo: mukeshsolanki/country-picker-android


text:
cannot read properties of undefined (reading 'sendmessage') for numbers not in contact list

Advertising of monetized Frameworks is strictly forbidden and will be reported

[ ] The language must be English, if you are not fluent in English consider using: https://www.deepl.com/translator if it supports your native language

[ ] Please check if any other issue already adresses your concerns or if a recent PR is already fixing the mentioned issue

[ ] Please make sure to format your code, and to mark your code as such, with the provided tools from github (upper right of this box)

[ ] Please state your Operating System (inlcuding version), your Python Version, and your installation way (pip, from repo) and if you are running it inside a docker container

[ ] Note that the pip installation might be behind, so try to fix your issue with a pull from the repo and update to the most recent version

[ ] Follow the Stackoverflow Guidelines (https://stackoverflow.com/help/how-to-ask) when in need of help

[ ] Consider posting your question on Stackoverflow if it is a general programming question

[ ] There will be no support for spamming, or other mischief

[ ] There will be no support for finding professionals

sendmessage is reserved for contacts (each contact and group has an id that must be passed to sendmessage).

Thank you @Diegocndd.
What should I use to send a message to a number not exist in my contact list?

I think the only way is using the link https://api.whatsapp.com/send?phone=xxxxxxxxx&text=yyyyyyy

repo: mukulhase/WebWhatsapp-Wrapper


text:
wuch15's practice

吼啊

敢不敢每次的commit message有点创意……

repo: mulab/try-git

license: unlicense


text:
W-12450976 redo for v45merge duke

Writer's Quality Checklist
Before merging your PR, did you:

[ ] Run spell checker
[ ] Run link checker to check for broken xrefs
[ ] Check for orphan files
[ ] Perform a local build and do a final visual check of your content, including checking for:

Broken images
Dead links
Correct rendering of partials if they are used in your content
Formatting issues, such as:

Misnumbered ordered lists (steps) or incorrectly nested unordered lists
Messed up tables
Proper indentation
Correct header levels

[ ] Receive final review and signoff from:

Technical SME
Product Manager
Editor or peer reviewer
Reporter, if this content is in response to a reported issue (internal or external feedback)

[ ] If applicable, verify that the software actually got released

Doing this via https://github.com/mulesoft/docs-mule-runtime/pull/2475 instead

repo: mulesoft/docs-mule-runtime