Change to how SPO votes are counted

It has been brought up by a number of community members that the way we currently compute SPO votes is not what everyone expected.
Current implementation is such that for HardForkInitiation behavior is exactly the same as for DReps, however for the other three governance actions, that SPOs can vote on, behavior is different for SPOs that did not vote. In other words for these three governance action types:

NoConfidence
UpdateCommittee
ParameterUpdate (when it includes updates to parameter belonging to the security group)

the default vote counted for SPOs that didn't vote is Abstain, instead of No. The default vote of No is the behavior for DReps, while for SPOs it is default only when HardForkInitiation is proposed.
Current behavior is specified in this portion of the spec and the actual implementation lives here: https://github.com/IntersectMBO/cardano-ledger/blob/8d16d698dd499fd171845da16611c7c7026c1754/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Ratify.hs#L204-L207
This lead to some concerns about inclusion of SPOs into the future of parameter updates, that is why many have suggested that we should mimic the behavior of DReps exactly. However, that defaulting of SPOs to vote No, has its own concerns. In particular there is a danger if SPOs aren't active enough that they could inadvertently block sensible proposals. Inactivity could be potentially blamed either on indifference or issues with legality for some SPOs.
In order to solve this conundrum we made it the topic of Ledger Working Group Meeting #4 and had a very productive discussion with some community members and came up with an ingenious solution:
Everyone agreed right of the bat that if we had a mechanism for SPOs to choose whether they wanted to default to Abstain instead of No, we would have solved the problem. However making a change to PoolParams at this time is impossible without a new era. Also, whenever this issue of customizing PoolParams has surfaced during Conway development, we knew that making such a change would have been too ambitious of a goal, which would have lead to an extensive delay to the Conway delivery. This has to do with the fact that PoolParams is not a type family yet. Therefore, since adding a custom field to the PoolParams with an optional default vote was not a path that we could choose we almost discarded this idea. It was then that Martin Lang of ATADA Stake Pool proposed an interesting and unexpected solution: we can achieve ability of specifying a default vote for SPOs if we choose to mimic the default delegation of ppRewardAccount that is specified in the PoolParams.
To be more specific the solution to this problem is:

To change the default vote for SPOs to No from Abstain for all of the three proposals in question
Check whether SPO's reward address is delegated to the predefined AlwaysNoConfidence DRep and count default vote as Yes only on NoConfidence proposals for that SPO.
Check whether SPO's reward address is delegated to predefined AlwaysAbstain DRep and count default vote as Abstain for that SPO on all three: NoConfidence, UpdateCommitee and ParameterUpdate proposals.

This is not a terribly complicated logic to implement, which means that we can almost certainly take care of in time for the protocol version 10.0, i.e. the intra-era hard fork, a.k.a Chang+1

I think step 1 is a bad idea, since it still forces participation in governance to return to Abstain. What's wrong with leaving it to default to Abstain? Then SPOs that want to actively participate can change their default and SPOs that don't want to participate don't have to do anything. If you go with the hacky solution for delegation you can just check if there's any DRep delegation in there to default to No.
There's also the issue that this solution means that whatever Ada is associated with that particular stake credential now has to be delegated to a predefined vote. That means that the hacky solution will likely have to be in the code eternally since it affects voting outcomes.
I don't understand the issue with adding a field of type Maybe Vote to PoolParams and just not making it a type family. Is it that it would require CDDL changes?

The issue is that a single SPO pool voting YES can change the whole SPO acceptance to 100%. That was the reason to change it to default NO, so this cannot happen anymore. Setting all to abstain would lead into the same result.

My opinion is we go forward with this proposal. Yes, there's nothing that forces an exchange to delegate their rewards address to abstain, but this at least gives them the option to do so. Note that to claim rewards, they already will have to delegate their rewards address anyways, and most likely they'll pick abstain, so that feature alone could get large players to opt-out of voting on anything other than hard fork initiation proposals.

I do agree that a field on the pool registration certificate is a better design; however we ruled that out months ago because of the time it would take to trickle down the CDDL changes to hw wallets and other tools integrating pool registration certificates.

Note that if we let SPOs pick their default, the initial instability is mitigated even more. If, say, 10% of stake defaults to No, you now need 10% of other stake to stealthily vote to overtake them. At that point this doesn't even seem like a problem to me anymore, and defaulting everyone to No only has the downside of forcing everybody who doesn't want to participate to do something.

Agreed, this seems like a sensible solution.   Where it differs, we will make sure the CIP text is consistent with it.  Thank you to @gitmachtl for making the suggestion, and to @lehins for finding a way to implement it easily.

I don't understand the issue with adding a field of type Maybe Vote to PoolParams and just not making it a type family. Is it that it would require CDDL changes?

Yes, it would require CDDL changes. For this particular case not making it a type family and adding an optional field would work. Yet again, we do need a new era for this, because we can't change serialization for intra-era hardfork. Maybe, if I knew about this issue early enough we could have solved it in Conway by adding that optional field. But, I only learned about it a week ago.

I had no idea that SPO votes defaulted to abstain when nothing happened.  I just assumed they were treated the same as dReps where inaction means an implicit 'no'.  In that case, I have a 4th suggestion @lehins and @disassembler.
Regarding this...

So let's say that most exchanges don't do anything and 20% of the stake defaults to No now. That means that for the remaining SPOs to pass anything, 62.5% of the votes need to be Yes if nobody abstains. And that number just goes up in the presence of abstention. If 20% abstain as well (as some other exchanges would probably do) you now need 83.3% in favour. Good luck passing anything.

I'd previously joined a couple of SPO calls to voice my concern over precisely this issue.  My suggestion...

Add a new spoActivity parameter that functions exactly like drepActivity but for SPOs.  So if an SPO hasn't voted in that many epochs (currently 20 epochs for dReps), they are switched to abstain and removed from quorum.

That way CEXes or SPOs who don't do anything will simply be removed after a period of time.
Is there any reason why we can't treat both dReps and SPOs the same way?  Occam's Razor.

@Cerkoryn The issue I see here is that SPO's will inherently be voting less than dReps, and with a focus on proposals directly relating to infrastructure (as they should be). So if spoActivity countdown is set similarly to drepActivity, it may be the case that most SPOs don't vote for this period, are removed from the quorum, and soon we are back where we started with a very low SPO quorum. If we counteract this by setting spoActivity to much higher than drepActivity, the inverse can quickly become an issue: SPO-relevant parameters progress very slowly due to the high number of (almost always defaulted) "No"s.
IMO giving SPO's more granular optionality in their participation would be more fruitful than trying to arrive at the "right number" for an spoActivity parameter.

Keep it simple: Force SPOs to choose when booting up their node

I think the whole 'one SPO can single-handedly approve an action' argument is somewhat overblown. It's rather 'one SPO can single-handedly approve an action if all others ignore it while at the same time at least half of the DReps approve it'. Sounds very far-fetched to me. The real danger is that some SPOs don't pay attention in the time frame where the DReps approve the action and it gets just barely in because of that. But you have to weigh that against forcing exchanges to cast votes.

I made a similar argument in the Working Group meeting because I think the possibility of locking up governance over SPO lack of participation is a far greater danger than underrepresentation of SPOs if they don't cast votes.
However, if we have the ability to offer an auto-abstain option with relatively few trade-offs that is a far more elegant solution that keeps default SPO actions in line with DReps and the CC.
What is incredibly shocking here is that we had such a huge discrepancy come up between the specs/implementation and what I see as clear language in the text of the CIP.  We spent months socializing the fact that SPOs must cast votes and cannot auto-abstain.  We set the SPO related governance parameters based on the understanding that these thresholds must be met as a percentage of the stake held by all stake pools.  These things cannot be taken lightly.

Default abstain without a 'quorum' requirement presents significant risks to what I view as our last line of defense against bad behavior—the SPOs.
What’s being proposed here, in my opinion, offers the best of both worlds, at least for now. I tested a catastrophic scenario on SanchoNet that effectively worked:

I tracked all drepActivity of DReps to time my actions for the right Epoch boundary.

Then, 5 minutes before the Epoch boundary:

I submitted an 'Update Committee' governance action to position myself (with 7 cold credentials) and remove all CC-cold credentials currently in place. (In respect of the committeeMinSize protocol parameter.)
I registered an incredibly powerful DRep and voted yes on it, counterbalancing the previously active DReps.
I voted yes only with my own Stake Pool, all within the last 5 minutes of the Epoch to ensure that no other SPOs had time to counterweight that before the said Epoch boundary.

This scripted approach effectively changed the CC without anyone noticing before the calculations occurred, leaving no time for inactive DReps to respond.
In conclusion, I believe that what is being proposed here represents an excellent option, and I genuinely support it.

Add a new spoActivity parameter that functions exactly like drepActivity but for SPOs. So if an SPO hasn't voted in that many epochs (currently 20 epochs for dReps), they are switched to abstain and removed from quorum.

@Cerkoryn Despite that this would be a feasible solution, it would be pretty complicated to implement. It is one of the more complex features that DReps have. So, we definitely would not be able to implement it in time for the next intra-era hard fork. Moreover, we would have to hard code a value for this new "spoActivity" parameter, because it would not be an actual amendable protocol parameter yet, since we can't add new parameters without a new era. That being said, nothing is preventing us from adding this as a feature in the next era, but that feature would require a whole new CIP.

Is there any reason why we can't treat both dReps and SPOs the same way? Occam's Razor.

Yes, we can't use Occam's Razor, because at this point it is not the simplest solution from technical point of view.

Keep it simple: Force SPOs to choose their default when booting up their node

@Pdest08 Can't be done, because booting of a node is not reflected on chain.

We spent months socializing the fact that SPOs must cast votes and cannot auto-abstain.

