text:
Consider dropping non_exhaustive on Network, etc

In 0.30, #[non_exhaustive] was added to the Network enum in what I assume was a step towards stabilization with forwards compatibility. #[non_exhaustive] doesn't, itself, provide forwards compatibility with minor version changes, but rather forces downstream devs to think about it, and puts the burden for forwards compatibility on them. This only works if downstream projects have to be able to have some kind of sensible default behavior for "unknown future bitcoin-style network", which isn't super practical. For example, this came up in the lightning-invoice crate, we have to convert from the rust-bitcoin Network to a BOLT11-specific Currency - we cannot reasonably have forward-compatible code that will "just work" if a new enum variant is added, so an unreachable was added. That will obviously be removed, but there's really nothing we can do to be forwards compatible here, and instead would strongly prefer to see a version bump of rust-bitcoin so that we can update our code to handle entire new bitcoin-compatible networks.

Specifically with Network we've moved away from an open-ended enum to just a "mainnet/testnet" dichotomy. So definitely +1 to removing #[non_exhaustive] there.
For other types, I tend to agree with you. I think we should leave #[non_exhaustive] on errors (which we expect people will rarely/never match on, and usually only match on a single variant that they care about), and for everything else we should think hard about what we actually expect people to do with unknown variants. And if the answer is "panic" we shouldn't make them do that.

Agreed on removal where it makes sense. I'm not a huge fan of non_exhaustive generally, but it does make sense for parts of a library API.

NACK, I believe having the enum #[non_exhaustive] makes more sense. As we can already observe, there's wide variety of applications supporting different networks. Electrum supports simnet (IDK what it is) in addition to the networks we support for instance, some applications do not support the existing networks and others are only defined for the current ones and it's unclear what will happen when there's a new one. For instance currency in LN is defined for each network we have today except for simnet. It's not predetermined what will happen once this changes.
As such I believe the parameter is application-specific and cannot be universal unless the application is specifically built to support all possible networks. (This is possible, I did this for Firefish by using magic as the network identifier when serialized and native parsing methods for stringly inputs.) And if an application is not made universal then it has to have its own type to represent the network it supports, with conversions and such.
I'm aware this is more annoying but like many other things in Rust, it prevents problems by dealing with these things upfront. I'm still interested in making the API easier. For instance I think using impl Into<Network> in function signatures may be a good idea, just must be weighted against loss of inference.
Another approach we could take for selected applications is to add methods that convert values to and from their representation. E.g. we could add methods to return LN currency string. But the conditions for inclusion would be very strict: we would have to be convinced that whenever Core releases support for a new network the appropriate teams will define how this is mapped to their domain ASAP. So e.g. if Core adds foonet then LN folks will quickly decide what the string for currency is. FTR I currently don't know of any case where I would be confident to do that.
We could also provide a macro that makes it easier to define your own network types if it helps.

They already suffer the issue, they just wouldn't need to convert between networks inside business rules but at the boundary which is good. I don't see how it's related to strings, since the crates can (and should) define their own strong types.
Also if there's a collection of crates that is guaranteed to support some specific set of networks they should share a type.

it forces users to deal with an unknown network up front

It doesn't force users to do that. It's entirely possible to design an application that uses no match and communicates with external entities using already-standard types/interfaces (magic, human-readable names). I know this because I've done it in an actual production application. Also IIRC elects is written this way too.
The fact that you perceive it as forcing stems from you happening to work on a library where the protocol itself forces you to do something different. And because you're forced to use a specific set of networks you should define your own - which you did with the Currency type. If you impl From<Currency> for Network then you nearly won't see a big difference. Calling into() sometimes is fine, we can remove it completely trading it for worse inference.
For the opposite conversion, I have verified that we never return Network from any function. (LMK if I missed something.) It's always Option<Network> or Result<Network> this means that for any case where you'd be forced to deal with an unknown network you would be regardless! You can just map whatever you don't support to None/Err:
let currency = match Network::from_chain_hash(chain_hash) {
    Some(Network::BItcoin) => Currency::Bitcoin,
    Some(Network::Regtest) => Currency::Regtest,
    Some(Network::Testnet) => Currency::Testnet,
    Some(Network::Signet) => Currency::Signet,
    _ => return Err(UnknownChainHash(chain_hash)),
}

The code is pretty elegant IMO.

If we remove #[non_exhaustive] that's not a case that ever exists, a change to rust-bitcoin to add a new network will simply require handling a new network

It's an unknown network for the protocol that doesn't define it. But what's worse it will force breakage across the entire ecosystem and cause coordination nightmares whenever a new network is added. We're trying to bring the crate to the state where each crate can rely on 1.0 primitives and never worry about breakages again. Isn't it worth a few more lines in your code?

Another way to look at rust-bitcoin's Network is "the minimum set of supported networks that everyone should really support",

I disagree with this view in two ways. First, I personally see very little value in supporting anything else than mainnet and regtest for most applications. Regtest is million times easier to work with than everything else when it comes to testing. So I don't understand why the type should have other variants if this is its definition. Second, the type really is "whatever Core supports" this can be clearly seen from having to_core_arg (infallible) and from_core_arg which suggests that we've committed to never adding a network that Core doesn't support. The other conversions are also defined in Core (but it's consensus, so it doesn't matter much).

Sadly Bitcoin is filled with people defining their own network enum.

Really? Can you point to specific examples? I haven't seen any other than Currency in lightning which is perfectly reasonable.

not having good convertibility between them would be a massive PITA for everyone (I think on this point we agree)

It already is by simply the applications and, more importantly, protocols not being designed to be network-agnostic. You can't change it by making the enum not #[non_exhaustive] because then we'll need to issue breaking releases and you can't convert between different versions of Network so we're back at square one and even worse - it infects all other types in the crate so the whole crate becomes incompatible!

Users are going to use the stuff that's exposed, and not always in the idealized way

I'm willing to accept it for many other things. But after fighting so hard to get this crate to stabilize one day being told that's not going to happen is absolutely horrible to hear. If that's the position of other maintainers I might be better off forking the crate.

given the BOLT 11 set is congruous with the rust-bitcoin set

Only today. It's perfectly possible it won't be in the future. E.g. I have an example of a network that I believe could be interesting: signed like signet but zero difficulty like regtest. And when that happens we get ecosystem-wide breakage forcing everyone to update or be incompatible.

We store a Network in some Invoice

Yeah, that's the incorrect thing. You should store Currency. Basically use Currency everywhere except when communicating with the bitcoin crate. Then it works fine. This is the classic Rust pattern that you validate data at boundary and use strong type inside so I'm not even proposing anything exotic.

Can this debate be reduced to the following question:

rust-bitcoin v1.0.0 is released.
Bitcoin Core adds a new network.
Should users of rust-bitcoin be able to use v1.1.0 to get the new network or is it reasonable to force them to use v2.0.0 to get it (forcing them to take all the other changes in v2.0)?

Its a trade off, right? Upgrade to v2.0.0 might be super painful (or timewise impossible) but enabling usage of v1.1.0 is painful because it requires non_exhaustive on the Network type.

@TheBlueMatt I took a look at LDK and I found that nothing is broken, just From needed to be changed to TryFrom so it looks like it's not as big of a deal as you thought? Did I miss something? See this PR: https://github.com/lightningdevkit/rust-lightning/pull/2789
I've searched for other instances of matching on Network and didn't find any. So it seems your crate is completely unaffected aside from Currency being a separate type which may be annoying to some people.
@tcharding yes, that summary is accurate, though maybe #[non_ehaustive] is not that painful. I've yet to see a crate where it causes a massive breakage.

but is also likely to impact other things, like how work calculations work across blocks, what difficulty means, etc

Those are entirely contained within Params and our API methods and will be even more when we implement proper difficulty adjustment. Moreover, many, many applications don't really need to deal with these things as they simply connect to Core and accept it as the source of truth.

Great, so now we've pushed the dead-code error handling from rust-bitcoin down into LDK and then pushed it further into the code of our users, rather than just not having to handle the non-case at all :)

They already have to handle invalid inputs when they parse and if they use Network instead they only have to change it to Currency.

If we think this is a reasonable use of the Network enum then istm a new variant should be a major release, irrespective of semver concerns, because it implies downstream libraries (though not really applications) need to handle the new network.

I don't think so. Either the library is written to work with any network in which case they can be updated with no code change at all or the library for some reason cannot support other networks in which case it will just return errors for the unknown ones and the applications using them will propagate those errors. Nothing really has to be broken.
I was thinking of putting the network into a separate crate (with whatever other things are likely to break for stupid reasons like someone else releasing something) and then make the crate optional everywhere but I don't think it works since it forces Address to release a new major version anyway which still breaks things.
Anyway, since you're annoyed about Currency and it's only related to parsing or serializing BOLT11 invoices maybe it'd help you if we just added the methods to the Network. However to accept it I'd want to see several LN protocol developers to agree that in the event of a new network added in Core they will either define what the new values are within one month of Core release or leave it up to rust-bitcoin developers to decide if they can't in time. :)

No library can be written to handle "any hypothetical future network" but it's easy in most cases to write a library that supports all the existing networks. I agree with Matt that adding new networks is (a) extremely rare, and (b) likely to break things beyond the enum, even if those are things that 99% of users will never touch.
So by making the enum #[non_exhaustive] and forcing people to use TryFrom for conversions that are actually infallible, we're just creating dead error paths that are untestable until an undefined future date.

No library can be written to handle "any hypothetical future network"

Funny that you say this because I wrote such library. :) It is perfectly possible if there's no silly protocol that would invent its own representations for networks. In my case I encode Network by converting it to Magic and back and on the side of WASM consumers I just take and parse strings because JavaScript can't reasonably use anything else anyway.
I think we can decouple Network at least from units  and blockdata (or just transaction) If we do that then I'm more open to it since that would minimize the damage. That being said, Address is also a significant API piece that happens to use Network - theoretically, we're now moving away from it and since we're using impl Trait in arguments we might be able to separate that one as well.
Still it sucks that any software that did this right will get punished because majority of stuff is badly designed.

It is perfectly possible if there's no silly protocol that would invent its own representations for networks. In my case I encode Network by converting it to Magic and back and on the side of WASM consumers I just take and parse strings because JavaScript can't reasonably use anything else anyway.

This sounds like you throw away the type information from Network, then getting it back is necessarily fallible, giving you an error path that you can use to handle unknown networks. But if somebody wasn't round-tripping to magics or strings, they could write code without error paths. Unless the Network enum were tagged #[non_exhaustive], that is. Then they would need error paths that were impossible to execute until a probably-never-coming version of rust-bitcoin finally adds a new variant.

