Can we double blocksize at the same time as we introduce Segwit?

Example code pull https://github.com/bitcoin/bitcoin/pull/6451
This topic has received massive upvotes with 97% up for doubling blocksize when introducing segwit: https://www.reddit.com/r/dogecoindev/comments/mvdzls/transaction_speed_and_fees_hyper_doge/
And this topic describes it also:  https://www.reddit.com/r/dogecoindev/comments/muvl1t/scaling_bitcoin_was_supposed_to_implement_segwit/
Even supposing Segwit leads to a fully functional lightning network, still a transaction pair needs to be completed before a lightning channel can be opened.  So it makes sense to scale blocksize to accommodate for mass adoption so that fees and congestion stay low - and high value transactions can be settled on-chain.  Also I strongly suggest that segwit addresses always remain optional, like in Bitcoin. My suggestion is to double blocksize whenever needed, perhaps every 7 years.  I think doing this at the same time as the addition of segwit can help set a culture that we will increase blocksize as needed to scale to be money for the world.  Currently we never fill up blocks which also shows that increasing the blocksize isn't going to magically make the blocks bigger in the near term and there would be no difference to running a node.  As a global payments network, we will eventually need to settle (on-chain) hundreds or more transactions per second (even if there are thousands of lightning per second) and we can only accommodate 33 with a 1mb block size.  If we doubled blocksize every 7 years on average, this stays well below moore's law and running a node will never become burdensome to someone willing to invest in a reasonable server.  Again each server is hosting a global payments network so we shouldn't assume a full node will always be able to be run from a smartphone, so I think slowly increasing blocksize would be the way to go to make sure we are able to scale properly.
I understand this will take a hard fork, but it keeps with the core of Dogecoin so it will get full adoption and will not lead to a chain split.  I think the biggest risk to a chain split is refusing to increase blocksize, and that is what led to the creation of Bitcoin Cash.  So a hard fork to double blocksize will not lead to a chain split and can help unify the community and show the world that we indeed will scale to be money for the world and can increase mainstream adoption even more.  ETH hardforks regularly and this does not lead to chain splits, so it is a very viable strategy especially if planned long in advance.

I'm glad if Dogecoin community supports increasing througput of the base network. However, now is not a good time to make that decision. Dogecoin network struggles as it is. We have a lot of work to do to improve it in order to even reach the currently allowed throughput. You cannot increase the capacity by just changing one number. So here is the deal: improvements first, then decisions to change the protocol.
As for SegWit and second-layer solutions, I don't count on them for increasing throughput. Maybe they will help, maybe not. I see it as a separate question.

I certainly understand the want to optimize the existing efficiency first, before expanding it. Approaching a consensus on the issue does not however necessarily mean putting it ahead of that task in priority.
We could consider it implied that needed optimization tasks fall ahead of block size changes, yes? I've noted that lightening as it exists for BTC today, isn't quite as refined as it could be, whilst segwit does open up multiple future options (such as crosschain, and l2 scaling) and is thus desirable, it doesn't really immediately solve for scaling from what I can determine.
In my mind lowering fees, and improving TPS are core functionality aims, with dogecoin being conceived by the community to be an alternative cash system. Block size is clearly an obvious choice for TPS.
Setting up the notion of an incremental increase over time actually isn't a bad idea, as it reduces some of the issues one might have maintaining the network in the short run, and also sets an expectation that helps maintain that keeping of pace of the network with the expansion of block. It doesn't hurt that 7 years is actually dog years ;)

So immediate thoughts:

What problem are we solving?
What does this do to network scalability; bandwidth per node, obviously, but do we need to expand mempool if we're increasing throughput? There's a LOT of people already struggling to download the blockchain (partly P2P doesn't scale aggressively when the network size goes 10x, but partly downloading 100+GB takes a while).
How does this affect disk usage? I mean the blockchain's already fairly large, are we okay doubling the increase rate? Potentially increasing it exponentially?
Are there any feasibility issues with miners, especially given they're frequently located in China, and how does the Chinese firewall affect this?
Does this affect miner viability? If a block is twice the size, it takes twice as long to relay, so is that twice the risk window of two miners creating competing blocks?

Bitcoin had a massive holy war over this, and I don't necessarily agree with their conclusion that basically 10MB every 10 minutes is enough, but we're 10MB every minute. For scaling past that, personally I'd rather we scale horizontally onto multiple chains. We already have pDoge/renDoge wrapped tokens on Ethereum, introducing SegWit means we could look at Lightning (although that has different issues around whether you need to have a license to run a Lightning node, in some places). I accept it's a harder route, but I think multi-chain is a better idea. WDYT?

What problem are we solving?
I'd say transactional speed, from a complete layman's perspective. Dogecoin needs to be as musk eloquently put it 'ideally orders of magnitude faster' to suit it's proposed use as a digital currency. That might not be fully achievable onchain, but there's the immediate rise it use for retail to consider, and the nessasary interaction of crosschain or offchain applications with the mainnet in the longer term (whether that's something like a payment chain, or another chain entirely)
Re: multi-chain. I've thought about this. But there are issues here too. For one, centralized bridges are centralized.
Secondly they add user friction - you have to manually bridge, you can't send to a dogechain wallet from said bridge, neither of which are intuitive and set up boundaries to adoption. Any crosschain solution needs to interact directly with the native chain in order to be frictionless (something more like thorchain for eg, which is based on cosmos)
Thirdly there's the issue of longevity. Assuming dogecoin is still around in say twenty years, doesn't mean than ANY other chain still will be, or maintained to it's current level. If the chain we rely on for efficiency is in a poor state further down the track, we've introduced a dependency. Things may seem stable in the short term, but the future is major guess work. You could end up building out a whole support ecosystem on another chain, only to find it falls apart.
I can totally see the reasoning, and desire to do settlement crosschain. Especially because some such chains are orders of magnitude faster already than proof of work (although perhaps less secure, at least theoretically in some cases). And perhaps all these issues can be eliminated in some manner. But I don't think a wrapped ethereum token is close to addressing those issues.

I guess the other thing worth considering is that most of the issues are related to the file size. If the blocks aren't being filled currently, is it actually correct to assume they suddenly will be in technically relevant time frames if the block size is increased? Or is it a non-problem?
Also I guess, BCH has done this already - what was their experience, and did they have to solve for any of this? That may not be relevant, I'm not sure.

So Gaven Andresen has proposed both compression for BCH as well as Bootstrapping for faster syncing of new nodes.  Both of those could be looked at of course and I seem to think we could get Gavin to help us a bit.
What problem are we solving?
The main problem I see us solving by increasing blocksize at the same time as segwit, is setting a culture to both scale on and off chain as reasonable.  I can see devs getting sucked into just following all BTC update path and not really stopping to consider what might or might not be suitable for dogecoin.  If we want to be the peoples money it should always be cheap and fast to settle on-chain, and off-chain also if possible.  We want the best of both worlds.
What does this do to network scalability; bandwidth per node, obviously, but do we need to expand mempool if we're increasing throughput? There's a LOT of people already struggling to download the blockchain (partly P2P doesn't scale aggressively when the network size goes 10x, but partly downloading 100+GB takes a while).
Firstly we have to realize that each full node is literally a global payments network.  We run thousands of copies of it compared to Paypal that uses server farms to run ONE copy of it.  It is inevitable that at least a rudimentary server would be required to run a global payments network.  We need to prioritize the end user paying for a stick of gum at circle k more than if it is going to require a $1000 server to run a full node in the future.  It is awesome that anyone on a laptop can run a server currently, but we can't let that hang us up from being a global payments network first and foremost.  Gavin Andresen (successor to Satoshi) has proposed both compression solutions and also Boostrapping solutions to make syncing a new node as painless as possible for BCH.  Also I honestly think that most of our blockchain is a layer-2 to litecoin's merged mining might be playing a large part of why it is tough to sync currently.  As we win more blocks outside of AuxPoW, I think that will improve our syncing rates.
How does this affect disk usage? I mean the blockchain's already fairly large, are we okay doubling the increase rate? Potentially increasing it exponentially?
Firstly this will not effect the blockchian size at all in the near term.    So even if there was no limit to how large blocks could get, it wouldn't effect anything presently.  As we grow and start to fill up blocks then yes it will grow faster, but only 2x as fast, and it is now 7 years since we started and everyones harddrive space has more than doubled in that time.  I think a very-sub-moore's law scaling (moores law is doubling every 2 years, I am proposing doubling every 7) will keep us safe on disk usage.
Are there any feasibility issues with miners, especially given they're frequently located in China, and how does the Chinese firewall affect this?
I have never heard of any problem with this from the BCH people, but would be valuable to reach out and see what SV and BCH devs think.
Does this affect miner viability? If a block is twice the size, it takes twice as long to relay, so is that twice the risk window of two miners creating competing blocks?
Yes there might be a slight increase in orphan rate, which is the measure of this sort of thing.  Orphan rate of dogecoin has reduced dramatically since launch, look at the ANN on bitcointalk.org and when dogecoin started everyone was complaining about orphans!  This relay rate has improved dramatically since and I don't think dogecoin has any issues with orphans now.  I have seen coins with 30 second blocktimes doing ok on orphan rate, so we would be safe.  And no it is not quite a 1:1 time thing, a 2 mb block would not take double as long to relay, maybe a percentage slower like 25-50% I would guess.  There are probably formula's out there.  I will look into our current orphan rate and relay time equations and get back to you.

I can't find doge's orphan rate, but for comparison CranePay has 30 second blocktimes and has around a 1% orphan rate which to me is acceptable. http://cpu-pool.com/tbs  Eth I believe has very short blocktimes and they are doing just fine and their amount of transactions will continue to dwarf ours for a long time.
As you can see here: https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-6-data-propagation doubling the block size does NOT double to time to relay.  Probably more like 50% longer instead of 100% longer.

What problem are we solving?

We don't know how fast Dogecoin will be growing. We want to be ready to handle the increased demand if it happens.

What does this do to network scalability

We need to test that. I'm afraid that even if we removed block size limit completely, we would still not reach the desired throughput because, for example, much of current code runs in a single thread.

How does this affect disk usage?

Current limit allows about 500 GB of new data per year. That already would prevent most regular users from using Dogecoin Core. One problem with that is that we currently don't have a good open source alternative.

Are there any feasibility issues with miners, especially given they're frequently located in China, and how does the Chinese firewall affect this?

Miners will probably have to make sure they are directly connected to most other miners. Any intermediate node may have an effect on profitability. They may have VPN tunnels where needed. Making high bandwidth channels to China should be doable.

Does this affect miner viability? If a block is twice the size, it takes twice as long to relay, so is that twice the risk window of two miners creating competing blocks?

It will not affect viability significantly if propagation times will still be low enough. New blocks normally are not transmitted in full, but are reconstructed on the receiving node. Though we may need to further improve this technology.

For scaling past that, personally I'd rather we scale horizontally onto multiple chains.

We may eventually having to rely on sharding or off-chain transactions, but we will likely still need high throughput of individual chain. I think that it makes sense to work on increasing on-chain capacity now, which will have immediate benefit in case of increased demand.

Thanks for your input Shibe2!
"Current limit allows about 500 GB of new data per year. That already would prevent most regular users from using Dogecoin Core. One problem with that is that we currently don't have a good open source alternative."
Yes, and again this shows that we are not currently filling up blocks so this change would mean nothing for the short term.  Eventually yes a server size storage amount would be needed, but again I think our priority should be end user experience, not people who want to run a payments network server, which would need to be at least a rudimentary server to serve the globe.  Each node is basically competing with Paypal, so it would be naive to think you could run it on an off the shelf laptop forever.

Okay, so if we want transactions to be faster, it feels like block time needs to come down, not size per block going up.
Definitely for now I want to even just get 1.21 working (with the tests passing, which is the tricky part, I'm aware there's a prototype that sync but breaks most of the tests, so we have low confidence in it), and get a release cycle rolling, and then worry about what needs to be in the later releases.

Where we need faster transactions, I'd say they should reliably go through in under 5 seconds to compete with other payment options. The idea is to use some kind of off-chain transactions for these cases. For example, based on payment channels.

Yes, 5-10 seconds seems about right for point of sale transactions (like a person, in a store standing in a queue). Under 5 ideally. Not sure if it's practical to lower block time that much. I'd guess not anyway.
I hope this isn't me showing my stupidity, but I'm going to share some random thoughts.

Say a person locks away 1000 doge in the system, as a bond or stake and then the network confirms their 'fast doge' transaction without actually completing finality (just literally that the transfer is processing), but if it somehow doesn't process or is an attack it uses the stake to compensate the other party. Still using proof of work, but handwaving it for point of sale purposes because the individual has collateralized it?

Once any pending transactions are fully finalized, the stake money can be withdrawn. Might be a little unwieldy to users. Chunky perhaps.

Would a hybrid consensus method simply for quick payments be an insane or overly complicated idea? I think there are some coins that do that.

There may be a way to solve those xchain issues, such as using wrappers, wallet send/receive incompatibility and dependency on specific chains that I raised.

I notice thorchain and cosmos use tendermint to achieve some level of native crosschain interaction without wrappers, or manual bridging by the user. Could this be used to create some kind of generic compatibility for a crosschain settlement channel, using other chains for settlement but without being chain specific or requiring that user friction? Leaving the problem somewhat third party, but without the friction or dependency?
If segwit is still in a state of relative immaturity, then for crosschain purposes it might pay to focus somewhere else anyway.
These are probably all downright foolish suggestions, but I thought perhaps there might be a way to approach this problem from a fresh angle, rather than using what others have done. I'm not a coder I dropped out of C++ level 1! But maybe there's something in my throwing things at a wall, that inspires a more informed chain of thought.

Okay, so if we want transactions to be faster, it feels like block time needs to come down, not size per block going up.
Definitely for now I want to even just get 1.21 working (with the tests passing, which is the tricky part, I'm aware there's a prototype that sync but breaks most of the tests, so we have low confidence in it), and get a release cycle rolling, and then worry about what needs to be in the later releases.

So, its a tradeoff when we are talking blocksize vs blocktime.  Blocksize doubling will not (quite) double to time it takes for the block to propagate the network.  Halving the blocktime will exactly half the time the block gets to propogate before an orphan.  So it seems to me the best gains in terms of scaling for maintaining a low orphan rate is to increase blocksize, not reduce blocktime.
The benefit to reducing blocktime is faster confirmations, which is a big bonus.  So for raw TPS, blocksize increase is best.  For quicker confirmations and a moderate increase in TPS, lower blocktime is best.  In reality there would be an optimum blocksize and blocktime, no one has figured it out yet.  Another coin with a quick blocktime is Digibyte with 15 second blocktime.
Either way, 30 sec blocktime OR 2mb blocks would turn out to be fine in practice.  the 30 sec blocktime would show results immediately, as people can send transactions faster.
Another thing to consider is there is a practical limit to blocktime, and you can never really go under 15 seconds because it takes light 0.15 seconds to travel around the world https://web2.0calc.com/questions/how-long-does-it-take-for-light-to-travel-around-the-world , so that is 1% of 15 seconds.  Right now we are very far away from the speed of light connections so we should not go below 30 seconds blocktime IMO.
In conclusion blocksize can (in theory) scale to infinity.  Blocktime cannot.  But we do have room to reduce blocktime, perhaps that is a good step to take since there are much faster coins out there, and Doge was designed to be super fast.
Here is the ANN (which is hard to find) for posterity sake https://bitcointalk.org/index.php?topic=361813.0

Where we need faster transactions, I'd say they should reliably go through in under 5 seconds to compete with other payment options. The idea is to use some kind of off-chain transactions for these cases. For example, based on payment channels.

That is just not possible, there is a practical limit to how fast blocks can propogate the network.  15 seconds would be the absolute minimum in a p2p currency in my educated opinion since light takes 0.15 to navigate the globe and that is 1% of 15 seconds.  We need there to be a 1% orphan rate (or less) imo.  For a centralized network 5 seconds can work.  Not for decentralized.

I dont see the need for faster block times since zero confirmation
transactions are generally safe. We dont have RBF. Follow what BCH is doing.
On Fri, Apr 23, 2021 at 10:03 AM GiverofMemory @.***>
wrote:

Where we need faster transactions, I'd say they should reliably go through
in under 5 seconds to compete with other payment options. The idea is to
use some kind of off-chain transactions for these cases. For example, based
on payment channels.
That is just not possible, there is a practical limit to how fast blocks
can propogate the network. 15 seconds would be the absolute minimum in a
p2p currency in my educated opinion since light takes 0.15 to navigate the
globe and that is 1% of 15 seconds. We need there to be a 1% orphan rate
(or less) imo. For a centralized network 5 seconds can work. Not for
decentralized.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dogecoin/dogecoin/issues/1849#issuecomment-825792698,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDMU4SOWMN74CHYH25QYPDTKGR57ANCNFSM43M6OQYA
.

I dont see the need for faster block times since zero confirmation
transactions are generally safe. We dont have RBF. Follow what BCH is doing.

Even so, it is nice to get it in a block, as that does add a good bit more security.  Also halving the blocktime will double TPS just like blocksize doubling would.  Eventually the only way to scale to "infinity" is with blocksize increases on a regular basis.

RBF has been in Dogecoin for over 3 years?

I suppose because dogecoin has only recently waken from it's slumber, there might be network reasons from a developers perspective for favouring block time over size, for now? (ie, some nodes not connecting or propagating well)
And what giverofmemory is advocating (correct me if wrong), is not nessasarily immediate block size increase, but a long term commitment to onchain scaling.
I can see the argument. Offchain scaling will require onchain scaling to be efficient anyway, as there does need to be interaction with the mainnet, yes?
And there are vagueries around how well present day solutions, like lightening actually work (ie for btc) and I guess also basically delivery - who will provide them, how decentralized, how secure they are (I've heard people question this with lightening). Perhaps that might tie in also with my question about whether segwit is actually optimal for increasing multichain compatibility, instead of something custom based around tendermint implementation which seems to be the currently popular crosschain methodology? (that might be gobbledegook, but I'm trying!)
So it seems to me that, in part, it's not about whether increasing block size is a good idea, generally, from a future perspective assuming dogecoin useage grows, just as to whether it's the most practical right now.
Perhaps time could be halved soon-ish (next update or similar), with the intention to increase size later with the growth of the network and the refinement of various levels of optimization? Or that block size increases could be planned, but just deferred until appropriate?

I consider unconfirmed transactions risky, especially considering the current state of Dogecoin P2P network. We could improve reliability of unconfirmed transactions such that they would be acceptable for more use cases, but it would still not be a general solution. We would still need off-chain transactions to improve speed in other use cases.

And what giverofmemory is advocating (correct me if wrong), is not nessasarily immediate block size increase, but a long term commitment to onchain scaling.
Yes!
Offchain scaling will require onchain scaling to be efficient anyway, longer term, as there does need to be interaction with the mainnet, yes? It avoids a certain level of dependency on a relatively unknown solution.
Yes, and to me I see no reason to implement Segwit without BTC having proven out a lightning network.  Segwit is a bridge, and I prefer not to build a bridge to nowhere without a realized destination.  But if we commit to on-chain scaling, then I am fine with introducing Segwit if that is what people want.  It might have some negative repercussions in the near term though since we are already having issues with syncing and segwit is splitting our network into an entirely other layer which will harm syncing.
When segwit was written, there were no or next to no active crosschain developments, or actually active networks. We are in a place where we can see these actively popping up and have a better idea of what connections between blockchains look like.
If there was a mechanism, within the chain, for commiting a stake of dogecoin, that might allow other networks with tendermint, to apply smart contracts to the locked dogecoin pool?
Also I'm pretty sure we can use something like OP_RETURN to do cross chain stuff with our current tech, I'm curious what BCH is doing since they have tokens and the like there.  I think the issue was BTC is dead set on keeping 1mb blocks and extra metadata on the blockchain is a big no-no for them hence why they need something like segwit to allow for things outside of blocks.

"Also I'm pretty sure we can use something like OP_RETURN to do cross chain stuff with our current tech, I'm curious what BCH and BSV are doing since they have tokens and the like there. I think the issue was BTC is dead-set on keeping 1mb blocks, and since their blocks are full, extra metadata on the blockchain is a big no-no for them hence why they need something like segwit to allow for things outside of blocks."
Hmm, no I was hinting at something more sophisticated, but that I don't quite have the coding experience to refine or articulate well.
I'll use a practical example. Thorchain uses tendermint (as most new xchain applications do, if not all), to bridge to other chains. But in order for them to create smart contracts, liquidity pools, loans and the like, they've had to create a liquidity infrastructure that stores the other chains assets. It's a lot of infrastructure. That allows them to layer stuff ontop of native assets, without wrappers or manual bridging.
Now if there were a way, for external smart contracts, and other chains, to access in a particular, limited fashion, the dogechain directly - like a special type of wallet for example, that could then be locked into a smart contract - then all these features could be built ontop of the doge network, without wrappers, AND without special infrastructure on the other end.
I'm not sure how this would look. Likely you'd need to go for high confirmation transfers, and limit access of the external party to ensure security, avoid double spends and exploitation.
But something like this could provide the expandability of a settlement layer, and crosschain composability and communication without a high infrastructure requirement or user end friction.
Rather than just allowing communication, it would enable functionality to cross chains.

Sorry BTW, to go slightly off topic with the whole multichain thing. I've just been having a kind of lightbulb moment with all that.
Generally I agree that, onchain scaling is more of an ongoing issue, and would be nice to just see a slow march, in some form. Not knowing the technicals intimately, I have no particular preferences, and defer to others. But it always pays to be future minded.
It's also possible if what I suggest above was implemented, that faster confirms might help, and at least higher TPS in the long run too (see ethereum to what happens when you start to get not just users, but dapps running on your network).

Oh, and so sorry to add to much off-topic, here, but I learnt Solana uses a blockchain clock (based on SHA256) to help govern their security. Seems like a rather more elegant way to prevent double spend on a xchain, or l2 solution than lightening (just limit the timing of transactions out from those specialized wallets with smart contract access, or otherwise locked funds).
Adds slightly to my thinking out loud about timeout periods, instead of lightnings fixed payees - that it is possible to keep time on the blockchain.  With a built in chain clock, one could just set the rate at which out transactions can occur via this mechanism to whatever finality is required to prevent double spend.

All good stuff and the concepts you are bringing up we need to talk on discord.  Does Dogecoin have a discord?  That would help.
Solana doesn't have a PoW blockchain.  The clock is probably just to help nodes agree on transaction ordering.  More like a distributed ledger than a blockchain in the sense we think of as a blockchain.  Proof of stake is pretty close to instant.
15 seconds is the absolute minimum for a PoW blocktime.  But we still aren't there yet.  30 seconds is doable with the current network.  For on-chain scaling not only is blocksize increase inevitable to keep a network functioning, it is preferable to reducing blocktime in the sense that for doubling of the blocksize you do not get doubling of transmission time.  So it has better returns on TPS than reducing the blocktime does.  I think both should be done in tandem with small changes over time.
Segwit is fine, it will make node syncing harder.  It won't significantly improve TPS, it is the foundation to a lightning network which will never be more than a niche product.  So to me segwit is more of a distraction from proper TPS on-chain scaling than anything else, and an excuse for devs to tap into that tasty 6.5 million dollar dev fund since segwit would be a major release.

Yeah that's right solana is proof of stake.
But a blockchain clock could in theory remove the need for confirmations, and also be used as a limiter for offchain, so that offchain transactions coin can be locked only until the onchain is complete? It wouldn't be batch processing, just a timeout.
So far as I can tell, confirmations preserve immutability of history. But if you have proof of history, via a blockchain clock, perhaps they might not be needed - as the order, or history can be written in to each txn by time based hashes generated by the miners?
You could also potentially remove orphan blocks this way (earlier completed blocks are preserved, later are removed). Assuming the clock itself is unique and unfalsifiable - ie based around cryptography. It's not simply a timestamp. It's based around generated hashes.
I might be wildly off on the conceptualization of all this. Maybe it's a dumb/unworkable idea!

Ya we talked about this on discord and it is a good idea.  To preface it, the biggest problem with reducing the blocktime is orphans.  And the biggest problem with orphans is centralization.
Big miners who mine lots of blocks can complete a mining challenge (1), see that (it looks like) no one else mined it first, and accept their block to mine the next challenge on.  If they win the next block too (2), then their previous block (1) is solidified in the blockchain.  Meanwhile small solo miner actually mined (1) first but by the time it got to big miner, big miner already saw his own block first so rejects the solo miner block (1).  What if there was a way to prove that solo miner actually mined block (1) first?  Well there is and it is called Proof of History (PoH) which Drael64 referenced from Solana.  This (seems to) work by each node broadcasting hashes every 0.4 seconds.  The next broadcast hash needs to hash all the other nodes last hashes.  This way there is this integrated timestamp into everything the miner or node does.  So the miner could include this timestamp hash in his block before mining it, to prove that he mined it when he said he did.  Now that part gets kind of hazy because he could always mine on an old hash and claim that his block was old.  So i'm not quite sure how he can prove something is old.  Not sure how solana solves that.

Yeah, there are some vagueries to how solana actually works to ensure the proofs from the validators (miners in our case), are collated into an absolute sense of time across the chain. I think perhaps that's connected to them being variable (ie can't be predicted in advance).
But if they do it, it can probably be done for proof of work.

I know I'm commenting a little late but anything that is done that causes unconfirmed transactions on the blockchain needs to be looked over a few times before putting it in effect, if unconfirmed transactions stay in the network for a long period of time it opens the door for malicious attacks on nodes or the transaction itself. Just my two cents worth from work experience

I know I'm commenting a little late but anything that is done that causes unconfirmed transactions on the blockchain needs to be looked over a few times before putting it in effect, if unconfirmed transactions stay in the network for a long period of time it opens the door for malicious attacks on nodes or the transaction itself. Just my two cents worth from work experience

I don't know what you mean by unconfirmed transactions on the blockchain.  If they are on the blockchain they are, by definition, confirmed.

I know I'm commenting a little late but anything that is done that causes unconfirmed transactions on the blockchain needs to be looked over a few times before putting it in effect, if unconfirmed transactions stay in the network for a long period of time it opens the door for malicious attacks on nodes or the transaction itself. Just my two cents worth from work experience

If you were speaking about my suggestion, to scale using 'Proof of History' ala solana, but in proof of work (+block time, and eventually block size)- it would be a very large project, and of course there would be testing.
But the idea is, if time of event/transaction is proofed, in the same way work is currently proofed, then you shouldn't need to do confirmations (or at minimum, far less), there should be less ways to do double spends (or none), and orphan blocks should be fairer.
Double spend type exploits derive from not knowing which order events come in. Depending on the degree to which you could have a blockchain clock in proof for work (like the tick'), it should at least be able to minimize every one of those.
Absolutely not sure whether it's entirely workable as a concept either, for proof of work. But seems like as a general concept, it has the potential to solve for a lot of proof of work inefficiencies, all based around not knowing order of events. If order of events could be solved somehow, that reduces the need to scale off chain considerably, long term.

One more thought, and this one more pertains to increasing blocksize. What about a cryptographic accumulator to prove that the current blockchain state is the correct one, rather than a full txn history on nodes?
This might help mitigate the storage issue.

Reverse download order and UTXO commitment are being worked on in other Bitcoin-based cryptocurrencies. I think that it should be a prerequisite for increasing block size limit.

This is another, related idea for scaling. Basically using a proof of stake sidechain for offchain scaling, instead of lightening. Using validation on a side chain, removes the need for payee specific payment channels, which makes payments much more viable.
https://github.com/dogecoin/dogecoin/issues/1924

What problem are we solving?
I see the issue as two fold. The work to be done and the decision to be made.  Block size change, coinciding with Segwit, sets up future increases as a matter of course, assuring the community we are truly trying to be a currency not a wealth storage gimmick.  I can understand the devs just thinking it can be put off because it’s not a priority, but I think the decision would be a signal to the community that our aims remain pure.  We are the peoples’ coin it should be cheap to facilitate txn settlement.
Also… Multi chain! A layer 2 for retail and institutional entities that want to use doge. Then they could pay the txn fees in the layer two reducing the cross chain traffic and security could be done by the retailer possibly even making a discounted txn fee for running node servers thus removing the onus from the consumer and placing it on the retailer. I know I know we want use case rn but really we are the people’s coin and if we use this as another selling point to the community we will get the use case when they start demanding their favorite retailers accept Doge. You could figure out a way to keep individuals on the main chain thus insuring the value stays in the hands of the consumer.
Our main focus should be spreading the ethos of the community to the rest of the world if we really want to make this dream come true. I know it’s supposed to be a joke coin but the joke should be that the ethos of the community backing this thing infects the world and we learn to use value for the things that matter not amassing wealth.
You guys ( core devs) are amazing people, you have created a Frankenstein, but this one has friends and a community that believes the stuff you have told us, and if we can truly create a crypto that helps to balance the scales, that’s worth taking the time to think about it, at least, if not working on it this second. I know everyone is super busy rn and we all appreciate it more than you will ever know, and now that the people know you Shibes need help, I imagine you will be getting it in spades soon.

I am closing this issue. We now have a discussion space (https://github.com/dogecoin/dogecoin/discussions). I encourage folks who would like to engage on this topic, which is important, to create a discussion to hash out ideas. The Issues section is for tehnical issues we can take action on and not architecture decisions about the blockchain.


Game freeze when open minimap (L Trigger) or Taunt menu (R Trigger)

every time i press it, it crashes

is there an error in the browser console?


Demo is unavailable

Hi. Demo app is not working properly. I see response status code as 401 Unauthorized ("Not Authorized - Invalid Token"). I believe you have to change mapbox token which is invalid now...

@dkocich Thanks for checking. It is working now.


Changed Capitalization to be better(On README)

Summary
Changed Capitalization to be better
Checklist

[x] This PR is not a code change (e.g. documentation, README, ...)

Don't see the point, they're literally just image links nobody will ever see


Change FolderList activity into a folder manager

Add a "Manage folders" entry above "Settings" in the navigation drawer.
Remove actions from action bar that are not directly involved in managing folders (check mail, compose, search, send messages, empty trash, settings)
Make going to folder settings the main action when clicking on a folder in the list.

Things left to do:

[ ] change Activity title to "Manage folders"
[ ] remove unread/star indicator
[ ] remove folder state text below folder name
[ ] make "up" navigation go to the MessageList Activity
[ ] rename activity + create activity-alias for old activity, point it to MessageList and handle all old intents (so existing homescreen shortcuts will still work)

The last one should probably be deferred until we got rid of the Accounts activity.
Nice to have:

display folders similar to how we do in the side drawer (folder icon on the left, same order)
get rid of chip color?
have some kind of visual indication that clicking on a folder will open its folder settings

For work that is left to do, see #4350.


How to config requireJS to load tinycolor.js and angularjs-color-picker.js

How to config requireJS to load tinycolor.js and angularjs-color-picker.js.Thanks

I find that when I using requireJS to load tinycolor.js and angularjs-color-picker.js.Some errors will happen, it tip that tinycolor is not defined in angularjs-color-picker.js.I can sure that tinycolor.js is load before angularjs-color-picker.js.But, when I using tag

Can you post your code where you are including angularjs-color-picker.js

@ruhley Sure,the code in main.js is like that `require.config({
baseUrl:'../../js',
paths: {
//app
'app':'libs/angular/app',
// angular
'angular': 'libs/angular/angular.min',
// angular-ui
'router': 'libs/angular/angular-ui-router.min',
'tinycolor':'libs/color-picker/tinycolor.js',
'colorPicker':'libs/color-picker/angularjs-color-picker.min'
},
shim: {
// angular
'angular': {
exports: 'angular'
},
// angular-ui
'router': ['angular'],
'app':['router'],
'tinycolor':['angular'],
'colorPicker':['angular']
}
});
// 初始化bnApp模块
require(['app', 'colorPicker'], function(){
angular.bootstrap(document, ['bnApp']);
});and when I open the page which use '<color-picker>' tag, the errorReferenceError: tinycolor is not defined
at m.c.hueUpdate (angularjs-color-picker.min.js:34) will show in browsers console.

I must admit I have never used RequireJS, but try require(["app", "tinycolor, "colorPicker"], function(){ instead.

Thanks.I have tried that, but nothing can help.I wonder that tinycolor.js is just a general javascript file,isn`t it?And I defined a simple javascript file which just has only a simple function that alert something, and it can run normally whereever I use.

As this seems to be a RequireJS configuration issue and not a problem with this library, I am closing this ticket. Sorry I couldn't help you.

fine

I found this issue because I struggled with the same problem. Tinycolor doesn't register on the window object if you use a loader, see https://github.com/bgrins/TinyColor/issues/122.
require(['tinycolor'], function(tinycolor) {
    window.tinycolor = tinycolor;
});

Will fix it.

@pevers thanks


WIP | Global notification setup

https://linear.app/pillarproject/issue/PRO-2153/story-task-notification-setup
Description

Global notification setup

How Has This Been Tested?

Tested on local

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

@IAmKio, I have put button on home to test notification is working or not.

@IAmKio , It is common structure for notification throughout app, but we have not created any component on which we can set notification yet so, I put this PR as WIP. I am merging this PR and start working on login component so, will check notification in that also.


nested data invalid

The following example works on Handlebars but is invalid in the dynamic text plugin.
template:
{{person.1.firstname}} {{person.0.lastname}}

json payload:
{
  "person": [
    {
      "firstname": "Yehud",
      "lastname": "Katz"
    },
    {
      "firstname": "Yehd",
      "lastname": "Kat"
    }
  ],
}

Thank you for reporting! I'm not sure when I'll be able to look into this, but I'll prioritize it if you'd be willing to submit a PR 🙏

Where are you defining the JSON payload? The dynamic text panel uses the result from a query. Do you mean that one of fields in the query result contains JSON data? In that case I think you'd need to tell Handlebars to parse that into JSON somehow.

I think I have a similar issue but maybe I just miss how to use Handlebars/dynamic panels. basically, I have a query (table not time series) and i want to axes to data of second row. {{userName}} always will return results of the first row from the table but I need {(userName.[2]}} from my second row of the table. and my question it is possible? I saw just the function "render template for every row" but I do not need for all rows templates :)

@freedeaths @bankauskas It's possible to address a specific row in the returned data with the 'All Rows' option enabled and use Handlebars variables like:
{{#each data}}
  {{#if (eq @index 3)}}
    {{title}}
  {{/if}}
{{/each}}

We added this recipe into documentation: https://volkovlabs.io/plugins/volkovlabs-dynamictext-panel/recipes
Let us know if there is anything else.

Actually, it's possible to address it using {{data.4.title}} with All Rows option enabled.


t.getId is not a function

Issue Id: 03bb3666-4d56-a8c6-e4f9-cbf7719cf0a5Versions - 1.7.0-insider (10/24/2016 9:49:46 AM)Stack TypeError: t.getId is not a function/vs/workbench/parts/debug/electron-browser/debugViewer.ts#L274:47 (getProcesses)/vs/base/parts/tree/browser/treeModel.ts#L394:58 (_this)/vs/base/common/winjs.base.raw.js#L1170:0 (onComplete)/vs/base/common/winjs.base.raw.js#L852:0 (_notify)/vs/base/common/winjs.base.raw.js#L1068:0 (enter)/vs/base/common/winjs.base.raw.js#L1036:0 (_run)/vs/workbench/parts/debug/electron-browser/terminalSupport.ts#L96:8/vs/workbench/parts/debug/node/v8Protocol.ts#L67:9 (prototype)/vs/workbench/parts/debug/node/v8Protocol.ts#L28:9 (this)/vs/workbench/parts/debug/electron-browser/terminalSupport.ts#L85:85

@isidorn fyi this was from an insiders build.

@bpasero I do not think this is possible. Is the stack trace 100% accurate, how many times did it happen might you know.

public getId(tree: tree.ITree, element: any): string {
	if (typeof element === 'number') {
		return element.toString();
	}
	if (typeof element === 'string') {
		return element;
	}

	return element.getId();
}

I would put my bet that element is null/undefined or another primitive type.

Wow first time ever that error telemetry uncovered an awesome bug for me!
This was a regression that 'Load more stack frames' scenario was not working
Though the error stack frame I was looking at did no lead to that function, not sure how you got that

To verify:

Have a breakpoint that has a deep stack when hit, for instance a recursive fibonaci function
Make sure you get 'Load more stack frames' in the call stack view and that you can browse them


[Bug]: resetWidget function is not evaluating Disabled code on widgets

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When an input field, who's Disabled field code resolves to true, is explicitly enabled (setDisabled(false)), it will stay enabled, even after executing resetWidget("inputWidget").
Steps To Reproduce

Add a Table1 to the page.  Put any data in it.  Set default selected row to -1.
Add Input1 to page.  Set Disabled to {{Table1.selectedRowIndex < 0}}
Add Button1 - onClick {{Input1.setDisabled(false)}}
Add Button2 - onClick {{resetWidget("Input1")}}
Reload the page (Table will have no row selected, -1, so Input1 will be disabled)
Click Button1 - Input1 is now enabled.
Click Button2 - Input1 is still enabled.
Select a row in the table.  Input1 is still enabled.
Select the same row in the table (index = -1), Input1 is disabled.
Go to step 6 to repeat behavior.

Public Sample App
No response
Environment
Production
Severity
Medium (Frustrating UX)
Issue video log
https://www.loom.com/share/4c26cc1f4f864619a61b11f604a07a4a?sid=e72afcb2-ea9b-4637-938d-6bda433f8b78
Version
Self Hosted 1.9.60

I just discovered the same behavior with a button.  It's Disabled code is not being evaluated with the resetWidget function.  Replace Input1 with Button3 in the steps above and you will see the same behavior with Button3.

Reset widget is only to reset the inputs given to a widget and not to reset programmatic manipulations to the property

Reset widget is only to reset the inputs given to a widget and not to reset programmatic manipulations to the property

I've noticed that the value ( set by setValue ) does get reset, but the disabled prop does not. How are they different?


[reliability][fix] If MFA input field becomes stale, retry sending keys

I'm not sure why, but starting Apr. 7th, 2021, my script using mintapi started failing with the following stacktrace:
Traceback (most recent call last):
  File "scraper.py", line 372, in <module>
    main()
  File "scraper.py", line 342, in main
    cookies)
  File "scraper.py", line 206, in _LogIntoMint
    wait_for_sync=_GLOBAL_CONFIG.WAIT_FOR_ACCOUNT_SYNC,
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/mintapi/api.py", line 516, in __init__
    chromedriver_download_path=chromedriver_download_path)
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/mintapi/api.py", line 605, in login_and_get_token
    chromedriver_download_path=chromedriver_download_path)
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/mintapi/api.py", line 422, in get_web_driver
    imap_password, imap_server, imap_folder)
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/mintapi/api.py", line 351, in _sign_in
    mfa_token_input.send_keys(mfa_code)
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/selenium/webdriver/remote/webelement.py", line 479, in send_keys
    'value': keys_to_typing(value)})
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/selenium/webdriver/remote/webelement.py", line 633, in _execute
    return self._parent.execute(command, params)
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute
    self.error_handler.check_response(response)
  File "/Users/luispe/.virtualenvs/my-transactions/lib/python3.7/site-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response
    raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: element is not attached to the page document
  (Session info: headless chrome=89.0.4389.114)

I tried digging around to identify the root cause, which appears to be caused by the page refreshing between grabbing the input field for the MFA tokens and actually submitting the generated keys.
This PR modifies the code so that it tries a second time in case this exception is raised.
Please let me know if there's a more appropriate way to handle this. I tried increasing the implicitly_wait timeout as well but that did not help.

I just pip installed your branch and I got the same error
selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: element is not attached to the page document


How to connect only the coordinating node

How to connect only the coordinating node.
I didn't see it on the documentation or use cases

Hi @wudaoluo
Assuming we are talking about the discovery process, you can enable in the client's Config the DiscoverNodesOnStart and DiscoverNodesInterval and then provide a ConnectionPoolFunc function to filter the connection pool in a way that best fit your usage.
Let me know if that's not the case!


Time issues by week

let parameters = ConfigurationParameters(startDate: startDate!,
endDate: endDate!,
numberOfRows: 1,
calendar: Calendar.current,
generateInDates: .forAllMonths,
generateOutDates: .off
firstDayOfWeek: .monday,
hasStrictBoundaries: false)

This is the correct setup for a single row calendar

closing this issue.
Let me know if other problems.


Class definitions interpreted as branches

Describe the bug
Using coverage run --branch reports an unexpected number of branches in a file with class definitions when using coverage >= 6.2.
To Reproduce
class MyClass:
    def my_method(self):
        return True

    @property
    def my_property(self):
        return True

my_class = MyClass()
my_class.my_method()
my_class.my_property

$ coverage --version
Coverage.py, version 6.4.4 with C extension
Full documentation is at https://coverage.readthedocs.io
$ coverage run --branch test.py && coverage report
Name      Stmts   Miss Branch BrPart  Cover
-------------------------------------------
test.py       9      0      2      0   100%
-------------------------------------------
TOTAL         9      0      2      0   100%

Generating the result XML file shows that the branch statement comes from the first line in the test file.
<class name="test.py" filename="test.py" complexity="0" line-rate="1" branch-rate="1">
    <methods/>
    <lines>
        <line number="1" hits="1" branch="true" condition-coverage="100% (2/2)"/>
        <line number="2" hits="1"/>
        <line number="3" hits="1"/>
        <line number="5" hits="1"/>
        <line number="6" hits="1"/>
        <line number="7" hits="1"/>
        <line number="10" hits="1"/>
        <line number="11" hits="1"/>
        <line number="12" hits="1"/>
    </lines>
</class>

Downgrading to 6.1.2 yields a different (but expected) result.
$ coverage --version
Coverage.py, version 6.1.2 with C extension
Full documentation is at https://coverage.readthedocs.io
$ coverage run --branch test.py && coverage report
Name      Stmts   Miss Branch BrPart  Cover
-------------------------------------------
test.py       9      0      0      0   100%
-------------------------------------------
TOTAL         9      0      0      0   100%

6.2 is the earliest version where I have found the unexpected behaviour.
$ coverage --version
Coverage.py, version 6.2 with C extension
Full documentation is at https://coverage.readthedocs.io
$ coverage run --branch test.py && coverage report
Name      Stmts   Miss Branch BrPart  Cover
-------------------------------------------
test.py       9      0      2      0   100%
-------------------------------------------
TOTAL         9      0      2      0   100%

Tested with Python 3.8.14, 3.9.13, 3.10.6 on macOS 12.6 (x86) with a minimal virtualenv only containing the tested version of coverage.
Expected behavior
No branch statements are reported in a file with a class definition but no branch statements (coverage 6.1.2 behaviour).

Hmm, I'm not sure why I changed this in 6.2, but I think you are right: classes shouldn't be considered branches.  I've put back the old behavior in commit fd369186.
A remaining mystery is why classes were considered branches when def lines were not...

This is now released as part of coverage 6.5.0.


Remove DNN Corp Default Copyright

Description of bug
On a new install of DNN, the Copyright that is configured is DNN Corp.
Steps to reproduce

Create a new blank DNN site

Notice the DNN Corp copyright in the footer of the default skin

Expected behavior
I think the community copyright should be used here.
Screenshots

Affected version

[x ]  9.6.0

Noticed on 9.6 but I assume this is in all of the versions.

this need to be fixed in the website template

I’ll try to take a crack at this one.

I believe the issue is in the script that loads the seed data... I was going to work on that a while back.  I think this is the next "cleanup" area.

Reason I did not move forward on fixing this was knowing the desired end result.   I think it should be "generic" as can be for all seed data.

You can see this shows in the theme, the theme is in good shape it is the seed data.   @sleupold you probably the best to know how to dig this up or @valadas and @mitchelsellers would you know off hand which file loads the seed data.
What I recall is a sql script that is part of the upgrade process and during one of the upgrades it fixes an issue and adds DNN Corp into the DB.

\DNN Platform\Website\Install\DotNetNuke.install.config.resources
This is part of the initial installation... however one version I recall changes the host title
Maybe in this file this can get set or is set, but then gets changed?
Host Settings > Host Title is the field in the database it is connected to.
I think the UI is missing the ability to utilize and edit this for skins?!

Found the file
https://github.com/dnnsoftware/Dnn.Platform/blob/develop/DNN Platform/Website/Portals/_default/subhost.aspx
Line 792

@thabaum Fyi...I already have a PR being prepped for this issue.  Notice I assigned the issue to a little over a week ago.  ;-)