@adamrusch I think the real problem here is that the CIP and spec designers had no participation in those months of socializing. If there was better inclusion of architects into discussions with the community, I suspect we would not be discussing this problem right now. In the three years I was with IOG I personally attended only three events that involved members of community. In my opinion all three of those events were incredibly useful for me as the leader of the Ledger team. I even have an example of this, remember @adamrusch how we got a chance to talk about another confusion with respect to the wording about thresholds in particular 51% vs 50% + 1 Lovelace. Maybe no changes to the code came out of it, but it certainly improved the clarity and understanding of the system. Resolution of ambiguities can only happen through proper discussions. So, maybe this is something we can improve on by including developers in community events a lot more often. That is, of course, not my call and not a decision that I can influence. Even without live events, I feel like we are moving more and more towards better communication between developers and community. Working groups meetings and discord channels are a great testament to that. On Monday we were able to get together in the Ledegr Working group meeting and address concerns of the community with a solution that came out of a community member. Which is pretty amazing in my opinion.

I registered an incredibly powerful DRep and voted yes on it, counterbalancing the remaining active DReps.

@Hornan7 That is something you wouldn't be able to do on Mainnet. Although maybe I am wrong and you do have a secret stash with billions of Ada. :wink:

The same applies to changing the guardrails within the constitution itself, which is why I strongly prefer getting back to the Default No with the added voting options for SPOs as proposed here.

So, it seems to me that everyone is so far in favor of this new solution proposed in this ticket. @WhatisRT is the only one that isn't sold on it 100% percent, but I haven't heard from him any viable concerns against this approach either. Therefore, unless anything changes before Chang+1 we are still planning on implementing this solution.

@Hornan7 That is something you wouldn't be able to do on Mainnet. Although maybe I am wrong and you do have a secret stash with billions of Ada. :wink:

With the current amount of ADA delegated to DReps on mainnet (553M live stake), I can assure you that I know entities (not myself) capable of executing exactly that in the first Epoch of Chang +1 if the proposed changes aren't implemented.
While it's unlikely to happen, the mere possibility is still a concern for me. But hey, that's what we're here for, right? 😅😇

With the current amount of ADA delegated to DReps on mainnet (553M live stake)

@Hornan7 Good thing we are not ending bootstrap period now! :smile:
Considering that we've only enabled DReps 3 and a half weeks ago .5B ADA is a really good progress. So, a more realistic estimation of live stake for DReps would be some extrapolation of current progress of DRep registration and delegation, rather than assuming we'll be stuck and half a billion ADA in two months at Chang+1

While it's unlikely to happen, the mere possibility is still a concern for me. But hey, that's what we're here for, right?

I do hear your concern though. Which is why we are changing the behavior. :wink:

Add a new spoActivity parameter that functions exactly like drepActivity but for SPOs. So if an SPO hasn't voted in that many epochs (currently 20 epochs for dReps), they are switched to abstain and removed from quorum.

 For DReps, we 'pause' the clock if there is nothing to vote on, which is easy because they vote on everything. For SPOs, you'd need to restrict that to those actions that they actually can vote on. Should a HF proposal be included in that? Combined with the fact that giving the SPOs the ability to pick their default, and people being incentivized to delegate away from them if the SPO shuts down (because of missing rewards) it's not really necessary to add this additional complexity. If this problem was pointed out early in the design phase then that might have been a solution, but now it's too late and other options look more sensible.
Various concerns I have the approach from this ticket (none of which are a dealbreaker, but they make me prefer other options):

It is giving something a double meaning that was never intended in the first place. This is mostly a matter of taste, though I could see this lead to confusion and various unintended consequences downstream. There is also a decent chance that this is going to cause complications with the ledger formalization in the future.
If you want to revert to a default No, you have to delegate to a DRep, which you might not want to. You can make a 'garbage DRep' to solve this problem, but it's a bit ugly.
A SPO that doesn't want to vote themself but wants to delegate to a DRep is stuck in a difficult position: either manually vote Abstain on everything, or delegate to AlwaysAbstain and not the the intended DRep. Note that this affects at least the pledge of the pool, other funds could be moved to a different stake credential.
I don't know if there is any use case for this, but this scheme cannot really be exposed to Plutus. It doesn't matter whether you want to allow pool credentials to be scripts or not here, there is some information that we show to Plutus right now, and it might make sense to include the default vote there. If you want to allow pool credentials to be scripts, this issue becomes more pressing.

The biggest issue of these is probably the one concerning the pledge. No matter if you think that SPOs should also vote as DReps, the most restrictive opinion I've heard says you should be able to at least pick which one you want. With this design, you might not even be able to do that with all of your Ada.
I've made an alternative proposal based on transaction metadata, which also gives pools the option to pick their default, which I believe is easier to implement and functions identically to it just being a part of the pool registration certificate. It doesn't have any of the above issues, but it doesn't force pools to make a choice, which is why in that case it might be better to stay with the default of Abstain.
Anyway, I'm now mostly working on a different project and I shouldn't spend any more time on this issue. So as long as nobody asks for my opinion, I'll stay out of this discussion.

If you want to revert to a default No, you have to delegate to a DRep, which you might not want to. You can make a 'garbage DRep' to solve this problem, but it's a bit ugly.

On Chang + 1 they will have to delegate their voting power anyway if they want to be able to withdraw their reward. So giving them the additional opportunity to passively "auto-abstain" or "No-confidence" with their Stake pool on top of what they already have, sounds right to me.

A SPO that doesn't want to vote themself but wants to delegate to a DRep is stuck in a difficult position: either manually vote Abstain on everything, or delegate to AlwaysAbstain and not the the intended DRep. Note that this affects at least the pledge of the pool, other funds could be moved to a different stake credential.

It might not be super popular right now but I have a nice script that can batch vote on all governance actions (votable by SPOs) into 1 single transaction (up to 400 votes per Tx) if they want to delegate to a specific DRep and still actively Abstain with their pool.

It's probably too late for this, but after reviewing the code for the spec for this, I think it would have made more sense to use the delegation of the pool itself instead of its stake credential. There are two reasons for this:

With the current implementation, you need to use a different credential for voting than for setting the default vote.
We also need to pass the PoolParams around, which we wouldn't have to.

As an added bonus, that solution wouldn't have locked up the pledge for a default vote.

I think it would have made more sense to use the delegation of the pool itself instead of its stake credential

Could you please elaborate on this. I don't understand what it means "delegation of the pool itself". How can a pool delegate to anything?

It's probably too late for this

It's definitely too late for Conway. But, if you have clever ideas that we could use for the next era, I am all ears.

Thinking a bit more about this alternative solution I think I am starting to understand the suggested solution. It is phrased a bit ambiguously, but here is my understanding of it.

Pool operator would register a stake credential using the same private key as it is used to register the stake pool.
Whenever we would be looking up a default vote for an SPO, instead of using a reward account from the pool params, we would look if the poolId is also registered as a stake credential.
Then we would resolve its delegation to a DRep and then proceed like we do in the current solution that has already been implemented: namely check if that stake credential (i.e poolId) has delegated to a predefined DRep and use that as a default vote.

@WhatisRT Please correct me if I misunderstood it.
In my opinion it is strictly worse than the current solution of using the reward account specified in the pool params, because current solution provides a motivation for that reward account to be delegated to a DRep. In particular, thinking of Stake Pools that are operated by exchanges, current solution forces them to delegate to a DRep, which is most likely going to be an AlwaysAbstainDRep. If we were to use this hack of using a poolId instead, then this motivation is gone. In fact there would be no motivation for an SPO to register a stake credential using the Pool's Key and we would be back to square one.
With respect to a more permanent solution in the future, it will make more sense to actually add this decision of default vote as a pool parameter, rather than relying on this indirection. Which is something we can target for the next era. Note that during era translation we'll be able to easily populate that new field with the value that is decided by the current mechanism.
So, in the end, I think, this was the best solution from all perspectives:

We have a way for SPOs to change their default vote
We have a motivation for SPOs to change their default
We have a plan to make the process of selecting default vote for SPOs more idiomatic in the future by adding it to pool params. We'll also require it during pool registration and we'll be able to populate that decision for all pools that are already registered.


Background is set up as poster

Version Number
1.18.3 (Docker)  (unraid)
What branch are you on?
master
Describe the Bug
Sometimes, PMM seems to mix up collection posters with backgrounds. So, instead of plex showing the correct collection poster, it shows the background from that collection as a poster.
Example:
I have set up a collection "Everyones Watching this" and it worked very well the last months, but all of a sudden (with no changing anything to the collections config), instead of the poster, the background shows up in Plex.

