feat(protocol): Auction

Describe the feature request
We want to try an implementation of an auction mechanism, ideally as an L3 running parallell with our L2 running the current tokenomics, to compare and contrast. This thread can serve as a discussion among core members to figure out the best way to make a simple, early, non-gas optimzied proof of concept.
Describe alternatives you've considered
Description of the alternatives you've considered here.
Additional context
Additional context here.

The main thing I like about this strategy vs other tokenomics is:

Less math, less things can "go wrong" or be obtuse to understand.
Proofs are only generated by people who will actually be able to submit them, not wasting resources, or other peoples time/hardware.
Slightly more fair distribution depending on implementation, largely I think a core small group would still prove most of the blocks though, as you could bid through multiple addresses.
Less manualy tweaking of parameters (proofTimeTarget, proofTimeIssued, etc) that cause the fee to either go exponentially to infinite, or approach 0.

This is a very simple, one day WIP:
https://github.com/taikoxyz/taiko-client/pull/241
https://github.com/taikoxyz/taiko-mono/pull/13811
It ignores more complicated concepts like "bidding for batches", and things like this, and simply says:
after a block is proposed, you bid, and then an auction ends, and whoever says they will accept the least amount of wei per gasUsed as the reward, wins.
and the proposal fee becomes some multiplier of the averageProofReward.
and then the client says
here is the bidding strategy I would like to use (Always bid, Profitable only [if you can estimate the cost of proofs only], Down to a minimum amount, etc etc), and then if you are the successful bidder, you start to generate the proof.
It is missing a lot, obviously, but it simply something to get the discussion/ball rolling.

Implementing a simple, batch-based auction system for prover cost-efficiency
Background
Our current tokenomics framework rewards the fastest prover, encouraging prioritization of speed over cost-effectiveness. This conflicts with Taiko's commitment to delivering cost-efficient proofs. By incentivizing cost-effective proofs, we can significantly reduce Taiko's overall Layer 2 (L2) expenses, enhancing our competitive edge in the marketplace.
Proposed Solution
I suggest introducing an auction mechanism to recalibrate provers' incentives, guiding them towards prioritizing cost-effectiveness. This mechanism facilitates provers to bid for block rewards, creating a transparent fee market.
Design Considerations
Batch-Based Strategy
Given the high gas fees associated with Ethereum, we endorse a batch-based strategy for running auctions. This approach bestows the winning bidder with proving rights for a batch of blocks, thereby reducing per-block gas costs. During the testnet phases, we anticipate starting with a smaller batch size, with plans to scale up to 256 blocks by the mainnet launch.
Considerations for Future Blocks and Gas Costs
To mitigate the potential for accumulated ZKP delays, I suggest conducting auctions for upcoming blocks even before they are proposed. This approach does introduce uncertainty for provers due to the unknown block gas used and data size at the auction's outset. To address this, I propose a pricing model for the auction based on the gas/data usage of the auctioned block, with the block reward calculated as x*y if the winning bid is x TKO token per gas and the actual gas used by the block is y. Here, x will be termed as the bid per gas, or simply bid.
Bidding Procedures and Deposit Requirements
I suggest setting the initial bidding price for new auctions at s=2*p, while maintaining a moving average bid for all verified blocks, represented as p. Each successive bid should be at least 5% lower than the current bid. Bidders would need to deposit s * max_block_gas_limit * num_blocks * 1.5 Taiko tokens for the batch. A penalty of s * max_block_gas_limit * 1.5 Taiko tokens will be imposed and then burnt for each block the winner fails to prove within the stipulated timeframe; if successful, the deposit will be refunded.
Auction Window, Proving Window, and Multiple Auction Management
The auction window starts with the first bid and ends after either 5 minutes or 25 Ethereum blocks( or if the bid falls to 50% smaller than p?). Blocks become eligible for proving only once the auction has officially ended. The auction winner must submit the first ZKP for the block within 60 minutes of the block proposal or the auction's end, whichever is later. Other provers can submit proofs to create additional fork choices after the initial ZKP submission or upon the proving window's expiration. Multiple concurrent auctions for different batches are allowed, but I suggest limiting the upcoming 100 batches for improved manageability.
Reward and Penalty Mechanisms
If the verified block's chosen fork choice originates from the auction winner's proof, the winner's deposit and reward TKO tokens are refunded. If the chosen fork choice comes from another prover's proof, the latter receives half the deposit, and the remaining half is burnt. This mechanism ensures fair competition and deters manipulation, such as winners submitting correct proofs via different addresses.
Absence of Fallback Mode
There is no fallback fee/reward model for blocks that are not auctioned. This simplifies the auction design and eliminates the need for dual tokenomics systems - an auction-based primary system and an alternative fallback one.
Block Fees
I propose to charge a fee in Taiko tokens from the block proposer calculated as p * gas_limit, where p is the moving average bid for all verified blocks. We could introduce another moving average q to cover the bid of all unverified blocks that have been auctioned. For instance, the fee could be calculated as (p * 0.5 + q * 0.5) * gas_limit.
Challenges
Insufficient Competition
The success of the proposed auction framework heavily relies on the participation of many independent entities. If provers collude or form alliances to increase their profits, they could strategically place a single bid at the initial/highest price s, leading to a constant rise in rewards. Such behavior contradicts the system's intended cost-efficient competition.
Nevertheless, this behavior may unintentionally incite competition. As the proving reward considerably increases, it is likely to catch the attention of other provers, thus encouraging their participation. This market self-regulation could restore balance and maintain the competitive integrity of the auction process.
Additional Verification Delay
Introducing an auction window inevitably adds an extra delay to the proving time. This delay might not be noticeable when the average proving time is relatively long (over 30 minutes). Still, it could become significant in future scenarios where proof generation takes just a few minutes.
However, as emphasized at the outset of the proposal, our goal is to optimize for cost, not speed. While this additional delay is an important consideration, it's unlikely to pose a major hurdle to our primary objective of cost-effectiveness.

Some previous discussion on this: https://github.com/taikoxyz/internal/issues/121
Also let's take into account batch verification of proofs onchain when possible! Otherwise we'll have to modify things again when we can do this.

Less math, less things can "go wrong" or be obtuse to understand.
Less manualy tweaking of parameters (proofTimeTarget, proofTimeIssued, etc) that cause the fee to either go exponentially to infinite, or approach 0.

It seems underappreciated that the current proving system works exactly the same as the L2 proposing fee, which in turn is based on the data blobs EIP-1559 system (which in its turn is based on the current EIP-1559)! Same mechanism, same inputs, exactly the same math, exactly the same code (well in theory, unfortunately our current code base contains two pretty distinctive paths for doing the same thing). Even on the nodes side exactly the same logic needs to be followed when proposing blocks as is currently required for submitting proofs! This is why I like in the first place, same well known system, all code we already have basically reused as is, but in practice it seems like it's not really seen that way. :(

Slightly more fair distribution depending on implementation, largely I think a core small group would still prove most of the blocks though, as you could bid through multiple addresses.

Yeah that's also my fear about an auction system. Will it actually have a different outcome then the current prover system that allows us to reuse code, in exchange for a completely new system that may end up being the same (single prover winning everything).
Why would multiple addresses help though?

after a block is proposed, you bid, and then an auction ends, and whoever says they will accept the least amount of wei per gasUsed as the reward, wins.

Will it take into account just the expected reward? Or also the expected proving delay? In the issue linked above I think it makes sense to take both into account.
To minimize game theory things like the most efficient prover submitting a high bid, and then other provers having to bid lower, and then that same more efficient prover submitting a new lower bid only when somebody outbid him (and thus wasted gas and so won't bid anymore in the future, so price will remain higher) I think an auction that defines a curve where the prover fee/delay goes up in time is probably better. That way only the prover that wins the auction (bids the fastest, lowest prover fee/expected proof delay) spends gas (when using flashbots).

Our current tokenomics framework rewards the fastest prover, encouraging prioritization of speed over cost-effectiveness. This conflicts with Taiko's commitment to delivering cost-efficient proofs. By incentivizing cost-effective proofs, we can significantly reduce Taiko's overall Layer 2 (L2) expenses, enhancing our competitive edge in the marketplace.

Hmm it doesn't! It very much aims to find the most efficient prover for the target time.

To mitigate the potential for accumulated ZKP delays, I suggest conducting auctions for upcoming blocks even before they are proposed. This approach does introduce uncertainty for provers due to the unknown block gas used and data size at the auction's outset. To address this, I propose a pricing model for the auction based on the gas/data usage of the auctioned block, with the block reward calculated as x*y if the winning bid is x TKO token per gas and the actual gas used by the block is y. Here, x will be termed as the bid per gas, or simply bid.

Unfortunately gas is not a great proxy for proving cost. I think a couple of smallish risks here:

Because of the likely significant varying proving costs (well probably! Unprovable blocks may make this much less so) it could be that provers will only want to bid on the worst expected case to not lose money, which in turn makes sure the proving fee is higher than needed.
If the batch size is reasonably small the variance in blocks that need to be proven can be high, so the prover may again have to take into account the worst case scenario that makes sure he can prove all the blocks. This can increase the required prover fee as well.

I suggest setting the initial bidding price for new auctions at s=2*p, while maintaining a moving average bid for all verified blocks, represented as p. Each successive bid should be at least 5% lower than the current bid.

I think a curve going up in time has some nice properties (see above).

The auction window starts with the first bid and ends after either 5 minutes or 25 Ethereum blocks( or if the bid falls to 50% smaller than p?). Blocks become eligible for proving only once the auction has officially ended. The auction winner must submit the first ZKP for the block within 60 minutes of the block proposal or the auction's end, whichever is later.

So you propose to still have a built-in target time into the protocol, similar to the current proving system?

Multiple concurrent auctions for different batches are allowed, but I suggest limiting the upcoming 100 batches for improved manageability.

The auctions can be for block ids %n, and so also n the number of auctions that need to be run for a sequential range of blocks, that way we make the system more parallelizable because now the prover doesn't have to be able to prove all sequential blocks himself, the work can be shared between up to n provers.

I propose to charge a fee in Taiko tokens from the block proposer calculated as p * gas_limit, where p is the moving average bid for all verified blocks.

Using the gas cost to estimate the prover cost isn't great because, regardless of the gas used in the L2 block, the prover has to pay the same gas fees to get the proof on-chain. These on-chain fees will (hopefully) be the biggest part of the proof generation cost (batching proof verification on-chain will obviously help here!).

Introducing an auction window inevitably adds an extra delay to the proving time. This delay might not be noticeable when the average proving time is relatively long (over 30 minutes). Still, it could become significant in future scenarios where proof generation takes just a few minutes.

Auctions make the most sense when we're pessimistic about prover times in the future. The redacted fee proving system would work well in the optimistic and pessimistic case which is part of why I like it.

I'm out of the loop on this, is there another issue/TLDR? One proof can be proofs for multiple blocks?

There currently is no loop to be in on. Yeah a proof of proofs so the proof verification cost on-chain can be lowered. I haven't really thought much about it to be honest, it also depends a bit on how blocks are assigned to provers, but only really two options that I currently see:

Proofs are still submitted per block, but those proofs are not immediately verified. The proof data is just made available on-chain, and that prover will get the reward for that block. Afterwards another prover (or of course maybe the same one) comes in and collects those proofs and verifies them all in a new proof that is verified on-chain. Only at this point are the blocks actually proven. This extra prover also needs to be paid somehow.
The block prover and the batch block prover are the same, we basically just allow multiple blocks to be proven at the same time in the smart contract, which internally supports batching to lower the verification cost. Easiest solution because no changes needed to the fees.

2 seems to be a good fit for an auction system. 1 seems to fit well when blocks aren't assigned to specific provers.

I would think so, because we need to slash the prover's deposit if they take a week to submit a proof for a block. I was thinking some small constant grace window + state.avgProofTime though, rather than a specific built-in target time. This window ending also allows someone else to submit the proof, and receive the other % of the deposit that wasnt slashed.

We have to be very careful with average proof times. If I understand correct that mean that the fastest prover can bring down the average time so much that only he would be able to submit proofs in a way that would not get slashed. After that happens, the most efficient provers cannot bid on the auction anymore because the given window would be impossible for them to achieve.

Agreed, this is the idea behind the configurable grace window, to make sure it's always somewhat realistic.
Thanks for the info on proof of proofs!

Agreed, this is the idea behind the configurable grace window, to make sure it's always somewhat realistic.

Isn't that basically just a fixed proof target with extra steps haha :)

I like the idea of the auction because in ideal conditions less math, less complex. Also saving (gas and resource) perspective, good if we have no or less waste.

In terms of complexity it's hard to beat basically 10 lines of code using code/formula we already have to use anyway! I can't imagine a more simple solution than the current system (well, a constant prover fee I guess :). It also has only one critical input parameter, the proof target time, which is easy to understand. The only other important one is the quotient that is just a damping factor. All the other ones are not important.

You can propose rubbish blocks (by paying TKO (if non-zero:) ) + ETH gas) which spams the network and slows canonical chain down. Proof generation time for valid and invalid blocks are the same (according to John) so this is a valid concern here.