ok cool I also found it here.  Can we work with Host Title?  so a another issue I take it needs created... which I will do when I fix it I suppose :)
https://github.com/dnnsoftware/Dnn.Platform/blob/62e0c62531e64a21e9296a5845f7bd94c5082739/Dnn.AdminExperience/Dnn.PersonaBar.Extensions/admin/personaBar/Dnn.Licensing/App_LocalResources/Licensing.resx#L237

https://github.com/dnnsoftware/Dnn.Platform/blob/62e0c62531e64a21e9296a5845f7bd94c5082739/DNN Platform/Tests/DotNetNuke.Tests.Web/Api/JwtAuthMessageHandlerTests.cs#L158
https://github.com/dnnsoftware/Dnn.Platform/blob/62e0c62531e64a21e9296a5845f7bd94c5082739/DNN Platform/Tests/DotNetNuke.Tests.Web/Api/StandardTabAndModuleInfoProviderTests.cs#L99
https://github.com/dnnsoftware/Dnn.Platform/blob/62e0c62531e64a21e9296a5845f7bd94c5082739/DNN Platform/Library/Application/Application.cs#L39
These are some more places that could get changed along with the one above possibly along with the database entry.
Should I make another issue?  I put them here so you can do what you will with those places or leave them I am not worried about it.