This happens only from time to time.
I can fixit by hand in Plex and then the problem seems not to come back for those fixed collections. But for others. Over the last year, I had to fix about 5 collections by hand, I guess.
Those collections worked great and everything seems to be configured correctly.
The links in the collection config are good, the files in the assets folder are good.
I have no clue why this happens.
Log (from the "Everyones Watching this" collection):
[2023-03-29 06:25:14,343] [builder.py:193]            [INFO]     |========================================================================================================================================================================================================|
[2023-03-29 06:25:14,347] [builder.py:193]            [INFO]     |                                                                              Everyones Watching this Collection in Filme                                                                               |
[2023-03-29 06:25:14,350] [builder.py:193]            [INFO]     |========================================================================================================================================================================================================|
[2023-03-29 06:25:14,353] [builder.py:194]            [INFO]     |                                                                                |
[2023-03-29 06:25:14,356] [builder.py:233]            [INFO]     |============================================================================ Validating Everyones Watching this Attributes =============================================================================|
[2023-03-29 06:25:15,515] [builder.py:473]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:15,521] [builder.py:474]            [DEBUG]    | Validating Method: smart_label                                                                                |
[2023-03-29 06:25:15,524] [builder.py:479]            [DEBUG]    | Value: audience_rating.desc                                                                                |
[2023-03-29 06:25:15,565] [builder.py:579]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:15,569] [builder.py:580]            [DEBUG]    | Validating Method: sync_mode                                                                                |
[2023-03-29 06:25:15,573] [builder.py:584]            [DEBUG]    | Value: sync                                                                                |
[2023-03-29 06:25:15,576] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:15,580] [builder.py:719]            [DEBUG]    | Validating Method: trakt_chart                                                                                |
[2023-03-29 06:25:15,584] [builder.py:720]            [DEBUG]    | Value: ordereddict([('chart', 'watched'), ('limit', 50), ('time_period', 'weekly')])                                                                                |
[2023-03-29 06:25:15,608] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:15,611] [builder.py:719]            [DEBUG]    | Validating Method: trakt_list                                                                                |
[2023-03-29 06:25:15,614] [builder.py:720]            [DEBUG]    | Value: https://trakt.tv/users/hdlists/lists/top-films-everyone-s-watching                                                                                |
[2023-03-29 06:25:16,045] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,049] [builder.py:719]            [DEBUG]    | Validating Method: sort_title                                                                                |
[2023-03-29 06:25:16,052] [builder.py:720]            [DEBUG]    | Value: +++01_0_Everyones Watching this                                                                                |
[2023-03-29 06:25:16,055] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,059] [builder.py:719]            [DEBUG]    | Validating Method: limit                                                                                |
[2023-03-29 06:25:16,061] [builder.py:720]            [DEBUG]    | Value: 50                                                                                |
[2023-03-29 06:25:16,065] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,068] [builder.py:719]            [DEBUG]    | Validating Method: collection_mode                                                                                |
[2023-03-29 06:25:16,071] [builder.py:720]            [DEBUG]    | Value: hide                                                                                |
[2023-03-29 06:25:16,074] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,078] [builder.py:719]            [DEBUG]    | Validating Method: item_refresh                                                                                |
[2023-03-29 06:25:16,081] [builder.py:720]            [DEBUG]    | Value: True                                                                                |
[2023-03-29 06:25:16,084] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,087] [builder.py:719]            [DEBUG]    | Validating Method: summary                                                                                |
[2023-03-29 06:25:16,090] [builder.py:720]            [DEBUG]    | Value: Movies That Everyone is Watching                                                                                |
[2023-03-29 06:25:16,094] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,097] [builder.py:719]            [DEBUG]    | Validating Method: url_background                                                                                |
[2023-03-29 06:25:16,101] [builder.py:720]            [DEBUG]    | Value: https://i.imgur.com/SOVfrIq.png                                                                                |
[2023-03-29 06:25:16,207] [builder.py:715]            [DEBUG]    |                                                                                |
[2023-03-29 06:25:16,211] [builder.py:719]            [DEBUG]    | Validating Method: url_poster                                                                                |
[2023-03-29 06:25:16,214] [builder.py:720]            [DEBUG]    | Value: https://i.imgur.com/GQca9tU.png                                                                                |
[2023-03-29 06:25:17,082] [builder.py:885]            [INFO]     |                                                                                |
[2023-03-29 06:25:17,086] [builder.py:886]            [INFO]     | Validation Successful                                                                                |
[2023-03-29 06:25:17,089] [plex_meta_manager.py:636]  [INFO]     |                                                                                |
[2023-03-29 06:25:17,093] [plex_meta_manager.py:638]  [INFO]     |============================================================================== Running Everyones Watching this Collection ==============================================================================|
[2023-03-29 06:25:17,096] [plex_meta_manager.py:644]  [INFO]     |                                                                                |
[2023-03-29 06:25:17,099] [plex_meta_manager.py:645]  [INFO]     | Smart Movie Label                                                                                |
                                                                 | Sort By: ['audience_rating.desc']                                                                                |
                                                                 | Filter:                                                                                |
                                                                 |   Match all of the following:                                                                                |
                                                                 |     Label is Everyones Watching this                                                                                |
[2023-03-29 06:25:17,115] [plex_meta_manager.py:646]  [INFO]     |                                                                                |
[2023-03-29 06:25:17,118] [plex_meta_manager.py:647]  [INFO]     | Items Found: 50                                                                                |
[2023-03-29 06:25:17,122] [plex_meta_manager.py:652]  [INFO]     |                                                                                |
[2023-03-29 06:25:17,126] [plex_meta_manager.py:653]  [INFO]     | Sync Mode: sync                                                                                |
[2023-03-29 06:25:17,128] [plex_meta_manager.py:656]  [DEBUG]    |                                                                                |
[2023-03-29 06:25:17,131] [plex_meta_manager.py:657]  [DEBUG]    | Builder: trakt_chart: {'chart': 'watched', 'limit': 50, 'time_period': 'weekly'}                                                                                |
[2023-03-29 06:25:17,134] [plex_meta_manager.py:658]  [INFO]     |                                                                                |
[2023-03-29 06:25:17,137] [trakt.py:501]              [INFO]     | Processing Trakt Chart: 50 Weekly Watched Movies                                                                                |
[2023-03-29 06:25:17,174] [builder.py:1665]           [DEBUG]    |                                                                                |
[2023-03-29 06:25:17,178] [builder.py:1666]           [DEBUG]    | 50 IDs Found                                                                                |
[2023-03-29 06:25:17,181] [builder.py:1668]           [DEBUG]    |                                                                                |
[2023-03-29 06:25:17,189] [plex_meta_manager.py:656]  [DEBUG]    |                                                                                |
[2023-03-29 06:25:17,192] [plex_meta_manager.py:657]  [DEBUG]    | Builder: trakt_list: https://trakt.tv/users/hdlists/lists/top-films-everyone-s-watching                                                                                |
[2023-03-29 06:25:17,196] [plex_meta_manager.py:658]  [INFO]     |                                                                                |
[2023-03-29 06:25:17,200] [trakt.py:493]              [INFO]     | Processing Trakt List: https://trakt.tv/users/hdlists/lists/top-films-everyone-s-watching                                                                                |
[2023-03-29 06:25:17,623] [builder.py:1665]           [DEBUG]    |                                                                                |
[2023-03-29 06:25:17,627] [builder.py:1666]           [DEBUG]    | 30 IDs Found                                                                                |
[2023-03-29 06:25:17,631] [builder.py:1668]           [DEBUG]    |                                                                                |
[2023-03-29 06:25:17,643] [builder.py:2249]           [INFO]     |                                                                                |
[2023-03-29 06:25:17,647] [builder.py:2250]           [INFO]     |============================================================================= Adding to Everyones Watching this Collection =============================================================================|
[2023-03-29 06:25:17,651] [builder.py:2251]           [INFO]     |                                                                                |
...
[2023-03-29 06:25:28,510] [builder.py:2285]           [INFO]     |                                                                                |
[2023-03-29 06:25:28,513] [builder.py:2287]           [INFO]     | 50 Movies Processed 3 Movies Added                                                                                |
[2023-03-29 06:25:28,516] [builder.py:2295]           [INFO]     |                                                                                |
[2023-03-29 06:25:28,519] [builder.py:2296]           [INFO]     |=========================================================================== Removed from Everyones Watching this Collection ============================================================================|
[2023-03-29 06:25:28,521] [builder.py:2297]           [INFO]     |                                                                                |
...
[2023-03-29 06:25:31,849] [builder.py:2314]           [INFO]     |                                                                                |
[2023-03-29 06:25:31,852] [builder.py:2315]           [INFO]     | 3 Movie Removed                                                                                |
[2023-03-29 06:25:32,729] [builder.py:2623]           [INFO]     |                                                                                |
[2023-03-29 06:25:32,733] [builder.py:2624]           [INFO]     |======================================================================== Updating Details of Everyones Watching this Collection ========================================================================|
[2023-03-29 06:25:32,737] [builder.py:2625]           [INFO]     |                                                                                |
[2023-03-29 06:25:32,758] [builder.py:2689]           [INFO]     | Collection Metadata Edits                                                                                |
[2023-03-29 06:25:32,766] [util.py:178]               [DEBUG]    | 2 posters found:                                                                                |
[2023-03-29 06:25:32,770] [util.py:180]               [DEBUG]    | Method: url_poster Poster: https://i.imgur.com/GQca9tU.png                                                                                |
[2023-03-29 06:25:32,773] [util.py:180]               [DEBUG]    | Method: asset_directory Poster: {'attribute': 'asset_directory', 'location': '/config/assets/Everyones Watching this/poster.png', 'prefix': "Everyones Watching this's ", 'is_poster': True, 'is_url': False, 'compare': 191987, 'message': "Everyones Watching this's poster to [File] /config/assets/Everyones Watching this/poster.png"} |
[2023-03-29 06:25:32,777] [util.py:178]               [DEBUG]    | 2 backgrounds found:                                                                                |
[2023-03-29 06:25:32,781] [util.py:180]               [DEBUG]    | Method: url_background Background: https://i.imgur.com/SOVfrIq.png                                                                                |
[2023-03-29 06:25:32,785] [util.py:180]               [DEBUG]    | Method: asset_directory Background: {'attribute': 'asset_directory', 'location': '/config/assets/Everyones Watching this/background.png', 'prefix': "Everyones Watching this's ", 'is_poster': False, 'is_url': False, 'compare': 1626780, 'message': "Everyones Watching this's background to [File] /config/assets/Everyones Watching this/background.png"} |
[2023-03-29 06:25:33,660] [builder.py:2511]           [INFO]     |                                                                                |
[2023-03-29 06:25:33,665] [builder.py:2512]           [INFO]     |================================================================= Updating Details of the Items in Everyones Watching this Collection ==================================================================|
[2023-03-29 06:25:33,669] [builder.py:2513]           [INFO]     |                                                                                |
[2023-03-29 06:28:43,396] [plex_meta_manager.py:780]  [INFO]     |                                                                                |
[2023-03-29 06:28:43,400] [plex_meta_manager.py:781]  [INFO]     |========================================================================================================================================================================================================|
[2023-03-29 06:28:43,403] [plex_meta_manager.py:781]  [INFO]     |                                                                              Finished Everyones Watching this Collection                                                                               |
[2023-03-29 06:28:43,406] [plex_meta_manager.py:781]  [INFO]     |                                                                                Collection Run Time: 0:03:29                                                                                |
[2023-03-29 06:28:43,410] [plex_meta_manager.py:781]  [INFO]     |========================================================================================================================================================================================================|