It doesn't really spam the network that much because all these will simply be skipped, and only the actual gas used is taken into account for the L2 base fee, so it won't raise quickly. So I don't think anyone can really exploit the invalid stuff, even when trying to attack the network. Proof costs for some of these blocks containing invalid data can go from very cheap to the same as normal blocks.

In auction:
- We did not eliminate the ‘spamming’ factor (for some malicious actors with the same intention and capital)
- What if someone submits unbeatable bids (1gwei per gas) and never submits the block in time ? It means we need a window to elapse, then ‘free market’. This, pairing with spamming could slow down the network even more.
Let’s say the required deposit is a high flat rate. High enough to dis-incentivize this kind of activity, which can be a solution to this problem, but does not eliminate the first.

People with money to waste can still mess with an auction system for sure. And if we make the required deposit big that can get slashed that means we make the entry cost to be a prover very high, which greatly reduces the permissionlessness/decentralization of the provers.

One argument I did not share, but now I do with Brecht is: we should not care how tokenomics look like - until it makes common / rational sense. I just feel it’s not a good argument because if the current system tanks the TKO to 0 (which kinda could seem ugly but), it means the network is efficient and cheaper to use, and we should not care if anyone is unrational and losing money on it by submitting proofs in a way it does not worth it for him/her.

I see no reason why on a testnet the prover fee would not go to 0 with an auction system. Every system depends on people to follow the rules in a rational way. If people want to submit the proof no matter what (which will be the case when people speculate) the prover fee will go to 0.
Imagine having a prover fee system that makes the proof generation cost free for users and thinking it's bad!

I still like the auction because it helps with wasting resources (for some provers) on one hand - but can it introduce other wasting (e.g.: on smart contract logic complexity costs) which will affect every end user not only some provers ?

Yeah some pros, some cons. However, especially on a testnet where there's room for speculation (and maybe even on mainnet) I don't expect this to result in a different outcome with an auction compared to any other proving fee system that is dynamic.

Following several attempts at designing and implementing Taiko's tokenomics, I've come to a few important realizations:

We may have underestimated the complexity and time investment required for this task. Having started a year ago, it seems we've essentially returned to square one.
Clearly, we need a set of metrics to effectively evaluate and compare different designs. A metric-based comparison approach could bring objectivity to our discussions and keep our focus on the essential aspects of various ideas, rather than on endless minutiae.

With these points in mind, I propose several metrics to evaluate tokenomics, arranged according to their perceived importance. I invite feedback and am open to further discussion.

No Wasted Proving Resources: Provers shouldn't waste computational resources on non-profitable endeavors. If resources are wasted, provers will understandably expect higher returns from those proofs that are accepted, in order to compensate for their losses. This will inevitably increase the average cost of proofs.

Preference for Cheaper Proofs over Faster Proofs: Ideally, proofs should be both cheaper and faster. However, if two proofs incur the same time delay, the cheaper one should win most, if not all, of the time. If two proofs' time delays fall within a certain upper limit, say, one hour, the cheaper should also be favored. By prioritizing cheaper proofs, tokenomics will encourage provers to optimize for cost, rather than speed, pushing our L2 transaction costs down.

No Built-In PoS Reward: To avoid being classified as a security, our tokenomics shouldn't reward tokens to stakers. While a prover might build a staking-based reward system to allow token holders to delegate their power, this should not be seen as part of our tokenomics.

Minimal L1 Cost: Our tokenomics should aim to keep the average extra cost per block on its base layer as small as possible. Provers will likely charge higher fees on L2 to cover this cost, potentially excluding lower fee transactions.

Simple Decision Making: Decisions on whether or not to prove Taiko's blocks shouldn't depend on complex algorithms. The fewer the inputs for such decisions, the better.

No Waiting When Proofs are Ready: Provers shouldn't be required to hold their proofs and wait offline for the perfect moment to submit. Such an obligation would necessitate them developing a small system to hold proofs and make intelligent decisions about submission times. This extra effort, compared to our competitors, could deter our adoption among provers. Therefore, our tokenomics should permit proofs to be submitted immediately after they're ready, without negatively impacting the block reward. This also means that block verification times can be shortened, as provers aren't obliged to wait.

Straightforward: Our tokenomics must be easily understood, particularly by decision-makers and engineers within prover companies. These stakeholders should be able to distill the core concepts into a few succinct sentences that allow listeners to quickly grasp the main points. The simplicity of communication will facilitate comprehension and acceptance of our tokenomics.

I'm hopeful that these comparison metrics will guide our discussions, preventing us from veering into too much subjectivity.

In an effort to facilitate our ongoing discussions on tokenomics, I've developed a comparison table based on the metrics we've discussed. You may observe that these metrics seemingly tilt towards the "Batch Auction" method. I wish to candidly recognize that this bias could be inadvertent, given that I conceived the "Batch Auction" approach prior to establishing these metrics. Hence, I am earnestly soliciting your valuable feedback and suggestions to refine these metrics, thereby ensuring their fairness and objectivity.

Metrics
Alpha-3
Batch Auction
PoS
SomethingElse

Built Around Taiko Token
✓
✓

No Wasted Proving Resources
✕
✓

Preference for Cheaper over Faster Proofs
✕
✓

No Built-In PoS Reward
✓
✓

Minimal L1 Cost
✓
◎

Simple Decision Making
✓
✓

No Waiting When Proofs are Ready
✕
✓

Straightforward
◎
✓

Please note that the symbol "✓" signifies full compliance with a metric, "✕" denotes non-compliance, and "◎" indicates partial compliance. I encourage you to complete the remaining cells under the "PoS" and "SomethingElse" columns based on your understanding and evaluation of these designs.
For future discussions, I propose that we focus on each cell of the table, if possible. This approach will likely keep our discussion more focused and directly pertinent to each metric.