@thabaum Fyi...I already have a PR being prepped for this issue. Notice I assigned the issue to a little over a week ago. ;-)

Thank you!


Update README.md

Update the plugin documentation to explain module_dir as I had mis-interpreted it.

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then  say 'jenkins, test it'.

Thank you. I hope that makes it clearer for other users.
Are you able to sign the CLA so i can merge it?
Thanks!

CLA signed.

Thanks!


New plot type: Dendrogram

Not very popular but still useful type of graph
Details:
Dendrogram
Dendrogram
Some images taken from the link above

I have considered adding more graph and tree-like ideas but never moved forward with it for a few reasons:

They don't really rely on coordinate space, although this also applies to things like pie charts which have been added

Thus they're not really plottables
This also makes the scope for interaction low, it would mostly just be the user zooming in to read small text

They are often (though certainly not always) static, so the user is often better served by using (La)TeX

This is not unique to this proposal, things like SignalConst are always static

Work on graphs or trees is unlikely to transfer to other plottables
It seems difficult

The last point is in my mind the main reason I have not put any effort into this area. As I pointed out, pie charts don't really fit into coordinate space but I worked on it anyways because it was easy. Plenty of plottables are mostly or entirely static, that is also not reason in and of itself to not consider it.
On top of the challenges above, I wonder if it fits just in terms of scope? This does seem like something a diagramming library should do instead. I'm noticing that there are not particularly many options for diagramming libraries, and most of them are not open source or even free. Perhaps that's an opportunity but I don't think it quite fits within ScottPlot's existing scope.