The assets folder has 2 files:
background.png:

poster.png:

Inside Plex, before fixing by hand:

Relevant Collection/Overlay/Playlist Definition
Everyones Watching this:
    trakt_chart:
      chart: watched
      limit: 50
      time_period: weekly
    trakt_list: https://trakt.tv/users/hdlists/lists/top-films-everyone-s-watching
    sort_title: +++01_0_Everyones Watching this
    limit: 50
    sync_mode: sync
    collection_mode: hide
    smart_label: audience_rating.desc
    item_refresh: true
    summary: Movies That Everyone is Watching
    url_background: https://i.imgur.com/SOVfrIq.png
    url_poster: https://i.imgur.com/GQca9tU.png

Logs
No response

@gitttt54 can you switch to nightly and see if the issue still happens?

I'll do atm, but that issue comes very randomly, so I don't think, I will catch it, as I don't want to stay too long on nightly (milquetoast I am)

@gitttt54 can you switch to nightly and see if the issue still happens?

I'll do atm, but that issue comes very randomly, so I don't think, I will catch it, as I don't want to stay too long on nightly (milquetoast I am)

The current nightly build will be pushed to the master branch very soon as a 1.19 release - I think meisnate12 wants to verify this is resolved in nightly, or if he needs to address something prior to pushing the build.

@gitttt54 have you been able to confirm this issue is resolved? 1.19 has now been pushed.

@gitttt54 have you been able to confirm this issue is resolved? 1.19 has now been pushed.

Thank you for mention it, I now have switched to the :latest tag again and will monitor.
Until now, I did not see it again, but -as I said- it pops up very rare.
In the trust that issue is being fixed, I will now close this issue, and just reopen it if it pops up again. ;-D
Thank you!

Unfortunately, that issue is not solved with Version: 1.19.0 (Docker).
I removed a PMM managed collection  yesterday, where the poster and the background were shown correct in plex,
but today, the newly created collection now shows the background as poster and has no background shown in plex.
I double checked my config, but its correkt. url_background + url_poster are both set to background + poster.
Interestingly, in plex, when I check the properties of that collection, I see the set up poster, the set up background and the automaticly generated 4-poster by plex in the poster tab of the collection. (all 3 in that order)
It looks like, PMM added the set up background  as a poster and selected it.

And again, another collection:

The collection was fine before I changed the urls for the poster (just commented them out and add the new one):
  Top Rated:
    imdb_list: https://www.imdb.com/search/title/?groups=top_250&count=250&view=simple
    tmdb_top_rated: 250
    limit: 25
    sort_title: +++01_1_Top Rated
    sync_mode: sync
    collection_mode: hide
    smart_label: audience_rating.desc
    summary: Top Rated Movies across the internet
    url_background: https://i.imgur.com/SOVfrIq.png
#    url_poster: https://i.imgur.com/x7BhedD.png
#    url_poster: https://theposterdb.com/api/assets/213605
    url_poster: https://theposterdb.com/api/assets/215438

I might have had fiddled with the assets folders, like deleting old poster and background images to be sure, PMM will save the new ones. But I don't know for sure, because I did this also with a lot of other collections, which did not seem to mix up background and poster.


[WebGPU] Translate int8x4 into u32

This patch translates an int8x4 into a u32 in WGSL shaders as 8-bit integers are not supported in WebGPU right now and the WGSL built-in function dot4I8Packed() accepts u32 as its inputs and each of the u32 value logically represents a 4-element 8-bit integer vector.
issue: #16627

Hi @tqchen I'd like to submit this part first then work on adding DP4A in TIR.
PTAL, thanks!

thank you @Jiawei-Shao


Render LaTeX expressions

Hi
Is there a way to include TeX / LaTeX expressions in the markdown? It will be a huge help in our documentation.

Seems like somebody has done this before with MathJax?
https://github.com/tripit/slate/issues/269

Thanks for that info!

Yup! Closing, but feel free to keep replying if that other issue is insufficient.


[BEAM-10383] Update Snowflake JDBC dependency

This PR updates Snowflake JDBC and adds "application=beam" string to URL when building Snowflake JDBC connection.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[x] Update CHANGES.md with noteworthy changes.
[] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Hi @kamilwu, will you find a moment to make a CR ?

Thanks, LGTM. Do Snowflake tests run as a part of Java PreCommit?

Run Java PreCommit

Run Java PreCommit

Run Java PreCommit

I can see all tests passed and review passed, so I'm merging. Thanks a lot all! :)


Honor casing in filter and search inputs

When entering something into the filter or search inputs and later changing the casing of that input (while not changing anything else), the input snaps back to the old casing.
That's bad, because filtering for MLStream is something else than filtering for mlstream and a simple typo in your casing will prevent you from filtering/searching the correct term unless you add a space to the end of your input or add something like  and True to the end.

ping


ModelCheckpoint Callback state loader with missing dir

Bug description
Loading a checkpoint with the ModelCheckpoint callback on a different machine (or with a missing/moved "best_model_path" dir) results in an error and crash.
A common use case for me is to train a model (with .ckpt stored elsewhere i.e Neptune), and then pull the checkpoint from that model to another machine to continue training later. This used to work in older versions, but now breaks. Currently, the code deals with situations where the directory structure has changed, but not for larger changes in the absolute file-structure.
How to reproduce the bug
1. Run a model with ModelCheckpoint
2. Save the whole model as a .ckpt
3. Resume the .ckpt run on another machine.

Error messages and logs

# Error messages and logs here please

Restoring states from the checkpoint path at /home/kyle/v6x_wsl/vrew/TTS/training/nv_fast_pitch/cache/TTS-781/step=100000.ckpt
/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/callbacks/model_checkpoint.py:345: UserWarning: The dirpath has changed from '/home/kyle/v6x/vrew/TTS/training/nv_fast_pitch/TTS-781/.neptune/Untitled/TTS-781/checkpoints' to '/home/kyle/v6x_wsl/vrew/TTS/training/nv_fast_pitch/TTS-798/.neptune/Untitled/TTS-798/checkpoints', therefore best_model_score, kth_best_model_path, kth_value, last_model_path and best_k_models won't be reloaded. Only best_model_path will be reloaded.
Error executing job with overrides: []
Traceback (most recent call last):
File "/home/kyle/v6x_wsl/vrew/TTS/train.py", line 25, in train
trainer.fit(model, datamodule=datamodule, ckpt_path=checkpoint)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 696, in fit
self._call_and_handle_interrupt(
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 648, in _call_and_handle_interrupt
return self.strategy.launcher.launch(trainer_fn, *args, trainer=self, **kwargs)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/strategies/launchers/subprocess_script.py", line 93, in launch
return function(*args, **kwargs)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 735, in _fit_impl
results = self._run(model, ckpt_path=self.ckpt_path)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 1166, in _run
results = self._run_stage()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 1252, in _run_stage
return self._run_train()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 1283, in _run_train
self.fit_loop.run()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/loop.py", line 200, in run
self.advance(*args, **kwargs)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/fit_loop.py", line 271, in advance
self._outputs = self.epoch_loop.run(self._data_fetcher)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/loop.py", line 201, in run
self.on_advance_end()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/epoch/training_epoch_loop.py", line 241, in on_advance_end
self._run_validation()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/epoch/training_epoch_loop.py", line 299, in _run_validation
self.val_loop.run()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/loop.py", line 207, in run
output = self.on_run_end()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/dataloader/evaluation_loop.py", line 201, in on_run_end
self._on_evaluation_end()
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loops/dataloader/evaluation_loop.py", line 265, in _on_evaluation_end
self.trainer._call_callback_hooks(hook_name, *args, **kwargs)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/trainer/trainer.py", line 1597, in _call_callback_hooks
fn(self, self.lightning_module, *args, **kwargs)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/callbacks/model_checkpoint.py", line 320, in on_validation_end
self._save_last_checkpoint(trainer, monitor_candidates)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/callbacks/model_checkpoint.py", line 653, in _save_last_checkpoint
self._save_checkpoint(trainer, filepath)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/callbacks/model_checkpoint.py", line 394, in _save_checkpoint
logger.after_save_checkpoint(proxy(self))
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/utilities/rank_zero.py", line 32, in wrapped_fn
return fn(*args, **kwargs)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loggers/neptune.py", line 572, in after_save_checkpoint
model_name = self._get_full_model_name(checkpoint_callback.best_model_path, checkpoint_callback)
File "/home/kyle/anaconda3/envs/tts/lib/python3.8/site-packages/pytorch_lightning/loggers/neptune.py", line 596, in _get_full_model_name
raise ValueError(f"{model_path} was expected to start with {expected_model_path}.")
ValueError: /home/kyle/v6x/vrew/TTS/training/nv_fast_pitch/TTS-781/.neptune/Untitled/TTS-781/checkpoints/step=100000.ckpt was expected to start with /home/kyle/v6x_wsl/vrew/TTS/training/nv_fast_pitch/TTS-798/.neptune/Untitled/TTS-798/checkpoints/.
Environment

#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow):
#- PyTorch Lightning Version (e.g., 1.5.0): 1.7.7
#- Lightning App Version (e.g., 0.5.2): N/A
#- PyTorch Version (e.g., 1.10): 1.12.1
#- Python version (e.g., 3.9): 3.8
#- OS (e.g., Linux): Linux(WSL)
#- CUDA/cuDNN version: 11.3/8.3.2
#- GPU models and configuration: 3090x2
#- How you installed Lightning(`conda`, `pip`, source): conda
#- Running environment of LightningApp (e.g. local, cloud): local

More info
It seems like the simplest and maybe most straight forward solution is to not restore the ModelCheckpoint state at all if the directory has changed. There are more complex solutions (like checking each field) but given that this specific checkpoint is tightly coupled with the file structure it seems ill advised.

I wonder if it would be beneficial to allow the 'ckpt_path' of Trainer.fit() to accept a dict loaded from a .ckpt file using torch.load. Then you could manually remove problematic state dicts if required.

@Stack-Attack Hello! I face the same issue, but on the same machine.
I do the following:
1) train some experiment with neptune logger, model checkpoint callback
2) start to finetune from saved full .ckpt (from 1) with different experiment name on the same machine
3) see this mistake when all paths are existing and not changed