I changed a ✕ to a ✓ for Alpha-3 for "Preference for Cheaper over Faster Proofs" because that fee system also selects the most efficient proof for the target proof time (exactly the same as the auction implementations given above, though there are ways to do auction without it of course).
For "No Wasted Proving Resources" for Alpha-3 I think in practice could also be a ✓ because of off-chain communication between professional provers who will decide among themselves who will prove which block (because non-professional provers won't be able to compete anyway for now, but in the future when proofs may be able to be generated on normal desktops there may still be some unexpected competition). I think it's a realistic scenario, but it's only speculation so a ✕ is fair.

Note that there is a very easy "upgrade" path from the Alpha-3 to solve the downsides (real or speculative). The only thing that has to be changed to turn it into PoS:

In proveBlock simply add a guard who can submit a proof for a given block withing some allocated window. For a PoS system this would be based on some staking contract.
Because now only a single prover can submit a proof for a block (given the normal time allocated) it's not necessary anymore to delay when the proof is submitted to signal the expected reward for the proof. The expected reward can now be specified in proveBlock and that one is used to update the prover fee.

There's of course still some details left out here that are important and we need to think more how things would work out within the set out constraints. But I just want to show that most of these goals are not really specific to any prover fee system, the implementation details very much matter! The Alpha-3 implementation in many ways is also an auction, it's just that the auction part is done implicitly based on when proofs are being submitted, which removes a lot of the complexity of actually implementing a full on-chain auction system.

With these points in mind, I propose several metrics to evaluate tokenomics, arranged according to their perceived importance. I invite feedback and am open to further discussion.

Some other important ones I can currently think of:

Prover redundancy/decentralization: Does the system incentivize multiple provers to stick around to prove blocks, or will it likely result in a single prover to prove all blocks which may result in unexpected and significantly higher withdrawal times
Prover work security: How sure provers are that they will be able to prove blocks in the (nearish) future. Of course if they are more expensive than other provers they should eventually (and reasonably fast) lose their work.
Minimal prover fee: This is different from "Preference for Cheaper Proofs over Faster Proofs" because for example adding extra uncertainty about either what and how many blocks need to be proven in certain period, and if the prover is able to spread that uncertainty risk over a steady stream of blocks it is able to prove in the future, will also dictate how low a reward the prover will accept for blocks.

A rough sketch of how PoS could work. Only small changes necessary to the current proving system, and some parts get simpler:
Protocol:

proveBlock is modified to restrict who can prove a block:

if proof delay <= proof_target: check if the prover address is allowed to prove the block: PoS.verify_prover(block_id, prover_address).
else: open proving. (note that other provers are automatically incentivized to prove these blocks as well because only verified blocks are rewarded).

Optional: instead of going to open proving directly, first let another staked prover have the chance to post the proof exclusively for another proof_target seconds.
Optional: slashing (from prover only stake), but would not do so because should not be needed in this implementation.

The requested prover reward is signaled in proveBlock by the prover. The basefee updates in the required direction by increasing/decreasing the x with a fixed delta, resulting in proverFee := exp(x). The basefee should update fairly slowly because there is no reason for it to update quickly (sudden and long term increases in gas price may be one though)
Every block now has a simple fixed reward: the prover fee. We can do that because provers will prove many blocks averaging things out + block proof aggregation batching on top of that.
The protocol assigns a range the prover fee will be kept in no matter what: min_prover_fee <= prover_fee <= max_prover_fee (max_prover_fee may depend on the current L1 basefee to take into large swings in the L1 gas price). This range is set by the DAO and ensures that even if staking is taken over by bad actors the prover fee cannot change without limit. This is to work around the problem that stakers cannot be rewarded, and so also should not directly be punished for behaving badly (otherwise only risk without any reward, nobody would stake). Of course, TKO holders are directly incentivized to make good choices for the network which they own a part of so this is only a safety precaution.

POS contract:

Ideally a full dPoS smart contract implementation if possible. But if that's complicated we can also keep this contract very simple: a small amount of addresses that are set with permission or similar thing, but one of the addresses is special and allows for fully open proving like currently the case as a sort of escape hatch.
TKO holders stake for whatever address they want. TKO is locked for at least an epoch.
Stake amounts are analyzed and set per epoch, so that blocks are deterministically assigned in advance for a full epoch.

I think that's it.

We may have underestimated the complexity and time investment required for this task. Having started a year ago, it seems we've essentially returned to square one.

I think we're pretty close to being done! I think the fees work in a reasonable way, the only thing left is to iterate and tweak the more we learn (also from partners).

Clearly, we need a set of metrics to effectively evaluate and compare different designs. A metric-based comparison approach could bring objectivity to our discussions and keep our focus on the essential aspects of various ideas, rather than on endless minutiae.

I would counter that a lot of the things that are really important are exactly these minutiae! A good example is the current proving system, the things about it that are now seen as not desirable are relatively small things that can be iterated on, no full overhaul necessary. Classifying these systems on a general level is still useful, but without taking into account some of the implementation details would mean that a lot of possible options and nuance are lost.

No Waiting When Proofs are Ready: Provers shouldn't be required to hold their proofs and wait offline for the perfect moment to submit. Such an obligation would necessitate them developing a small system to hold proofs and make intelligent decisions about submission times. This extra effort, compared to our competitors, could deter our adoption among provers. Therefore, our tokenomics should permit proofs to be submitted immediately after they're ready, without negatively impacting the block reward. This also means that block verification times can be shortened, as provers aren't obliged to wait.

Realistically they will always withhold proofs to optimize for gas costs as well. Provers will (and should) take whatever time is allocated to them to submit their proof only when L1 gas fees are as low as possible. So I think waiting is inevitable, and a generous window for provers to submit their proof is a good thing to minimize costs everywhere.

I changed a ✕ to a ✓ for Alpha-3 for "Preference for Cheaper over Faster Proofs" because that fee system also selects the most efficient proof for the target proof time (exactly the same as the auction implementations given above, though there are ways to do auction without it of course).

It's really hard for me to follow here. Lets say Alice can generate a proof in 30m and her cost per proof is $1, Bob's time delay is 20m and his cost is $1.1. Now bot can always submit his proofs between 20-30m to beat Alice, right? So Alice always loses.
You may argue if Bob keeps doing it, the fee is getting lower and lower, but if the above is true, Alice will never join the competition and Bob never needs to submit proof earlier to lower the reward in the first place.

Isn't PoS the same as the rich ones always wins?
Assuming Alice stakes a lot of tokens and now can prove 10% of all blocks, but her proofs are on average 100% more expensive than others, she is not going to take a loss in most of her blocks, so rationally she will simply include only transactions that can make her profit and end up excluding transactions that will otherwise be included if she can lower her proof cost by 50%. I think this effectively increase the network's overall transaction fees as those 10% of Alice blocks now have higher L2 transaction fees than others.

Maybe we should prepare two branches with different tokenomics. When we launch our mainnet, we can have one token but two L2s, each with a different tokenomics. If we feel like this current one is good to keep, keep it. I'll start an implementation based on the auction idea.

We have help some provers to run in previous Testnet of Taiko. It is good to see this discussion and I have learned a lot. We understand Taiko's desire to make cost a higher priority to make Taiko more competitive.
Based on the current a3 economic design of the contract codes and the auction discussion, here are some comments from the provers' perspective, hope it will be helpful:
For A3:

Basically, it is a mechanism that we did not know before.
There is some dilemma for provers: submit in time or wait? There is still some game theory to be applied. However, we don't want to focus too much on game theory. That is not the core competitiveness of the provers and not benefial for the zkp ecosystem, as the whole indutry requires faster and cheaper zkp proving cost. In the meantime, speed or cost may be a competitive factor we can work on. So a clearer strategy for provers would be better than a dilemma or waiting for submission, which may discourage provers.

For Auction:

Based on the principle of cost-effectiveness, it is very likely that the best cost-effective provers will dominate the reward. Therefore, it would be desirable if there could be some randomness to encourage more provers to participate.
To encourage hardware vendors to optimize zkp proving performance, which is good for the whole zkp ecosystem, the target proof time should be gradually reduced. That is, vendors should still be encouraged to optimize, even if it is not the most important thing.
I am wondering whether we could set a minimum reward which can be gradually reduced threshold to avoid excessive competition and malicious bidding. If there is excessive competition, the provers may consider the market totally unprofitable and be discouraged .

It is really a challenge to develop a perfect economic mechanism. I admire all the work that the Taiko team has done. We are looking forward to the final design.

It's really hard for me to follow here. Lets say Alice can generate a proof in 30m and her cost per proof is $1, Bob's time delay is 20m and his cost is $1.1. Now Bob can always submit his proofs between 20-30m to beat Alice, right? So Alice know she will always lose, so she will not join the competition. That means potential cheaper proofs do not prevail.

I think this has been explained quite a lot already because it's the core mechanism of the current design. Bob can only win by submitting the proofs earlier, but that will decrease the basefee and lower the prover fee and future rewards. So if Bob's proving cost is higher he will lose money by doing so. That is not sustainable for Bob, but is actually a good thing for the network because it reduces the prover fee!

So Alice now has to find a BD person to build on relationship with existing provers?

They only have to do so if they are worried about wasted prover work. Otherwise automatically the most efficient should prevail, it will just take a while to settle down and some will lose money in the progress. Everything is pointing in the direction of there only really be a couple of provers that will do the work anyway.

Doesn't talking to other provers means worse decentralization?

I don't really care about actual prover decentralization, the only thing that matteres is getting that 1proof/block in a reasonable time for a low price. Liveness and low fees, in a permissionless system, I think is the actual goal.

Isn't PoS the same as the rich ones always wins?

It's important that it's a delegated PoS, not a simple richest prover decides all. The Taiko token will already be used to control much more important things than selecting a short period in which a prover has the sole right to prove a block.

Assuming Alice stakes a lot of tokens and now can prove 10% of all blocks, but her proofs are on average 100% more expensive than others, she is not going to take a loss in most of her blocks.

How would that work in practice if blocks are assigned randomly (but sure, deterministic in advance)? Other provers should randomly have very similar costs, especially when taking into account that gas costs will be significant part. I think in practice the actual proof generation cost variance will be low, and we also control how much that variance is based on the circuits we offer.

so rationally she will simply include only transactions that can make her profit and end up excluding transactions that will otherwise be included if she can lower her proof cost by 50%.

Provers don't decide which transactions get included in blocks?

I think this effectively increase the network's overall transaction fees as those 10% of Alice blocks now have higher L2 transaction fees than others.

All blocks will have the same prover fee, the same as in the current design. If Alice only has 10% of the stake, Alice cannot increase the prover fee, a >50% consensus of staked TKO is necessary for that.

Maybe we should prepare two branches with different tokenomics. When we launch our mainnet, we can have one token but two L2s, each with a different tokenomics. If we feel like this current one is good to keep, keep it. I'll start an implementation based on the auction idea.

Fair enough.

It takes less time to write the code than to debate here.

Isn't that how ~9 months of the 10 months were spent on this? It feels like this is the opposite conclusion of what the past has learned us! From your feedback above I think more discussion is necessary, my thinking of how things work are significantly different from yours and probably other people.


Update research

jerry_git_learn_EP1_6

jerry_git_learn_EP1_1

Just a heads up, you can review notebook changes like this using GitNotebooks.
e.g. this pull request https://gitnotebooks.com/jerry-git/learn-python3/pull/40
It's free for public repos, so might be helpful for y'all.


MD5 Erorrs

So im on technic solder since i just updated to 7.1.0. and i decided to do a brand new install, which worked perfectly fine. so then i goto add mods in it, i can click the link and it'll let me download the mod, but when i click add version, nope, i get "can't get md5, URL correct?" and its apparent my url is correct considering when i click the link it lets me download it.

Hello,
Several issues regarding the MD5 have been resolved. Maybe one of them can help you :

Forgotten trailing slash : #64
Permission issue : #165
File too large : #125

Hoping that the right answer is in the list.
Have a nice day.

Am having the same issue as well, the solder.php is correct, I had decided to install a fresh solder 7.1 build and its already have a ton of issues when installing fresh.

Hi @RocketwareGames,
Is that your problem is resolved or do you need more help?

Closing due to inactivity


cleanup: clean up commented code in daemon/stats.go

- What I did
This line is not need any more, it's from legacy execdriver
- How I did it
- How to verify it
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)
Signed-off-by: Lei Jitang<EMAIL_ADDRESS>