This is an interesting idea! On one hand it definitely seems doable, but on the other hand it seems outside the scope of what a typical plotting library would be expected to do. This almost seems like something you should use a SVG library to implement.
I added this to the plottable section of triaged tasks (#1028) next to wiggle plots (#450). It might get implemented one day, but it's not actively being worked on so I'm going to close this issue for now.


[SPARK-18394][SQL] Make an Attribute.toSeq output order consistent

What changes were proposed in this pull request?
This pr sorted output attributes on their name and exprId in Attribute.toSeq to make the order consistent.  If the order is different, spark possibly generates different code and then misses cache in CodeGenerator, e.g., GenerateColumnAccessor generates code depending on an input attribute order.
How was this patch tested?
Added tests in AttributeSetSuite and manually checked if the cache worked well in the given query of the JIRA.

Test build #80725 has started for PR 18959 at commit 3201f0a.

Test build #80725 has finished for PR 18959 at commit 3201f0a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80725/
Test PASSed.

Merged build finished. Test PASSed.

Test build #80736 has started for PR 18959 at commit eba844e.

In title and description, Attribute.toSeq seems to be AttributeSet.toSeq?

oh..ya, my bad.... thanks.

Test build #80736 has finished for PR 18959 at commit eba844e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80736/
Test PASSed.

LGTM except two minor comments.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80761/
Test FAILed.

Jenkins, retest this please.

Test build #80763 has started for PR 18959 at commit b33fde8.

Test build #80763 has finished for PR 18959 at commit b33fde8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80763/
Test PASSed.

Test build #80770 has started for PR 18959 at commit 973402b.

Test build #80770 has finished for PR 18959 at commit 973402b.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80770/
Test FAILed.

Jenkins, retest this please.

Test build #80781 has started for PR 18959 at commit 973402b.

Test build #80781 has finished for PR 18959 at commit 973402b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80781/
Test PASSed.

Merging to master. Thanks!


Maze Game and Inverted color

I have added the maze game using react. I hope you will like it.
Closes: #111
Closes: #112
https://github.com/user-attachments/assets/6db02edd-f899-4a3e-9441-4d48bbdf1c47

I raised 2 issues, but it is not taking them separately, I dont know how to manage that. But can you please assign me points accordingly, as I resolved 2 issues.

which two issues did you work upon?
I dont find anything chaotic in the recording you shared, can you rework on it and make it chaotic in functionality along with UI
Resolve merge conflicts
After all these 3 tasks, commit and tag me

1st issue was maze game and 2nd one was inverted color toggle butto

resolve conflicts

I cannot understand the conflicts. Can you guide me please.

The place where you added code, there already exists some code thats why it has merge conflicts, if you have added some new lines then shift the position of those lines which are creating conflicts, try understanding if not then search on google or youtube once, it would help you understand better

Please review @vansh-codes , it shows checks have failed.

Please review my PR.

Share screenshots and videos of your work

here is the video.
Uploading maze game and invert button.mp4…

@vansh-codes I have mailed you the video of my work.

here is the video of my work
https://github.com/user-attachments/assets/75e55873-085b-4a2b-a3a2-6cfe74e3f96f

Fix this errors

Fix the conflicts

@vansh-codes  Review please.

Thank you soo much


Vickel: Watch venueindelhi.com

Vickel requests the watch of the watch_keyword venueindelhi\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

venueindelhi\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by VLAZ in Charcoal HQ


Can't override template, Uncaught Error: Syntax error, unrecognized expression: #:visible

When I attempt to override plugins/widgets/ckeditor.html, I get:
Uncaught Error: Syntax error, unrecognized expression: #:visible

even if I just copy/paste the exact same contents into my override. What am I doing wrong?

Nevermind. Ended up being a random issue.


DBZ-7374 Allow NULL as the default value for SQL server (Unicode) character strings

https://issues.redhat.com/browse/DBZ-7374
SQL server connector -- allow the default value mapper properly to accept character strings & Unicode character strings n(char|varchar|text), when using NULL as the default value

@jpechane PTAL once got a chance / a minute (I would appreciate also some pointer / examples on how to contribute a test, so I could add them)
Thanks,
Jan

Hi @iankko, there is already a default value test in the SqlServerConnectionIT where a table is created, and we assert the resolved default values; see shouldProperlyGetDefaultColumnValues.
You can either choose to add a new column to that table definition with the right default value combinations your change is to support and then assert the column's state in that same method or copy that method into a new method with an appropriate name related to this PR's change, remove all the columns expect those that apply to this change and then assert on only those columns.

@Naros
Hello Chris,

Hi @iankko, there is already a default value test in the SqlServerConnectionIT where a table is created, and we assert the resolved default values; see shouldProperlyGetDefaultColumnValues.

Wonderful, TYVM for the pointers! (these are exactly the ones I was searching for).

You can either choose to add a new column to that table definition with the right default value combinations your change is to support and then assert the column's state in that same method or copy that method into a new method with an appropriate name related to this PR's change, remove all the columns except those that apply to this change and then assert on only those columns.

Noticed, there was existing shouldProperlyGetDefaultColumnNullValues() test method, thus added those tests for null string (char, varchar etc.) datatype there (for all three combinations of NULL, (NULL), and ((NULL)) we are aware might cause the problem (seems various versions of MS SQL server can return either (NULL) or ((NULL)), but not exactly sure TBH which particular version is returning which variant. Should you need this list, this would need to be collected yet).
Thanks again!
Jan

LGTM, I triggered CI build. If passes the PR can be merged and backported to 2.5 too.

LGTM, I triggered CI build. If passes the PR can be merged and backported to 2.5 too.

👍

@iankko Applied, thanks!

@iankko Applied, thanks!

@jpechane Wonderful, thank you very much! Truly appreciate it (extra points for merging this against / into the 2.5 branch too! :))


Using max-height does not work in IE11

This is a really great scrollbar. It satisfies all my needs except when I try to use max-height on IE11. I don't want to specify a height on my scrollable panels because I need them to collapse when there is no content. Is there any way for this to work?

Hi @jacksonv1lle , I think I experienced this issue as well. Could you let me know if applying this css solves the issue?
.simplebar-scroll-content {
    max-height: inherit!important;
}

Thanks for your report!

@Grsmto Thank you sir. That has worked

I will implement this fix in the plugin for the next version! Thanks!


test(storagenode): do not delete ".keep" file from internal/storagenode/testdata/relative_volume

What this PR does
This patch makes test not delete internal/storagenode/testdata/relative_volume/.keep.
Hidden file internal/storagenode/testdata/relative_volume/.keep prevents
internal/storagenode/testdata/relative_volume from deleting since git is
ignore empty directory.
Which issue(s) this PR resolves
Anything else

This change is

Codecov Report

Merging #123 (34b8eb0) into main (2a4768e) will increase coverage by 0.20%.
The diff coverage is n/a.

:exclamation: Current head 34b8eb0 differs from pull request most recent head fd89e38. Consider uploading reports for the commit fd89e38 to get more accurate results

@@            Coverage Diff             @@
##             main     #123      +/-   ##
==========================================
+ Coverage   62.83%   63.03%   +0.20%
==========================================
  Files         125      125
  Lines       16951    16951
==========================================
+ Hits        10651    10685      +34
+ Misses       5750     5727      -23
+ Partials      550      539      -11

Impacted Files
Coverage Δ

internal/metarepos/report_collector.go
78.27% <0.00%> (-0.41%)
:arrow_down:

internal/metarepos/raft_metadata_repository.go
71.93% <0.00%> (+0.26%)
:arrow_up:

internal/metarepos/storage.go
80.81% <0.00%> (+0.78%)
:arrow_up:

internal/storagenode/logstream/committer.go
82.91% <0.00%> (+1.06%)
:arrow_up:

internal/storagenode/logstream/executor.go
77.84% <0.00%> (+1.89%)
:arrow_up:

pkg/mrc/mrconnector/mr_connector.go
77.86% <0.00%> (+4.58%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add geometric mean aggregation function

In SQL you can get geometric mean with exp(avg(ln(x)))

@dain , isn't that going to cost much more computation effort ?

@martint, I took a try, the problem I found is I cannot set the initial state of the accumulator, which is currently 0 all the time. current thoughts is to create some special accumulator state for the aggregation but that seems make this issue much more complicated.
any hints on implementing using a shortcut?

Fixed by #3366.


Parse user crontab

Add the ability to parse user crontabs: https://code.google.com/p/chkcrontab/issues/detail?id=2

Yes, saw that and saw I was too late to migrate issues. :(
But this works as a way to do it! Good idea. I've committed my home dir to a VCS for a long time - subversion, hg and now use vcsh as a wrapper around git. And I recently put in a way to maintain a user crontab per-machine. Having this would be a nice addition. Adding a vcsh hook to check crontabs before commits would save some screwups.
This will be a little tricky as the name issue is just part of it. I'll address that partially in #4.
What I think makes the most sense would be to add a -u option where it would ignore the file name and have it skip usernames.


Python 3.7

fixes #425

seems like sudo needs to be enabled in travis to support python 3.7: https://github.com/travis-ci/travis-ci/issues/9815#issuecomment-401756442

Yes, sudo+xenial just for that job

Thanks


Signal extension

Could you please add support for Signal?
They have open Java API, whole project is open-source and I believe they have web api as well.
Looking forward to your response.
Tibor Dancs
LINKS:
Signal Doccumentation
Signal Github

Seconded, this would be really nice to have, as signal is my main messenger with the fam.

+1

Duplicate of #207

Duplicate of #207
At least I provided links and documentation.

Pleaseeee add signal!


Update CLI for --namespace

belongs to https://github.com/epinio/epinio/pull/1293

It appears that epinio cli could already generate those files so we should automate that


cmd/kfulint: add sanity checks

Every linter must be properly handle files that may contain unexpected input.
For example:
func external() // Function with nil body

func empty() {} // Function without input/output params and empty body

// Empty value/type specs:
var ()
const ()
type ()

And so on.

It looks easy. Maybe mark it as good first issue?

Also, I think other linter would find that.

It's not a suggestion for checker, it's extension to our end2end tests.
We don't want our checkers to panic on such constructs just because we forgot about some corner case.


Fix mypy errors created with latest numpy

Summary
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 6 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.619%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4067

Relevant Lines:
4488

💛  - Coveralls


feat: disable wifi on esp8266 during tests

Summary

Disabled WiFi  radio during tests to lower current  draw.
Increased CPU frequency to execute tests faster to improve
stability.  Stability has been improved but is not perfect.  There is
~15% failure rate when running complex tests where the board
goes through a DMT reset.

Improves #179

Checklist

[ ] Documentation (if necessary)
[x] Tests (if necessary)
[x] Ready to be merged

Thanks for submitting this pull request! A maintainer will review this in the next few days and explicitly select labels so you know what's going on.
If no reviewer appears after a week, a reminder will be sent out.

@ciband
There's actually a build flag for cpu speed in PIO.
[env:esp8266_api_blockchain_tests]
platform = https://github.com/platformio/platform-espressif8266.git#feature/stage
board = huzzah
framework = arduino
lib_deps = ${common.lib_deps}
lib_ignore = ${common.lib_ignore}
build_flags = ${common.build_flags}
src_filter = ${common.src_filter}  ${api_blockchain_tests.src_filter}
upload_speed = ${common.upload_speed}
board_build.f_cpu = 160000000L

build output:

HARDWARE: ESP8266 160MHz, 80KB RAM, 4MB Flash

That means you could also probably drop the new file altogether and just do:
void setup() {
  Serial.begin(115200);

  #ifdef ESP8266
    WiFi.forceSleepBegin();  // turn off WiFi to save power and processing time
  #endif

  setDummyTime();

  testing::InitGoogleTest();

  auto __attribute__((unused)) run = RUN_ALL_TESTS();
}

I can make the PIO change for the CPU.  Can we leave the extra file?  The goal was to hide all the conditional compile mess.  I suspect we will want to do something like this on ESP32 and any other MCU that we can strip down for testing.
For the future automated tester, I have an interest in reduced current draw.

@ciband
The plan is to split everything up anyways, so that works 👍

A member has approved this PR. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait.
Thank you for your contribution!

Your pull request has been merged but was not assigned a bounty tier. A maintainer will assign a bounty tier to this pull request in the next few days.

Your pull request has been merged and marked as tier 4. It will earn you $20 USD.


[BUG] nuget install package error

my project is on .net 4.5.2,get this error  when install package by nuget.
Failed to add reference. The package 'Microsoft.Rest.ClientRuntime' tried to add a framework reference to 'System.Runtime' which was not found in the GAC. This is possibly a bug in the package. Please contact the package owners for assistance.			0

@TommixYuan Is your project targeted at .Net452, or at netstandard or a different framework?  Also, what kind of component is your product building (WebApp, DLL, executable, something else)?System.Runtime is a standard package in .Net 4.5.2 Framework, so this would seem to be an error in .Net452 on your machine, or the targeting pack in your IDE.
If none of these sound like your issue, can you please share your OS, Installed Frameworks, and a small repro project ?

@TommixYuan Is your project targeted at .Net452, or at netstandard or a different framework?  Also, what kind of component is your product building (WebApp, DLL, executable, something else)?System.Runtime is a standard package in .Net 4.5.2 Framework, so this would seem to be an error in .Net452 on your machine, or the targeting pack in your IDE.
If none of these sound like your issue, can you please share your OS, Installed Frameworks, and a small repro project ?


How to manually assign values to a future?

If I have a variable as the following then how do I add/insert values manually?:
final myVar = Future.value(<String?>[null, null, null]).obs
I want to be able to set a value e.g.        myVar.value[0] = "hello"; //this doesn't work

This is not specific to getx and stackoverflow may be your best bet. Paste a link to the question and I might be able to help you there. Please add more details, though. What is your use case? What do you expect to happen once you set myVar.value[0]?

With GetX you have observables and you don't need to work with futures directly. Maybe using append with StateMixin is something you might be looking for.
Try help in community chats.


swagger/openAPI does not handle remote file references

swagger allows $ref to refer to an object in another swagger file (see https://swagger.io/docs/specification/using-ref/)
This is currently not supported by the sysl importer

just to clarify, in additional to adding the definitions in the same file, there will be an additional feature to add local files (url links not included for now)


Add isAudioOnly to player interface

Is it possible to add an isAudioOnly to player interface, in the same way as isInProgress eg.?
Note: in the demo app, the form for get this is not very clear: https://github.com/google/shaka-player/blob/master/demo/asset_section.js#L211-L219

Good idea!  This should be easy to do.


Separate Directory for Static Files in main Directory after Build

What problem does this feature solve?
This  Feature will provide a Separate directory for static files in the Application like The Vue Config (assetsDir) in Vue CLI which allows user to create a Separate files for all The Static assets
It Solves the issue for many Servers as It eases the Server to Send Static Files
For Eg: I am using Django at the Backend so i have to create a Separate Static dir relative to Templates dir . This would Be really easy if a Feature like this is Implemented
What does the proposed changes look like?
/dist
--/index.html
--/static

This feature request is available on Nuxt community (#c9899)

This is now implemented in Nuxt 3 with the public directory. You can also add other directories with nitro.publicAssets and the .output/public folder is then the production public folder after build.


CDPS-857: Bumping dependencies

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 83.72%. Comparing base (72ada26) to head (bd2e47d).

Additional details and impacted files
@@             Coverage Diff              @@
##               main      #43      +/-   ##
============================================
+ Coverage     83.61%   83.72%   +0.11%
- Complexity      284      285       +1
============================================
  Files            54       54
  Lines           903      903
  Branches         63       63
============================================
+ Hits            755      756       +1
  Misses          110      110
+ Partials         38       37       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


reconfigure_bridges:88 CRASH REPORT Process <0.214.0> with 0 neighbours exited with reason: no match of right hand value

Bridging problem: when I configure to use IPv6 to connect other agents, the startup fails. The error should be that I don't recognize the IPv6 address. If anyone encounters and solves this problem, please help me. Thank you very much!
plugins.vmq_bridge = on
vmq_bridge.tcp.br0 = 2001:2002:2003:2004:2005:2006:2007:2111:1882
crash.log
exception exit: {{bad_return,{{vmq_server_app,start,[normal,[]]},{'EXIT',{{badmatch,{"br0","2001","2002","2003","2004","2005","2006","2007","2111","1882"}},[{vmq_bridge_sup,reconfigure_bridges,3,[{file,"/share/build/cross-compile/x64/build/PlatformCBB_daily/o0-component/00-opensource/vernemq/apps/vmq_bridge/src/vmq_bridge_sup.erl"},{line,88}]},{vmq_bridge_sup,change_config,1,[{file,"/share/build/cross-compile/x64/build/PlatformCBB_daily/o0-component/00-opensource/vernemq/apps/vmq_bridge/src/vmq_bridge_sup.erl"},{line,82}]},{vmq_plugin_helper,all,3,[{file,"/share/build/cross-compile/x64/build/PlatformCBB_daily/o0-component/00-opensource/vernemq/apps/vmq_plugin/src/vmq_plugin_helper.erl"},{line,26}]},{vmq_server_app,start,2,[{file,"/share/build/cross-compile/x64/build/PlatformCBB_daily/o0-component/00-opensource/vernemq/apps/vmq_server/src/vmq_server_app.erl"},{line,42}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,277}]}]}}}},[{application_master,init,4,[{file,"application_master.erl"},{line,138}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,226}]}]}

@sxdyff Thanks, yes, the plugins that you configure in the vernemq.conf file need to be startable, due to the current configuration architecture.

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@ioolkos Thank you. The problem is that it can't be started. How can I configure it correctly？

Note to self: Review/implement ipv6 support for outgoing bridges.

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@sxdyff On the remote chances this is still interesting to you, a draft PR to enable inet6 here: https://github.com/vernemq/vernemq/pull/2269
(although it's still somewhat untested)

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.


'NoneType' object has no attribute 'strip'

I was just poking around http://staff.eecs70.org/ and got this... I had clicked on an event (I think one of the Homework Party @ Woz events).  I was not signed in on the site.

Mm. Wasn't able to replicate, but I will investigate. Thanks!

I have the same issue for lab Friday 11-1pm, 1/29 (http://cs61b.piipod.com/u/21). I'm not sure if the link works for you, but this is where I get the error: http://cs61b.piipod.com/e/20/.

Oh, thanks! Yeah, I'm seeing the error too.

Fixed!

Awesome. Thanks!

Nice!  :)


Kms 63 can create article with same title as soft deleted one

Coverage decreased (-0.71%) to 47.94% when pulling 387881bf1a440c26431d25c6c506827769c694e5 on KMS-63_can_create_article_with_same_title_as_softDeleted_one into c425b7656200a907453b0dc96ebbc71d41aca606 on master.

Coverage decreased (-0.71%) to 47.94% when pulling 387881bf1a440c26431d25c6c506827769c694e5 on KMS-63_can_create_article_with_same_title_as_softDeleted_one into c425b7656200a907453b0dc96ebbc71d41aca606 on master.

:+1:

Coverage decreased (-0.71%) to 47.94% when pulling 57e351ead6f369762f751110f4ec8b79f00ae549 on KMS-63_can_create_article_with_same_title_as_softDeleted_one into c425b7656200a907453b0dc96ebbc71d41aca606 on master.

Coverage decreased (-0.71%) to 47.94% when pulling 8bda64a918d56610971f06570bdd7f9742700ab6 on KMS-63_can_create_article_with_same_title_as_softDeleted_one into c425b7656200a907453b0dc96ebbc71d41aca606 on master.

Coverage decreased (-0.71%) to 47.94% when pulling 8bda64a918d56610971f06570bdd7f9742700ab6 on KMS-63_can_create_article_with_same_title_as_softDeleted_one into c425b7656200a907453b0dc96ebbc71d41aca606 on master.


Doc Feedback:

Location : https://ei.docs.wso2.com/en/latest/micro-integrator/overview/introduction/
Hi Team,
Please provide pdf documentation file as it is more comfortable to read.
Document of API Manager 3.0.0 and Micro Integrator 7.0.0 and Streaming Intregator 7.0.0
Thanks
Sandeep Parbat

Thank you for the feedback.
We are currently looking into this.

This requirement will be tracked through https://github.com/wso2/docs-ei/issues/439


Test dask implementation on home credit notebook

Original Notebooks:
https://github.com/Featuretools/Automated-Manual-Comparison/blob/master/Loan Repayment/notebooks/Automated Loan Repayment.ipynb
https://github.com/Featuretools/Automated-Manual-Comparison/blob/master/Loan Repayment/notebooks/Featuretools on Dask.ipynb

@thehomebrewnerd can you add link to the homecredit notebook?

@kmax12 Added links in the issue description above.

Performed two rounds of benchmarking using different primitives.
First benchmark: and (trans), sum (agg), max (agg) - 938 features
New Implementation
-Read Data: <1s
-Clean Data: <1s
-Partition Data: 0s
-Create Entityset: <1s
-Run DFS: 128s
-Compute FM: 190s
TOTAL: 319s
Original Notebook
-Read Data: 53s
-Clean Data: 27s
-Partition Data: 1006s
-Create Entityset: <1s
-Run DFS: <1s
-Compute FM: 183s
TOTAL: 1270s
Second benchmark: and (trans), sum (agg), max (agg), min (agg), mean (agg) - 1545 features
New Implementation
-Read Data: <1s
-Clean Data: <1s
-Partition Data: 0s
-Create Entityset: <1s
-Run DFS: 169s
-Compute FM: 815s
TOTAL: 985s
Original Notebook
-Read Data: 53s
-Clean Data: 27s
-Partition Data: 1006s
-Create Entityset: <1s
-Run DFS: <1s
-Compute FM: 310s
TOTAL: 1396s
To date, I have not been able to successfully generate more features than the second benchmark. The first benchmark was run using client=Client() which created 4 workers with 4GB memory each. The second benchmark was run using client=Client(n_workers=1) which created a single worker with 16GB of memory. The second benchmark would not run successfully with 4 workers. Note, the feature matrix generated by the second benchmark was approximately 3.1 GB in size when read in as a pandas dataframe.

Found some issues that seem to be related to partition size as well as attempting to compute to many aggregation features at once. Updated FeatureSetCalculator based on these issues and was able to generate a feature matrix with 1636 features using 4 workers with 4GB memory each using these primitives: and (trans), sum (agg), max (agg), min (agg), mean (agg), count (agg), any (agg), all (agg)
New Implementation
-Read Data: <1s
-Clean Data: <1s
-Partition Data: 0s
-Create Entityset: <1s
-Run DFS: 15s
-Save to CSV: 900s
TOTAL: 916s
Original Notebook
-Read Data: 53s
-Clean Data: 27s
-Partition Data: 1006s
-Create Entityset: <1s
-Run DFS: 1s
-Save to CSV: 661s
TOTAL: 1749s
Although the run with the new dask implementation has been completed successfully, it seems to be somewhat unreliable. Sometimes the run will fail and several worker high memory warnings are generated. There are also occasional errors generated related to unpickling coming from Dask.
Attempting to generate larger feature matrices by adding additional transform primitives still results in failures due to memory issues. These failures may be due to a complex dask task graph being generated by all of the merge operations that take place during calculation of the aggregation features.

Four different benchmark runs have been completed with various primitive combinations. The results are summarized in the file linked below.
https://app.zenhub.com/files/102908804/d9db7c3a-1bc5-40f1-b61f-3ccd51e14bee/download

Closed by #953


Private/Secret Group and Spaces creation should be managed by Permissions

We are seeing that the secret group and spaces feature can be missused. In the current design, all users who have access to group and space can create them. Can we look at putting a segregation through membership levels the access to Private and secret group or space creation ability, so that we can control the population who can create these group and spaces. It will also help UNA site owners to monetize this feature further through membership level/benefits. Currently all members having access to groups and spaces can create them. Let's give UNA owners to charge further for these features and it also reduces the misuse of this feature by exposing to only specifically paid members for these features, others don't need this.

I am very interested to know how this turns out.  It would be powerful to be able to control and monetize creation of groups and spaces.


build sbt 1.2.3 and its modules

/cc @eed3si9n

https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/3536/ (404 for now)

looks like our include/exclude list for zinc needs updating
[zinc] [info] These subprojects will be built: zincApiInfoTemplate, compilerBridgeTemplate, zincRoot, zincScripted, zinc, zincIvyIntegration, zincCompile, zincCompileCore, zincPersist, zincCore, zincTesting, compilerBridgeTest210, zincApiInfo210, zincClassfile210, compilerBridge210, zincClasspath210, compilerInterface210, compilerBridgeTest211, zincApiInfo211, compilerBridge211, zincClasspath211, zincClassfile211, compilerInterface211, compilerBridgeTest212, zincApiInfo212, zincClassfile212, zincClasspath212, compilerBridge212, compilerInterface212, classesDep1, jar1, zincClasspathTemplate, zincClassfileTemplate, jar2, compilerBridge213, compilerInterface213, compilerBridgeTestTemplate
...
[error] java.lang.RuntimeException:
[error]
[error] Fatal: multiple projects have the same artifacts visible in the same space.
[error]
[error]   org.scala-sbt#zinc-classpath  from zinc and zinc, both visible in space "scala.main.jawn_0_10"
[error]   org.scala-sbt#zinc-apiinfo  from zinc and zinc, both visible in space "scala.main.jawn_0_10"
[error]   org.scala-sbt#zinc-classfile  from zinc and zinc, both visible in space "scala.main.jawn_0_10"
[error]   org.scala-sbt#compiler-bridge  from zinc and zinc, both visible in space "scala.main.jawn_0_10"

this may need to be combined with #778

closing for now, we can revisit once #778 moves forward


Increase retention of Artifacts on S3 to 72hours

What does this PR do?
We now keep artifacts on our S3 buckets for three days

Motivation
It costs almost nothing, and can be helpful for dev working on pipelines triggered before the week end for exemple

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


make compatible ASGI get_request, login and logout

The context object can turn into a dict when using ASGI.  This pull requests accounts for both ASGI and WSGI conditions and replaces the use of info.context.request with get_request(info)

Codecov Report
Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (25e3ca2) 87.46% compared to head (14282b9) 87.44%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #393      +/-   ##
==========================================
- Coverage   87.46%   87.44%   -0.03%
==========================================
  Files          35       36       +1
  Lines        3024     3035      +11
==========================================
+ Hits         2645     2654       +9
- Misses        379      381       +2

Files
Coverage Δ

strawberry_django/auth/mutations.py
100.00% <100.00%> (ø)

strawberry_django/auth/utils.py
66.66% <60.00%> (+3.50%)
:arrow_up:

strawberry_django/utils/requests.py
75.00% <75.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

It would seem that login and logout mutations were also non compatible with ASGI/websockets. This was addressed by using the channels authentication rather then the default django.

It would seem that login and logout mutations were also non compatible with ASGI/websockets. This was addressed by using the channels authentication rather then the default django.

@bellini666 Not sure if you need anything else from mee on this pull-request?  All tests seem to be passing.

Sorry for not replying earlier to this.

No problem :)

I was out during last week for the djangocon event (I was a speaker there https://2023.djangocon.us/talks/building-high-performance-type-safe-graphql-apis-with-strawberry-and-django/).

Nice!  Some publicity for the library is a good idea indeed!

I made a small suggestion regarding the logout that you pointed out. If you want to fix it, I'll merge it after. Otherwise just tell me and this is fine to be merged already

Yes, I'll take a look.  I hope it's a detail, but I fear that logout function may not work as advertised otherwise the login wouldn't work - which it does.

All done. Ready for merge from my end @bellini666


Fixed bug with --electrumx-git-branch

The --electrumx-git-branch option didn't work due to a small bug in distributions/base.sh.

Thanks!


Fixed pom for proper generation of jar and OSGi mainfest.

Thanks, Andrea!

Andrea: the generated JAR contains no classes! Can you look into this? I used mvn clean package

I spoke too soon, ignore this, it works now...


Guard for unsupported features of iOS 8 extensions

See Issue #2119.
It seems that a couple of references to unsupported APIs in extensions were missed. I'd really appreciate a fix because I can't properly build my extension at the moment.
Credit goes to @jpmhouston.

Thanks for the PR, @phylor. I missed that diff from @jpmhouston.

When will this be released to cocoapods?

+1

This doesn't appear to work for me. I'm on master and i can see checks for AF_APP_EXTENSION in your code @mattt yet the build still fails with this message. I added a pch-file to my App Extension:
#define AF_APP_EXTENSION
#import <HittaServiceLib/HITHittaServiceLib.h>

To fix this issue i had to put AF_APP_EXTENSIONS=1as a preprocessor macro for the Pods-hitta.se WatchKit Extension-AFNetworking target. Adding #define AF_APP_EXTENSIONS to the prefix header didn't work, neither did adding it as a preprocessor macro to the watch extension target work.
@mattt Have you considered using this instead? I replaced your #if !defined(AF_APP_EXTENSIONS) with the below code instead and it appears to be working correctly.
#if !(defined(__has_feature) && __has_feature(attribute_availability_app_extension))
    Code that can't compile for WatchKit.
#endif

+1


Install runtime

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@303c840). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #3   +/-   ##
=======================================
  Coverage        ?   25.13%
=======================================
  Files           ?        1
  Lines           ?      187
  Branches        ?        0
=======================================
  Hits            ?       47
  Misses          ?      134
  Partials        ?        6

Continue to review full report at Codecov.

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


Incorporate new PheWeb manhattan plot filtering

Our Manhattan plots draw from the PheWeb codebase, with modifications.
PheWeb recently gained the ability to filter manhattan plots by variant type and annotation. We should investigate incorporating that feature into the upload service, as well as abstracting manhattan plots in a way that better supports code sharing.

The python to get the top 100k variants is nice: https://github.com/statgen/pheweb/blob/master/pheweb/load/best_of_pheno.py .
The js is not great.  It's almost-but-not-quite the same as the normal manhattan code, and I didn't do the work of factoring out common sections.  And even before the duplication it wasn't elegant code.  Somehow I never learned how to make d3 readable.  https://github.com/statgen/pheweb/blob/master/pheweb/serve/static/pheno-filter.js .

Thanks! If I do incorporate this, I'll try to modularize my JS code to be useful across both services. I've been trying to make LZ's d3 usages more readable in the upcoming release as well.
Two examples of potential code sharing:

Provide "save as svg/png" buttons for the manhattan plot. It's a frequent request in the my.locuszoom.org service and I imagine it would be useful to pheweb too. As of 0.12, we've made the feature a bit faster and cleaner.
Upgrade the manhattan and qq plots to d3 v5 (if pheweb isn't there already), when I upgrade pheweb to LZ 0.12-0.13. Changes here: https://github.com/statgen/locuszoom-hosted/blob/develop/assets/js/util/pheweb_plots.js

Last question: Is the "top 100k variants" code a replacement for the old manhattan binner, or a supplement used for filtering?

https://github.com/statgen/pheweb/blob/master/pheweb/load/best_of_pheno.py#L35 just makes a normal tsv file with only 100k variants in it.  https://github.com/statgen/pheweb/blob/8f43ca0075cc14c4b58673c6c3e2dcaac0a9951d/pheweb/serve/server.py#L124 reads that file, filters variants, feeds them into the manhattan plot binner, and then sends the result to the client.  During pre-processing, the same manhattan plot binner runs on the full input file to make the normal manhattan plots.


Bump openapi-generator to v6.6.0

The image is now pinned to the sha256 of v6.6.0.
This gets use the latest  fixes for the golang generated code.

Setting this to draft for now. There seem to be some issues introduced in the golang generator. (At least the unit test on the graph service fail with the new client code)


Windows: Does not save my last change/edit

If I go into structor: edit a property or a text field then refresh the page my last edit is dropped. Pretty annoying if I want a quick tweak then move onto something else.
It does save my edits, but after looking at model.json in the desk folder, it is always one step behind where I am.

@Diniden this is one step behind because of adding a component with runtime error (which could not be caught - there is still problem with that in React) you'll have an empty screen and it is not always clear what is happened. So, the next time you load page you will not be frustrated by that error.

Understandable. It may be a lot of extra work, but you can look into the code base of mobx. The creator of that project had a very unique solution to this and reports run time errors back to you when one exists. If you implemented something like this, the editor would be able to undo the errored component or replace the errored component with a  that indicates an error.