Using torch.load and removing callback state is the best way for this issue?

@Stack-Attack Thank you so much for a quick reply! I hope Lightning team will fix that behavior later :)

Hey @Stack-Attack,  @ArtemSivtsov
Aleksander here - eng. at Neptune.ai.
I came across this issue a couple of days ago.
Would it be possible for you to create/share a minimal code snippet that would help reproduce the bug?


Azure-Search Needs to be present on Search landing page

Re-adding.

Can one of the admins verify this patch?


cleanup: static.py created

Removed redundant global variable statements, moved static variables, improved visual state of modules imports

#7

Closes #7


Fixing the title

"Foundation" needs to be upper case
Description

Related Issue(s)

Checklist

[ ] I have read the contribution guidelines
[ ] I have considered the performance impact of these changes
[ ] Suitable unit/system level tests have been added and they pass
[ ] Documentation has been updated

@Yndira-E Can you also fix the artwork tile to have an upper case for Foundation please

@Hasmin-AC done!


Compiler consider instance var nilable when assigning @var = self in constructor

Hi :smiley:
I have a strange behaviuor when i set an instance var equals to self in constructor:
class Node
    @child : Node
    def initialize
        @child = self
    end
end

Node.new

gives me Error: instance variable '@child' of Node was not initialized directly in all of the 'initialize' methods, rendering it nilable. Indirect initialization is not supported. so i'm forced to treat child as nilable to make it work.
Imho it is not correct, for example in kotlin the code below compiles with no error:
class Node {
     var child: Node

    constructor() {
        child = this
    }
}

fun main(){
    val n = Node()
}

This is not a bug but intentional to prevent the compiler from producing code that uses an object before it's entirely initialized.
It can surely be improved (see #11835).
Maybe the compiler could be smart one day and figure out that assigning self to an ivar in an initiallizer is safe (as long as nothing else happens with that).
A possible workaround to force the compiler to accept this is to prepend @child = uninitialized self (it basically tells the compiler that it's okay for @child to be uninitialized).
class Node
    @child : Node
    def initialize
        @child = uninitialized self
        @child = self
    end
end

Node.new

Workaround would also require to make @child assigned after all other fields (or prepend other fields with uninitialized too ).
class Node
    @x : Int32
    @y : Int32
    @child : Node
    def initialize
        @x = 1 # this is ok
        @child = uninitialized self
        @child = self
        @y = 2 # this won't compile as @y was not initialized before usage of `self`
    end
end

Node.new

@konovod right, but i don't understand why. @y refers to the current object, but only @child is not initialized, so why i can't initialize @y after assign @child?

@konovod right, but i don't understand why. @y refers to the current object, but only @child is not initialized, so why i can't initialize @y after assign @child?

This is because currect logic is simple - if we use self in constructor, we can, in theory, pass it to some method or anywhere, so at this point all fields must be initialized (or nillable).
so when you do @child = self, compiler can guarantee that you next call won't be e.g<EMAIL_ADDRESS>(and this would lead to undefined behavior because @y is still not initialized).

oh right :), maybe could i update the doc about this workaround? imho is useful to know because in recursive data structures is quite common to assign self in constructor

This is similar to https://github.com/crystal-lang/crystal/issues/9182, i.e. safe uses of self in constructor that could be detected by the compiler.

I recently got a similar case with a dual reference (Bar <-> Foo):
class Bar
  def initialize(@foo : Foo)
  end
end

class Foo
  @bar = uninitialized Bar

  def initialize
    @bar = Bar.new(self)
  end
end

p Foo.new

That will fail to compile with:
Error: instance variable '@bar' of Foo must be Bar, not Nil
'self' was used before initializing instance variable '@bar', rendering it nilable

A workaround is to specify @bar = uninitialized Bar inside the #initialize method for the type checker to notice it:
def initialize
  @bar = uninitialized Bar
  @bar = Bar.new(self)
end

I think the type checker handles the global ivar assignments for concrete values, but loses (or overlooks) when we use the uninitialized state.


Feature: Dark mode support

PR Fixes the Issue : #4
changes:

Darkmode config for Tailwind
Dark mode Toggle button
Topbar component to add Darkmode Toggler
Add dark mode contrast color in relevant components

please attack an issue and also follow the CONTRIBUTING guidelines

@gangadharbenni its not working, i'm not able see any effects. Can you record a video instead?

@rupali-codes I have linked the issue let me know for any more changes..

could you check why light mode is not showing up? maybe for browser settings?

could you check why light mode is not showing up? maybe for browser settings?

Looks like its issue because of Daisy UI plugin.
https://github.com/saadeghi/daisyui/discussions/640

@rohitdasu  pls try now made fix for plugin issue..

@gangadharbenni i'm not able see logo, kindly fix

Thank you

@gangadharbenni i'm not able see logo, kindly fix
Thank you

I think i found the issue

make it dark by default, and also update this logo (Links) color based on the theme chosen

@rupali-codes
Updated Dark as default on very first visit of site.
There on for next load of site it will use previous set theme in local storage..
Regarding logo color change my thought is like logo is theme independent
hence it should be same between mode changes..

@gangadharbenni thanks for quick changes, we appreciate your time and efforts. keep contributing :)


Specific domains of what type?

When you say "allow syncing only on PCs joined to specific domains" do you mean local Active Directory domains or Azure Active Directory domains?

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

ID: a62d5896-3262-b49f-aeb1-2fe8aceed122
Version Independent ID: bc621edd-c309-1ccb-bfb8-104eae7204fb
Content: Allow syncing only on computers joined to specific domains
Content Source: OneDrive/allow-syncing-only-on-specific-domains.md
Service: one-drive
GitHub Login: @kaarins
Microsoft Alias: kaarins

It refers to Active Directory domains. On Step 4, it clearly takes you to an AD cmdlet to determine that information.

@ang216 Thank you for this feedback
From my understanding Trevor has answered your question and resolved this issue. If this issue is not resolved please reopen this issue.


fix confused names of presentational and container components in react-router-redux examples

It seems like react-router-redux examples have wrong names of Presentational and Container Components.

As far as I know we should call connect() this way:
const MyContainer = connect(mapStateToProps, mapDispatchToProps)(MyComponent)
     └────────────────── container that passes    ─────────────┘      ↑
                         state and action creators                    │
                         into your component ─────────────────────────┘

i see this way of using connect there:

Usage with React · Redux | Full Source
connect() - returns - react-redux/api.md

Instead in current examples we see opposite:
const MyComponent = connect(mapStateToProps, mapDispatchToProps)(MyContainer)
     └────────────────── component passes  ───────────────┘           ↑
                         to container! ───────────────────────────────┘

I'm new in react world so maybe I'm missing something.

These are just names for patterns. You don't have to apply them to your component names. Thanks for the PR, but I'd rather their kept simple.


[ADAP-1051] [Feature] Allow configuration of expiration of temp table used in incremental models

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt-bigquery functionality, rather than a Big Idea better suited to a discussion

Describe the feature
The current behavior is for dbt-bigquery to create a "temporary" table that expires after 12 hours when performing an incremental model update. This duration is hard-coded here. It would be useful to make this duration configurable, particularly for incremental refreshes that occur more frequently than every 12 hours.
Describe alternatives you've considered
It may be worth considering dropping the temporary table upon a successful incremental refresh. There are other issues in this repo that speak to that approach. And using that approach would resolve this issue.
Who will this benefit?
This benefits folks who refresh incremental models more frequently than every 12 hours. It would also benefit folks who are conscious of incremental spend as a result of these tables.
Are you interested in contributing this feature?
No response
Anything else?
No response

It may be worth considering dropping the temporary table upon a successful incremental refresh

From a user perspective, it would be awesome if dbt just drops temporary table like you mentioned.
@mikealfare What do you think about the following acceptance criteria?
Proposed acceptance criteria

When materializing a model, any intermediate database objects that are created along the way are dropped by the end of the materialization

We can re-use this acceptance criteria for other types of materializations as well (not just incremental models).

Questions about temp table vs. expiring permanent table vs. non-expiring permanent table
@mikealfare is there any way to create the intermediate table so that it is droppable?
Ideally, we'd avoid any intermediate objects persisting beyond the materialization (even if they they expire after X hours).
Is there something about adding an expiration to a permanent table that makes it harder to drop? Or are permanent tables inherently hard to drop in BigQuery? Is using a real BigQuery temp table an option?
Current implementation
To the best that I can tell, we are not creating temp tables. Rather, it looks like the intermediate table is a permanent table with an expiration of 12 hours (like you mentioned).
Side note: To make the code easier to read, it would be nice to replace references to "temp" or "temporary" to be either "intermediate" or "expiring" instead (to the extent either/or are accurate).

Full code trace

macros/materializations/incremental.sql#L131
macros/materializations/incremental.sql#L26-L39
macros/adapters.sql#L29
macros/relations/table/options.sql#L3
impl.py#L728
impl.py#L737
macros/relations/options.sql#L4