then getting it back is necessarily fallible

That's only done during parsing which is already fallible so it doesn't matter (and the compiler will easily remove the dead branch).

But if somebody wasn't round-tripping to magics or strings, they could write code without error paths.

Is there an actual real code that needs that though? Even LDK, a super-big crate, didn't have a single line that needed to be changed apart From -> TryFrom. And what are people doing with Network if not eventually translating it to something else?

Wouldn't adding a new network be tantamount to IP creating a new version IPv4 vs IPv6?  I think most examples of parsing IP Addr type consider it to be exhaustive since the addition of a new type of IP scheme is a big deal and should cause breakage downstream.  IE not expected to happen without serious consideration.

@yancyribbens no. This adding of new networks happened in the past several times.

#1930 is more-or-less the same is this issue.

Is it worth reaching consensus on this? Feels like if we do nothing that is agreeing with @Kixunil. Do you guys have the energy or want to just leave it as is? Some ideas:

We leave it on there - (what @Kixunil wants)
We remove it - (what @TheBlueMatt and at least one other user wants (#1930))
We remove it and discuss putting it back on before v1.0
@Kixunil and @TheBlueMatt punch on until one of them changes their mind.
@apoelstra swoops in as BDFL and makes a call.

FTR I have no horse in this race.

I can change my mind if someone figures out a good solution to resolving compatibility issues when a new network is added. Basically what I want is for Network to be in a separate rate bitcoin-network-enum and when it bumps version existing stuff is mostly going to work - only the crates that depend on the new one will have to add variants when they start depending on it.
Note though that this needs to include inquiry about how much are downstream maintainers willing to not use Network in public API.

What if, to the extent possible, we used open-ended types like network::Params or Hrp. Our methods would take T: Into<Hrp> and our network enum would impl Into for all the relevant open-ended types.
Then we could make Network a closed enum, people could use it like normal, but whenever a new network arrives, people using that network need to explicitly construct a Params or Hrp or whatever to get the correct parameters. Network just wouldn't work for them.
We could even add a Network2 enum which had the extra variant and again supported Into<> for all the open-ended types.
I recall rejecting this idea a long time ago, I think because we originally proposed using Params for everything which is a big heavy type, but if we instead split it up I think it'd be alright.

Yes this could work, especially if we add Network into bitcoin-network-enum crate so instead of having Network2 we could just have the crate versioned.
The trouble is people will likely use Network in their APIs and then cause libcplocalypse-like event themselves. non_exhaustive Network forces them not to do that (but yeah, maybe whatever, just document it and let it be; I just wouldn't depend on such crates myself).

using Params for everything which is a big heavy type

Non-issue if it's behind a reference which can also be 'static.

Yes this could work, especially if we add Network into bitcoin-network-enum crate so instead of having Network2 we could just have the crate versioned.

This is morally more correct and elegant, but honestly it's less discoverable and I'd prefer doing the ugly thing where there's clearly a Network and Network2 which show up beside each other in the docs (and which your favorite crate has suddenly started using) and you know the latter is the one that supports the most networks.
We can also do both -- have the crate with a versioned Network type and then re-export it as Network, Network2, etc. Though that's maybe the worst of both worlds .. or even worse :).

The trouble is people will likely use Network in their APIs and then cause libcplocalypse-like event themselves. non_exhaustive Network forces them not to do that (but yeah, maybe whatever, just document it and let it be; I just wouldn't depend on such crates myself).

Well, it forces them to libcocalypse but at runtime, which will be worse.
But I don't think it'll actually be apocalyptic. The core types in this crate will work with every version of Network using the Into<Params> thing so addresses, xkeys, block header validation, network magics, etc etc etc will all work seamlessly. And if LDK wants to standardize on Network explicitly they can have a mini-apocalypse within their own set of crates which is smaller and closer to the application level.
This also lets them have their own Network enum which'll work with rust-bitcoin as long as they implement the appropriate From adaptors. Which is what I expect they'll do if we try to get too clever with our own enum ;).

Non-issue if it's behind a reference which can also be 'static.

Hmm, there was definitely some reason that we rejected this idea in the past. I seem to recall wanting a non-'static lifetime and then people hated the lifetime proliferation. But even if we wanted to do that (unclear; it would let people do bitcoin-inquisition stuff with custom chain params for example) we could accomplish it by using AsRef rather than Into, which hides the references away.
Anyway the previous discussion was definitely not this in-depth so I don't think it's worth the effort to dig it up.

it's less discoverable

There's a version number and we can explicitly explain what's going on.

maybe the worst of both worlds .. or even worse

Yeah, I suspect so. My main intention is not having to maintain multiple versions indefinitely.

Well, it forces them to libcocalypse but at runtime, which will be worse.

It wouldn't if done correctly but if everyone understood how and why they should do it we wouldn't be having this conversation so I guess you're right.

addresses, xkeys, block header validation, network magics, etc etc etc will all work seamlessly.

A long as we don't return the type. Which IIRC we're not doing already except for methods on Network itself.

I seem to recall wanting a non-'static lifetime and then people hated the lifetime proliferation.

I think that combination of producing &'static but accepting any lifetime should work fine.

it would let people do bitcoin-inquisition stuff with custom chain params for example

I don't see how this is harmful but anyway, I think Params really, really should be non_exhaustive because adding more params is likely. I've seen some things scattered around the code that should go there.

Oh, one more thing. Even if we do figure out some workaround we need to be careful about breaking the set of users that want to just cargo update and get a new network support out of the box. I don't know if this set is larger than one (myself) but it might be.

Even if we do figure out some workaround we need to be careful about breaking the set of users that want to just cargo update and get a new network support out of the box.

If this is possible, it will be because the new network behaves substantially similar to the other networks (as far as the software in question is concerned). And in this case the Into generics will mean that things Just Work. Without having untestable "unknown network" codepaths which are impossible to predict the meaning of.
I think that conceptually this Into thing describes our differing requirements pretty well.

because the new network behaves substantially similar to the other networks

Because it has same scripts, transaction layout etc, what most applications care about. Most applications delegate validation to Core (as they should) so the difference in behavior is similar.

in this case the Into generics will mean that things Just Work

It won't because of parsing/from magic construction so if the enum is exhaustive I also have to update Cargo.toml to get the new version of Network (or worse, the code if we choose Network2). I suspect we should have both. bitcoin-network-exhaustive and bitcoin-network-non-exhaustive. I will be happy to use the former, others will use the latter.

I don't really buy that that's realistic.

Of course it isn't, there's the time overflow bug that will have to be fixed one day... But if we want to break the API of a core primitive that causes libcpocalypse-like event there should be a pretty damn good reason to do that and "Core added a new feature we were able to anticipate" doesn't seem like one.

we're invariably going to end up with some major changes to the API in places where it least makes more sense to break compatibility and just do a major rev

That may happen but it doesn't invalidate the idea that we can minimize those cases by good API design.

Because it has same scripts, transaction layout etc, what most applications care about. Most applications delegate validation to Core (as they should) so the difference in behavior is similar.

It might. Though we can't know that ahead of time.
As an aside, most applications in my experience don't do validation at all, but construction. And when constructing Bitcoin objects nobody is going to delegate to Core, they expect the library to produce valid objects.

I suspect we should have both.

Sure, we can have both. I don't think we need extra crates for them -- the #[non_exhaustive] one is inherently unversioned and everybody who wants the exhaustive one expects it to come with rust-bitcoin 2.0 anyway.
I also really don't think there will be any libcopalypse event in any case. Basically no functions produce this enum, and the ones that receive it can accept a generic which describes the features they expect from a network (e.g. to have a Hrp for segwit addresses).
Yes, applications that want to support the new network will need to update their code, but that's what we want, rather than having the new network suddenly show up because of a minor version update, alongside a ton of assumptions about its behavior that were made before the network was ever imagined.

most applications in my experience don't do validation at all, but construction.

Exactly.

they expect the library to produce valid objects.

And we will.

I don't think we need extra crates for them -- the #[non_exhaustive] one is inherently unversioned and everybody who wants the exhaustive one expects it to come with rust-bitcoin 2.0 anyway.

They need appropriate home in different crates because they are versioned differently. I personally don't plan to depend on bitcoin but on its individual parts when possible.

libcpocalypse happened precisely because libc updated something that was rarely used. If people need to upgrade fundamental crates to incompatible versions we have libcpocalypse.

They don't. Applications that want to support the new network need to switch from Network to Network2. To the extent Network2 supports all the Into impls that the old one did, everything will just work. And if Network2 doesn't support these, that reflects an actual breaking change associated with the new network, and the application will need to switch to a new API (which plausibly could mean switching to another ecosystem-wide fork but I'm doubtful anything would be that extreme; it seems we can always add new APIs in parallel).
Libraries meanwhile can continue to use whatever combination of Into impls and concrete types reflects the networks they support. And if they use the Into impls the type system will ensure they're not lying, unlike wildcard matches which are a runtime promise that "whatever this network is, it'll work with my library".

We've now had several cases of downstream users complaining that #[non_exhaustive] broke their intended use of the Network enum in several ways.

Please forward those complaints to us. Just knowing the number of them and not their kind or "quality" isn't very helpful.

Its important that there exist some enum somewhere that we can use across BDK/LDK/fedi/rust-bitcoin/etc.

That can only happen if the LN developers give up their authority to define HRP for invoices to the rust-bitcoin developers. Let's say they are lazy/forgetful just like whoever didn't assign a special signet HRP for bech32, what will you do then? There logically cannot be one enum. At best there can be two: one for LN - Currency, one for bitcoin.

If we want that to be in a separate crate that rust-bitcoin depends on with some Into, fine

OK, let's try to progress on this then. I'll try to split it up after primitives are separated if nobody beats me to it.

there's a whole ecosystem out there, and we need to consider how best to integrate across them

Well, the funny part is if they all have the same enum they just trade immediate benefit for significant breakages later. And it's likely they don't realize it. It's the same old story about Rust: some API looks too complex and later you realize it's because of some reason you didn't even know about and it actually makes sense. And then people say things like Rust is difficult or complain at various forums where more experienced people have to explain to them that if they don't want the safety/security benefits provided by Rust maybe they should use something else... (Not trying to shame anyone here, just try to look at things from Rust perspective. I understand it takes time.)

Please forward those complaints to us. Just knowing the number of them and not their kind or "quality" isn't very helpful.

I'm really struggling to understand this point of view and I've read this entire thread. If the enum is #[non_exhaustive] then it's impossible to match on it and anybody who needs to match on it is forced to go make their own enum. (Or they can stick untestable paths with unknowable semantics into their code which will become active in the future without warning.)
It seems like if we want to imagine that new future networks will match existing networks in significant ways (e.g. using bech32m but with different HRPs, using the same network protocol but with different constants) then we can make our imagining explicit by using Into<Hrp> and the like. In this way libraries can be generic and future-proof without eliminating a "standard set of networks enum" that can be shared amongst multiple applications and their associated libraries.

I believe they're all in this thread, both the other issue and the several instances of LDK preferring to use Network (language bindings needs it, but also we'd like to drop Currency in lightning-invoice).

I mean, I would like to see specific code and more examples of it. What I want to know is if all of them are "I can't be bothered to write my own" or if there are more serious issues. It's the exact thing you pointed out: I see mainly rust-bitcoin and not that much of wider ecosystem.

and almost certainly any one(s) that rust-bitcoin supports, lightning-invoice will too.

In real world we have a ton of incoherent garbage because someone didn't specify legacy address prefix when coming up with regtest, then someone didn't specify HRP when coming up with signet, then I remember hearing the term simnet which isn't even in Core and now I'm supposed to believe you that lightning developers are the bright exception that will swiftly standardize a unique HRP for any new network that is added to Core? Even though there are multiple teams that already have hard time agreeing on things?
I'd love to see some track record that would prove otherwise and I'd absolutely love not having 3+ different enums in the codebase but if this is the reality, rather than hiding from it and hitting problems down the line I want it represented in the type system today so I can be confident it won't break horribly in the future.

No, they don't, this assumes some future where rust-bitcoin starts supporting a new network and all the other crates upgrade,

It doesn't need to assume the latter because if the enum is exhaustive then a single crate upgrading will break everything unless every single upstream crate wants to backport everything just to keep the old Network alive. I've seen an old codebase where lot of backporting and otherwise duplicating things led to crazy inconsistencies. Absolutely wouldn't recommend.
And even if we did this, the history says that most likely there will be some ridiculous edge case like unspecified HRP and people will start using an existing one and then things stop roundtripping and you'll be pulling your hair out trying to clean up the mess.

I'm really struggling to understand this point of view

I know the theoretical problems with #[non_exhaustive] but I've seen zero lines of code where this is a practical problem. I want to see it, so I ask for examples. I do want to help but not over-promise in API just because someone is too lazy to write a few lines to define an enum.

unknowable semantics

Seems pretty clear to me: only changes to how blocks headers are validated and only soft-forks when it comes to other changes. (Note that every app already must assume soft forks.) But surely, we should document that. Also even if it's untestable, anything that's not mainnet is not a big deal and mainnet is already defined.

then we can make our imagining explicit by using Into<Hrp> and the like

Yes, I want that.

libraries can be generic and future-proof

Yes, unfortunately, nothing encourages them to be - we wouldn't have this discussion otherwise. But whatever, that's on them. If bitcoin is solid, then I'll just use the good stuff for my projects.

I mean, I would like to see specific code and more examples of it.

From some test code within Liquid, setting up a bitcoin.conf file section for a specific network
        match self.network {
            Some(bitcoin::Network::Bitcoin) | None => {},
            Some(bitcoin::Network::Testnet) => {
                writeln!(w, "testnet=1")?;
                if version > 17_00_00 {
                    writeln!(w, "[testnet]")?;
                }
            }
            Some(bitcoin::Network::Signet) => {
                writeln!(w, "signet=1")?;
                if version > 17_00_00 {
                    writeln!(w, "[signet]")?;
                }
            }
            Some(bitcoin::Network::Regtest) => {
                writeln!(w, "regtest=1")?;
                if version > 17_00_00 {
                    writeln!(w, "[regtest]")?;
                }
            }
        }

What should we do here in case of "unknown network"? (This is test-harness code so on some level it doesn't matter, but it's easy to imagine something like this being used in production.)

Seems pretty clear to me: only changes to how blocks headers are validated and only soft-forks when it comes to other changes.

So, we'd never have a test network with confidential transactions, say, or which replaced all the crypto with post-quantum equivalents, or more generally which tried some big change without bothering to define and test a soft-fork transition mechanism?
You may be correct. But it's not a promise we can make from the rust-bitcoin API.

Why not use to_core_arg to produce the correct string?

In this case that would happen to work, because Bitcoin is the only one that's a special case and it already exists. But the fact that there is a special case suggests that we'd rather make this code explicit rather than coercing the output of a related function.
And any future network would still need to be slightly different, because at the very least there would be no pre-0.17 syntax to generate and we'd presumably need to panic or something there.
So basically, yes, we could, but we'd still need to make assumptions about the future network, and the comments describing these assumptions would be longer and less reliable than the existing code.

If a new network is added you'll have to "panic or something" on older versions anyway so you might a s well write the code now. But I don't see a versions check for the network in the code you posted so either it's a bug in your code or you intentionally don't care about it. But also, this just gave me an idea that we should have a method returning the version Core added the network in. (Regardless of your use case.)
If you think making these assumptions is unacceptable for you then you really should make your own enum for networks which will give you option to upgrade whenever you need it rather than being forced to either change the code or miss new features in bitcoin. Though now I realize a common versioned Network is great because people who share the version don't have to write effectively the same enum multiple times.

But I don't see a versions check for the network in the code you posted so either it's a bug in your code or you intentionally don't care about it.

A version check for what network?

Though now I realize a common versioned Network is great because people who share the version don't have to write effectively the same enum multiple times.

Yes. If we were using Into<Hrp> etc in this library then the Network enum literally wouldn't matter to rust-bitcoin because we'd never be directly using it here. Its only purpose is to provide a canonical "these are the networks that the rust-bitcoin ecosystem supports" indicator and to provide a schelling point for other developers to use as a set of supported networks.
This is why I continue not to see any "libcopalypse" scenario happening, nor do I see a problem with just adding a Network2 enum if we want to widen the set of networks.

A version check for what network?

Something like fn is_supported_by_core_version(self, core_version: u32) -> bool

This is why I continue not to see any "libcopalypse" scenario happening,

It's less of a problem if we do it right and also less of a problem for consumers of downstream crates that do it right. I'm not hyped enough to say it's non-issue in that case but it might be.

Core is never going to update so that existing configuration files stop working. So I'm not sure what a Core version check would accomplish.

It's less of a problem if we do it right

If "do it right" means putting #[non_exhaustive] on it, then nobody will use the Network type included in rust-bitcoin so we might as well just drop it.

So I'm not sure what a Core version check would accomplish.

Very similar thing your version > 17_00_00 check does: raise a readable error if the core version doesn't support specific network. (In your case you don't need to error.)

If "do it right" means putting #[non_exhaustive] on it,

No, it's doing all these traits and making sure nothing returns it etc...

No, it's doing all these traits and making sure nothing returns it etc...

Ok, perfect, we are in agreement there :).
So if we do things right in rust-bitcoin, the Network enum actually will be unsused within rust-bitcoin, other than abstractly as a "Into" or "Into" or whatever. This gives us a lot of freedom here. We can

Have no blessed Network enum at all (personally I could live with this; for my own projects I never need the enum to be interoperable; it sounds like the ldk people would need to define their own enum but they already have a near-universal rust-lightning dep so they could put it there).
Have a #[non_exhaustive] Network enum whose documentation explains how to match on it (and we will have a drawn-out fight over what this text should be).
Have an exhaustive enum which we will version by releasing rust-bitcoin 2.0 whenever a new network arrives. (I think we all agree this is a bad idea; it would definitely cause libcopalypse).
Have an exhaustive enum in its own crate, which gets upgraded by major versions. We advise all libraries to never return the type, accept it only via generics, to access the type through rust-bitcoin, and failing that, accept all published major versions. rust-bitcoin naturally would do all of these things.
Have an exhaustive enum which we will version by just adding a parallel `Network2 enum. Again, tell libraries to avoid directly using the type if at all possible.

In fact, we could do any combination of these since none of them actually interfere with each other (though it would probably be confusing!).
My personal view at this point is

if we're telling libraries to basically not use the enum, then exhaustiveness becomes irrelevant for libraries (so no risk of libcopalypse) but remains relevant for applications (who want exhaustiveness so that their users aren't suddenly using a new network that the application authors don't know about and can't predict behavior of)
having said that , there are some "applications" (e.g. the Lightning Network) which are spread across multiple libraries and actual applications, and they actually will use the enum despite our advice (and I get why that makes you nervous @Kixunil since then our type is implicitly reflecting some LN thing that we have no relationship to). I think this is still fine; if we later add an enum that they don't like, or upgrade our type in a breaking way, they can have a "local" libcopalypse but it won't affect people outside their space

I continue to think we should have an exhaustive enum, with a bunch of documentation about how to use it properly. I am warming up to the "don't have an enum, just have rules for defining your own" but I think this would be needless work for people who just want to grab an off-the-shelf set of networks or people who want to make their own enum but want to see an example of how to do it first.

Yeah, pretty much it. I want combination of having #[non_exhaustive] enum in some reasonable crate and an exhaustive one in a separate versioned crate. With all the docs you mention and the enums mentioning each-other.

I think this would be needless work for people who just want to grab an off-the-shelf set of networks or people who want to make their own enum but want to see an example of how to do it first.

Yep.

Cool, if I'm following, we have rough consensus here now, and a solution on how to progress. We can get this done before next release, right?
@TheBlueMatt  are you in agreement here or have we missed something? If we haven't I'll get to work.
That would still make v31 annoying for users though.

We can get this done before next release, right?

I doubt so, I suspect we need to progress with crate splitting more. But if you find a way to do it I'm fine with it.

Can we resolve that, remove non_exhaustive in a point release?

And we'll be putting it back in the next one and then people will have to fix their code again. It's not really worth it.

Fair and fair. I'll just do nothing then :)

What would the crate dep tree look like here? Would we have two separate crates and rust-bitcoin depends on both of them? Where does Params live and where does the Into<Params> impl live?

Currently I'm not sure if the non_exhaustive enum should go to a separate crate or it fits somewhere else, I'd like to first split up other things. I also suspect bitcoin can't depend on exhaustive one but the exhaustive one can depend on bitcoin. Params will probably live alongside with the non_exhaustive one.
I think we'll see it more clearly when we're closer. There's other stuff to do now.

Ok, so crate(s) that depend on rust-bitcoin, rather than the other way around. Ok, makes sense.
I suspect both the non-exhaustive and the exhaustive one could go into the same crate -- aside from naming conflicts. Because the non_exhaustive type can be expanded in minor versions, and when the exhaustive type forces major versions, we could semver-trick the non-exhaustive one to prevent breakage. Maaaybe we could even use the same type but have exhaustiveness be feature-gated (this would be a super weird feature-gate that'd turn off the semver trick, so maybe it just doesn't work).
Anyway agreed that there are higher priorities right now and happy to revisit when we're closer.

both the non-exhaustive and the exhaustive one could go into the same crate

They can't because they have to be versioned differently. Semver trick would have to maintain old versions indefinitely and cause crate duplication which would trigger CI checks and people would then have to add exceptions. Semver trick is great but not having to use it in the first place is better.

exhaustiveness be feature-gated

Strictly speaking, removing non_exhaustive is not a breaking change but triggers a bunch of warnings about unreachable branches so I'd rather avoid that.

Removing the milestone from this issue, we have #2541 to hopefully alleviate the current pain.

authors: Kixunil TheBlueMatt apoelstra clarkmoody tcharding yancyribbens


text:
docs: Expand on how to use the crate

Fixes #31

I think you consider this PR ready. I will merge i as soon as actions succeed.

source: gharchive/pull-request

authors: epage matthiasbeyer

repo: rust-cli/clap-verbosity-flag

license_type: permissive

license_source: github-api


text:
Add datafuselabs/datafuse

datafuselabs/datafuse: A Modern Real-Time Data Processing & Analytics DBMS with Cloud-Native Architecture, built to make the Data Cloud easy
Signed-off-by: Chojan Shang psiace@outlook.com

https://github.com/rust-cloud-native/rust-cloud-native.github.io/issues/33

authors: PsiACE nickgerace


text:
add default SPI word types

Thought about this reading #295
cc @eldruin  @Sh3Rm4n  @ryankurte
Should we restrict types be some trait?

r? @ryankurte
(rust-highfive has picked a reviewer for you, use r? to override)

u32 should be added: stm32h7xx-hal has an impl for Word=u32.
This is fixing the in-RAM representation of u9 etc. Perhaps a chip wants the 9 bits be msb-aligned inside the u16 instead of lsb-aligned to be able to DMA. Without the bound, a HAL can define their own WeirdU9 newtype that handles this and take &[WeirdU9] which already has the right repr to DMA straight out of it. Restricting word types makes this impossible.
I'm not sure if the benefit is worth the extra complexity, with new types, a new trait, and associated types.

authors: Dirbaio burrbull rust-highfive

repo: rust-embedded/embedded-hal


text:
Publish Version 0.3.0

Any chance this crate can be updated on crates.io?

Version 0.3.0 now published, sorry for the long delay!

source: gharchive/issue

authors: chris-ricketts posborne

repo: rust-embedded/gpio-cdev


text:
How to use SPI with gpio_cdev

Using gpio_cdev the line handler return Error { kind: Ioctl { kind: LineHandle, cause: EBUSY } } when requesting a pin configured as SPI chip select.
In my case, when running a raspberry pi 5:
line  16:     "GPIO16"   "spi1 CS2"  output   active-low [used]
ls /dev/spidev*
/dev/spidev0.0  /dev/spidev1.0  /dev/spidev10.0  /dev/spidev1.1  /dev/spidev1.2

Any suggestion or example of how to use chip selects with the new API ?
It appears to run fine in a Raspberry Pi 4.
line  16:     "GPIO16"       unused  output  active-high
ls /dev/spidev
spidev0.0  spidev1.0  spidev1.1  spidev1.2

any suggestion @eldruin ?

repo: rust-embedded/linux-embedded-hal


text:
Implement common traits

from the api guidelines:
https://rust-lang.github.io/api-guidelines/interoperability.html
For me it would be very useful if the Device struct had at least PartialEq in order to do tests.

@MarcoIeni I ran headfirst into this issue as well. My workaround for now is the following:
// Newtype to implement PartialEq on svd::Device without needing
// to fork the crate.
#[derive(Debug)]
struct DeviceWrapper(svd::Device);

impl PartialEq<DeviceWrapper> for DeviceWrapper {
    fn eq(&self, other: &DeviceWrapper) -> bool {
        let dev_self : &svd::Device = &self.0;
        let other_self : &svd::Device = &self.0;

        (dev_self.name == other_self.name) &&
        (dev_self.version == other_self.version) &&
        (dev_self.description == other_self.description) &&
        (dev_self.address_unit_bits == other_self.address_unit_bits) &&
        (dev_self.width == other_self.width) &&
        (dev_self.cpu == other_self.cpu) &&
        (dev_self.peripherals == other_self.peripherals) &&
        (dev_self.default_register_properties == other_self.default_register_properties)
    }
}

...
match svd::parse(&out_svd) {
        Ok(parsed) => { assert_eq!(DeviceWrapper(svd_dev), DeviceWrapper(parsed)); },
        Err(e) => {
            eprintln!("Parsing output file {} during round-trip test failed", out_svd);
            return;
        }
    }

_Unfortunately, this is not sufficient for my needs for msp430_svd and trying to remove the outdated local copy we have.
It's not possible for me to actually construct peripheral instances at all because the _extensible: (), field is private. I believe this would be solved if a Default implementation was derived, combined with struct update syntax (..)?
Perhaps provide it behind a feature gate?

Wow, thank you for the workaround, but I would prefer a proper fix in this repo

It's not possible for me to actually construct peripheral instances at all

See #101

repo: rust-embedded/svd


text:
Make lib.rs accessible to dependers

Hi,
we are trying to use svd2rust from a build.rs file. As of now, cargo build-dependencies can't be binaries and using svd2rust as a dependency yields an empty crate. svd2rust has to be installed manually for our build.rs to work.
This is a proposal to fix that. I'm not sure this patch is the right way, but it seems all we need is access to the generate() function and we're good to go.
Thanks!

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @therealprof (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

I though there was a similar PR to this but I can't find it. Sounds good to me in principle but I'm not a very keen user of build.rs so I'd like to hear other opinions.
CC @rust-embedded/tools

#214 did indeed do this. I can't reproduce the mentioned issue when using latest changes (currently unreleased, candidate for 0.15) in cargo 1.33.0 (2019-02-12). Unless there's a good reason to add this I think this should be closed.

Yes, using the current master, it seems to work as expected. I must've gotten 0.14 and master mixed up, sorry.
Is there an ETA for 0.15?

authors: Emilgardis rust-highfive therealprof vojtechkral


text:
Add instructions for compiling release notes

From https://internals.rust-lang.org/t/rust-release-milestone-predictions/4591/33. Seems like the kind of knowledge that should be maintained.

🎊

authors: brson steveklabnik

repo: rust-lang-nursery/rust-forge


text:
Incorrect comma inserted in cfg (CI only)

E.g.,
#[cfg(not(all(feature="std",
              any(target_os = "linux", target_os = "android",
                  target_os = "netbsd",
                  target_os = "dragonfly",
                  target_os = "haiku",
                  target_os = "emscripten",
                  target_os = "solaris",
                  target_os = "cloudabi",
                  target_os = "macos", target_os = "ios",
                  target_os = "freebsd",
                  target_os = "openbsd", target_os = "bitrig",
                  target_os = "redox",
                  target_os = "fuchsia",
                  windows,
                  all(target_arch = "wasm32", feature = "stdweb"),
                  all(target_arch = "wasm32", feature = "wasm-bindgen"),
))))]
type Os = NoSource;

Changes the last line to ),))].
I can't reproduce this locally, but it seems to be causing rand to fail testing in CI.

https://github.com/rust-lang-nursery/rustfmt/blob/1c408818c8a752dd584e7858b4afd3ceb011a7da/src/attr.rs#L221-L223
This assumption does not stand when the attribute is nested, and causes rustfmt to be non-idempotent.

authors: nrc topecongiro

repo: rust-lang-nursery/rustfmt


text:
opt-out

Related to https://github.com/rust-lang-nursery/thanks/issues/42, an explicit opt out is a good call.
This information is public, as in, it's in the github history for anyone to see, but if someone doesn't want their name on this page for some reason, we should respect that.
I am happy to do this manually for now, but it's gonna need to be automated in some fashion.

Blocked on infrastructure work that's part of https://github.com/rust-lang-nursery/thanks/issues/8

I could work on that (cannot commit to work on higher priority issues right now like fixing support for multiple projects due to a lack of time).
I think we should do the following:

finally normalize the database and pull the authors out of commits to their own table;
add a new binary (e.g. opt-out) that will mark the author as opted-out (or create a new one marked as opted-out from the start -- if someone wants to opt-out before their project is added to thanks);
fix front-end to respect that.

Going with this approach we would still have the names/emails in the database (just not show them in the front-end), but I think it is acceptable as this data is publicly available in the repos on GitHub. If not, then we should investigate some other solution.

finally normalize the database and pull the authors out of commits to their own table;

💯

add a new binary (e.g. opt-out) that will mark the author as opted-out

💯

fix front-end to respect that.

👍 , luckily this shouldn't need any real front-end work, just modifying queries, which you'll have to do anyway for 1.

I think it is acceptable as this data is publicly available in the repos on GitHub

Yes, this is about ease of getting the information; in my experience, this would be fine. Nobody has straight-up wanted to opt out yet, so I can't consult anyone directly.

https://github.com/rust-lang-nursery/thanks/pull/72 closes this!

authors: jmatraszek steveklabnik

repo: rust-lang-nursery/thanks


text:
CARGO_LOG is not documented in cargo reference

Problem
The environment variable CARGO_LOG exists, is talked about (example: https://stackoverflow.com/questions/70174147/how-do-i-make-cargo-show-what-files-are-causing-a-rebuild/70174212#70174212 ) and changes cargo's behavoir.
But is not listed on

https://doc.rust-lang.org/cargo/reference/environment-variables.html
https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/environment-variables.md

Steps
No response
Possible Solution(s)
Add it to https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-reads
Notes
No response
Version
https://github.com/rust-lang/cargo/blob/e6827eee9b6720a1bd69c6115cac22f8125b24aa/src/doc/src/reference/environment-variables.md

Thanks for the report! We do have CARGO_LOG documented in Cargo contributor guide. It's more like an internal debugging variable but might be worth mentioning in general user guide. Need some word tweaks tho.

authors: rfjakob weihanglo

repo: rust-lang/cargo


text:
rustflags overwritten not added

Problem
When both
[build]
rustflags =

and
[target.'cfg(...)']
rustflags =

are used, the target flags overwrite the build flags instead of adding on top of them.
This seems like a bug to me since I would expect [build] rust flags to be globals that are added upon.
Steps
The following is a failing test case I would expect to succeed:
#[cargo_test]
fn build_flags_and_target_flags() {
    let config = format!(
        r#"
            [build]
            rustflags = ["-Wunused"]
            [target.'cfg(target_arch = "{}")']
            rustflags = ["-Wunsafe-code"]
        "#,
        std::env::consts::ARCH
    );

    let p = project()
        .file(".cargo/config.toml", config.as_str())
        .file("src/lib.rs", r#""#)
        .build();

    p.cargo("build -vv")
        .with_stderr_contains("[..]-Wunsafe-code[..]")
        .with_stderr_contains("[..]-Wunused[..]")
        .run();
}

Possible Solution(s)
A possible solution would be changing core/compiler/build_context/target_info.rs:env_args
end of function to:
    let mut all_rustflags = Vec::new();
    if let Some(rustflags) = rustflags_from_env(flags) {
        all_rustflags.extend(rustflags);
    }
    if let Some(rustflags) = rustflags_from_target(config, host_triple, target_cfg, kind, flags)? {
        all_rustflags.extend(rustflags);
    }
    if let Some(rustflags) = rustflags_from_build(config, flags)? {
        all_rustflags.extend(rustflags);
    }
    Ok(all_rustflags)

Notes
No response
Version
Stable and Nightly both reproduce
Nightly:
cargo 1.66.0-nightly (082503982 2022-09-13)
release: 1.66.0-nightly
commit-hash: 082503982ea0fb7a8fd72210427d43a2e2128a63
commit-date: 2022-09-13
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.79.1 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.5.1 [64-bit]

Stable:
cargo 1.63.0 (fd9c4297c 2022-07-01)
release: 1.63.0
commit-hash: fd9c4297ccbee36d39e9a79067edab0b614edb5a
commit-date: 2022-07-01
host: aarch64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.5.1 [64-bit]

Thank you for this comprehensive report, and even with tests! I really appreciate that.
I believe this is a duplicate of #5376, so I'll close this in favour of that, as more discussions happened there. Thank you.

authors: danlapid weihanglo


text:
Snake Game when compiling

Problem
For small projects, it doesn't take too long to compile Rust projects.
For big projects, it can take a while, definitely if you've made a lot of changes. Hence why it could be nice to have a small snake game to play on the side in your terminal. Maybe a cool little easter egg that only works when you pass a specific flag in the cargo run command.
Proposed Solution
Snake game.
Notes
Snake game.

As for gaming during compilation, I would recommend Factorio, which you also wait for cargos a lot in game.
Joke a side, we have a Performance label tracking Cargo's performance issues. The compilation of Rust mostly spend on the compiler side. Read this chapter of The Rust Performance Book for how to improve the compile time.
As for Cargo itself, issues would immediately impact compile time is a better story around caches. Per user cache is one of them. A better scheduling algorithm also a potential one.
Close as maintainers have no capacity to maintain this easter egg. Feel free to discuss more on those issues :)

authors: arnoexe weihanglo


text:
Cfgs from build script not passed to rustdoc

The cfg directives returned by the build script via the cargo:rustc-cfg=foo convention are not passed to rustdoc when invoking cargo doc.
rustdoc seems to accept them just fine i.e. invoking it manually with --cfg foo produces the expected results.

I think this is a dupe of #1277, but thanks for the report!

Not really. #1277 talks about features. It appears to have been fixed back then.

Hm, good point. I could of sworn we had a few dupes for this issue, but I guess this one will now become the "one true issue"!

authors: alexcrichton gkoz


text:
Compile OpenSSL from source on OSX

I'm seeing a bunch of weird illegal instructions on OSX nightlies for
Cargo. My guess is that they're all related to OpenSSL linking. Right
now we're linking from Homebrew but I have a sneaking suspicion that it
compiles with -march=native rather than what we'd like as a portable
binary. To work around this compile OpenSSL ourselves and link it that
way.
Note that I believe this won't bring in the certificate trust store of
OpenSSL on OSX (or at least not the right one from the keychain). We
shouldn't need that, however, as OpenSSL is just used as the
cryptographic primitives in libssh2 and Cargo itself. So in that sense
we shouldn't need it for actually SSL at all.

r? @brson
(rust_highfive has picked a reviewer for you, use r? to override)

I’ve seen Travis fail with "Illegal instruction: 4" on OS X on the Nigthly channel, but OpenSSL is not involved. In fact, even cargo --version fails:
https://travis-ci.org/servo/string-cache/jobs/179029570

@SimonSapin unfortunately I haven't confirmed that the illegal instruction is specifically related to OpenSSL, but it's the biggest thing that changed that'd cause me to suspect it. OpenSSL is actually always related I believe because we initialize the various libraries (libgit2, libssh2, openssl) I believe on startup no matter the command. So in that sense I think there's at least a vector for OpenSSL to get involved?
Obviously a stack trace would be best but unfortunately I don't know how to get one out of Travis.

Oh, sorry, you mean cargo itself using OpenSSL. I was thinking of cargo building the rust-openssl crate.

Oh right yeah Cargo's linking to OpenSSL, but the way we do that changed very recently, and that's what I think the bug is (pulling in bad binaries).
Another reason I suspect this is at fault is that locally Cargo works just fine for me, but I also likely have a more recent Mac with a newer CPU than what Travis is running (presumably)

@bors: r+

:pushpin: Commit 8ab8595 has been approved by alexcrichton

:hourglass: Testing commit 8ab8595 with merge 3568be9...

:sunny: Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64
Approved by: alexcrichton
Pushing 3568be94c0ca73488954ad209c07e7998786b3d9 to master...

authors: SimonSapin alexcrichton bors rust-highfive


text:
Crates using vulkano-shaders fail to build

We have a bit of a situation in that all crates that use vulkano-shaders fail to build on docs.rs, at least as of 0.33, for reasons that are beyond me. There's no metadata for docs.rs in vulkano-shaders or any of these crates, and documenting of course works locally.
The following crates are affected:

basalt
egui_winit_vulkano
ilmenite

It may have been https://github.com/rust-lang/rust/pull/111461 giving a wrong error message, but not sure why it would have been erroring at all, I will queue a new build of those versions.

Hmmm, still failed with a more normal error message. I don't see why it's failing though, trying to do a local build using some of the options that docs.rs does doesn't cause any similar sort of failure, and there's no more useful data in the service logs. I can try and debug some more in a local docs.rs instance tomorrow.

license: MIT


text:
Make PartialEq for map and set more flexible

Fixes #172

The test failures fixed by https://github.com/rust-lang/hashbrown/pull/173/commits/360d6a29c0378f74f9786fa6baeaf306ee1ad836 are a little awkward. I guess that makes this a backwards-incompatible change?

I am concerned about the type inference implications. I feel that it's probably not worth it for such a niche feature. Do you have a specific use case for this?

No, I don't, I just added it because it seemed like a straightforward enough capability to add. It mostly comes in handy in tests I think. But I agree with you that the inference implications are unfortunate. I'm okay with closing this if you'd prefer.

I'd rather close this. Generally you're going to use the same hasher for all your hashmaps anyways.

authors: Amanieu jonhoo

repo: rust-lang/hashbrown

license_source: bigquery


text:
Implement IndexMut for HashMap

Since HashMap already has get_mut and implements Index i believe there is no good reason not to implement IndexMut.
If there is some reason I missed for why this isn't a good idea, please let me know :)
My initial intention was to implement this for the std HashMap directly, but then I saw that past PR's with changes to that got told to implement the changes in hashbrown as well, so I made this PR first.

I'm pretty sure the clippy CI failure wasn't caused by my change.
It seems trivial to fix though, should I make a PR for that?

I believe the reason this hasn't been implemented before is because of the surprising behavior for missing keys. In other languages such as Python and C++ you can insert a new entry by using map[key] = value. Making this cause a panic in Rust could be surprising to many users coming from other languages.
Perhaps in the future we can make this work by supporting an assignment version of the Index trait.

I rebased this to allow the CI to run.

I believe the reason this hasn't been implemented before is because of the surprising behavior for missing keys.
In other languages such as Python and C++ you can insert a new entry by using map[key] = value.
Making this cause a panic in Rust could be surprising to many users coming from other languages.

I personally don't think having a read-only map[key] is less confusing than a mutable but not replaceable map[key].
In fact Vec and VecDeque already implement IndexMut, though LinkedList doesn't for some reason.
It seems like LinkedList doesn't implement IndexMut because it doesn't implement Index.
Well, if IndexMut not being implemented is a conscious decision, feel free to close this PR.

I would say that this is a conscious decision: we want to leave the door open for supporting a future IndexAssign functionality. If we were to implement IndexMut today, this would no longer be possible since adding IndexAssign later would be a breaking change.


text:
"./miri test" builds Miri twice

We (again) have some dependency situation which leads to Miri being built twice for ./miri test -- likely one of our dev-dependencies enables a feature on another dependency that is shared with a regular build of Miri and so the Miri binary gets rebuilt by cargo.
Is there any way we can automatically test this, and avoid having to manually track this down at least once a year?
Is there some cargo bugreport that would have cargo re-use the perfectly fine miri binary that we have rather than re-building it with more features enabled that we didn't need?

For now I worked around this by always telling cargo to build everything... only ./miri run still has a separate build now.
https://github.com/rust-lang/miri/issues/3372 may be a better solution.

repo: rust-lang/miri


text:
Allow use reserved keywords as variable, argument function and etc.

For example rustc code contains many krate variables just because crate is reserved keyword. I like the way it is implemented in C# with @.
    let @crate = cache.fold_crate(@crate);

The goal is eliminate intentional typos.

You can already do this using _.

You are right. I don't think about it.

AFAIK adding _ changes their name, it does not allow you to use them as identifiers.
The following library would not export a function named fn; it would export a function named _fn.
#![crate_type="lib"]

#[no_mangle]
pub extern fn _fn() -> usize {
    42
}

Note that the main use I know for this kind of features is interop and code generation (example: I have a schema and need to generate structs to represent them; ideally I want to keep the name matching the original ones). It becomes even more interesting when reflection is allowed, as the (type, member, ...) names are usually also observable as strings.

@ranma42 First of all. The _ should be placed after the ident to avoid silencing the unused warnings. Also, @KalitaAlexey propose an @ operator, which is no different from the _, we already got.

@Ticki I tried to move the _ as you suggested: http://is.gd/w77SqT
In the LLVM IR and in the assembly output I still get the wrong name for the function (fn_ instead of fn). How should I call the function so that its name is fn?
In C# @ can be used to "escape" the identifier, but it does not become part of it. I cannot get the same behaviour with _ (but I might be misusing it... a code example would be very useful).

@ranma42 _ will be part of name. It is ok for me.

Yeah, ranma42, I must have misunderstood you, there are currently no way to escape the names, but (unless you're using #[no_mangle]) the names are mangled anyways. A possibility is to add an attribute for setting the name, you want.

authors: KalitaAlexey Ticki ranma42

repo: rust-lang/rfcs


text:
Implement std::convert::From for the json Error types

Implement From<io::Error> for ParserError and From<ParserError>
for DecoderError.
I considered implementing From<io::Error> for DecoderError as well,
as a convenience for mapping it through ParserError, but that seems
less obviously useful.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see CONTRIBUTING.md for more information.

Thanks!

authors: alexcrichton kballard rust-highfive

repo: rust-lang/rustc-serialize


text:
let ... = ... else {} badly and infinitely indented with repeated formatting

This issue is similar to #4609.
To reproduce:
macro_rules! a {
    () => {
        let x = y else {
            any
        };
    };
}

fn b() {
    let Some(x) = Some("hai") else {panic!("oops");};
}

d!(
    macro x() {
        let x = y else {
            any
        };
    }
);

Run $ rustfmt test.rs
And now you get this:
macro_rules! a {
    () => {
        let x = y else {
                    any
                };
    };
}

fn b() {
    let Some(x) = Some("hai") else {panic!("oops");};
}

d!(
    macro x() {
        let x = y else {
                    any
                };
    }
);

Notice the bad indentation in macro_rules! a and d!(...) and the unchanged bad indentation in b().
for d!(), this only happens with:

macro invocation with !()
the macro keyword (weird!)
and it should look like a function except you replace fn with macro
and of course the let ... = ... else {}; statement; yes you need ;

And for the case in b() it just happens anywhere; seems like there is no support for formatting let ... = ... else {}; statements in rustfmt?
Some of the affected versions

rustfmt 1.5.1-stable (d5a82bb 2023-02-07)
rustfmt 1.5.2-stable (8ede3aa 2023-07-12)

Thanks but I'm going to close because this is a duplicate of #5503 and you need to have rustfmt v1.6.0 or higher to have a version that has formatting support for let-else statements. That version of rustfmt should be on stable in Rust 1.72, and has been out on the nightly toolchains for a while.
Some docs/links below for reference:
https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#160-2023-07-02
https://github.com/rust-lang/rustfmt/issues/4914
https://blog.rust-lang.org/2023/07/01/rustfmt-supports-let-else-statements.html

repo: rust-lang/rustfmt


text:
Formatting of consecutive vec! lines requires multiple runs

rustfmt requires multiple runs to generate consistent output for this input code:
fn zserio_read(&mut self, reader: &mut BitReader) -> Result<()> {
    self.headers = vec![crate::reference_modules::parameter_passing::index_operator::block_header::BlockHeader::new(); headers_array_length];
    self.blocks = vec![crate::reference_modules::parameter_passing::index_operator::block::Block::new(); blocks_array_length];
}

After a first pass the code is updated to this:
fn zserio_read(&mut self, reader: &mut BitReader) -> Result<()> {
    self.headers = vec![crate::reference_modules::parameter_passing::index_operator::block_header::BlockHeader::new(); headers_array_length];
    self.blocks =
        vec![
            crate::reference_modules::parameter_passing::index_operator::block::Block::new();
            blocks_array_length
        ];
}

And after a second pass it moves the vec! invocation to the line with the assignment:
fn zserio_read(&mut self, reader: &mut BitReader) -> Result<()> {
    self.headers = vec![crate::reference_modules::parameter_passing::index_operator::block_header::BlockHeader::new(); headers_array_length];
    self.blocks = vec![
            crate::reference_modules::parameter_passing::index_operator::block::Block::new();
            blocks_array_length
        ];
}

after this rustfmt is happy an running it again creates no further changes.

Thanks for the report. The indentation on the second vec![] looks off to me too.

authors: wichert ytmimi


text:
msghdr as a private field in MsgHdr/MsgMutHdr

Hi, could anyone help me here, msghdr exists as a private field in MsgHdr/MsgMutHdr, I can't get/set ip packet info using libc::CMSG_FIRSTHDR/CMSG_DATA/CMSG_NXTHDR etc, maybe we can expose msghdr as a public field?
It's not clear to me what should be done here now, to complete the C implementation of this example: https://github.com/a-ba/udp_sas/blob/master/src/udp_sas.c
/// Receive a datagram (low-level function)
///
/// Parameters
///
/// * `buf`: buffer for storing the payload
///
/// Returns a tuple containing:
///
///   * the size of the payload
///   * the source socket address (peer)
///   * the destination ip address (local)
///
/// Note: the source (peer) and destination (local) addresses may not be present in the result if
/// the underlying socket does not provide them.
pub fn udp_recv(
    socket: RawFd,
    buf: &mut [u8],
) -> io::Result<(usize, Option<SocketAddr>, Option<IpAddr>)> {
    let socket = unsafe { socket2::Socket::from_raw_fd(socket) };

    let mut src = new_sock_addr_uninit();
    let mut dst = new_sock_addr_uninit();

    let mut iov = [socket2::MaybeUninitSlice::new(unsafe {
        slice::from_raw_parts_mut(buf.as_mut_ptr() as *mut MaybeUninit<u8>, buf.len())
    })];
    let mut ctl = Vec::with_capacity(256);
    let mut ctl = ctl.spare_capacity_mut();

    let mut msg = socket2::MsgHdrMut::new()
        .with_addr(&mut src)
        .with_buffers(&mut iov)
        .with_control(&mut ctl);
    let nb = socket.recvmsg(&mut msg, 0)?;

    // TODO: how to set dst address to msg ip packet info

    Ok((nb, src.as_socket(), dst.as_socket().map(|addr| addr.ip())))
}

/// Send datagram (low-level function)
///
/// Return the size of the sent payload
///
/// Note: the source (local) and destination (target) addresses are optional.
pub fn udp_send(
    socket: RawFd,
    buf: &[u8],
    src: Option<&IpAddr>,     // local
    dst: Option<&SocketAddr>, // target
) -> io::Result<usize> {
    let socket = unsafe { socket2::Socket::from_raw_fd(socket) };

    let src = src.map_or_else(new_sock_addr_uninit, new_sock_addr_from_ip);
    let dst = dst.map_or_else(new_sock_addr_uninit, new_sock_addr_from_addr);
    let iov = [io::IoSlice::new(buf)];
    let ctl = Vec::with_capacity(256);

    let msg = socket2::MsgHdr::new()
        .with_addr(&dst)
        .with_buffers(&iov)
        .with_control(&ctl);

    // TODO: how to set src address to msg ip packet info

    let nb = socket.sendmsg(&msg, 0)?;

    Ok(nb as usize)
}

Hi, could anyone help me here, msghdr exists as a private field in MsgHdr/MsgMutHdr, I can't get/set ip packet info using libc::CMSG_FIRSTHDR/CMSG_DATA/CMSG_NXTHDR etc, maybe we can expose msghdr as a public field?

The whole point of MsgHdr and MsgHdrMut is to expose msghdr in a cross-platform supported way. So we will not expose msghdr as a public field. However we can add a method to get and set the IP packet info, similar to the with_buffers or with_flags methods. A pr for that would be welcome.

Sure, thanks for your explain, I might try it after the feature version is stable if possible.

authors: Thomasdezeeuw cavivie


text:
Bump ndarray to 0.15.0

Addresses #124.
Having issues with new version of sprs. The compile error most likely has something to do with https://github.com/vbarrielle/sprs/issues/278 and was introduced by https://github.com/vbarrielle/sprs/pull/290.

replacing the operator with sprs::binop::csmat_binop(mat.view(), mat.transpose_view(), |x, y| x.add(*y)); seems to work as a workaround. The difference between making the explicit call to add and the operator makes the difference: https://docs.rs/sprs/0.11.0/src/sprs/sparse/binop.rs.html#63

the construction of the sparse matrix fails though and I'm not yet sure why

the new constructor assumes ordered indices, this solves it:
    // create CSR matrix from data, indptr and indices
    let mat = CsMatBase::new_from_unsorted((n_points, n_points), indptr, indices, data).unwrap();
    let mut mat = sprs::binop::csmat_binop(mat.view(), mat.transpose_view().to_other_storage().view(), |x, y| x.add(*y));

It seems there are some strange type inference going on when using linfa::Float in sprs. You can use the following code instead:
    // create CSR matrix from data, indptr and indices
    let mat = CsMat::<F>::new_from_unsorted((n_points, n_points), indptr, indices, data).unwrap();
    let transpose = mat.transpose_view().to_other_storage();
    sprs::binop::csmat_binop(mat.view(), transpose.view(), |_, _| F::one())

This does the same as we do behind the scene. I have assumed x + y != 0, and moved this computation into binop, which might be more performant

the CI pipeline somehow failed to run here as well, I checked manually ..

authors: YuhanLiin bytesnake mulimoen

repo: rust-ml/linfa


text:
Outdated unsoundness information in AsPrimitive documentation

The page for AsPrimitive mentions soundness holes from old versions of Rust related to floating point cast results, more specifically, #10184 and #15536. Those have now been resolved, which is why the documentation should remove mentions of those bugs or explicitly state that those have been fixed and no longer cause undefined behavior.

#184 updated this, but it hasn't been published in a release yet.

authors: cuviper kotauskas

repo: rust-num/num-traits


text:
A safe API wrapper interface

Has there been any consideration as to wrapping the unsafe bits of the user facing API into a safe abstraction?

Thanks. I'll keep an eye on @notgull's project. I have been using the rust pixels crate in lieu of softbuffer for an application that doesn't actually require GPU acceleration. It appears to be hiding the RawWindowHandle inside the implementation.

raw-window-handle 0.5.2 now has a safe API based on notgull's work, maybe this issue could be revisited?

raw-window-handle 0.5.2 now has a safe API based on notgull's work, maybe this issue could be revisited?

I've opened a PR (https://github.com/rust-windowing/softbuffer/pull/132) in anticipation of the new raw-window-handle breaking changes in the upcoming v0.6 (rust-windowing/raw-window-handle#125).
I'd like to file equivalent draft PRs for glutin and wgpu before I release rwh v0.6. There's also this issue which needs to be resolved as well.

authors: Jules-Bertholet notgull rbermani

repo: rust-windowing/softbuffer


text:
Citing nalgebra?

What is the appropriate way to cite nalgebra in an academic publication?
edit: Is this appropriate?
@misc{crozet2019nalgebra,
    title={nalgebra: a linear algebra library for {R}ust},
    author={Crozet, S\'ebastien},
    year = {2019},
    publisher = {GitHub},
    url = "https://github.com/rustsim/nalgebra"
}

Hi! I suggest the following:
@misc{crozet2019nalgebra,
    title={nalgebra: a linear algebra library for {R}ust},
    author={Crozet, S\'ebastien and others},
    year = {2019},
    url = "https://nalgebra.org"
}

authors: breandan sebcrozet

repo: rustsim/nalgebra


text:
Enum: Enable annotating discriminant of only some variants

Motivation
In the codebase I am working on are a couple of C-style enums, which have some variants annotated with discriminants and others not. (see for example enum ColorPrimaries)
I'd like to export these enums to js, to be able to use them as input parameters for some functions.
But, currently following code doesn't work, because onemust either annotate discriminant of all variants or none.
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
#[derive(Debug)]
pub enum Boat {
    Red,
    Blue,
    Green = 42,
    Yellow,
}

#[wasm_bindgen]
pub fn run_it(b: Boat) -> String {
    format!("{:?}", b)
}

Proposed Solution
I'd like wasm-bindgen to generate following js-glue-code:
export const Boat = Object.freeze({
    Red: 0,     "0":  "Red",
    Blue: 1,    "1":  "Blue",
    Green: 42,  "42": "Green",
    Yellow: 43, "43": "Yellow",
});

... and following type annotations:
export enum Boat {
  Red,
  Green,
  Blue,
  Yellow,
}

Alternatives
I could also create a copy of the needed enums, remove all discriminants and then match the copied and actual enum in the function. But this sounds not like a clean and maintainable solution...
Additional Context
I am happy to implement these changes, but would need a bit of mentoring :smile:

Edit
Initially I proposed to generate following js-Object:
export const Boat = Object.freeze({
    Red: 0,     "0":  "Red",
    Blue: 1,    "1":  "Blue",
    Green: 42,  "42": "Green",
    Yellow: 2,  "2":  "Yellow",
});

But playing around with rust I saw that following code:
pub enum Boat {
    Red,
    Blue,
    Green = 42,
    Yellow,
}

fn main() {
    let a = Boat::Red as u32;
    let b = Boat::Blue as u32;
    let c = Boat::Green as u32;
    let d = Boat::Yellow as u32;

    for i in [a, b, c, d].iter() {
        eprintln!("{:?}", i);
    }
}

... actually outputs:
0
1
42
43

So I guess it is better to stick with that also for the js code.

Digging a bit into the code, if found that the error message comes from: https://github.com/rustwasm/wasm-bindgen/blob/87663c6d2a442d98b3d8ea6242f20c5c21fc0174/crates/macro-support/src/parser.rs#L1155-L1163
The important bit is "We don't really want to get in the business of emulating how rustc assigns values to enums." (written by @alexcrichton).
Wouldn't it be possible to read the values rustc assigns to the enum variants (by casting them to u32)?

Currently, no, there's no way to read what rustc assigns a variant.

Currently, no, there's no way to read what rustc assigns a variant.

@alexcrichton That's a pity :/ Can you think of any other way to make this possible?

Unfortunately, no, I cannot at this time.

Currently, no, there's no way to read what rustc assigns a variant.

Implicit discriminants are assigned by Rust using a very simple algorithm. We don't need rustc to know which value is assigned, because we know the algorithm it uses.
To copy a code example from the docs:
enum Foo {
    Bar,            // 0
    Baz = 123,      // 123
    Quux,           // 124
}

let baz_discriminant = Foo::Baz as u32;
assert_eq!(baz_discriminant, 123);

authors: RunDevelopment Urhengulas alexcrichton

repo: rustwasm/wasm-bindgen


text:
About MoNet GMMConv.py

❓ Questions & Help

I noticed the forward function of GMMConv has two parameters and two parameters with default values.

For the edge_attr, it seemly can be set as None. However, if I do so, it raises an error when I do a node classification task for Cora:

I find the error caused by the line:

For the edge_attr, it seemly can't be set as None.
I'm confused that the Cora dataset doesn't edge_attr. How I set the value of edge_attr for the node classification tasks?

Yeah, it is marked as optional because in case you are using SparseTensor, we expect edge attributes to be included there, e.g.:
adj = SparseTensor(row=edge_index[0], col=edge_index[1], value=edge_attr)

MoNet needs edge attributes/pseudo coordinates, and in case they are not given, the paper suggests to generate them by yourself, e.g. via node degrees (check Sec. 5.2 in the paper).

Thanks for your reply! whether do I need to construct a two-tuples list  according to the edge index? Then, the edge attributes are a tensor with shape [num_edges, 2].

Yes, exactly.

Thanks very much! ! !


text:
Ensuring that all possible negative edges are considered

I have been working with a custom dataset and took inspiration from the link_pred.py example in the repository. I have had the model working after some issues and am getting good results. However, in order to make my results comparable to previous work, I need to ensure that when testing, all possible edges in a graph, both positive and negative, are considered.
From what I understand, the example considers all positive edges but downsamples to a much smaller size of the negative sample set, as done in the GAE paper as well. I have tried to work around this by training and testing on the probability adjacency matrix output from the model, but the results seem to be very poor. Is there a way to ensure that all possible edges are considered and predicted on in a graph when working with the link prediction model?

Training and testing is usually only performed on a subset of negative examples due to memory limitations. Furthermore, testing against all possible negative edges is quite challenging, due to the larger amount of negative samples.
I think what you are doing is already correct for evaluation (if you have doubts please feel free to post a code snippet). As the decoder in the link_pred example is quite dumb, you might also see more success when using more sophisticated decoders (such as running an MLP on the concatenated feature values of source and target nodes).

I represented the dataset I am working with as a list of graphs, and each graph tends to be small (I believe the biggest graphs I have are around 10-15 nodes), so memory limitations should not be an issue. The previous work that I am trying to compare application of GNN too are SVM/LSTM with attention based, so it is important that all edges are considered for GNN as well, in order to make the results comparable. Is there any GNN implementation you have in mind that does so?
Additionally, could you post a short snippet with regard to your MLP decoder suggestion? That could be helpful.

I see. In this case, I think you are save to simply use all non-positive edges as negative edges, e.g., by storing them in data.neg_train_edge_index in a pre-processing step.
For a decoder based on MLP, I have something like this in mind:
def decode(self, z, edge_index):
    z = torch.cat([z[edge_index[0]], z[edge_index[1]]], dim=-1)
    return self.MLP(z)

where self.MLP is a MLP mapping from 2 * hidden_channels to 1.

Thank you for the help, will experiment with this!


text:
Fixed bug in read_obj

read_obj did not extract mesh faces correctly from Wavefront .obj files because only the first index per triangle was processed.
Example:
Face in .obj file: f 1/2/3 4/1/6 3/2/4
Processed output of current read_obj: [0,3,2]
Correct output: [0,1,2,3,0,5,2,1,3]

Thanks!


text:
Lazy loading for datasets and nn.models

See discussion in #2189 .
This PR uses the LazyLoader class from TensorFlow to lazy-load torch_geometric.datasets and torch_geometric.nn.models.
The file from TensorFlow is under an Apache 2.0 license, so it should be fine to include in an MIT license project? See:

https://softwareengineering.stackexchange.com/questions/297217/using-code-under-apache-2-0-license-in-my-program-using-mit-license
https://opensource.stackexchange.com/questions/8135/can-i-use-mit-isc-apache-2-0-in-a-project-licensed-as-mit-or-apache-2-0
https://law.stackexchange.com/questions/6081/can-i-bundle-mit-licensed-components-in-a-apache-2-0-licensed-project

The last commit is needed to lazy load all of nn instead of nn.models. Unfortunately, because torch_geometric/nn/__init__.py had
from .models import *

there doesn't seem to be any way to lazy load those individual classes.
This lazy loading setup (from TensorFlow) only supports modules. I tried to use importlib.utils.LazyLoader from the stdlib, but was unable to get it to work without circular import errors.

I further polished and achieved faster loading by fixing some imports in torch_geometric.transforms which directly imported from torch_geometric.nn.

Looks good, thanks @rusty1s . I'm not sure why the CI tests are failing, though.

CI fails because of https://github.com/pytorch/vision/issues/3504, which is independent of this PR.


text:
Don't link to Spanish Wikipedia

Because the README is in English

Not sure why it thinks I changed the last line

repo: rviscarra/webrtc-remote-screen


text:
Are there any trained forward/backward models checkpoints available?

Hi,
Thanks for this nice project! But are there any trained forward/backward models checkpoints available to reproduce the results? Thanks!

Hi @queliyong thanks a lot for the interest in our work. We do not have shareable checkpoints, but it is relatively easy to train your own using the instructions and the code base we provide in https://github.com/rxn4chemistry/rxn-onmt-models.
There you find all the details on how to format your dataset and set the parameters for training both backward and forward models.

authors: drugilsberg queliyong


text:
Display commenter's email address and the date/time of posting alongs…

…ide each comment.

Site is deployed at http://ryandraper-step-2020.appspot.com/.

@charu0291 I meant for this PR to just include the information with the plan of a future PR to clean up the comment formatting/appearance, but I can try to fix the alignment now.

repo: ryan-draper/step-portfolio


text:
pyright says it is not awaitable

async_property version: 0.2.2
Python version: 3.10
Operating System: Windows

Description
I am having problems with pyright because of the types. when I try to await an async_cached_property I get the following hint:
  C:\bakdata\kpops\kpops\component_handlers\topic\proxy_wrapper.py:87:39 - error: "AsyncCachedPropertyDescriptor" is not awaitable (reportGeneralTypeIssues)
  C:\bakdata\kpops\kpops\component_handlers\topic\proxy_wrapper.py:87:39 - error: "AwaitableOnly" is not awaitable (reportGeneralTypeIssues)

What I Did
https://github.com/bakdata/kpops/blob/2f7212fa00660b4219cb4532c734ac220b330bdd/kpops/component_handlers/topic/proxy_wrapper.py#L106
https://github.com/bakdata/kpops/blob/2f7212fa00660b4219cb4532c734ac220b330bdd/kpops/component_handlers/topic/proxy_wrapper.py#L37

@irux I have a draft PR here to fix it: https://github.com/ryananguiano/async_property/pull/15/files
haven't tested it yet. maybe you can install from this branch and test it out?

@ryananguiano Just tried out the branch, it doesn't solve the issue:
  <REDACTED>:19:22 - error: "AsyncCachedPropertyDescriptor" is not awaitable
    "AsyncCachedPropertyDescriptor" is incompatible with protocol "Awaitable[_T_co@Awaitable]"
      "__await__" is not present (reportGeneralTypeIssues)
  <REDACTED>:19:22 - error: "AwaitableProxy" is not awaitable
    "AwaitableProxy" is incompatible with protocol "Awaitable[_T_co@Awaitable]"
      "__await__" is an incompatible type
        Type "() -> T@__await__" cannot be assigned to type "() -> Generator[Any, None, _T_co@Awaitable]"
          Function return type "T@__await__" is incompatible with type "Generator[Any, None, _T_co@Awaitable]"
            "object*" is incompatible with "Generator[Any, None, _T_co@Awaitable]" (reportGeneralTypeIssues)

authors: felipetavares irux ryananguiano


text:
move content into folders

per the Pelican docs you don't need to specify a category if you organize into folders. Need to move all docs into folders

closed with https://github.com/ryancheley/ryancheley.com/commit/985e5b67741cd96369fc27eb437c93253ec57a74


text:
Create 0000-01-02-ryangrut.md

Add a second slide

Add text

repo: ryangrut/github-slideshow


text:
[Question] Is there any way to share the failures in a thread created under the message sent by the report?

Is there any way to share the failures in a thread created under the message sent by the report?
The idea around this suggestion is reducing verbosity on the message we are sending to the team.

The highlighted section would go to a thread under the message with the results summary.

I'll  do some googling and see if they have an endpoint for this.

Found this one: https://api.slack.com/messaging/sending#threading

It seems doable, here's my initial attempt at this ...

Just having a think about what to display though, I guess we can keep it simple initially as per your example above:
Failed test name

Stack trace (first 100 characters)

I will also need to add an extra config key (boolean - defaulted to false), something like summarizeFailuresInThread

added in https://github.com/ryanrosello-og/playwright-slack-report/releases/tag/v1.1.14

authors: miguelofbc ryanrosello-og

repo: ryanrosello-og/playwright-slack-report


text:
Create a sample set of SOPs

We need to get some real to world SOPs put in here so that folks with an agency today can get started. We can then add this to the website to help raise awareness of the utility.

This looks like a good source: http://emsprotocols.org/

Decided to focus on DeSoto County MS for now. I have a copy of their protocols, so I'm assigning this to me.

repo: ryanturner/procedure-center


text:
Lecture06. Замахаев Влад

message and findByName

Coverage decreased (-0.2%) to 43.017% when pulling 2e7928ac419ce74b818f99bd73067a87b76b376d on zamakhaevV:lecture06 into 1745e97298a69006e12bfbf4f971f2fa2783fbcb on rybalkinsd:lecture06.

checked

authors: coveralls rybalkinsd zamakhaevV

repo: rybalkinsd/atom


text:
🛑 Linked Events is down

In 26fcc42, Linked Events (https://linkedevents.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Linked Events is back up in 3eb8d47 after 5 minutes.

repo: rybesh/status


text:
no verb conjugations being returned for hebrew

I am running into a strange problem where the getConjugation method returns no conjugation for the Hebrew language.
It works for Russian though
e.g.:
 reverso.getConjugation( "לִרְצוֹת", 'hebrew',
        async (err, response) => {
            if (err) throw new Error(err.message)

            console.log(response)

           return response;

        }
    )

returns:
{
data: {
ok: true,
verbForms: [
{
id: 0,
conjugation: "Present",
verbs: [ ]
},
{
id: 1,
conjugation: "Past",
verbs: [ ]
},
{
id: 2,
conjugation: "Future",
verbs: [ ]
},
{
id: 3,
conjugation: "Passive Participle",
verbs: [ ]
}
]
}
}

I wonder if it's something to do with the language being RTL right to left

it might be due to RTL, yes. It happened before to getContext method. I’ll check out it later and release a patch asap. Thanks!

fixed in 2.22.6


text:
Site cannot fully load sometime

It looks like this:

We should somehow mitigate it, current answer in such cases:
"icon": "https://d15f34w2p8l1cc.cloudfront.net/overwatch/7d21d4ae099ba3299fef3688cd45e6635478bc9a0ff957643f873c18522b6839.png",
    "name": "Example-1234",
    "level": 100,
    "rating": 2000,
    "private": false,
    "gamesWon": 500,
    "prestige": 1,
    "levelIcon": "https://d15f34w2p8l1cc.cloudfront.net/overwatch/e8b7df4b88998380658d49d00e7bc483c740432ac417218e94fab4137bec4ae0.png",
    "ratingIcon": "https://d1u1mce87gyfbn.cloudfront.net/game/rank-icons/rank-GoldTier.png",
    "endorsement": 3,
    "prestigeIcon": "https://d15f34w2p8l1cc.cloudfront.net/overwatch/8de2fe5d938256a5725abe4b3655ee5e9067b7a1f4d5ff637d974eb9c2e4a1ea.png",
    "quickPlayStats": {
      "topHeroes": {
        "": {
          "gamesWon": 0,
          "timePlayed": "0",
          "multiKillBest": 0,
          "winPercentage": 0,
          "objectiveKills": 0,
          "weaponAccuracy": 0,
          "eliminationsPerLife": 0,
          "timePlayedInSeconds": 0
        }
      },
      "careerStats": {
        "": {
          "best": null,
          "game": null,
          "combat": null,
          "deaths": null,
          "assists": null,
          "average": null,
          "matchAwards": null,
          "heroSpecific": null,
          "miscellaneous": null
        },
        "allHeroes": {
          "best": null,
          "game": null,
          "combat": null,
          "deaths": null,
          "assists": null,
          "average": null,
          "matchAwards": null,
          "heroSpecific": null,
          "miscellaneous": null
        }
      }
    },
    "endorsementIcon": "https://d3hmvhl7ru3t12.cloudfront.net/svg/icons/endorsement-frames-aa182c1f63b51afa951daec63595791283ab97ea3a07f8d47abf9dc7aeda5cc67c786041042de0b8e427194ed084f7cee6b56fa984532199e7ea95bc12bbd995.svg#_3",
    "competitiveStats": {
      "topHeroes": {
        "": {
          "gamesWon": 0,
          "timePlayed": "0",
          "multiKillBest": 0,
          "winPercentage": 0,
          "objectiveKills": 0,
          "weaponAccuracy": 0,
          "eliminationsPerLife": 0,
          "timePlayedInSeconds": 0
        }
      },
      "careerStats": {
        "": {
          "best": null,
          "game": null,
          "combat": null,
          "deaths": null,
          "assists": null,
          "average": null,
          "matchAwards": null,
          "heroSpecific": null,
          "miscellaneous": null
        },
        "allHeroes": {
          "best": null,
          "game": null,
          "combat": null,
          "deaths": null,
          "assists": null,
          "average": null,
          "matchAwards": null,
          "heroSpecific": null,
          "miscellaneous": null
        }
      }
    }
  }

It happens pretty often (40% of page loads).
Related to #22

TBH, I am pretty disappointed HOW bad blizzard site is. It uses crazy cache that can show be literally three different profiles just by clicking "refresh" button in browser. Refresh -- profile is private. Refresh -- profile SUDDENLY NOT private. Refresh -- profile not private, but dozen of info not loaded. It's f...in crazy.
I am thinking about abandoning my project until API will be released (so sort of never, I guess).

I see what you're saying. It's pretty sad that it would load this way via blizzards frontend. The most I could recommend is hitting the endpoint several times (perhaps concurrently) and hope one of the payloads is larger than the rest and has real data. Since this app is a basic passthrough I don't think there's much I can do on my end besides performing the same concurrent logic.
Web scraping is never fun.  This project and my anime ripper are both projects I don't keep up with very often for this particular reason. It's almost not worth the trouble.

I tried to make stats-function recursive with attempts counter. Even with 100 attempts it not loads for some profiles. Because their caching is NIGHTMARE. It started only after december, their forums have tons of reports, but nobody cares, "api is not a priority"...


text:
🛑 Cisco Meraki is down

In 3c39fd8, Cisco Meraki (https://dashboard.meraki.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Cisco Meraki is back up in 6270f18 after 29 minutes.


text:
forbidden

وقتی به یک user برای دسترسی به اطلاعات همه کاربران permissionداده میشه باز هم خطای forbiddenمیده.
توکن توی هدر ارسال میشه
axios.get('http://localhost:8000/user/get_all_users/',{headers:{
Authorization: user.token
}})
.then((res)=>{console.log(res);
})

چطوری به یوزر پرمیشن کافی دادید؟

از پنل ادمین به کاربر پرمیشنview user دادم

is_superuser
is_stuff
این هارو اکتیو کنید

لطفا اطلاعات یوزرتون رو در پنل ادمین به صورت عکس بفرستید تا بررسی کنیم چه مشکلی در تعریف یوزر هست، من کد هارو دیدم مشکل از داخل کد نیست، پرمیشن به درستی به یوزر داده نشده. بیایید ایراد رو پیدا کنیم.

![1](https://user-images.githubusercontent.com/104249338/188285854-9c04d0c8-6797-46f0-89d

3-8ad1bc685a69.png)

لطفا در این بخش
user/views.py
لاین ۶۵ و ۶۶ یه اینتر بزنید این رو وارد کنید.
print(request.user.dict)
بعد دوباره درخواست بزنید، ببینید اطلاعات یوزر مد نظرتون درسته یا نه.
چند تا مشکل میتونه اینجا رخ داده باشه:
۱- توکن یوزر اشتباه رو دارید میدید
۲- درست پول نمیکنید ریپازیتوری رو، از این دستور استفاده کنید
git pull origin master
۳- از قبل از تغییر این بخش شما تا الان کانتینر رو بیلد نکردید.
لطفا اگر مشکل با این موارد حل نشد نتیجه اون لاینی که اضافه کردید رو اینجا بذارید.

یک مورد دیگه ای که احتمالا ممکنه توش ایراد وجود داشته باشه این هست که شما نوشتید:
Authorization: user.token
در صورتی که باید باشه:
Authorization: "Token " + user.token

authors: ali-sj sadeghesfahani

repo: sadeghesfahani/e-commerce


text:
Test ci

Purpose
Resolves #
Describe your changes
PR checklist

[ ] Add link to the issue
[ ] Choose PR label
[ ] New unit tests added
[ ] Modified code has meaningful comments
[ ] All TODOs are linked with the issues
[ ] All comments are resolved

Testing
Provide test details

/support

repo: safronovD/csi-baremetal