LGTM 🐮


Add linefeed binary

We should have multiple binary versions to run

[ ]  File mode
[ ] Console mode

see https://github.com/murarth/linefeed

Closed by a2b28140f28d54eca9a995360646798312d9e4ae


lint and validate dependency metadata to reference dependencies with …

…a unique key (name or alias)
Report charts with the following bad dependency specifications as bad charts:
dependencies:
- name: foo
  alias: baz # ← baz used twice
  version: 1.0.0
- name: bar
  alias: baz # ← baz used twice
  version: 1.0.0

dependencies:
- name: foo
  alias: bar # ← shadows chart below
  version: 1.0.0
- name: bar
  version: 1.0.0

dependencies:
- name: foo
  version: 1.0.0
- name: foo # ← chart with same name as above (although version or repo will be different, this will not work currently)
  version: 1.2.3

Closes #9169
Signed-off-by: Daniel Strobusch<EMAIL_ADDRESS>
What this PR does / why we need it:
Special notes for your reviewer:
If applicable:

[ ] this PR contains documentation
[x] this PR contains unit tests
[x] this PR has been tested for backwards compatibility

Rebased onto current main.

why isn't this merged

Rebased onto current main.

I'm now (v3.14.0) getting error messages, is this a non valid use case?:
dependencies:
  - name: kube-rbac-proxy
    version: "0.9.1"
    repository: "<...>"
    alias: loki-query-proxy
    condition: loki-query-proxy.enabled
  - name: kube-rbac-proxy
    version: "0.9.1"
    repository: "<...>"
    alias: loki-ingestion-proxy
    condition: loki-ingestion-proxy.enabled

index.go:366: skipping loading invalid entry for chart "<...>" "1.3.0" from <...>: validation: more than one dependency with name or alias "kube-rbac-proxy"

According to the documentation for the Chart.yaml using name twice with separate aliases seems to be okay.
Quote: alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times
But now this seemed to be treated as error!

index.go:366: skipping loading invalid entry for chart "<...>" "1.3.0" from <...>: validation: more than one dependency with name or alias "kube-rbac-proxy"
Or am I missing something?

@dbluxo I guess your case should work as long as the repo and version is identical for both dependencies. Otherwise you will hit the case described in https://github.com/helm/helm/issues/9169 (undefined behaviour).
As this PR is closed, I'd suggest to create a new issue for this.
I can try to create a fix for this. Note that I am not a maintainer, though.

@dastrobu Thank you for your response. I have created an issue, would be great if our use case (same repository and version) would work again.

While looking for a fix I found that aliasing as you wish to use it will actually not work in many cases, see #9150 and https://github.com/helm/helm/pull/9175/files#r1043661769.
As I reported this three years ago, I did not remember all the details.
My suggestion would be to lift the validation constraint on your case, when #9150 is fixed. Otherwise, there is a high risk of getting undefined behavior, but maintainers may have other opinions.

index.go:366: skipping loading invalid entry for chart "<...>" "1.3.0" from <...>: validation: more than one dependency with name or alias "kube-rbac-proxy"
Or am I missing something?

@dbluxo I guess your case should work as long as the repo and version is identical for both dependencies. Otherwise you will hit the case described in #9169 (undefined behaviour). As this PR is closed, I'd suggest to create a new issue for this. I can try to create a fix for this. Note that I am not a maintainer, though.

Hi @dastrobu , I opened an issue related to this change. In my case, the two dependencies are exactly the same with different aliases. But the alias is removed by JFrog in its index.yaml metadata. If all versions of the helm charts are with the same kind (aliases duplicate), it seems they will show up in search result. But that's not reliable. Refer to my issue for more details. Thanks.
https://github.com/helm/helm/issues/12744


A604204973640971 swiftsure procedure

Move models from lots.loki to api

This change is

Coverage increased (+0.3%) to 69.856% when pulling 7da502190531ba7d0c49b8143ada7ec87837fb9e on Scandie:a604204973640971_swiftsure_procedure into f06dfa54d0f63a428cb55cf3eb054e44c84a09fb on openprocurement:ea_core_master.


Web: add coverage reporting to tests

It wouldn't be particularly hard to add coverage to the tests. What does everyone think?

@klingerf @rmars ^^ ?

I don't feel too strongly about test coverage, but it probably doesn't hurt. In repos that I've previously worked in, test coverage reports went mostly ignored unless developers were forced to pay attention to them, either by way of CI or email or some other setup. If we're going to add coverage reports, we should put them somewhere that people will see them.

I'm not sure what my opinion is on it either. In the past, it has helped me hunt down bugs missed by tests (usually logic branches that I wasn't actually using/testing). That said, it can also be a pretty big burden without any huge gains. Given that it slows the tests down (3s -> 5s), I'm inclined to say that we suggest it as a tool to check that new tests are going through all the logic branches and just leave it at that.
If we did decide that it was a good idea, it'd need to be part of normal test running and a check for CI to pass the build. Otherwise, to your point @klingerf it is just data that isn't worth it.

Yeah, I don't have strong feelings about this either. It is a nice to have; if it slows the tests down a lot, then maybe just as a suggested tool.

Sounds like it is a "not for now". We can revisit later if it makes sense then =)


non-Gradio scripts and instructions

Hi, I'd like to know when will the non-Gradio scripts and instructions be abailable?

+1, was wondering aswell


Fix path when using CamelCase

Closes #95
Before
{
  "code": "REPORT zfoobar.",
 "fileName": "test.abap",
 "profileInfo": {
  }
}

After
{
  "code": "REPORT zfoobar.",
  "fileName": "test.abap",
  "profileInfo": {
    "showFullname": true,
    "position": "bottom-center"
  }
}

I added a test to the mapping class

Nice bug catch! merging ! Thank you !


Support capital integer literal prefixes (0X, 0B)

From C/C++ standard standpoint capital 0X prefix is valid at least from C99 and capital 0B prefix is valid starting C++14. This PR adds basic tests and fixes both cases.

Thanks for the PR!
bors r+


docs: latest is not valid commit reference

The root version field is for the commit reference of https://github.com/golangci/golangci-lint.
If you specify latest, golangci-lint tends to clone latest branch but it does not exist.
So this field must be a valid commit reference (branches, tags, or so on).

I misunderstood about version field, thank you!


Slight tweak to our previous submission

This update slightly tweaks our previous submission with the hope of a small improvement.
Please use the following notebook for the test:
SHandPR/Face_classification_SHPR_GradientBoost_Updated.ipynb

Hello! This one scores 0.618. Not bad at all, but does not change your current high score. Cheers, Matt


Headless LabOne installer

Is your feature request related to a problem? Please describe.
Installing LabOne inside a docker container does not work straight forwardly. Trying running the install.sh script form the LabOneLinux64-23.02.42414 package inside a python:3.11-slim-bullseye docker container (when building the container) results in an "License agreement not accepted" message. I did not find a suitable method to feed the inputs into the whiptail ui.
Describe the solution you'd like
Feeding the required inputs into the installer by means of arguments.
Describe alternatives you've considered
Simulating the user inputs might break with updates of the installer.
And so would patching the install.sh.
Additional context

Hey
I am sorry for the late response. We somehow overlooked this issue completely.
The good thing is that we now have official docker images available. So maybe you can reuse them instead of trying to install them in a blank Python docker image.
https://hub.docker.com/r/zhinst/labone
The sources for the image are also available open source:
https://github.com/zhinst/labone-docker


Storybook: Box/Margins, Icon, Checkbox

@keybase/react-hackers this adds more common-adapters to the storybook

This is really great! 😄


aaa

啊这，原来之前都没交上，蚌埠住了

Please make a new pull request and send the pr to the branch with your name.


fix(nuxt3-sentry-recipe): minor maintenance

add a missing bracket
remove a now resolved issue comment

Thanks! 🙌


Make actions animation rotate counterclockwisely

Because the icon is:

So it must rotate counterclockwisely

Looks weird to me.
What about mirroring the icon instead?
Should be a transform: scaleX(-1);

Looks weird to me. What about mirroring the icon instead? Should be a transform: scaleX(-1);

Could you edit this PR directly? 🙏

Looks weird to me. What about mirroring the icon instead? Should be a transform: scaleX(-1);

Could you edit this PR directly? 🙏

Hmm ...

Looks weird to me. What about mirroring the icon instead? Should be a transform: scaleX(-1);

Could you edit this PR directly? 🙏

TBH at the moment I can't make transform: scaleX(-1); work on this element, because it also affects the animation, the icon just flips again and again .... maybe need more tricks and test: eg: move the transform to upper level?


Zys branch my push

Ⅰ. Describe what this PR does
Ⅱ. Does this pull request fix one issue?

fixes #XXXX
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

ok


Remove np.float due to deprecation error

At this line, Numpy 1.24 will raise an error for np.float, which is deprecated. This causes error in downstream mgwr's auto testing.
Numpy 1.24 release note

This is affecting current environments. Can we cut a pathc release that includes this?

This is affecting current fresh environments. Can we cut a patch release that includes this?

It has been a very long time since I have done a release without our modern GHA tooling. If we can wait until the completion of #43, then I can take of it.

Agree to get #43 in first.
We will also need @TaylorOshan to share PyPI rights or add a token later. But there's currently only a single person with PyPI access, it would be wise to share it anyway with someone else (@jGaboardi?).

No, only @TaylorOshan has PyPI rights here.


Not working on 10.14.6 No info.plist or no NSPrincipalClass

Running on Mac os 10.14.6 gives me an error:
"/applications/utilities/notifier.app/contents/resources/alert/Notifier - Alerts.app/contents/macos/Notifier - Alerts" --message "test"
2020-12-21 12:26:09.225 Notifier - Alerts[3531:27450] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting
If i cd in to the folder and issue "./Notifier - Alerts" --message "test" I get a notification.

@tomaswallentinus still an issue? Not seen another other reports and does indeed work on 10.14.6 for us.

I don't know anymore I haven't used in some time :)


hello-react-front-end

Hello Code Reviewer 🙂,
I hope you're doing fine :nerd_face:
In this milestone,
the project is created with npx create-react-app .
all necessary node dependencies are installed and added to package.json
redux store, action and reducer are created and set up
Components:
App component has a react-router and renders Greeting component
Greeting component displays the greeting
Thank you for reviewing my PR, stay blessed :star2:

@julie-ify Hello code reviewer, hope you're doing well!
When I submitted the project, the linters had checked the code. I believe the issue comes from GitHub.

before the submission


Upgrade libraries

I am not sure if this is maintained and/or if you would be interested in this PR. I was playing around with subscriptions and Websockets and came across this example, and decided to upgrade all libraries to the latest. I also upgraded the UI to Bootstrap 5.

Fix #4

@bbakerman @andimarek not sure if this example is still alive, in case not, you are welcome to just close this PR :)


Bower package

Would it be worth registering d3fc as a Bower package?

I have a personal dislike of bower (don't understand why you'd not use npm)
but don't see any harm in adding a metadata file for it
On Thu, 16 Jul 2015 14:14 James Leftley<EMAIL_ADDRESS>wrote:

Would it be worth registering d3fc as a Bower http://bower.io/ package?
—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3fc/issues/499.

Adding to bower is very easy, just add a bower.json then run a one-off bower register command.
However there is one issue, bower links to tagged version of the git repo, however we do not add our distribution code to git, or update the version number in fc.js, so the bower package will be pretty ineffective.
... which mirrors the experience I have had with a few bower packages in the past!

I think this settles it.

Found this via google search -- disappointed not to have bower package. I am new-ish to js and use brackets with a bower package manager extension

Hi @PeterVermont we don't want to include our bundled (compiled) code within the repository. For that reason (among others) we do not publish to bower. However, you can still use bower to define your dependency to d3fc using the npm package from the npm CDN as follows:
bower install<EMAIL_ADDRESS>--save

Hope that helps.

Thank you!


Throwing on missing value or get full path to field from node object ?

Hi, not sure if this is already doable and I'm just not finding it in the documentation, but my issue today was getting:
terminate called after throwing an instance of 'std::bad_optional_access'
  what():  bad optional access
[1]    69626 abort (core dumped)  ./build/foo

... and thinking "I wish I knew which mandatory key I forgot!"
From there, I was hoping there was an equivalent to bar["baz"].value<unsigned int>(); that would return the value, or throw some error allowing me to pretty print which node could not be found (std::vector<std::string> for example?).
Afterwards, another solution I thought about was to write a short macro e.g.
#define GET_NODE(n, t) \
[&n] { \
    try { \
        return n.value<t>.value(); \
    } catch (std::bad_optional_access) { \
        throw MyException("Missing parameter: {}", n.as_string(); \
    } \
}()

But getting the path from the node doesn't seem supported as far I can see :(
This feels like a rather simple problem though, is there already something for this use-case?
Thanks for the help and hard-work on the library!

Currently there's no built-in way to do this since the node_views don't keep track of their parent, but you could put together a helper function to do it with some variadic template magic. I just whipped this up and it seems to do what you need:
template <typename DesiredValue, typename... Keys>
[[nodiscard]]
static DesiredValue get_fully_qualified_value_as(const toml::table& cfg, Keys&&... keys)
{
	using namespace std::string_view_literals;
	using namespace std::string_literals;
	using const_node_view = toml::node_view<const toml::node>;

	static constexpr auto build_key_string_elem = [](std::ostringstream& str, const auto& key, bool& prev_was_str)
	{
		using key_type = std::remove_cv_t<std::remove_reference_t<decltype(key)>>;
		static_assert(
			std::is_integral_v<key_type> || std::is_convertible_v<key_type, std::string_view>,
			"keys must be integers or strings"
		);

		if constexpr (std::is_integral_v<key_type>)
		{
			str << "["sv << static_cast<std::size_t>(key) << "]"sv;
			prev_was_str = false;
		}
		else
		{
			if (prev_was_str)
				str << "."sv;
			str << static_cast<std::string_view>(key);
			prev_was_str = true;
		}
	};

	static constexpr auto build_key_string = [&](const auto& ...keys_)
		-> std::string
	{
		bool prev_was_str = false;
		std::ostringstream oss;
		(build_key_string_elem(oss, keys_, prev_was_str), ...);
		return oss.str();
	};

	const_node_view nv{ cfg };
	((void)(nv = nv[keys]), ...);
	if (!nv)
		throw std::runtime_error{ "missing value: "s + build_key_string(keys...) };

	auto val = nv.value_exact<DesiredValue>();
	if (!val)
		throw std::runtime_error{ "value "s + build_key_string(keys...) + " was an unexpected type"s };

	return *val;
}

Example usage:
const auto val = get_fully_qualified_value_as<int64_t>(tbl, "database", "ports", 2);

Hey, thanks a lot, this indeed does what I was thinking about!

No worries, happy to help.


react-native-permissions bug

Ironically, react-native-permissions https://github.com/yonahforst/react-native-permissions, requests a bunch of uneccessary permissions and causes deployment to itunes to fail. Need to workaround the bug or dump the library.

Sorry, posted this in wrong repository.


[Bug] MaxScale startup failing

When deploying maxscale with galera I'm running into an issue where the maxscale pods are failing to start. Oddly, a fresh deployment of both galera and maxscale seems to work fine. However, if I deploy maxscale alongside an existing galera environment, which didn't have maxscale already, the deployment fails with the following error when the maxscale pods start up. Nothing bad happens to the galera cluster itself, everything remains operational; however, maxscale simply never goes online.
Logs from maxscale pod
2024-03-23 18:26:07   notice : MaxScale started with 64 worker threads.
2024-03-23 18:26:36   warning: Authentication failed for '', no password. Request: GET /
2024-03-23 18:26:36   warning: Authentication failed for '', no password. Request: GET /

The pods then go into a crashloop and not recover. In trying to debug, I found the grants and users and validates that the users were functional.
Reproducing the error
I am able to reproduce this error by deleting the maxscale deployment via kubectl and then redeploying the same manifest. In doing that operation it seems I'm not able to get back to a functional state.
Documentation

[ x] I acknowledge that I have read the relevant documentation.

Cluster manifests can be seen here

galera: https://github.com/rackerlabs/genestack/blob/main/kustomize/mariadb-cluster/base/mariadb-galera.yaml
maxscale: https://github.com/rackerlabs/genestack/blob/main/kustomize/mariadb-cluster/base/mariadb-maxscale.yaml

I was able to overcome the startup issue by using a TCP liveness probe instaead of an HTTP probe.
  livenessProbe:
    failureThreshold: 3
    tcpSocket:
      port: 8989
    initialDelaySeconds: 20
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 5

  readinessProbe:
    failureThreshold: 3
    tcpSocket:
      port: 8989
    initialDelaySeconds: 20
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 5

While this worked, I think it's less than ideal. Sadly once the service started up I ran into a different issue where the /var/lib/maxscale/maxscale-config.json file was being populated with what seemed like an old password, or at least a wrong one. I was able to resolve this by taking the generated secrete from the maxscale and manually editing the JSON file to use the updated value. After making this change, the service started and began communicating with the backend normally.
I'm not sure where the password value is being pulled from, when I redeploy, but I can confirm this issue is reproducible with a fairly simply. Should I be manually generating the secrets/users/grants?

well my joy was short lived, the file /var/lib/maxscale/maxscale-config.json was resynced and the bad value was put back into place :'(

To work around the password issues I once again deleted the maxscale deployment. I then created a new password for maxscale that didn't have the ownerReferences
apiVersion: v1
data:
  password: SuperSecrete
kind: Secret
metadata:
  name: maxscale

With the secrete in place the issue is now "fixed," however, I had to use the password that was generated when I first started the maxscale deployment, which I took out of the maxscale-config.json file; I have no idea where it's getting that value from.

I did find the following error in the operator
{"level":"error","ts":1711303942.9507003,"msg":"Reconciler error","controller":"maxscale","controllerGroup":"k8s.mariadb.com","controllerKind":"MaxScale","MaxScale":{"name":"maxscale-galera","namespace":"openstack"},"namespace":"openstack","name":"maxscale-galera","reconcileID":"747f34b5-3863-49f4-b99f-9ffee929b5fa","error":"error reconciling phase Init: 1 error occurred:\n\t* error initializing Pod 'maxscale-galera-0': error creating monitor: Parameter 'password' contains unescaped newlines\n\n","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.2/pkg/internal/controller/controller.go:329\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.2/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.16.2/pkg/internal/controller/controller.go:227"}

I wonder if the original startup error is related to the unescaped value error?

Hey there @cloudnull ! Thanks for reporting with this level of detail, very much appreciated 🙏🏻

Authentication failed for '', no password. Request: GET /

Empty string as admin user here implies that it hasn't been initialized by the time the operator is configuring the admin user. I will raise a PR to fix this.

I am able to reproduce this error by deleting the maxscale deployment via kubectl and then redeploying the same manifest. In doing that operation it seems I'm not able to get back to a functional state.

Removing the MaxScale resource and leaving behind its PVCs may lead to intermediary states in the configuration. Please follow this steps:

Delete MaxScale resource
Delete the MaxScale PVCs: maxscale-galera-0, maxscale-galera-1... etc

It is important to note that is is safe to delete the PVCs in this situation, as we only store the MaxScale configuration here. This is the default StatefulSet behaviour that we may consider to opt out from this in further releases. There is a new feature for this in Kubernetes, but it is still in beta and a feature flag needs to the configured to opt in:

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-retention

We are aiming to support this in the future and don't leave PVCs behind by default. We will include this once persistentVolumeClaimRetentionPolicy is usable without feature flags.

Should I be manually generating the secrets/users/grants?

No, this will most likely lead to drifts in the configuration state. Please stick to the plan above ☝🏻
Again thanks for reporting. I believe starting from clean state and letting the operator do its thing should work unless you end up in the aforementioned race condition, which I will fix just now. Also I think other support request may be related to this problem, I will link them here for context:

https://mariadb-community.slack.com/archives/C01VAUKLR0Q/p1711149686020479
https://mariadb-community.slack.com/archives/C02R1CJ0LD6/p1711177608750409

Let me know how it goes!

I've raised a PR for this which will potentially prevent situations like the one described here:

https://github.com/mariadb-operator/mariadb-operator/pull/506

Happy to leave this open to confirm it works and gather more info!

I think this has been squashed. Thanks again @mmontes11 !


arduino-cli: 0.34.2 -> 0.35.1

Description of changes
https://github.com/arduino/arduino-cli/releases/tag/v0.35.0
https://github.com/arduino/arduino-cli/releases/tag/v0.35.1
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

2 packages built:

arduino-ci
arduino-cli

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3297


Job id's being converted to Strings

The stripFIFO function returns the string representation of the jobID (my fault, I missed that when writing it). I only noticed it now while doing strict comparison of cached jobID's in our unit tests.
I would suggest doing a type conversion before removing the jobID. Notice the added plus sign on the return.
 client.stripFIFO = function( zid ) {
      if ( typeof zid === 'string' ) {
        return +zid.substr(zid.indexOf('|')+1);
      } else {
        // Sometimes this gets called with an undefined
        // it seems to be OK to have that not resolve to an id
        return zid;
      }
    };

Thank you, this has been a very nice package to work with.

Why aren't you creating a PR @hockeytim11

Sorry, I was able to move my project back to the main branch so I kinda stopped using my fork. I will revive it and create a PR though.


Garden btle400m_v1.9

Hello,
Got a Garden BTLE400M_V1.9
handle : 0x0043 give : MESH GARDEN
handle : 0x0049 give : Application version <IP_ADDRESS>
handle : 0x0047 give : BTL400M_V1.9
Color are change with handle : 0x0023 (00ff0000 give a full red 000000ff give a full blue)
effect are change with handle : 0x0021 (rainbowprotocole is working on this : 00ff000001000f0f give a nice red pulse)
Still looking for a batterie status and charging statut, any advice is welcome

handleBattery = 0x002e  as you know ;)