Options for acceptance criteria
These are a mix of both behavior and implementation detail.
Option 1 includes the ideal state that all intermediate objects are dropped by the end of the materialization.
Options 2 and 3 explore what we could do if Option 1 isn't possible or practical for some reason.
Option 1

Create an intermediate table using a permanent table without any expiration time.
Try to drop it at the end.
Block until time out, error, or success.
Raise error if any, otherwise continue.

Alternatively, use a (non-permanent) temporary table somehow.
Option 2

Set expiration time for "temp" table to minimum time possible (60 minutes?).
Try to drop it at the end.
On error, make a log entry and continue anyway.

Make a log entry that the intermediate table will expire after X minutes.

Option 3
Add detail to one of the GitHub issues that we tried dropping the "temp" table and it didn't work (for some unknown reason).

Set expiration time for the intermediate table to minimum time possible (60 minutes?).
Don't try to drop it at the end.
Make a log entry that the intermediate table will expire after X minutes.

@dbeatty10 @mikealfare
Can we also explore an option where the user can define which dataset the temp table gets materialized in? I understand the tables are already configured with an expiration policy, but if the user is refreshing the models at a cadence faster than the expiration, or the model takes a longer time to build, the table will be visible to users who aren't supposed to see it, which might cause some confusion (This will be true if the accesses are defined on the dataset level).

Per @Fleid in an internal Slack conversation here, we don't have the bandwidth to tackle this.
So labeling this as help_wanted for a motivated community member to take on.
Ideally, a PR that solves this would:

Implement Option 1 by dropping any intermediate tables during the materialization so they don't persist beyond
Be well-tested

See here for an implementation idea.
And see here for ideal acceptance criteria.

Hi @dbeatty10 ,
I have followed your suggestion here and created a PR. I have also added a variable that can be defined in dbt_project.yaml tmp_relation_dataset where developers can define which dataset the tmp relations need to be materialized in. The default behavior remains the same, and the temp relations are dropped in both scenarios.
I have not updated the default expiration as drop_relation is dropping the table after execution.
Please let me know if you need me to update anything else. Thanks!!


[] operator not supported for strings

PHP 7.1 ... in function detectFulltextIndex
Seems doing
$a = ''
$a[] = 'bla'

is fatal in 7.1 ...  so change $context['fulltext_index'] = ''; to $context['fulltext_index'] = array(); and  if (is_array($context['fulltext_index'])) to if (!empty($context['fulltext_index']))
I do not immediaty see where it being a string (vs empty array) iis required, although it is in a global

If I read the code correctly, the array-form is used only in alterFullTextIndex to drop the indexes.
Also the global seems to be used in the template only to check for !empty, so if we want to break everything we could:
https://github.com/elkarte/Elkarte/commit/90442c0e40cd26f6254e942768eb58ea97d6b040

Seems reasonable ...  if the only check is already !empty then '' or array() will be the same.
This is probably in 1.1 as well, have not checked.

Yep, it's 1.1 as well, in fact the commit over there is for 1.1. :angel:

Fixed in 1.1 with 9850920fbc900cecc6df9e9c270ea42e7b3c1b7b to backport to 1.0.x


feat: useMultiStateValidator

Acts much like the useStateValidator but this time it handles multiple states simultaneously.
Example
Below validator will turn to true only if both values are even
const [state1, setState1] = React.useState(1);
const [state2, setState2] = React.useState(1);

const [[isValid]] = useMultiStateValidator([state1, state2], s => [s.every(num => !(num % 2))]);

:tada: This PR is included in version 12.7.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


ME81 Thermostat Valve State is missing

The  ME81 Thermostat is working fine, but the valve state is missing
thanks
      {         "code": "valve_state",         "name": "阀门状态",         "type": "Enum",         "values": "{\"range\":[\"open\",\"close\"]}"

The valve state is not missing, it is mapped to hvac_action.

Ok, thanks.
I cant find the valve state

If you attach the diagnostics for the device, I might be able to see more clearly why the hvac_action is not showing as expected.

Hello make-all,
attached is my diagnosis of the device
Thanks!
`{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2024.2.5",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.12.1",
"docker": true,
"arch": "x86_64",
"timezone": "Europe/Berlin",
"os_name": "Linux",
"os_version": "6.6.16-haos",
"supervisor": "2024.02.1",
"host_os": "Home Assistant OS 12.0",
"docker_version": "24.0.7",
"chassis": "embedded",
"run_as_root": true
},
}

},
"integration_manifest": {
"domain": "tuya_local",
"name": "Tuya Local",
"codeowners": [
"@make-all"
],
"config_flow": true,
"dependencies": [],
"documentation": "https://github.com/make-all/tuya-local",
"integration_type": "device",
"iot_class": "local_push",
"issue_tracker": "https://github.com/make-all/tuya-local/issues",
"requirements": [
"tinytuya==1.13.2"
],
"version": "2024.3.1",
"is_built_in": false
},
"data": {
"name": "Lager-1.OG Einzelb\u00fcro",
"type": "avatto_me81_thermostat",
"device_id": "REDACTED",
"device_cid": "",
"local_key": "REDACTED",
"host": "REDACTED",
"protocol_version": "auto",
"tinytuya_version": "1.13.2",
"api_version_set": 3.3,
"api_version_used": 3.3,
"api_working": true,
"status": {},
"cached_state": {
"updated_at":<PHONE_NUMBER>.9578216,
"1": true,
"2": "manual",
"10": true,
"16": 30,
"19": 30,
"24": 210,
"26": 12,
"27": -2,
"36": "open",
"39": true,
"40": true,
"43": "in",
"45": 0,
"101": 1,
"102": "00"
},
"pending_state": {},
"connected": true,
"force_dps": [],
"home_assistant": {
"name": "Lager-1.OG Einzelb\u00fcro",
"name_by_user": null,
"disabled": false,
"disabled_by": null,
"entities": [
{
"disabled": false,
"disabled_by": null,
"entity_category": "diagnostic",
"device_class": null,
"original_device_class": "problem",
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "binary_sensor.lager_1_og_einzelburo_problem",
"state": "off",
"attributes": {
"fault_code": 0,
"device_class": "problem",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Problem"
},
"last_changed": "2024-03-05T17:13:50.272308+00:00",
"last_updated": "2024-03-05T17:13:50.272308+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "select.lager_1_og_einzelburo_temperature_sensor",
"state": "Internal",
"attributes": {
"options": [
"Internal",
"External",
"Both"
],
"icon": "mdi:home-thermometer",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Temperature sensor"
},
"last_changed": "2024-03-05T17:13:50.297281+00:00",
"last_updated": "2024-03-05T17:13:50.297281+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "select.lager_1_og_einzelburo_program_type",
"state": "Disabled",
"attributes": {
"options": [
"Disabled",
"Weekdays+Weekend",
"Six working days",
"Daily"
],
"icon": "mdi:calendar-week",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Program type"
},
"last_changed": "2024-03-05T17:13:50.297685+00:00",
"last_updated": "2024-03-05T17:13:50.297685+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": "temperature",
"icon": null,
"unit_of_measurement": "\u00b0C",
"state": {
"entity_id": "number.lager_1_og_einzelburo_maximum_temperature",
"state": "30",
"attributes": {
"min": 30.0,
"max": 90.0,
"step": 1.0,
"mode": "auto",
"unit_of_measurement": "\u00b0C",
"device_class": "temperature",
"icon": "mdi:thermometer-chevron-up",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Maximum temperature"
},
"last_changed": "2024-03-05T17:13:50.273066+00:00",
"last_updated": "2024-03-05T17:13:50.273066+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": "temperature",
"icon": null,
"unit_of_measurement": "\u00b0C",
"state": {
"entity_id": "number.lager_1_og_einzelburo_minimum_temperature",
"state": "12",
"attributes": {
"min": 5.0,
"max": 20.0,
"step": 1.0,
"mode": "auto",
"unit_of_measurement": "\u00b0C",
"device_class": "temperature",
"icon": "mdi:thermometer-chevron-down",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Minimum temperature"
},
"last_changed": "2024-03-05T17:13:50.273182+00:00",
"last_updated": "2024-03-05T17:13:50.273182+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": "\u00b0",
"state": {
"entity_id": "number.lager_1_og_einzelburo_temperature_calibration",
"state": "-2",
"attributes": {
"min": -9.0,
"max": 9.0,
"step": 1.0,
"mode": "auto",
"unit_of_measurement": "\u00b0",
"icon": "mdi:thermometer-check",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Temperature calibration"
},
"last_changed": "2024-03-05T17:13:50.273280+00:00",
"last_updated": "2024-03-05T17:13:50.273280+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": "\u00b0",
"state": {
"entity_id": "number.lager_1_og_einzelburo_temperature_hysteresis",
"state": "1",
"attributes": {
"min": 1.0,
"max": 5.0,
"step": 1.0,
"mode": "auto",
"unit_of_measurement": "\u00b0",
"icon": "mdi:thermometer-plus",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Temperature hysteresis"
},
"last_changed": "2024-03-05T17:13:50.273374+00:00",
"last_updated": "2024-03-05T17:13:50.273374+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "lock.lager_1_og_einzelburo_child_lock",
"state": "locked",
"attributes": {
"friendly_name": "Lager-1.OG Einzelb\u00fcro Child lock",
"supported_features": 0
},
"last_changed": "2024-03-05T17:13:50.526076+00:00",
"last_updated": "2024-03-05T17:13:50.526076+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": "switch",
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "switch.lager_1_og_einzelburo_anti_frost",
"state": "on",
"attributes": {
"device_class": "switch",
"friendly_name": "Lager-1.OG Einzelb\u00fcro Anti-frost"
},
"last_changed": "2024-03-05T17:13:50.556675+00:00",
"last_updated": "2024-03-05T17:13:50.556675+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": "config",
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "button.lager_1_og_einzelburo_factory_reset",
"state": "unknown",
"attributes": {
"friendly_name": "Lager-1.OG Einzelb\u00fcro Factory reset"
},
"last_changed": "2024-03-05T17:13:50.325196+00:00",
"last_updated": "2024-03-05T17:13:50.325196+00:00"
}
},
{
"disabled": false,
"disabled_by": null,
"entity_category": null,
"device_class": null,
"original_device_class": null,
"icon": null,
"unit_of_measurement": null,
"state": {
"entity_id": "climate.lager_1_og_einzelburo_2",
"state": "heat",
"attributes": {
"hvac_modes": [
"off",
"auto",
"heat"
],
"min_temp": 12,
"max_temp": 30,
"target_temp_step": 1.0,
"current_temperature": 21.0,
"temperature": 30,
"friendly_name": "Lager-1.OG Einzelb\u00fcro",
"supported_features": 385
},
"last_changed": "2024-03-05T17:13:50.272930+00:00",
"last_updated": "2024-03-07T04:23:36.495929+00:00"
}
}
]
}
}
}`

Hello, i just installed the new version, but i can´t font the Thermostat Valve State

Sorry, but I cannot tell anything from that.  Please attach diagnostics as before.

Hello Horst,
The Valve State is visible, but only when valve is open. Then you will see hvac_action: heating. When valve is closed it will disappear. When you use the entity in a mushroom climate card, it works. The card shows you when the valve is open an extra symbol.
I got an other issue, in my log I have this error:
2024-04-05 14:54:43.017 WARNING (MainThread) [custom_components.tuya_local.climate] avatto_me81_thermostat.yaml/climate: Unrecognised HVAC Action close ignored
2024-04-05 14:35:47.706 WARNING (MainThread) [homeassistant.components.climate] Entity None (<class 'custom_components.tuya_local.climate.TuyaLocalClimate'>) implements HVACMode(s): off, auto, heat and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at https://github.com/make-all/tuya-local/issues
This perhaps have to to with errors made for id:1 and id:2
id:1 switches the thermostat on or off, the display is switched on or off.
hvac_mode should actually be on or off
id:2 allows you to choose between manual setting or automatic. With automatic, the programmed program is followed.
Auto should therefore not be in hvac_mode, but should be a separate selector switch, such as: childlock
So: manual/auto


Component generated with module parameter is not placed inside module folder (only imported in module)

Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [* ] feature request

Versions.
1.2.1

Repro steps.
ng generate component MyWidget -m WidgetLibrary
Generated component folder "my-widget" is not subfolder of "widget-library" module folder.
It is created in 'src/app' folder - 'src/app/my-widget' and only imported in WidgetLibraryModule.

The log given by the failure.

Desired functionality.
Component folder to be generated inside specified module folder.
'src/app/widget-library/my-widget'

Mention any other details that might be useful.

This could be an enhancement, as most of the time you would want your component to be created inside the specified module and there is no need to explicitly set the path of the module, which you have already provided with parameter "-m".

This behavior is intentional and the purpose of the module option.
The CLI will automatically locate the nearest module based on the current working directory and component path specified.  Specifying the module manually should only be needed in advanced scenarios.
Also, there is the "--flat" option to disable the creation of the component directory if desired.

But it is not convenient to change directory before executing the command. I want to have single terminal opened to the project root folder and from there to execute all my commands, most of which are not ng-cli related.
What @clydin explained that you have to navigate to the module directory in which you want to create the component is not practical at all. As I said earlier, it will be much better if you specify module for the generated component to put generated component folder inside the module folder.

I don't think this would be a very good addition, the --module is meant to specify a module to be imported in and shouldn't change the path of the generated component. I think the existing options that @ahaan729 and @clydin highlited work well for this scenario.


Vincent/general styling

Add styling to some of the pages that needed it
Description

Got the font mostly set to biski will change later, changed margin sizes in places and redid a lot of the current css used for the overview (still not done)
Related Issue

How Has This Been Tested?

Visually through live server
Checklist

[ ] All automated tests have been passed locally (unit / e2e / linter / coverage)
[ ] New unit and E2E tests have been added to address the changes made
[ ] Manual testing has been performed according to the provided instructions
[ ] Code follows team's coding style, convention and standards
[ ] Documentation has been updated to reflect relevant changes (if applicable)

Screenshots (if applicable):

Looks good


Footnote definitions don't support indenting?

You can indent the definition of a link, like so:
This is a [link][1]

  [1]: http://foo.com

But this doesn't seem to work:
This footnote[^1] doesn't work.

  [^1]: Nope, it doesn't.

I'm not sure if it's supposed to work though, since this is not quite standard.

Additionally, they have to appear after link definitions if link definitions are indented. If you have footnote definitions immediately preceding indented link definitions (even with a couple of blank lines in between), the link definitions don't work anymore.

Sorry for taking so long to answer. What version of Hoedown are you using? It doesn't seem to happen with the latest version:

This footnote1 doesn't work.

Nope, it doesn't. ↩

Additionally, they have to appear after link definitions if link definitions are indented. If you have footnote definitions immediately preceding indented link definitions (even with a couple of blank lines in between), the link definitions don't work anymore.

I've tried lightly, but I can't reproduce this either.

Ah I may be using an outdated version indeed. I'm using some python bindings, like Hoep and Python-Hoedown, and I think they haven't updated the Hoedown source for more than a year! I'll see if I can patch either of those with a newer version, sorry about that.
(btw, is there any preferred Python package for Hoedown?)

No problem.
Hmm, bad luck, both packages are using version 2 of Hoedown, it won't be easy to upgrade them to v3...

I personally think Hoep is slightly better, if you must choose between those two. More customisable, and the API feels more Pythonic. But my favourite Python library for Markdown is Mistune. It is pure Python (speedup available with Cython), and with proper customisation its output can be almost identical to Hoedown’s.

Yeah I tried mistune, already, but thanks (I'm currently evaluating a few different Markdown libraries for PieCrust).

For products like PieCrust I strongly recommend you pick a CommonMark one. If your Markdown is parsed in a standard way, you can switch parsers later without worrying about weird syntax issues popping up.
If you're fine with pure CommonMark syntax (Markdown + fenced code blocks) I'd definitively use CMark, it's fast and maintained. If you need extensions right now, I'd go for Mistune, even though it's not CommonMark.

In case you're interested, Hoedown v4 is even faster than CMark, it'll have more extensions than the current version and will implement CommonMark. It's still in development, but already usable (some extensions missing). You can find it in the develop branch.

Cool, thanks for the info!


Suggestion: add this repo to artifacthub.io

Hello and thank you for your hard work on this project.
I would like to deploy this to my cluster with the Terraform helm provider, but there is no simple way of adding this repo's helm chart and deploy it. Unless I am not aware of this chart's availability on a helm repository, publishing this chart to artifacthub.io would make things easier in that use case, and many other situations.

Hi !
Another option would be to host the chart repository as GitHub Pages directly.
https://medium.com/@mattiaperi/create-a-public-helm-chart-repository-with-github-pages-49b180dbb417

This would be lovely one!

Need a chart repo URL to use this chart in kustomize in helmCharts key

If you would like to see this feature implemented, please go to https://github.com/aureq/cert-manager-webhook-ovh, star the repo and open a feature request.


Wrong Forwarded header when original X-Forwarded-For is an IPv6

When X-Forwarded-For contains an IPv6 and server.forward-headers-strategy is set to framework, Gateway will pass an incorrect Forwarded header to downstream, as shown in the picture - resulting in an exception being thrown in services that also set server.forward-headers-strategy=framework

I have narrowed down issue to spring-cloud-gateway, as nothing else seems to add Forwarded header. I have prepared a reproducer that demonstrates this using IPv6 only haproxy and docker
https://github.com/ZIRAKrezovic/gateway-reproducer.git
There is a single test that starts 3 containers and uses ipv6 only to communicate, up to returning back to host (gateway) on 8080. Make sure to adjust the port in haproxy.cfg and application.properties if they should be changed.
The test contains a commented out direct entry to its own "/test" REST resource, and a call that causes the issue to "/testgateway", that simply routes back to itself and rewrites the path to "/test"

I can also reproduce this by using WebClient. Example has been updated.
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.reactive.server.WebTestClient;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)
class DemoApplicationSimpleTests {
    @Autowired
    private WebTestClient webClient;

    @Test
    void contextLoads() {
        webClient.get()
                // working url, bypasses gateway
                //.uri("/test")
                .uri("/testgateway")
                .header("X-Forwarded-For", "fd00:fefe:1::4")
                .exchange()
                .expectStatus()
                .isOk();
    }
}


InTune policy conflict within hardening guide for windows 10 and later settings catalog

In the ACSC hardened template for Windows 10 and later. The setting Browser -> Allow Password Manager (User/Computer) causes a conflict with Microsoft Edge -> Password manager and protection -> Enable saving passwords to the password manager (User/Computer)
The Browser settings are Policy-CSP items that only apply to Microsoft Edge 45 and earlier. The Microsoft Edge policy itself is the correct policy that applies to Edge 46 and later
To resolve this, we have to align all ALL 4 settings to resolve the conflict or remove the Browser settings from the catalogue settings.

Thank you for opening this issue and providing this feedback. I will implement the changes to resolve the conflicts, as well as update the relevant Edge settings in the coming weeks.

@CryptikCrisis I've updated the 'Windows Security Baseline (for use with ACSC Windows Hardening Guidelines)' policy to remove the conflict with Password Manager. I've opted to keep this setting in the 'Intune ACSC Windows Hardening Guidelines' in case someone has chosen not to deploy the Edge Security Baselines alongside this policy (in which case, the conflict will have to be resolved manually).
Please let me know if you had any additional input or if this does not resolve the issue.


Use alternative endpoints for Prime Brazil

Hi there! I was having issues syncing Amazon Prime in Brazil, possibly similar to the issues in #211, and I found the Account menu on the site was using a different set of endpoints to retrieve data here from my region. I'm not entirely sure what-all countries this might affect, or even if this is only relevant when region === 'na', so I'm not expecting this PR to be ready in the current state, but I wanted to open it and see what kinds of paths forward there might be.
I was previously receiving 4xxs or redirects to the main storefront for the /gp endpoints. Weirdly enough, I've just gone back and tested the previous endpoints and they're now working for me, so I don't have copies of the specific errors handy - I did have to log back in to Amazon a few different times while trying to set up the debugging environment for the extension, so maybe there's a situation where a cookie is only partially set or something, and only some endpoints work?
These new endpoints all seemed to work for me out of the box anyway, and are the ones Prime used on the Account page - here's some example data, which seems structurally identical to what the code is expecting:
Sample data
GET https://www.primevideo.com/region/na/api/getProfiles [etc]
{
  "__type":"atv.wps#GetProfilesOutput",
  "canCreate":true,
  "canEdit":true,
  "isProfileImplicitlySelectedOrLocked":false,
  "links":{"preEditProfile":"/region/na/profiles/ref=...?step=edit",...},
  "metadata":{...},
  "profiles":[...],
  "strings":{"DV_PROFILES_CANCEL":"Cancel",...}
}

GET https://www.primevideo.com/region/na/api/getWatchHistorySettingsPage?widgetArgs={}
{
  "__type": "atv.wps#SettingsOutput",
  "metadata": {...},
  "notifications": [...],
  "widgets": [
    {...,"widgetType": "page-title"},
    {...,"widgetType": "navigation-tabs"
    },
    {
      "content": {
        "__type": "atv.wps#ActivityHistoryOutput",
        "content": {
          "__type": "atv.wps#ActivityHistoryItems",
          "nextToken": "...",
          "seeMoreLink": {
            "href": "/region/na/settings/watch-history/...",
            "text": "Load more"
          },
          "strings": {...},
          "titles": [
            {
              "date": "January 21, 2023",
              "titles": [
                {
                  "actions": {...},
                  "children": [...],
                  "gti": "...",
                  "imageSrc": "...",
                  "time": ...,
                  "title": {
                    "href": "/region/na/detail/...",
                    "text": "American Gods, Season 3"
                  }
                }
              ]
            }, ...
          ]
        }
      },
      "widgetType": "watch-history"
    }
  ]
}

GET https://www.primevideo.com/region/na/api/enrichItemMetadata?metadataToEnrich={"playback":true}&titleIDsToEnrich=["amzn1.dv.gti.bebbba29-32ef-f78d-62c1-8d091d35f1c8"]
{
  "__type": "atv.wps#StorefrontEnrichItemsOutput",
  "enrichments": {
    "amzn1.dv.gti.bebbba29-32ef-f78d-62c1-8d091d35f1c8": {
      "cardBundle": {...},
      "degradations": [],
      "entitlements": [],
      "filterEntitled": false,
      "hasSubtitles": false,
      "messages": {...},
      "playbackActions": [
        {
          "appFallbackUrl": "https://www.microsoft.com/store/apps/9P6RC76MSMMJ",
          "disableJs": false,
          "fallbackUrl": "/region/na/detail/0QG47KI9CRBKFY19NDP5JJH808/ref=...?autoplay=1&t=0",
          "label": "Play S3 E10",
          "legacyOfferASIN": "...",
          "playbackExperienceMetadata": {},
          "playbackStatus": "FEATURE_IN_PROGRESS",
          "refMarker": "...",
          "resumeTime": 0,
          "sessionID": "...",
          "titleID": "amzn1.dv.gti.bebbba29-32ef-f78d-62c1-8d091d35f1c8",
          "videoMaterialType": "Feature"
        }
      ],
      "progress": {
        "isLive": false,
        "percentage": 100.0
      },
      "properties": {}
    }
  },
  "isTrailerAutoplayEnabled": true,
  "metadata": {
    "availability": {
      "description": "Fatal Count: 0, Error Count: 0, Warning Count: 0",
      "severity": "NoDegradation"
    }
  }
}

Is there some process to test this more thoroughly among more users, to make sure this doesn't break anything? Given the old endpoints are working again for me now, maybe it would be better to validate a "200 OK" response from the original ones before falling back to these ones - WDYT? I'd appreciate any guidance on how to validate this so we can determine if a change to use these new endpoints would be helpful.

Thanks for the PR! Closing in favor of #286.


extract to component fails for class side methods

Changing the receiver when extracting a method from a class side method, can cancel the refactoring:
https://github.com/feenkcom/gtoolkit/assets/16563825/5174a03e-ec60-485b-a713-83974c879458

https://github.com/feenkcom/gtoolkit/assets/16563825/2641cf5c-dcff-4c9c-9506-1b43eb6b6e8f


port http-server widl interface to smithy

a version of this exists in the weld/examples/interface folder

fixed in commit #dbe5f6724455a4402c6cd745a3889e38c8ea861d
wasmcloud/interfaces/httpserver


Account MyAccount, login error, Error: unable to verify the first certificate, reconnect in 65s

Today, suddenly the MELcloud plugin stopped working. When checking my Homebridge logs, I see this message:
[5/10/2023, 7:28:15 PM] [homebridge-melcloud-control] Account MyAccount, login error, Error: unable to verify the first certificate, reconnect in 65s.
The service works through MELcloud app, any idea why suddenly started to fail? I've been using it for months.
Thanks, BR
Abel

with me also the same error in the log

Same error here

Fix:
npm install --save node_extra_ca_certs_mozilla_bundle
and in melcloud.js add
in header:
const fs = require('fs');
const https = require('https');
in constructor:
https.globalAgent.options.ca = fs.readFileSync('node_modules/node_extra_ca_certs_mozilla_bundle/ca_bundle/ca_intermediate_root_bundle.pem');

The website https://app.melcloud.com/Mitsubishi.Wifi.Client/Login/ClientLogin is no longer available.

s through MELcloud
The website https://app.melcloud.com/Mitsubishi.Wifi.Client/Login/ClientLogin is no longer available.

Same issue here

Same issue here.

Same issue here, please update plugin

thanks @grzegorz914, it works perfectly.


how can i update regex

current regex used is (/:[a-zA-Z_]+/) i want to update in to (/\b[a-zA-Z_]+/) so that it only search from the beginning of the each word in string.
Example:-
India - In
Australia - AU
America - US
so when i type I in input result should be only "India - In" not Australia or America
or
if i type us it should only return America - US not A'us'tralia- AU even though Australia has us in it
Can you helps so that i can override the search  regex.

Please use Observable source for customized search.


Incomplete installations on Travis

We're installing on Travis-CI and notice that sometimes (probably rate limiting) assets are reported as installed (https://travis-ci.org/Elgg/Elgg/jobs/92918942#L261) but don't contain the build resources (https://travis-ci.org/Elgg/Elgg/jobs/92918942#L606 shows dist/jquery.js doesn't exist).
What can we do about this? If all files aren't installed, shouldn't composer report it as a failure?

Because, you don't install the stable version of jquery. In dev, the dist folder doesn't exist. And this plugin downloads only the source.

Our composer.json does have "prefer-stable": true. Is there really no way to use the "^2.1.4" syntax?

Or does resolving that to a particular tag cost a bunch of GitHub API requests...

I just did a test with:
{
    "require": {
        "bower-asset/jquery": "^2.1.4"
    },
    "prefer-stable": true,
    "minimum-stability": "dev"
}

Reslut:
$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
  - Installing bower-asset/jquery (2.1.4)
    Loading from cache

Writing lock file
Generating autoload files

The stable version with dist folder is downloaded.
For your question, you can see the FAQs How to reduce the number of requests for getting the package definitions?.

Same result with --prefer-source option:
$ composer install --prefer-source
Loading composer repositories with package information
Installing dependencies (including require-dev)
  - Installing bower-asset/jquery (2.1.4)
    Cloning 7751e69b615c6eca6f783a81e292a55725af6b85

Writing lock file
Generating autoload files

It is recommended that add the --prefer-source option in your Travis config.


WIP: mercurial support

I'm hoping to throw together basic mercurial support. I've still got a ways to go, but I wanted to get this PR up now to help prevent duplication of effort, if anyone else is possibly working on this.

Closing this, I don't think I'm going to be able to get this working in a reasonable amount of time :(


CI: Use newer checkout and upload-artifact

Sorry, I completely missed this when you posted it.  I just did the merge.


hello,I would like to ask a question, the CPU speed is faster than the MYRIAD execution speed, what is the reason?

AMD Ryzen 5 1600 Six-Core Processor × 12
MYRIAD is NCS 2
ssd_bin=***/inference_engine_samples_build/intel64/Release/object_detection_sample_ssd
network=/opt/intel/computer_vision_sdk_2018.5.455/deployment_tools/intel_models/person-detection-retail-0013/FP16/person-detection-retail-0013.xml
img=data/persons
${ssd_bin} -i $img -m ${network} -d MYRIAD -ni 10

Your CPU drains much more power than Myriad. A typical CPU would require smth like 65W of power (Xeons can eat more than 100W). NCS2 stick eats 1-2W. So, there's a 30-60x difference in power consumption. A typical perf difference is ~5x. So, the raw perf of NCS stick is about 5 times lower, but the power-efficiency is about 5-6x better.

thanks


Refactor validation to the last step.

This moves the validation the end, so that output of all data sets is written to disk prior to validation. This saves time when you want to run the script repeatedly, and want to skip validation for debugging purposes.

Makes sense. Are you just aborting script execution when you start seeing "Validating..." messages while debugging?

Yes.