RunMutation return type definition

Change return type of runMutation definition, in mutation widget
Fixes / Enhancements

Fixed wrong return type.

:tada: This PR is included in version 3.0.1-beta.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Service running?

Ok, so I'm reading https://www.collabora.com/news-and-blog/blog/2019/03/27/modern-usb-gadget-on-linux-and-how-to-integrate-it-with-systemd-part-2/ and i'm like.... this is nuts. (I have an uneasy truce with systemd on the best of days.)
Could gt learn to start a service, the process being:

load the scheme
mount the ffs
start the service
enable the gadget
Wait on the service (with signal forwarding?)
Unmount the ffs
remove the scheme
return the return code of the service

It doesn't need to do full daemon management, just wrap another program to do the necessary usb init/etc.
For the record, I'm using gt with https://github.com/viveris/uMTP-Responder/ because I wrote my own script to do all this and having an actual declarative file is much nicer.

@AstraLuma I think that would be fragile and it would be better to do the above in an event driven way using the systemd dependencies mentioned in post from @andrzejtp you linked above.
@andrzejtp I think that we should import more of the setup in the blog post above, but instanced, so you can drop your scheme in /etc/gt/ffs/foo.scheme, configure which daemon service to start and then start an instance of the relevant services. Thoughts?
BTW @andrzejtp added some of their systemd setup to gt in commit ed35e2f


The cs:alternative extension seems to be not supported

Hi,
As a researcher and developer in Japan, I'm super happy to see that the cs:layout extension of CSL-M has been supported in citeproc-lua. 🙇 I just confirmed that the feature works fine with a few CSL-M style files!
A missing feature is the cs:alternative extension such as alt-translator. Would you happen to have a plan to support the extension?
Here is an example of a bibliography item that contains alt-translator, alt-issued, alt-publisher-place, and alt-publisher.
[
  {
    "id": "morgan2022philosophy",
    "author": [
      {
        "family": "Morgan",
        "given": "Casey"
      },
      {
        "family": "Patrov",
        "given": "Alexei"
      }
    ],
    "citation-key": "morgan2022philosophy",
    "event-place": "Chicago, IL",
    "issued": {
      "date-parts": [[2022]]
    },
    "language": "en>ja",
    "note": "alt-title: 自由意志の哲学\nalt-translator: 鈴木||真紀\nalt-issued: 2023\nalt-publisher-place: 東京\nalt-publisher: 城南大学出版会",
    "publisher": "Imaginary University Press",
    "publisher-place": "Chicago, IL",
    "title": "The Philosophy of Free Will",
    "type": "book"
  }
]

It seems that this feature is marked as deprecated. Is it still required by some Japanese styles?


Filter search not search when typing multiple words

We have a filter search using data-search-attribute. When searching for an item with multiple words, the search result disappears (nothing found) when typing more than one word.
E.g. when typing "two words", the item with the data-search defined as data-search="two-words" wont appear as a result. Typing only "two" will make it appear. I have also tried data-search="two words" on the item. Returing no results when typing "two words" in the the filter search input.
Javascripts
mixitup.min.3.js
mixitup-multifilter.min.3.js
Codepen (only html and javascript, not "working")
https://codepen.io/anon/pen/MQbxdy

Unfortunately this type of searching (using DOM selectors) is very limited. You can really only reliably match single words. If you need to do anything else more complex you should do it server side over an API with a real database search.
However, it will probably help to understand what's going on.
When we type something into the search field:
"foo"`

That is then converted into a dynamically generated DOM selector:
[data-search*="foo"]

Which matches elements with a data-search attribute containing the characters "foo", e.g.:

So, in your case you are searching for two words:
"foo bar"

Which yields:
[data-search*="foo bar"]

So as long as your html contains the following (exactly those two words in that order, with a real space character in between):

It will match that item.

Thank you for explaining. It works with the exact match and a real space between.

Great


Implement internal cluster

See https://github.com/UKHomeOffice/keto/issues/71
Would be awesome if people could test this works as expected.

Internal Flag Testing:

[ ] Test create internal cluster with master & compute nodes (Successful)
[ ] Test create external cluster with master & compute nodes, validate no regression (Successful)
[ ] Test create internal cluster with 0 compute nodes, separately add compute pool and confirm it is internal
[ ] Test create internal cluster with compute pool on a VPC with NAT Gateway, validate external connectivity


fix: deep healthcheck on server startup

fixes #512

@ironman-machine try

Hello @rahulreddy
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/deepHealthcheckOnStartup", "DEFAULT_BRANCH": "rel/6.3"}
Please follow http://ci.ironmann.io/gh/scality/Integration/8444 for CI status.


Fix: ignore dot files in the monitored directory

Fixes #693

:white_check_mark: Build jmxtrans 266 completed (commit https://github.com/jmxtrans/jmxtrans/commit/494eeaee1c by @afn)

Rebased.

Rebased to master. Good to merge?

:white_check_mark: Build jmxtrans 333 completed (commit https://github.com/jmxtrans/jmxtrans/commit/a8b6e12d13 by @afn)


Master

Hello,
I fixed Ticker dto
and Added Gemini sand box exchange.
could you please include this change into next Maven release?
Thanks,
David

Thanks. The entire sandbox class seems overkill, when you can just use the default one and override the URL.

Please submit PRs against the develop branch. Sorry to make it harder for you!


How can I send back application/json as content type?

@vdantu For some reason ,I am using mxnet-model-server (1.0.4), which version has no "set_response_header" proprety, but has "set_response_content_type" property, I add a line "context.set_response_content_type(0, 'application/json')" in custom service entry point function, but it not wokrs. Can you tell me how to solve the problem, thank you?

Just for reference, this question is a continuation of #846 .
There were a few fixes that went in for MMS 1.0.5 and MMS 1.0.6 with regards to the HTTP headers and HTTP Error handling. I would recommend upgrading to later versions of MMS. The syntax that you are using will work for MMS 1.0.5 or later.
To answer your question specifically, in MMS 1.0.4, the context.set_response_content_type interface took a request Identifier and not a request index as the first argument. So, to make it work you would have to write it as follows
context.set_response_content_type(context.request_ids[0], "application/json")
For full example, you could checkout this example code

@xuweidongkobe : Please let us know if this worked for you.

@vdantu : it worked for me. Thank you very much for your answer. It helped me a lot.  It would be better if there were more documents between versions and MMS usage documents. Thank you.


Unable to download http://www.mtvbase.com's music videos...

Example:
$ youtube-dl -v http://www.mtvbase.com/music/videos/obpo2i/Future-Love-Paradise
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'http://www.mtvbase.com/music/videos/obpo2i/Future-Love-Paradise']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2017.10.29
[debug] Python version 3.4.2 - Linux-3.16.0-4-amd64-x86_64-with-debian-8.9
[debug] exe versions: ffmpeg 3.2.5-1, ffprobe 3.2.5-1, rtmpdump 2.4
[debug] Proxy map: {}
[generic] Future-Love-Paradise: Requesting header
WARNING: Falling back on generic information extractor.
[generic] Future-Love-Paradise: Downloading webpage
[generic] Future-Love-Paradise: Extracting information
ERROR: Unsupported URL: http://www.mtvbase.com/music/videos/obpo2i/Future-Love-Paradise
Traceback (most recent call last):
File "/home/ant/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 784, in extract_info
ie_result = ie.extract(url)
File "/home/ant/bin/youtube-dl/youtube_dl/extractor/common.py", line 434, in extract
ie_result = self._real_extract(url)
File "/home/ant/bin/youtube-dl/youtube_dl/extractor/generic.py", line 3059, in _real_extract
raise UnsupportedError(url)
youtube_dl.utils.UnsupportedError: Unsupported URL: http://www.mtvbase.com/music/videos/obpo2i/Future-Love-Paradise
Thank you in advance. :)

Site is not supported (yet), apparently..


[Bug]: Passing asymmetric matchers highlighted in diff when using .toMatchSnapshot

Version
29.2.1
Steps to reproduce
Run jest on the following test file:
it('test snapshot bug', () => {
    const user = {
      createdAt: new Date(),
      id: Math.floor(Math.random() * 20),
      name: "Lebron James",
      some_boolean: true

    };

    expect(user).toMatchSnapshot({
      createdAt: expect.any(Date),
      id: expect.any(Number),
      name: expect.stringMatching("Lebron Jaames")
    });
  });

Expected behavior
I expect only the name field to be highlighted in the diff.
Actual behavior
All the property matchers are highlighted and the diff explicitly mentions three lines as being different.

Additional context
This is a huge problem when you are testing against a big API payload and you have dozens of property matchers uisng regexes etc. It can be very hard to find the culprit field. It sounded like #9257 would fix this but the toMatchSnapshot code never executes printDiffOrStringify to my knowledge.
Environment
System:
    OS: macOS 12.5.1
    CPU: (8) arm64 Apple M1 Pro
  Binaries:
    Node: 16.18.0 - ~/.nvm/versions/node/v16.18.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.18.0/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v16.18.0/bin/npm
  npmPackages:
    jest: ^29.2.1 => 29.2.1

Wanna send a PR for it? 🙂

@SimenB I took a crack at it #13491


Sorting doesn't sort right

Sorting in Live Demo doesn't sort for almost all columns, for example, for "Animated Sort Icon" page:

for first column - Eclair, Cupcake, Gingerbread
for "Sodium" column - 337, 413, 327

I have the same problem with my mdDataTable installed from Bower 2 days ago. Are there any possible workarounds?

+1

Same here.
I tried the sort-by attribute, but I don't get it to work...

@Sanchokus, @surfjedi Working on it, you'll have the fix in few days.

Fixed and shipped with v1.6.6


New Vehicle Type listing on map

We're going to replace Contributing factors, which has not been useful, with a new Vehicle Type listing that would sum all crashes where each vtype is true (regardles of other vehicles involved in any given crash, so these will add up to more than total crashes)
So we replace this:

With this:

Ideally a 2 col approach would work here, so no scrolling, but I'm not confident in that. We could also do the scrolling method here, in which case we sort DESC by the total crashes per vtype

Scratch that, we're leaving this as is


[Tests] Add end-to-end tests for settings

There are currently no tests for settings.
List of all settings tests to do:

[ ] Should open settings menu
[ ] Should close settings menu on click X or click outside of window
[ ] Should toggle preferences

[ ] Dark mode
[ ] Active line highlight
[ ] Markdown preview

[ ] Should change sort order

[ ] Last updated
[ ] Favorites
[ ] Title (Alphabetical)
[ ] Date created

Going to tackle this one

@kodyclemens I can also help with this! Let me know if you need any help.

@kodyclemens I can also help with this! Let me know if you need any help.

Thanks for the offer! I actually just finished up and didn't see this until just now or I would have shared!


Random users from updateUser

I'm currently inserting data from updateUser into a database and noticed a lot of bots that I have never used nor share any groups with me, is this a bug or feature of tdlib? Some of them that I have never used or see in any group I'm in: https://i.imgur.com/9J09sfX.png
I've also tested this on a new account that isn't in any group/channel and it seems to get some of the same bots

Likely the bots are members in some of your groups and are automatically preloaded with the full info about the group.

Likely the bots are members in some of your groups and are automatically preloaded with the full info about the group.

I've tried it on a new account with a different number that isn't in any group/channel, but some of them are still showing even after I wiped the DB and .tdlib folder

The bots can't be received from nowhere. The exact reason can be found, only if you send the TDLib's log with verbosity level 4 to @tdlib_bot in Telegram.


TOA clipboard triggers in other raids

Since there is no isInToa(), clipboard text get copied on reward/kc message in cox, prob also tob

fixed with f4fc79edbf916a6b3b896bd53eb5822c0f5fb700


Additional color names with color picker

Provide a description of the new feature / enhancement
Hello the color names provided by color picker are VERY limited.  The tool groups large variations into single color names.  I ( and I am sure many others ) am interested in the much wider variety of color names available.  At a minimum I would suggest the color name list on https://w3schools.sinsixx.com/html/html_colornames.asp.htm  as  a start.  There are many other color names as well.
Thanks in advance,
Derek

Note: If we do this, we should add a link reference to the source of the used names list on settings ux and docs.

Right now this is something we're not planning to add.  We are using the same color logic as WinUI Color control and Office.
In addition, we are targeting groups of colors, where what you linked to is targeted color.  Also color naming is hard as 00FF00 is Lime according to that where i'd call that pure green and another color system may call it something else.


Demo do not show a colored image

HI @richzhang .
I followed the instructions  as the same as the notebook says.But I did NOT get a colored image .Instead I got a strange image as below:

This is my test code(I just copy them from the notebook) :
import numpy as np
import matplotlib.pyplot as plt
import os
import skimage.color as color
import scipy.ndimage.interpolation as sni
import caffe
plt.rcParams['figure.figsize'] = (12, 6)
gpu_id = 0
caffe.set_mode_gpu()
caffe.set_device(gpu_id)
Select desired model
net = caffe.Net('./models/colorization_deploy_v1.prototxt', './models/colorization_release_v2.caffemodel', caffe.TEST)
net = caffe.Net('../models/colorization_deploy_v2.prototxt', '../models/colorization_release_v2_norebal.caffemodel', caffe.TEST)
net = caffe.Net('../models/colorization_deploy_v1.prototxt', '../models/colorization_release_v1.caffemodel', caffe.TEST)
If you are training your own network, you may replace the *.caffemodel path with your trained network.
(H_in,W_in) = net.blobs['data_l'].data.shape[2:] # get input shape
(H_out,W_out) = net.blobs['class8_ab'].data.shape[2:] # get output shape
print 'Input dimensions: (%i,%i)'%(H_in,W_in)
print 'Output dimensions: (%i,%i)'%(H_out,W_out)
pts_in_hull = np.load('./resources/pts_in_hull.npy') # load cluster centers
net.params['class8_ab'][0].data[:,:,0,0] = pts_in_hull.transpose((1,0)) # populate cluster centers as 1x1 convolution kernel
print 'Annealed-Mean Parameters populated'
load the original image
print 'load the original image'
img_rgb = caffe.io.load_image('./imgs/hbfj1.jpg')
img_lab = color.rgb2lab(img_rgb) # convert image to lab color space
img_l = img_lab[:,:,0] # pull out L channel
(H_orig,W_orig) = img_rgb.shape[:2] # original image size
create grayscale version of image (just for displaying)
print 'create grayscale version of image (just for displaying)'
img_lab_bw = img_lab.copy()
img_lab_bw[:,:,1:] = 0
img_rgb_bw = color.lab2rgb(img_lab_bw)
resize image to network input size
print 'resize image to network input size'
img_rs = caffe.io.resize_image(img_rgb,(H_in,W_in)) # resize image to network input size
img_lab_rs = color.rgb2lab(img_rs)
img_l_rs = img_lab_rs[:,:,0]
show original image, along with grayscale input to the network
print 'show original image, along with grayscale input to the network'
img_pad = np.ones((H_orig,W_orig/10,3))
plt.imshow(np.hstack((img_rgb, img_pad, img_rgb_bw)))
plt.title('(Left) Loaded image   /   (Right) Grayscale input to network')
plt.axis('off')
net.blobs['data_l'].data[0,0,:,:] = img_l_rs-50 # subtract 50 for mean-centering
net.forward() # run network
ab_dec = net.blobs['class8_ab'].data[0,:,:,:].transpose((1,2,0)) # this is our result
ab_dec_us = sni.zoom(ab_dec,(1.*H_orig/H_out,1.*W_orig/W_out,1)) # upsample to match size of original image L
img_lab_out = np.concatenate((img_l[:,:,np.newaxis],ab_dec_us),axis=2) # concatenate with
concatenate with original image L
img_rgb_out = np.clip(color.lab2rgb(img_lab_out),0,1) # convert back to rgb
plt.imshow(img_rgb_out);
plt.axis('off')
plt.show()
Am I missing something?
Thank you very much!

I think  I found the reason : The model that I downloaded before is broken but the code didn't report any error. I fetched all model by using  fetch_release_models.sh , I worked fine!


test bug report

Troubleshooting

[ ] I've searched discuss.bitrise.io for possible solutions.
Which version of the step is effected? 1.2.3
Is the issue reproducible with the latest version? YES / NO
Does the issue happen sporadically, or every time? SPORADIC / EVERY TIME
Is the issue reproducible locally by following our local debug guide? YES / NO / NOT APPLICABLE

Useful information

FAQ
devcenter.bitrise.io

Issue description

Bitrise info

Build URL: Please share the build URL with us.
Bitrise Support enabled: YES / NO
Log:

Steps to reproduce

...
...

test


Site Request: thescene.com

https://thescene.com/watch/vogue/narciso-rodriguez-spring-2013-ready-to-wear?source=player_scene_logo

It will be supported in the next version.

Thank you guys, good job!

Excellent work as always. Thank you jaimeMF.


add support for starting envbuilder from built image

Fixes #291

I'll integrate this into my other changes if that's OK?


Take over mode will broken code lens

Hi volar team,
When I install volar in my project, and follow the guide to disable buildin TS feature, My code lens broken.

Code lens will help me found the code block reference, It's very helpful.
How can I enable code lens when I using volar in my project?

I have a similar issue where the merge code lens is missing in the conflicting files of Vue.

@brc-dd  Of coure using Volar typescript plugin, but in this (Guide)[https://vuejs.org/guide/typescript/overview.html#volar-takeover-mode] telled the buildin ts language feature will cause performance issue, so I should disable ts language feature, and then, some bad thing happen, like:

Code lens broken
Git lens broken
etc...


Code available?

This looks very interesting.
Will there be code available for testing soon?

Thanks for your attention! The paper is under review now, and I will release the code as soon as possible. Please stay tuned.

@ljzycmd hope you would release a colab notebook as well!

Is this paper still being reviewed?

Yes, the paper is still under review now.

Is there any chance that you can share pretrained model weights with us? @ljzycmd

Hi, I uploaded the checkpoints earlier, and you can follow the README.md to download them.

Found it! Thanks!


Conflict when trying to use an NPM package that uses glamor

I'm trying to export components from my project to a separate project
I use webpack to build the newly exported project and link the main project to the built version of the exported project
However, when I try using an imported React component, I get the cache miss error:
Error: [glamor] an unexpected rule cache miss occurred. This is probably a sign of multiple glamor instances in your app
Now, I get that means I have glamor running two instances, but how do I resolve this?

Check via npm ls glamor which versions of glamor are installed and try to dedupe them via version management.

There are no actual different versions (I verified that)
I believe it's that each project maintains its own Glamor instance and therefore there's a cache miss
This may not be related directly to Glamor, but I was wondering if anyone has ever done a similar thing

OK, I found out the reason to all my pain today - I would pass glamor generated classes as props from one project to another's component, whereas each project has its own glamor instance (i.e. cache)
that resulted in a cache miss :)

How did you solve this, @ChenRoth ?

@ChenRoth I am also experiencing that issue. Passing a glamor generated className to a glamorous component (a feature which glamorous officially supports) results in a cache miss. Did you end up solving the issue?


Add genre tag

This pull request add support for genre tag
Closes #13

Hi @Dalvany, fyi I forked the project (to martpie/rust-audiotags2) and incorporated your changes. I emailed the maintainer, and if I don't receive any news in the next days, I'll publish the updated crate.

@martpie , nice, thank you !

I close this PR as it is included in  audiotags2 of @martpie


Fix Filesystem::searchpath_find on Windows

Both Strutil::utf8_to_utf16 and Strutil::utf16_to_utf8 had a bug in which the converted string would include the trailing '\0', e.g., "foo" (len 3) would become L"foo\0" (len 4). This caused an infinite recursion on Filesystem::searchpath_find during recursive searches.
Also reduce the implicit conversions in Filesystem::searchpath_find happening when calling the helper oiio functions. Instead, keep explicit boost::filesystem::path objects for as long as possible and call the boost::filesystem methods directly.

Good to see you, Edgar, it's been a while.
Good catch on this.
I made a note about a slight efficiency you can add, but pending that, LGTM. I'll wait for you to patch that, then I'll merge and backport.

I should have said hi during SIGGRAPH :)
Thank you for noticing the string_view issue. I amended the commit as per your suggestion. Hopefully I will submit a few other pending fixes soon.

LGTM! I will merge now.


Error Connecting to XenServer Beta 3

I get this error: Error connecting to XenServer: reading body error: type mismatch - can't unmarshal interface to string
with this code:
package main

import (
	"fmt"
	"github.com/softlayer/xapi-go"
	"log"
)

func main() {
	fmt.Println("hello")

	client := xapi.NewXapiClient("http://<IP_ADDRESS>", "root", "password", "2.3")
	if err := client.Login(); err != nil {
		log.Fatal("Error connecting to XenServer: ", err)
	}

	session, _ := client.GetSession()
	fmt.Println(session)
}

I printed out the XML response:
<methodResponse><params><param><value><struct><member><name>Status</name><value>Success</value></member><member><name>Value</name><value>OpaqueRef:a490ac79-df44-d0a3-5270-ecdf56aeeeca</value></member></struct></value></param></params></methodResponse>

We are also seeing this, I've not been able to workout where the problem is. It looks on the surface like it should all work. Very odd

I'm sorry for neglecting this library for so long. I pushed a change which I hope fixes this. I don't currently have a server to test against, so I have to rely on a stubbed response.
I also fixed some of the non-idiomtic names for things. Most notable, underscores are now gone.

Reopening this since there's still some issues with what I have so far.

If you let me know when you have something workable, I can test it out.


User().Email returns UPN not email

Hi everyone.
Please note that the User().Email function returns the UPN and not the Email address. This is typically not a problem if the Email and UPN is the same, but it is important to be aware of if these are not the same. Below is a quick video to explain more.
https://youtu.be/6FU1xGxJK5w

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

ID: a5ca5a0a-bc28-3938-fb72-bf24deaede99
Version Independent ID: ade2f96a-f1ce-e96c-422c-a344ea5b0c84
Content: User function - PowerApps
Content Source: powerapps-docs/maker/canvas-apps/functions/function-user.md
Service: powerapps
GitHub Login: @gregli-msft
Microsoft Alias: gregli

Yes, it would greatly help if this was corrected so the Email property actually contained the user's primary email address instead of the UPN mislabeled as Email.

Also, it might be useful to note a workaround to get the actual (primary) email for a user is to use the Office365 Connector and either of the GetMyProfileV2 or GetUserProfileV2 actions/methods. E.g.
Set(global_CurrentUserEmail, Office365Users.MyProfileV2().mail);

Duplicate of #https://github.com/MicrosoftDocs/powerapps-docs/issues/1725. Closing the issue here. Please follow the other issue for updates.


use default variable format in messages

@rdeltour I know that %1s is also a valid format for string formatting variables in messages, but it is normally used to create fixed width strings like in %3s which would always create a string with 3 characters minimum.
I'd suggest to always use the default variable format %1$s instead. Okay for you?

LGTM, it was probably a typo  :blush:

LGTM, it was probably a typo :blush:

yeah, that's what I assumed as well... came up as a question over at Transifex from Dutch Translator Merijn...
Waiting for the CI build, then going to merge this...


Angular2 with Typescript AOT+Rollup Error

Dear friend
I am having trouble in importing momentjs
momentjs import statement in component
import * as moment from 'moment';
and used like
formatDate(date:Date, format: string){
return moment(date).format(format);
}
it works fine in Angular2 JIT Compilation while in development mode
but when I try to compile using Angular2 AOT it gives error "Cannot call a namespace ('moment')"
please help need solution in urgent
Thanks

I have this problem as well, and I would really like to know why does it have to be so hard to use moment with Angular 2... I have literally exhausted every possibility I can think of to make it work with both AoT and JIT.

So, it looks like this was asked/answered on Stack Overflow.

It appears the fix on stackoverflow is only a partial fix...
It makes rollup happy, but nothing else (systemjs, webpack, etc.) do not compile.
I am using both (webpack for dev, rollup for prod)... Is there any actual fix for this? :)
Why is it that moment seems to export in such a strange way, that many things have problems importing it correctly? This will be the second time I've had to do research on how to import moment into an angular2 environment...

@maggiepint Nope, as the commenter above mentioned, changing
import * as moment from 'moment';

to
import moment from 'moment';

makes Rollup happy but breaks things like SystemJS.
The typical Angular setup is to use SystemJS for unit tests and something like Rollup for production builds, but there is no one way to import Moment that supports both.
Please could you reopen this?

Yes, agreed.
I currently have to have a custom plugin in my build script that literally does a text find and replace of import * as moment with import moment for my production rollup build (vs my dev webpack build) - and that is a pretty bad/messy solution...

@maggiepint, It seems you have prematurely closed this issue.  I have the same issues as @sam-s4s and @benelliott.  The accepted answer is an ugly hack and makes including moment in an angular 2+ library a mess.

@sam-s4s I agree 👍

@sam-s4s angular-cli uses rollup internally for building libs, atleast on v7...

I believe it does! And Webpack 4 for some other stuff. I upgraded recently, and everything seems to be working correctly :)


topic/gar/devel

This change is part of the following stack:

#242

#236 ◀

#243
#244

Change managed by git-spice.


Text is not printed on page header with gem version 1.5.3

I noticed there was an issue for this, and it was fixed.
https://github.com/asciidoctor/asciidoctor-pdf/issues/1087
However, I'm facing the same issue, my asciidoctor-pdf is with below version:
WangXus-MacBook-Pro:github wangxu$ asciidoctor-pdf -V
Asciidoctor PDF 1.5.3 using Asciidoctor 2.0.10 [https://asciidoctor.org]
Runtime Environment (ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-darwin19]) (lc:UTF-8 fs:UTF-8 in:UTF-8 ex:UTF-8)

The theme file I am using:
extends: default
header:
  padding: [0.35in, 0, 0, -0.35in]
  height: 1in
  vertical-align: center
  line-height: 1
  recto:
    center:
      content: '(C) xxx -- v{revnumber}, {docdate}'
  verso:
    center:
      content:  '(C) xxx -- v{revnumber}, {docdate}'
footer:
  height: 0.75in
  line-height: 1
  recto:
    right:
      content: '{section-or-chapter-title} | *{page-number}*'
  verso:
    left:
      content: '*{page-number}* | {chapter-title}

The footer is displayed, the header is empty on the generated pdf.

This is happening because the revnumber attribute is not set in your document. If an attribute reference does not resolve in the running content, the converter drops the whole line (as a way to conditionally disable content). This behavior is describe in this section: https://github.com/asciidoctor/asciidoctor-pdf/blob/master/docs/theming-guide.adoc#attribute-references

thanks @mojavelinux for your quick help . Yes! removing revnumber solved the issue.


"Error while retrieving data: Timeout fetching weatherflow data" warning - should provide more informative info

While attempting to use the hass-weatherflow addon I found out my Weatherflow Tempest was malfunctioning and was not providing some key data. It is believed this lead to the warning message which has too broad of a scope.  Where the fetch is performed OK but the data is incomplete it is suggested to add additonal info or use a different message identifying a possible station malfunction for improved troubleshooting.

Thanks. I will work on this as soon as I have time.

Is this the same error message?
Error while retreiving data: Empty dataset returned from WeatherFlow. Make sure the station is online.
I'm getting this but checking the official app, it is indeed online so I suspect maybe they broke something as HA isn't getting the data now

@rightsaidfred99 Have you looked at the log file to see if errors show up? You could turn on debug for this integration if there is nothing in there. And it is working fine here.
Try also and go to https://weatherflow.github.io/Tempest/api/swagger/#!/observations/getStationObservation then click the Authorize button at the top and enter your personal token.
After that scroll down a bit on this page, and enter your Station ID. Please post the result here.
This will show if data are available. If they are, I will need to see what else can be wrong.

Thanks, it's working again (I redid the whole thing again).
I had only just created the API yesterday so maybe there was just a bit of lag on their end but it works now. Many thanks for putting the time into this!!

No activity for several month. Closing the issue


Unhandled Exception: 'NoneType' object has no attribute 'replace' (type: AttributeError)

info_9780135262726.log
Please see attached log. I'm new to programming and python and i'm not sure how to fix this error. If someone could assist me or point me in the right direction, I'd greatly appreciate it. I'm not exactly sure what is going on or where to begin to fix the code if necessary.

Hi,
it seems that this is related to https://github.com/lorenzodifuccia/safaribooks/issues/171
See https://github.com/TheSnoozer/safaribooks/commit/3d3147a1ad1bb80c9e37d306f618054a0495fc50 how it could be fixed.

Hi,
it seems that this is related to #171
See TheSnoozer@3d3147a how it could be fixed.

@TheSnoozer thanks! I replaced that line of code and it worked. I was able to pull it!


The "shopping24-for-the-record" pull request

We put the querqy parser in production on monday. This PR contains some minor changes we made to the codebase.

Closing this PR. We'll review the release/build configuration in connection with issue #3 anyway.


BaseActionWatcher.watch should provide a way to handle error

Currently method BaseActionWatcher.watch catches errors in an internal try/catch block and silently swallow the errors. It stops watching on any error without providing any chance to retry. It returns undefined in all cases :O, and all state properties are private so there's no way to handle errors from derived classes.

It should be a class design bug, not an enhancement. Because whenever a network error happens for example, client app (which using demux) knows nothing and can do nothing even if it wants to restart.