Pre-RFC describing mechanism to optionally loosen some orphan rule constraints

This RFC proposes a mechanism to allow impls for a type or trait to be in a
separate crate, while still meeting the soundness guarantees currently enforced
by the orphan rule. With this, the crate structure (and thus build system
dependency graph) can be decoupled from the actual implementations.
Rendered

The reason the orphan rules exist is precisely to avoid the situation where two crates cannot be used together because they have conflicting implementations. If there's a way to disable the orphan rules then you may as well just not have them, so I don't think this is a good idea.

I think that the need to restrict this feature to a local workspace shows how dangerous disabling the orphan rule really is. I personally do not want to have to think about any two crates creating an impl conflict, since it massively increases the complexity of crate relationships and possible impl-overlap compilation errors.
Perhaps the trait-defining crate could be required to declare (but not use-depend on) all crates which can impl-depend on it. This at least puts the task of avoiding conflicts in the court of the crate author instead of any user of the crates. Even if such crates are then published on crates.io, any conflicts could be detected within the limited list of crates before allowing publication.
Overall, I still think that the increase in complexity and nasty compilation errors is not merited. I feel like using features and improving parallel compilation itself are better approaches here.

I'd think "automatic dependencies" would address the usual issue here better:
[dependencies]
unwanted_dependency = { ..., optional=auto }

This says I'll impl whatever traits unwanted_dependency creates, but only if you use unwanted_dependency elsewhere.
After these cases, we need some "classification" of the possible newtype deriving stories, so folks can finally feel like they know the proper solutions there.

If you really need this, then you might do roughly this under the second orphan rule.  We've a type and trait like
pub struct Type { ... }

pub trait Trait<Localizer> { ... }

We then define impl Trait<MyLocalizer> for Type { } whenever we require some local flavor of the trait.  We do not care about Localizer being uncoverd since it comes first.
A priori, we'd want OtherTrait<MyLocalizer>: Type too perhaps, vaguely like if we'd created some newtype, but there now exist other options.  In particular, we could craft code to pass through different Localizers for Trait and OtherTrait, and then trait aliases could select the desired Localizers per trait.

With respect to features, if some crate foo enables serde in some other crate bar, foo probably depends on serde too, and so you don't add a dependency by enabling the feature (presumably foo would drop both if it dropped one, modulo typos in Cargo.toml).  Something like auto dependencies (cool idea) would make it automatic, but I don't take it as a given that the features to impl traits approach we have today is responsible for the convergence problem, and I don't see how this RFC makes it better.  It seems to me that the problem is that not bringing in tons of dependencies requires a lot of work either way, and for most people (including myself) there's a lot of bigger problems to address in our projects and not enough hours in the day.  If I'm following this right, we replace one crate with optional features with a bunch of small ones published somehow, which is worse than playing around with cfg attrs.
That's not to say I haven't personally found orphan rules painful, but they'd need to be replaced and not just removed for the same reason that we don't have type inference beyond the function boundary.  This doesn't sell me on it because it doesn't seem to make things take less work and it does definitely allow for spooky type action at a distance.  I don't want to patch one or more deep chains of dependencies because two semver-compatible versions now happen to provide conflict impls.  It's not just patch problem1 and/or problem2, it's patch those then climb up the chain patching everything between me and the problems.  I prefer slightly slow clean builds to a day of lost time.  Caching even without something like sccache covers the rebuilds most of the time, so I'm not concerned about those in terms of Rust compile time performance, and I suspect this RFC wouldn't move the needle much either way after the first build in regards to that either.
Anecdotally, I had to try to optimize build times for a large Rust codebase at work.  Removing even large numbers of dependencies was worth very little once sccache was running.  Surprisingly so in fact.  It was worth maybe a couple percent no matter what I tried in that regard (in that case the most gains were found helping Warp not to monomorphize as much and getting CI using sccache with s3).
Now to be clear: I'd love something less restrictive than the orphan rules that solves the same problem.  I'm not saying "O this is bad", more "O this will cause chaos".  If something was coming in to replace them, I'd feel more confident.

Oh, wow wasn't expecting this to attract attention so quickly.
The fundamental part of this proposal is the language-level mechanism, as a starting point for experimentation. The secondary part was a limited means to use it via Cargo so that there's something to work with. As I said numerous times in the RFC text, I do not think this should be considered for widespread use without a lot of extra discussion.
I'll reply to each person separately to help with discussion
@Diggsey:

If there's a way to disable the orphan rules then you may as well just not have them, so I don't think this is a good idea.

Right, but this does not propose disabling them; this RFC requires precisely the same coherence invariants that the current orphan rules do. All it proposes is implementing them with a bit more flexibility.

@juntyr:

I personally do not want to have to think about any two crates creating an impl conflict, since it massively increases the complexity of crate relationships and possible impl-overlap compilation errors.

One of the other key points of this proposal is that any conflict is detected and reported as close as possible to the conflicting crates. In principle one could do all coherence checking when linking the final binary crate. That would be fine from a correctness point of view, but a poor user experience since you'd get very late diagnostics about a problem. This design reports as soon as a conflict is possible to detect - in the common case, where impls and definitions are in the same crate as today, it would be indistinguishable from the status quo. Ideally, if you were using this mechanism, you'd set up unit tests which exercise all the valid combinations of defining and implementing crates within your workspace so that cargo check on them would give immediate feedback of problems.

Perhaps the trait-defining crate could be required to declare (but not use-depend on) all crates which can impl-depend on it. This at least puts the task of avoiding conflicts in the court of the crate author instead of any user of the crates.

Yes, I did consider that - that was the initial design. The problem is that since Rust has a flat crate namespace, there's no way to actually identify a crate without taking a dependency on it. Something of the form --allowed-impl my-serde-impl doesn't really do anything in particular, since it doesn't identify a specific crate. Currently the only place a crate name gets bound to a specific implementation is --extern my-serde-impl=/path/to/libmy_serde_impl.rlib which can't work here because it would be a cyclic dependency.
I also experimented with the idea of a "witness" crate-like object which takes a dependency on the defining and impl crates, and will only compile if the coherence invariants are correct. While that would work, it would also undermine all the other benefits of this proposal (since we'd still end up with binaries depending on everything even if they're not needed).

improving parallel compilation itself

There's two classes of parallel compilation - "internal", where rustc has internal parallelism to get better performance, and "external" where the build system can invoke multiple instances of rustc in parallel. The latter is much more scalable than the former.  Internal parallelism can make use of at most one machine's cores, assuming there's parallelism to be successfully extracted.
External parallelism can make use of a whole build-farm's worth of machines. In large scale systems, a build system like buck2 can have many thousands parallel compiler running at once, so long as the dependency graph allows it. In C++ this is relatively easy because of the decoupling header files give, but Rust is currently strongly constrained here. This is one of the things I'd like this RFC to improve.
That said, one of the "future possibilities" I propose is auto-splitting a crate into multiple subcrates. This effectively converts internal parallelism to external, and also mitigates all the complexity and eco system problems, since it's necessarily purely local.

@burdges

I'd think "automatic dependencies" would address the usual issue here better:

This looks like a "weak dependency" analogous to a weak symbol - the dependency here is not enough to bring in the crate, but some other strong dependency will.
Unfortunately this idea only work for small-scale build systems like Cargo, where you only have a single program within the dependency graph.
If you have a build system for a large system, then these weak dependencies can be hard to implement, if its possible at all, and even if you do have them they're very hard to reason about. Neither Buck nor Bazel (I think) support this kind of dependency.
I haven't thought about it in detail, but it seems quite possible you could get paradoxical situations: eg where you have an acyclic dependency graph, then you add one new dependency, which causes a weak dependency to be brought in, which in turn causes a cyclic dependency. Avoiding this means that you still need to analyze the entire dependency graph even for the "optional" parts you're not using, which add constraints on what you can depend on even though they're from things you're not using.
It doesn't seem any simpler, at any rate.

@ahicks92

I don't take it as a given that the features to impl traits approach we have today is responsible for the convergence problem, and I don't see how this RFC makes it better.

Could you expand on this? What do you mean by "the convergence problem"?

If I'm following this right, we replace one crate with optional features with a bunch of small ones published somehow, which is worse than playing around with cfg attrs.

Yeah, in the environments I'm working in, small crates are vastly preferable, from the perspective of:

better build parallelism
easier IDE presentation (no need for RA to understand which code is configured)
cfg/features not really being an option, since it would require per-dependency-edge cfg settings, with a corresponding combinatorial explosion

On the other hand, there's no requirement to use this mechanism if it doesn't solve any problems. It might make debugging issues with upstream dependencies harder if they misuse it; it doesn't feel to me like it would be much harder than feature combinetrics (ie the "how did this feature get enabled?" game).

I don't want to patch one or more deep chains of dependencies because two semver-compatible versions now happen to provide conflict impls. It's not just patch problem1 and/or problem2, it's patch those then climb up the chain patching everything between me and the problems. I prefer slightly slow clean builds to a day of lost time.

Yes I agree entirely - I would not want this to be available in the form of "any package can implement traits for any other package for types of any package" - ie, the "general third-party impls" problem. That would be a disaster. But that's orthogonal to what this RFC discusses, which is a basic mechanism which could be (mis)used this way, but also for many other much less problematic uses.

Caching even without something like sccache covers the rebuilds most of the time

Yes, to an extent. The environment I'm most familiar with uses Buck, which caches much more aggressively than Cargo (even with sccache). Warm builds are fine, but coldish builds are much more common than one would like - in a large multi-developer environment, someone is always touching something, and so we need to make those builds as quick as possible. But even if everything is cached, even analyzing the dependency graph to work out what even needs to be considered can take a considerable amount of time, so shrinking the dependency graph can be a build speed win in itself.
See also my comments above about internal vs external parallelism, where having a wide dependency graph which allows many build actions to be run in parallel has much better scaling.

(cc @JakobDegen @stepancheg @dtolnay)

Sorry, convergence was a bad word.  I mean the dependency explosion that happens when someone brings in (say) serde just to support its traits.
The thing is that the Rust parallel compilation model can be improved more and while it is indeed the case that clean builds happen more often than we would like, it's hard for me to see this as anything but a short-term hack to deal with such.  Typically, there's a way to design so that even local crate hierarchies don't have such issues.  For example, why not just pull your traits to a super-lightweight trait-defining crate, depend on that, and then implement them everywhere?  If we ignore everything about good code design and we say that this is entirely for build times/parallelism, then a my-traits crate solves that problem by pushing the serialization point down as far as possible so that all other workspace members can compile, potentially at the cost of triggering more rebuilds (take it as a given that I understand you can't always do  that, but it is still a solution that does often work).
If you're rebuilding from scratch all the time (including dependencies) then it seems to me that your build would always be dominated by external crates anyway, unless you're in an environment in which dependencies are disallowed, right?
Finally, with respect to parallel compilation and in full acknowledgement that I haven't done this, I would intuitively think that a build large enough to saturate more than one machine is large enough that the fact that there are dependency chains isn't going to be much of a factor.  There's bottlenecks, but I'm skeptical it's as clear-cut as "C++ headers good".  I also feel like there's probably a set of proper solutions to that which aren't allowing workspace-local breaking of the orphan rules.
I think if I was going to put it simply, what's the common use case this solves?  Right now I'm seeing this as primarily build time for a set of somewhat niche use cases.  Not invalid ones, it just feels like "turn off orphan rules" is really drastic to solve them.
I also don't personally see how this gets past experimentation to a point where it can interact with crates.io.  The RFC says it's leaving crates.io for the future, but it's hard for me to see this as a general solution to ecosystem problems because I don't see that future working out.  You're right that what replaces the orphan rules in that future could be deferred indefinitely, but without some idea of what that looks like I don't see how that's even a possible future; I'm not convinced the orphan rules can be relaxed, and convincing me that they could be would go a long way toward me seeing this as something general.

@jsgf This came up in today's @rust-lang/lang meeting. We have had some discussions in the past about a more general solution for orphan instances in the ecosystem (beyond just workspaces), and the requirements and tradeoffs of doing so. If @rust-lang/lang were able to provide some design constraints/requirements for this, would you be interested in working on the more general lang-level solution? (If so, we could start some further design conversations on this.)

@joshtriplett Yes, definitely. I'd really like to find a path forward here, but I also know it's important to get right.

@jsgf

Right, but this does not propose disabling them; this RFC requires precisely the same coherence invariants that the current orphan rules do. All it proposes is implementing them with a bit more flexibility.

I don't agree with that framing of the RFC. The RFC allows any crate to essentially "opt out" of the orphan rules for a specific dependency, and as a downstream consumer of the crate I have no control over this.
For example:

Bob starts writing his first crate, and tries to implement Serialize for some third party type Foo.
Bob gets a confusing error about coherence rules, and decides to google it.
He finds out that simply adding impl = True to his serde dependency will make the error go away.
He publishes his crate, happy that everything is working.
Some time later, the Foo gets a Serialize implementation.
Everything that transitively depends on Bob's crate is now broken!

If Bob had instead made a newtype wrapper, then the code might be slightly more complex, but there would be no risk of breakage down the line.
I think there is an argument to be had about whether the orphan rules should exist (it's certainly a trade-off). However, having the orphan rules but also having an opt-out with no apparant downside to the opt-out is the worst of both worlds, since you get both the confusing error messages, and a high risk of future breakage.
Personally I think the orphan rules are better than no orphan rules, but that there is still room for improvement.
First: making it easier for maintainers to structure crates how they want. This can be solved with a similar approach to this RFC but in reverse: the upstream crate can "nominate" downstream crates who are allowed to add implementations - this way you add flexibility without introducing the possibility for breakage.
Second: a mechanism for "fallback implementations". Fallback implementations can be provided for any type/trait pair but will only be used as a last resort if a "real" implementation is not found. If multiple fallback implementations exist, then the "root crate" can disambiguate: failure to do so is a compiler error. This mechanism should still be considered a "last resort" though. Obeying the coherenece rules is better for everyone involved if at all possible.

@jsgf
The problem, as I see it, is that you're not really giving a lot of motivation for the local solution being good enough to add something kinda hacky to the language.  I'm not saying you don't have valid concerns, merely that they're not yet at the level of "and we modified rust to address them".  If build times are an issue, there are lots of other things that can be done today which will address a lot of it, for example getting sccache and pointing it at redis or s3 in your CI provider.  Crates like prost provide ways to inject derive attributes, and while it's not necessarily ideal to go make trait impls live next to some protos, it does work out fine if you do so.
In my opinion, the crates.io/ecosystem solution is what moves this from hacky to cohesive.  Otherwise, it's hard for me to see this as anything but a build time workaround or something like that.  Locally, you have full control of what's where and I don't think I know of a case where this can't be made to work out.  Can you more clearly articulate the thing you can't do at all without this proposal?
@Diggsey
They're not proposing crates.io/publishing support right now.
I kinda like your solution re: fallback implementations, though I find myself asking how often they would be used in practice.  It sounds like specialization however.  Isn't what you're saying isomorphic to adding a rule/attribute to specialization that says "this trait is of the lowest priority"?

They're not proposing crates.io/publishing support right now.

True, but that is the natural progression if this RFC goes forward, and without the ability to publish such crates several of the main motivations for the RFC are not solved.

I find myself asking how often they would be used in practice

Ideally as infrequently as possible...

Isn't what you're saying isomorphic to adding a rule/attribute to specialization that says "this trait is of the lowest priority"?

As it stands, specialization does not relax the orphan rules, so you still can't define implementations outside of the crate defining the type or trait.

@Diggsey

He finds out that simply adding impl = True to his serde dependency will make the error go away.
He publishes his crate, happy that everything is working.

My proposal here is that 1) impl = True will only work on dependencies within the same workspace, and 2) publishing crates with impl = True to crates.io is not allowed.
I don't have a solution to the general third-party implementation problem which would for crates.io, for all the reasons that you're concerned about. I'm putting this forward as a mechanism which is locally useful, that could be part of a more complete solution. But it also enables a bunch of interesting possibilities even if it's never directly exposed to users, such as splitting std or auto-crate-splitting.
@ahicks92

If build times are an issue, there are lots of other things that can be done today which will address a lot of it, for example getting sccache and pointing it at redis or s3 in your CI provider.

Yeah, I'm very aware of those solutions. My principle build system is Buck2 which aggressively distributes and caches, and does a very good job of extracting as much concurrency from a build as is possible to extract with the current model. It's just not enough. And more generally it's just very frustrating having a hard language-imposed bound on how I can factor functionality to crates.

Crates like prost provide ways to inject derive attributes, and while it's not necessarily ideal to go make trait impls live next to some protos, it does work out fine if you do so.

Having a separate ad-hoc mechanism for every code generator is a specific example of this.
Fundamentally, I see this proposal as being a bit like specialization: its in the language, but not generally available without enabling a feature. It can be used in, say, libstd with a particular awareness of the problems and limitations, and maybe eventually it will be a generally available feature once there's a coherent story around how it can be made to work in the large.

@jsgf
There's a difference between "I can do this but it's awkward, so let's try to start an initiative" and "I can't do this at all".  In the former category I'm not happy with just saying no to crates.io and so, to me, it's important to explain how such an experimental initiative ends.  Without that, then the initiative has no clear scope and will just go on forever.  And it seems that the latter is not true: you can always get it working, even if it's ad-hoc.  Showing that certain important things are impossible makes your case much stronger.
Perhaps I should clarify, however, that I have no decision-making power either way, and am speaking only from a general project planning perspective; if Rust folks are happy with an unscoped experimental initiative for this, more power to them.

It's maybe helpful if people cc https://github.com/rust-lang/rust/issues/29635 whenever they'd consider using #[fundamental], but do not do so for stability.  This might help someone in future figure out in what form they could stabilize #[fundamental] (or if doing so is a good idea).

Maybe an alternative is to make it easier to create a wrapper type, which is how the orphan rule is usually worked around:
#[wrapper]
struct Foo(crate1::Bar);

impl crate2::Baz for Foo { /* ... */ }

#[wrapper] would:

Work only on structs with a single field
Create the same layout as #[repr(transparent)]
Derive AsRef, RefMut, Deref, DerefMut, From/Into to the inner type
Give the outer type whatever traits the inner type has (Clone, Debug, etc)

This could be generally helpful as well.

@tgross35 Yeah I should add a wrapper types discussion to the "alternatives" section. I think the main problem is getting all the wrappers confused with each other and the wrapped type. I guess we'd end up with lots of signatures of the form impl Into<WrappedType> or impl AsRef<WrappedType>.

Give the outer type whatever traits the inner type has (Clone, Debug, etc)

Do you mean just libstd traits, or all traits? What would this look like for serde, for example?

make it easier to create a wrapper type

The keyword there is delegation. For example, https://github.com/rust-lang/rfcs/pull/2393 and https://github.com/rust-lang/rfcs/pull/1406.

Give the outer type whatever traits the inner type has (Clone, Debug, etc)

Do you mean just libstd traits, or all traits? What would this look like for serde, for example?

Not a very refined idea :) I was initially thinking all traits but know that would come with complications. However...

The keyword there is delegation. For example, #2393 and #1406.

It seems like this idea has already been floating around

@ahicks92

There's a difference between "I can do this but it's awkward, so let's try to start an initiative" and "I can't do this at all".

Well take this for example. In C++, when I want to depend on another module I do #include <othermodule.h>, which gives me all that modules interface definitions, so I can then compile mymodule.o. This parallelizes perfectly - if I have 1000 modules, I can kick off their compilation in parallel, with no regard to whatever dependency relationship they may have. The only blocker is that the final link step needs to wait for the 1000 compilations to complete.
In addition to this, it's straightforward to factor the code for a given class's member functions into as many compilation units as one likes, either for code organization purposes, build speed tuning and/or whatever other criteria one desires.
In Rust, the max compilation parallelism is limited by the shape of the dependency graph - at best the amount of parallelism is the widest part of the dependency graph, which often isn't all that wide. But worse, there are often bottleneck dependencies, which depend on lots of things, and are depended on by lots of things - if they need to be rebuilt then everything comes to a standstill while that happens.
Rustc has a few techniques to mitigate this:

pipelined builds, to generate the metadata (equiv to a header file in the C++ case), which ideally gets the dependents building faster
parallelize codegen in llvm, which can reduce the path for linking
incremental builds which help with iterative builds
caching, which can often avoid rebuilding
(future) more internal parallelization within rustc

These all help to some degree. In many cases they help enough that one might not consider this to be a big issue.
But at a larger scale they are literally orders of magnitude away from being able to achieve the same build throughput that's possible with C++. Caching aside, none of those techniques - individually or collectively - are going to come anywhere close, because they're fundamentally limited by the structure of the dependency graph.
Now obviously C++ has a bunch of disadvantages here - the primary one being that you need to manually keep your headers and your implementations in sync, it's easy to cause UB by violating the One Definition Rule, etc - we absolutely do not want to let Rust be subject to any of these problems.
So what I'd like to be able to do is define "interface spec" crates, which just have a bunch of type/struct/trait definitions in them, and ideally no implementations at all. Any crate which needs those definitions need only depend on this crate. Since it does not contain code, its effectively equivalent to a .rmeta. The implementations are all split into separate crates in any organization that makes sense to the developer. Consumers can depend on any subset of those implementation crates that they actually need, and so take on only the build cost and transitive dependency cost of the functionality they need.
This structure not only inherently improves build performance, it also enhances all the other speedup techniques that rustc employs, mostly by letting them all operate on a finer grain:

pipelining smaller crates lowers the latency to kick off dependant builds
more llvm parallelization across multiple crates rather than within just one
easier to identify incrementality within smaller implementation crates
caching at the crate level is more effective, because the downstream effects are more contained

This last point is particularly important - changing a type definition is clearly going to cause a lot of downstream fallout to adjust. But changing the implementation of a seldom used function can be limited to that crate and its dependencies, even if the rest of the associated functionality is widely used.
(Note here I'm talking about a more general form of this RFC that also applies to intrinsic implementations as well as trait implementations. I included that in earlier drafts but it raised enough secondary complexity that it can be deferred to later.)
So, no, this change isn't essential in the sense that there's some lost expressiveness at the language level. But at some point, the effect of being able to improve the practical experience of using Rust counts for something - if we went the other way, and removed the notion of separate compilation entirely it would certainly simplify things, and open up a lot of opportunities for internal parallelism and incrementality and so on. And similarly incremental building is a fairly brittle, somewhat ad-hoc hack to improve inner loop compilation speed, which is nevertheless probably worthwhile.

@jsgf
But why is the solution to this problem "add a hack to the orphan rules"?  One could, for example, propose something more akin to the C++ model where (via some mechanism--idk what) rustc can process multiple files at once.  For example, perhaps we introduce Rust compiler-generated "headers" which can be generated cheaply and then allow the rest of rustc to run per-file.  Or perhaps you could split off the LLVM IR somehow and distribute that to multiple boxes instead.  I don't have an easy proposal here, but this RFC feels like an easy proposal and not a good proposal, and that's why I keep asking (though probably in an ambiguous way) for a non-build-time reason to do it.
A few things I think are worth noting:

In many ways this is the "I'm lazy" button: people will get frustrated at orphan rules and just use it because it's there.  Few people are going to only use it for build times.  We can expect new Rust coders to find it and use it without fully understanding the implications because it makes errors go away.
If you use this liberally in a large codebase at a company large enough for whom build times are a problem, then it invisibly adds tech debt that both prevents open sourcing or ever splitting the giant death repo with all the Rust code in it (the latter splits workspaces, too).

Put another way, in C++ I get to play with include paths and can split things up to give to different teams or etc. any way I want.  You can in Rust.  You can't in Rust once you use this flag.

This will require changes in rust-analyzer and whatever other tools might exist in the ecosystem, not just rustc itself.

It's not like a giant drop in code quality but using this is still generally a drop in code quality especially given all the ways you can use it wrong/too much in a given codebase.
I think it should be considered a very big open question whether or not this even fixes the build time problem as well.  What evidence exists that this is a large gain?  Looking through the RFC I don't see that addressed.  If it was (say) a 50% gain for lots of common codebases, I'd be more for this.  But everyone will probably be very sad if this is added and 6 months down the line it turns out it's only a 10% gain or something, but now we're stuck with it.  Also, what evidence is there that this time next year there won't have been some big initiative for compile times that renders this use obsolete?  Even if neither of those happens, this feels like a limited-time feature that "expires" at least as regards the original motivation whenever Rust fixes build times as a whole.

@ahicks92
I'm focusing on local use simply because I agree that it could cause deep problems at scale. I think the tooling around it should at the very least encourage, and probably enforce local use, in order to keep refactoring and so on tractable. That's one of the reasons I'm hesitant to tie this to a "do this at crates.io scale" because I'm doubtful that there's a way to do this - I think the current orphan rule works pretty well ecosystem wide, on balance.

this is the "I'm lazy" button

This is the "everyone will use unsafe to avoid the borrow checker" argument. I don't think it follows.

If you use this liberally in a large codebase at a company large enough for whom build times are a problem

Right, so don't do that. There's lots of ways to influence how a feature gets used to make sure it gets used in the ways one would like, and avoid bad patterns. There's a reason I keep saying "small scale", "limited", "local scope", "opt in", precisely because this is something that should be used carefully, and all the tooling should push users in that direction. But also because it hasn't been implemented yet, so it will take some practical experience to really understand the implications.
I understand your concerns, I really do. I'd also push back if this were "let's stabilize this tomorrow". I posted this because I want feedback on the technical aspects, to see if there's a fundamental soundness problem with the proposal, or something that makes it surprisingly hard to implement within current rustc. If it passes that bar, and we get to prototyping it, and merging it, it ends up as one of the many experiments currently live within rustc. Either we'll find value for it, in which case it stays (perhaps perma-unstable) or we drop it. I just don't think we're at the "this is an inherently flawed idea that is morally wrong" phase of the conversation yet.

I think it should be considered a very big open question whether or not this even fixes the build time problem as well. What evidence exists that this is a large gain? Looking through the RFC I don't see that addressed.

Yeah, that will need a working prototype to answer. Or maybe a local hack to just disable the orphan rule altogether so we can try it out, but that's later.
And while build perf isn't the only consideration for this feature, there's examples like this where useful functionality in a common crate is dropped in service of build time. Something like this RFC would make it much easier to have opt-in functionality.

This will require changes in rust-analyzer and whatever other tools

Sure.

This is the "everyone will use unsafe to avoid the borrow checker" argument. I don't think it follows.

Unsafe doesn't disable the borrow checker though. If it did, then people using unsafe incorrectly would be a much bigger issue than it is.

It's not the "everyone will use unsafe" argument because unsafe is hard to use even if you're doing it right, and the people who find Rust come to Rust to avoid unsafe.  Someone can't easily decide to use unsafe because using unsafe is hard.  Additionally using unsafe is local: it might reduce the code quality of one file/module/crate but it doesn't change anything much about project organization.  All operations one might wish to perform at the crate level can still work.  Additionally it's very easy to understand why unsafe introduces bugs.  On top of all of that, it's trivially easy to explain why unsafe is necessary and why Rust as a language would be impossible without it.
This flag takes an error that is hard to explain to new Rust users which exists for good-yet-esoteric reasons and silently makes it go away.  It doesn't introduce bugs today.  It's not syntactic in the code; everyone who comes after will "use" it without knowing that it was turned on.  I would agree that it's the "everyone will use unsafe" argument if it wasn't entirely invisible and/or was a holistic solution to the problem.
Also, that said, for something which appears to be mostly about build times, I think an RFC without some sort of prototype/proof that it will help isn't a great idea.  A proper implementation is likely not a small change in the compiler even though it seems like it should be, and (for example) probably means modifying the outputted crate metadata.  Perhaps there is a hacky way to prototype it instead.
We have one of these large monorepos at work which takes 12 minutes or so to build from scratch in CI, and we wouldn't benefit from this RFC for build times because:

This assumes heavy use of traits.  Only some codebases need heavy use of traits.
This assumes a bottleneck in the dependency graph in your own code which is so problematic that this RFC can fix it. In our case we do microservices, and so there's one bottleneck at the bottom and then like 7 or 8 services that build fully in parallel.
This assumes you're doing cargo build at the workspace root.  You probably should be, but if you don't the build semantics change.
Even assuming you hit all of those, this assumes you don't make firm choices like "only support Python 3" or "always use Postgres" or etc. and that the less-firm choice where everyone does what they want would require significant orphan rule breaking.

failing that, this assumes that one uses a lot of generated code in a way that requires significant orphan rule breaking, or some other code structure along those lines that makes orphan rules the problem.

This assumes your org decided to use a monorepo rather than Cargo's support for git dependencies in the first place (we're a monorepo but the point is important to point out).
This assumes that your bottleneck isn't the final linking step (ours is, for incremental builds)
This assumes you're not using lots of dependencies.  Even if you've got a large codebase locally it's entirely possible most of the time goes to dependencies especially if you e.g. bring in a web crate, some db crates, etc.
And, as regards CI specifically, this assumes your tests aren't the bottleneck.

Which is why I'm somewhat skeptical.  It requires a lot of assumptions before we can take it as a given that build times go down.

I would propose a very different approach that could solve the basic requirements.
The main idea is to allow overriding locally to the module the implementation of the trait/type by selecting explicitly alternate implementation.
/// Module in pkg3
pub mod my_mod {
use pkg1::my_trait
use pkg2::my_type
// This implementation override ONLY LOCALLY to this module the implementation in my_trait or in my_type if it exist
// This impl block has no effect outside this module and it cannot be referenced by any other module.
impl my_trait for my_type {
....
}
....
}

It should be possible to make public the implementation to allow usage in different modules/packages using pub keyword
/// Module in pkg3
pub mod my_mod {
use pkg1::my_trait
use pkg2::my_type
// This implementation override ONLY LOCALLY to this module the implementation in my_trait or in my_type if it exist
// Now it can be used in other modules
pub impl my_trait for my_type {
....
}
....
}

If a developer would like to previous implementation it has to declared explicitly
/// Module in pkg4
mod another_mod {
// Override the implementation in my_trait or my_type and bring automatically in scope  pkg1::my_trait and pkg2::my_type
use pkg3::impl(pkg1::my_trait,pkg2::my_type)

// Equivalent code
use pkg1::my_trait
use pkg2::my_type
use pkg3::impl(my_trait,my_type)

}

I see the following benefits:

adding other implementation is not breaking any code due to the explicit usage inside the module.
locally explicit declaration and dependencies
allow usage of different implementation in the same crate
backward compatible.

I think "local impls" should be done by delegation, but..
There is a large design space for delegation, so someone should explore this space.  In particular you've this flavor:
All traits of ForeignType work on LocalType, and even perceive LocalType as ForeignType, but new traits can be defined on LocalType too, and they perceive LocalType as being a different type from ForeignType.
type LocalType = delegate ForeignType;

For the very specific goal of optimizing build times of code which can be theoretically built in parallel after certain shared trait/type definitions are built first... I feel like crates and orphan rules are a red herring, and we should be asking if the compiler can be told that information directly. The same way we use #[inline] because that manual annotation is often just more practical than making the compiler spend time guessing what's more efficient.
As a pure strawman, I'm imagining a #[build_this_module_first] attribute, and maybe a Cargo.toml flag like parallel_modules where for build purposes only cargo tries to draw a module dependency graph within the crate, and parallelize its build of that crate accordingly. Is that completely ridiculous? How far off is that from rustc's current parallelization logic of crates/codegen units/etc?

Very, very weird case for this that came up when discussing the situation where ToOwned is currently defined in alloc, but technically could be defined in core. This comment is an absolute mess but hopefully it contains some insight, even though it may actually be impractical.
It might be interesting to loosen this to "deferred impls" where the crate explicitly states that the implementation is "deferred" to some dependency. This both strengthens and weakens the constraints, by allowing you to place restrictions on arbitrary types while requiring you to explicitly enumerate them.
Ultimately, the way this would be handled on the compiler side is by using either negative impls or reserved impls in the crate that can then be overridden in the explicitly allowed crate with a proper implementation.
Of course, the main issue here is that it defeats the original purpose: depending on crates which have these types. So, it would require some shenanigans where cargo lets you reference this crate from the same workspace for the sake of listing the allowed impls, but doesn't actually compile that code unless the dependency is visible anywhere in the tree. Something along the lines of a special, automatically enabled crate feature.

What if, at least, developers could entirely disable the orphan rules for crates that will never be a dependency to another?
The idea: Orphan rules should only be enforced on crates published on crates.io
There's no reason why the "end-stream" user should have to abide to such rules.


Supporting uploading images/attachments to messages in chat

A lot of people have requested the ability to send screenshots in particular. I guess a workaround we can recommend in the meantime is to just upload images to certain websites and share the links, but we should definitely support uploading images/attachments to messages at some point.

What is the difference to #130? :thinking:
PS: Thank you so much for papercups! :pray:

good point, I'll remove the duplicate 👍

Phoenix now supports file upload natively in LiveView!: https://www.phoenixframework.org/blog/phoenix-live-view-upload-deep-dive


Cannot load

Whenever trying to load the new model I am getting:
--> 764     magic_number = pickle_module.load(f, **pickle_load_args)
    765     if magic_number != MAGIC_NUMBER:
    766         raise RuntimeError("Invalid magic number; corrupt file?")

UnpicklingError: invalid load key, '<'.

Been trying with either python 3.7 and newer versions, and different pytorch versions.

sorry could you please provide more complete error log info?
On Thu, Sep 8, 2022 at 7:08 AM aviadmx @.***> wrote:

Whenever trying to load the new model I am getting:
--> 764     magic_number = pickle_module.load(f, **pickle_load_args)
765     if magic_number != MAGIC_NUMBER:
766         raise RuntimeError("Invalid magic number; corrupt file?")
UnpicklingError: invalid load key, '<'.
Been trying with either python 3.7 and newer versions, and different
pytorch versions.
—
Reply to this email directly, view it on GitHub
https://github.com/xuebinqin/DIS/issues/41, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORKBA3MOKKB2UL35YMDV5HXPNANCNFSM6AAAAAAQHZJJYA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Xuebin Qin
PhD
Department of Computing Science
University of Alberta, Edmonton, AB, Canada
Homepage: https://xuebinqin.github.io/


xlsx doesn't support dd/mm/yyyy date format as source data

Hello, my source table has field with dd/mm/yyyy as date format and when exporting to xlsx the datatype of the filed is "string" and not "date" (this means problem when sorting that column).
If I use mm/dd/yyyy in my field the datatype is correctly recognized as "date" but not when the source field has dd/mm/yyyy content.
I would expect that the date format dd/mm/yyyy is recognized as a correct date as is.
Version 5.2.0

As today, the only plugin which support dates in dd/mm/yyyy is the hhurz/tableExport.jquery.plugin


chore: sync with building base

Sync building base from https://github.com/kubebb/building-base

@CodiumAI-Agent


[Feature]Navbar added

Related Issue
resolved  issue #2
added a navbar
Proposed Changes
-first design of Navbar added.
Screenshots

@PankajKumar1947 You're supposed to have the issue assigned to yourself first. I cannot merge this as others are working on it already.

@PankajKumar1947 Please make sure you're getting an issue assigned first before you start working on anything or it will be a painful waste of time.


Use pre-build builds for equistore and rascaline

Using builds from https://luthaf.fr/nightly-wheels/ for the speading up the builds and allowing easier downstream usage. The makes the infrastructure code also much cleaner.
The env variable PIP_EXTRA_INDEX_URL=https://luthaf.fr/nightly-wheels/ for RTD is set in their web interface because setting them in yml file is for whatever reasons not working...

:books: Documentation preview :books:: https://equisolve--53.org.readthedocs.build/en/53/

Agreeing on general nightly builds would be nice. I don't if can manage to keep up with the changes in all our substream packages....

In the cookbook we already rely on the latest nightly build so maybe we can also here...

In the cookbook I also did not like this decision so much, but since we have many dependencies I wanted to keep the building time a low as possible by using prebuilts. When we have a metatensor release with prebuilts, I am thinking to change it to the latest release of metatensor.


new rule: mocha-done-error-handling

MochaDone will crash PhanomJS - Very Important! If you do any asynchronous work (like in a setTimeout) then any Mocha failure will cause PhantomJS to crash with the timeout error. You must clear MochaDone on all code paths to fix this! For example, here is some typical MochaDone code:
// THIS CODE IS BROKEN
it('should …', (done: MochaDone): void => {
    setTimeout((): void => {
        // if expect fails then PhantomJS crashes!!!
        expect(something).to.equal(someOtherValue);
        done();
    });
});

Here is how you must write the code correctly using a try catch block:
it('should …', (done: MochaDone): void => {
    setTimeout((): void => {
        try {
            expect(something).to.equal(someOtherValue);
            done();
        } catch (e) {
            done(e)
        }
    });
});

@HamletDRC is this still applicable? I don't remember having this error writing tests with Mocha+PhantomJS in late 2017.


Update 'use my current location' to use proj4js + DC reverseGeocode endpoint

alternatively we could use this http://citizenatlas.dc.gov/usng/getusng.asmx?op=MD_LLtoSPCS to go from lat/lng to Maryland State Plane (instead of the JS-based solution)

Closing this as won't fix for now as we are redirecting new development to a more slimmed down version of the app.


OPTIONS method not reaching the controller

I am trying to implement the OPTIONS method for CORS, but it isn't executing the options method defined in the swagger definition and which is exported/associated in the controller. I put a breakpoint in the swagger-node-runner/node_modules/cores/lib/index.js file in the middlewareWrapper function and manually set the preflightContinue property to true. This let the request through to the hello_world.js controller's getOptions function call. There doesn't seem to be a way to configure this in the project settings, or at least I cannot find any documentation on this topic.
Here is the swagger I've modified in the hello project:
swagger: "2.0"
info:
  version: "0.0.1"
  title: Hello World App
# during dev, should point to your local machine
host: localhost:10010
# basePath prefixes all resource paths
basePath: /
#
schemes:
  # tip: remove http to make production-grade
  - http
  - https
# format of bodies a client can send (Content-Type)
consumes:
  - application/json
# format of the responses to the client (Accepts)
produces:
  - application/json
paths:
  /hello:
    # binds a127 app logic to a route
    x-swagger-router-controller: hello_world
    get:
      description: Returns 'Hello' to the caller
      # used as the method name of the controller
      operationId: hello
      parameters:
        - name: name
          in: query
          description: The name of the person to whom to say hello
          required: false
          type: string
      responses:
        "200":
          description: Success
          schema:
            # a pointer to a definition
            $ref: "#/definitions/HelloWorldResponse"
        # responses may fall through to errors
        default:
          description: Error
          schema:
            $ref: "#/definitions/ErrorResponse"
    options:
      description: Return supported methods of this path
      operationId: getOptions
      responses:
        "204":
          description: Success
  /swagger:
    x-swagger-pipe: swagger_raw
# complex objects have schema definitions
definitions:
  HelloWorldResponse:
    required:
      - message
    properties:
      message:
        type: string
  ErrorResponse:
    required:
      - message
    properties:
      message:
        type: string

This is the request I'm making after starting the project:
curl -i -X OPTIONS http://localhost:10010/hello

I guess I should also provide the controller code as well:
/*
 'use strict' is not required but helpful for turning syntactical errors into true errors in the program flow
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
*/

/*
 Modules make it possible to import JavaScript files into your application.  Modules are imported
 using 'require' statements that give you a reference to the module.

  It is a good idea to list the modules that your application depends on in the package.json in the project root
 */
var util = require('util');

/*
 Once you 'require' a module you can reference the things that it exports.  These are defined in module.exports.

 For a controller in a127 (which this is) you should export the functions referenced in your Swagger document by name.

 Either:
  - The HTTP Verb of the corresponding operation (get, put, post, delete, etc)
  - Or the operationId associated with the operation in your Swagger document

  In the starter/skeleton project the 'get' operation on the '/hello' path has an operationId named 'hello'.  Here,
  we specify that in the exports of this module that 'hello' maps to the function named 'hello'
 */
module.exports = {
  hello: hello,
  getOptions: getOptions
};

/*
  Functions in a127 controllers used for operations should take two parameters:

  Param 1: a handle to the request object
  Param 2: a handle to the response object
 */
function hello(req, res) {
  // variables defined in the Swagger document can be referenced using req.swagger.params.{parameter_name}
  var name = req.swagger.params.name.value || 'stranger';
  var hello = util.format('Hello, %s!', name);

  // this sends back a JSON response which is a single string
  res.json({"message": hello});
}
/*
  Functions in a127 controllers used for operations should take two parameters:

  Param 1: a handle to the request object
  Param 2: a handle to the response object
 */
function getOptions(req, res) {
  res.set({
    "Allow": "GET, OPTIONS"
  });
  res.end();
}

@whitlockjc is this an issue or configuration inside swagger-tools?

swagger-tools is uninvolved here.  swagger-node uses a cors module and probably needs a way to allow you to configure it yourself.  You should be able to wire up your own cors middleware prior to swagger-node's middleware and then just not use the cors middleware in swagger-node.

Thanks guys for comments on this issue. The preflightContinue property seems to be where the allowance to the controller is taking place. I'm not sure the best way to expose this up the chain. Maybe under a swagger_controllers['cors'].preFlightContinue properoty in the config yaml file.

swagger-node uses a cors module and probably needs a way to allow you to configure it yourself.

Seems like this is what makes sense - what doesn't is why it's not configurable.


Bug fixes: Gateway TCP routing and timeout

Do not set destination IP list in gateway TCP proxy.
Fixes https://github.com/istio/istio/issues/5964
Set timeout by default (inbound/outbound) to 0s (i.e. disabled) unless
overridden by the user. Fixes bug found by user in mailing list.
Signed-off-by: Shriram Rajagopalan<EMAIL_ADDRESS>

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: rshriram
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [rshriram]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rshriram: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
9afab5c3b8febd4206361940ddc1f4d8b35db271
link
/test e2e-bookInfo

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rshriram: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests.sh
9afab5c3b8febd4206361940ddc1f4d8b35db271
link
/test e2e-bookInfo

prow/istio-pilot-e2e.sh
9afab5c3b8febd4206361940ddc1f4d8b35db271
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


TypeError: Invalid Version: istanbul-lib-instrument-1.8.0

Expected Behavior
"nyc": "^11.2.1",

Coverage Report after unit tests execution
Observed Behavior
`> cross-env NODE_ENV=test nyc mocha-webpack
/Users/aaaa/Projects/WebMobile/AppShells/boilerplate-react-redux-webpack/node_modules/nyc/node_modules/semver/semver.js:293
throw new TypeError('Invalid Version: ' + version);
^
TypeError: Invalid Version: https://registry.npmjs.org/istanbul-lib-instrument/-/istanbul-lib-instrument-1.8.0.tgz
at new SemVer (/Users/aaaa/Projects/WebMobile/AppShells/boilerplate-react-redux-webpack/node_modules/nyc/node_modules/semver/semver.js:293:11)
at major (/Users/aaaa/Projects/WebMobile/AppShells/boilerplate-react-redux-webpack/node_modules/nyc/node_modules/semver/semver.js:551:10)
at Object. (/Users/aaaa/Projects/WebMobile/AppShells/boilerplate-react-redux-webpack/node_modules/nyc/node_modules/istanbul-lib-instrument/dist/constants.js:19:117)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)`
Bonus Points! Code (or Repository) that Reproduces Issue
Running npm test
package.json
 "test": "cross-env NODE_ENV=test nyc mocha-webpack",
.nycrc
{    "check-coverage":true,    "instrument":false,    "sourceMap":false,    "reporter":[       "lcov",       "text",       "text-summary"    ],    "require":[       "babel-register"    ],    "include":[       "src/**/*.js"    ],    "exclude":[       "src/routes.js"    ],    "all":false,    "watermarks":{       "lines":[          80,          95       ],       "functions":[          80,          95       ],       "branches":[          80,          95       ],       "statements":[          80,          95       ]    } }
Forensic Information
Operating System: OSX 10.11.6
Environment Information:
https://gist.github.com/sesteva/a069468dd28eb0ee2d244264caaed46d

This was actually a problem with package-lock!

Thanks! I had the same issue, deleted the package-lock and node_modules, then did npm install and worked great


Add a (linked) load test for issue 4387

Re: PR #4404 and issue #4387.

/botio test

/botio makeref

Another good one, thank you!


Prevent NPEs when closing IOStreams and reading a list

There are several locations where a failed stream creation could be masked by an NPE when the tools attempt to close the stream in a finally block.
My contributions are licensed under the Apache 2.0 License as required for contributions to this project

Applied, pending sync.


Command not found - nofity

Hello there,
I have to go installed on my system, I've installed notify with go install -v github.com/projectdiscovery/notify/cmd/notify@latest but as soon as I try to type notify I got Command 'notify' not found, but can be installed with: both with bash and zsh. I am not a go developer but I don't understand what I did wrong
Thanks.
Cheers,
Fra

add ~/go/bin to your $PATH


docs: Update link to the new CNCF Slack channel

Signed-off-by: terrytangyuan<EMAIL_ADDRESS>Checklist:

[x] My organization is added to USERS.md.

This is more correct, I'm merging.


fix button loading attribute error

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Include the product price in the return of the order API

Returns the price of the product in the product array of the API response, as well as the product name and quantity. With the price and quantity it is possible to calculate the total price of the order.

okay, but also it will require it in the post method.

That is okay for me.


Formatting issues in MongoDB connector reference document

Description
Formatting issues can be observed in MongoDB connector reference document[1]
[1] - https://mi.docs.wso2.com/en/latest/reference/connectors/mongodb-connector/mongodb-connector-config/#operations

This issue is tracked in https://github.com/wso2/docs-mi/issues/51 and the fixes are already sent in https://github.com/wso2/docs-mi/pull/929. Therefore closing this issue.


Components exported with "export * from ..." are shown in error in the drawer

Hi, first off thanks for maintaining this really useful extension. I came accross this behaviour :
If your root file imports a child component from an index file that does export * from ..., then the child component appears red in the tree view and you can't expand it.
You can reproduce the issue with the following project :
Folder structure :
App.tsx
home/
├─ index.ts
├─ Home.tsx

Home.tsx :
export const Home = () => (<></>);

index.ts :
export * from './Home';

App.tsx :
import { Home } from './home';
export const App = () => (<Home />);

With this project if you select App.tsx as the root file in sapling then Home appears red and you can't expand it.
I get the issue on the latest version of vscode on Windows.
Thanks

Hi @aymericfraise,
Thanks for creating this issue - we are aware that Sapling is not currently capable of handling 'index imports' as you demonstrate here. It is a feature we hope to add in the future, will post a comment here if we release a new version with this capability.
Cheers!

My project also uses index imports. Sapling seems very cool, but I can't really use it due to this. Is this something you would accept a contribution for @PLCoster ? If so, any tips on how to get started on something like this?


Fail to expand the local Queues node that contains Azure AD attached queues with associated account removed

Storage Explorer Version: 1.14.0-dev
Build: 20200523.2
Branch: master
Platform/OS: Windows 10/ Linux Ubuntu 16.04/ macOS Mojave
Architecture: ia32/x64
Regression From: Not a regression
Steps to reproduce:

Expand one storage account -> Queues.
Create one queue -> Attach this queue via Azure Active Directory (Azure AD).
Remove the account associated with the Azure AD attached queue.
Expand Local & Attached -> Storage Accounts -> Attached Containers -> Queues.
Check the result.

Expect Experience:
Succeed to expand the Queues node.
Actual Experience:
Fail to expand the Queues node and pop up the below error dialog.

@v-xianya This sounds like expected behavior, although the message isn't helpful. Two things:

Can you be more specific about "remove the account"? Do you mean that you signed out of the Azure account associated with the attached queue?
Does this repro for blob containers as well?

@craxal

Yes, 'Remove the account' means to sign out the Azure account associated with the attached queue. (Go to ACCOUNT MANAGEMENT Page -> Remove the associated account)
This issue doesn't reproduce for blob containers.
Screentshot:


[BACKLOG-1793] Customizing Heartbeat Thread creation to ensure clean shu...

...tdown
- @ https://github.com/pentaho-nbaker/pentaho-kettle/commit/8c4abbc5f82eb9426d781bc33632d685d237d113

@pentaho-nbaker, @rmansoor please review


Feature naming conventions for positional information

Feature names have been a bit ad-hoc up to this point and we have acquired some inconsistencies.

Format
Time-aligned
Non-time-aligned

ELAN
alignment:startime, alignment:endtime
alignment:index

CoNLL-U
N/A
meta:index for words, nothing for sentences

FLExText
N/A?
meta:index

Macula
N/A
None

SFM
N/A
meta:index on words and morphemes, nothing on sentences

Text-Fabric
N/A
None

FLEx does support time alignment, but only if it's been imported from ELAN. In other words, you can't input time alignment via FLEx's UI, but its data model does support it, and the fields BeginTimeOffset and EndTimeOffset exist in .flextext files that are exported from FLEx.
Flex Data Model: https://github.com/sillsdev/liblcm/blob/master/src/SIL.LCModel/MasterLCModel.xml


[Question] Sweep thresholds, how do they work?

:question: Question
Hi I see that the package does some automatic sweeps to detect the best thresholds on the validation set. Can you explain briefly the contents of these files?
sweep_ensemble_iou.json
sweep_model_iou.json
sweep_model_nms_fn.json
sweep_model_score_thresh.json
sweep_remove_small_boxes.json
Do you think one could use those thresholds for filtering boxes inferred on an unseen test set?

Dear @dalbis ,
those jsons are intended for debug purposes and just show what is happening in the background (i.e. which values were tried and which results were computed). The inferred hyperparameters will automatically be used for inference on unseen data.
Inference Pipeline:

Model Min Predictions Score <- removes low scoring predictions, sweep_model_score_thresh.json
Remove Small Boxes <- remove small boxes, usually less important, sweep_remove_small_boxes.json
Model NMS <- apply models nms function, there are currently only two options in nndet, sweep_model_iou.json and sweep_model_nms_fn.json
Ensemble TTA and Model Predictions <- sweep_ensemble_iou.json, usually based on WBC

Hope this helps.
Best,
Michael

Thanks! I was not sure a thresholding on the score was done at inference time because I saw boxes with very little scores... and the first point above would suggest that they should be removed already. But perhaps it depends on the configuration?


Fix disabled breakpoint icon in disassembly view

Looks like when disabling breakpoint was implemented for the disassembly view, the disabled breakpoint icon wasn't added. This PR adds it.

@roblourens @weinand Can you please take a look at this PR?


release-notes.sh: read release highlights from tag annotation

Use git tag --annotate --cleanup=whitespace {TAG} to create the release tag. Enter the notable changes in the tag annotation. These will be prepended to the autogenerated release notes
note. the use of --cleanup=whitespace argument requires that you need to explicitly remove any lines that start with # characters if you don't want them to appear in the release notes.

I didn't fully understand at which release step the # comments need to be removed, or if that is something we should take into account when creating PRs.

You may have noticed that while writing a commit message, git will add some helper lines that are commented out using the # character. These normally aren't added to the commit message, but the --cleanup=whitespace flag disables this behavior which means you need to explicitly remove these line.
The reason I added this flag is so the we can add the # characters for the markdown formatting.


Add r2dbc-pool integration test

We don't have r2dbc-pool test.
you can refer https://github.com/r2dbc/r2dbc-mssql to implement the test

no need to add integration test since r2dbc-pool is supposed to be all impelementations of r2dbc-spi.
we might consider add integration test later but not now.


[Private CI] Clean up failures in smoke

@senelson7
Can you fix the failures in entropy_src_smoke, which causes some of the private CI failed?
https://reports.opentitan.org/hw/ip/entropy_src/dv/latest/results.html
When you have time, please also clean up the failures of CSR tests in EDN and CSRNG, which may affect CI too. But the passing rate of these tests is high, so I haven't seen those failures in CI. Thanks
@udinator as discussed, please fix the kmac_*_smoke. Thanks

@weicaiyang - PR #7642 should take care of these CI failures, thanks.

@weicaiyang - PR #7642 should take care of these CI failures, thanks.

Great, thanks @udinator

@weicaiyang Fixed in PR 7662.

The csrng fix is dependent on Mark's PR #7482

@senelson7 seems like #7662 didn't fix this CI failure in #7649
UVM_FATAL (dv_utils_pkg.sv:149) [csr_utils::csr_spinwait] timeout entropy_src_reg_block.intr_state.es_entropy_valid (addr=*) == * has 1 failures:
* Test entropy_src_smoke has 1 failures.
* 0.entropy_src_smoke.1
Line 60, in log /azp/agent/_work/1/s/scratch/HEAD/entropy_src-sim-vcs/0.entropy_src_smoke/out/run.log
            UVM_FATAL @<PHONE_NUMBER>4 ps: (dv_utils_pkg.sv:149) [csr_utils::csr_spinwait] timeout entropy_src_reg_block.intr_state.es_entropy_valid (addr=0xf9311f00) == 0x1
            UVM_INFO @<PHONE_NUMBER>4 ps: (uvm_report_server.svh:901) [UVM/REPORT/SERVER]
            --- UVM Report Summary ---

PR #7681. Moved knob set after the randomize.

And Mark has a PR draft going for the edn fails (same fix for all 3 blocks actually)


DependencyResolutionException: An exception was thrown while activating OfficeRibbonXEditor.ViewModels.Windows.MainWindowViewModel.

Describe the bug
Autofac.Core.DependencyResolutionException: An exception was thrown while activating OfficeRibbonXEditor.ViewModels.Windows.MainWindowViewModel. ---> Autofac.Core.DependencyResolutionException: An exception was thrown while invoking the constructor 'Void .ctor(OfficeRibbonXEditor.Interfaces.IMessageBoxService, OfficeRibbonXEditor.Interfaces.IFileDialogService, OfficeRibbonXEditor.Interfaces.IVersionChecker, OfficeRibbonXEditor.Interfaces.IDialogProvider, OfficeRibbonXEditor.Interfaces.IUrlHelper)' on type 'MainWindowViewModel'. ---> System.Configuration.ConfigurationErrorsException: Kan het configuratiesysteem niet initialiseren ---> System.Configuration.ConfigurationErrorsException: Niet-herkende configuratiesectie userSettings (C:\Users\bstor\AppData\Local\Fernando_Andreu\OfficeRibbonXEditor.exe_Url_ms1ab4w4nmqtiaapfpju3g3yc2fmcqx5\<IP_ADDRESS>6\user.config line 3)
   bij System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   bij System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
   bij System.Configuration.ClientConfigurationSystem.OnConfigRemoved(Object sender, InternalConfigEventArgs e)
   --- Einde van intern uitzonderingsstackpad ---
   bij System.Configuration.ConfigurationManager.PrepareConfigSystem()
   bij System.Configuration.ConfigurationManager.get_AppSettings()
   bij System.Windows.FrameworkCompatibilityPreferences..cctor()
   --- Einde van intern uitzonderingsstackpad ---
   bij Autofac.Core.Activators.Reflection.ConstructorParameterBinding.Instantiate()
   bij Autofac.Core.Activators.Reflection.ReflectionActivator.ActivateInstance(IComponentContext context, IEnumerable`1 parameters)
   bij Autofac.Core.Resolving.InstanceLookup.Activate(IEnumerable`1 parameters, Object& decoratorTarget)
   --- Einde van intern uitzonderingsstackpad ---
   bij Autofac.Core.Resolving.InstanceLookup.Activate(IEnumerable`1 parameters, Object& decoratorTarget)
   bij Autofac.Core.Resolving.InstanceLookup.Execute()
   bij Autofac.Core.Resolving.ResolveOperation.GetOrCreateInstance(ISharingLifetimeScope currentOperationScope, IComponentRegistration registration, IEnumerable`1 parameters)
   bij Autofac.Core.Resolving.ResolveOperation.Execute(IComponentRegistration registration, IEnumerable`1 parameters)
   bij Autofac.ResolutionExtensions.TryResolveService(IComponentContext context, Service service, IEnumerable`1 parameters, Object& instance)
   bij Autofac.ResolutionExtensions.ResolveService(IComponentContext context, Service service, IEnumerable`1 parameters)
   bij Autofac.ResolutionExtensions.Resolve[TService](IComponentContext context, IEnumerable`1 parameters)
   bij OfficeRibbonXEditor.App.LaunchMainWindow()
   bij System.Windows.Application.<.ctor>b__1_0(Object unused)
   bij System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   bij System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

To Reproduce
Please describe the steps that lead to the unhandled exception here, including example files if relevant.
Screenshots
If applicable, add screenshots to help explain how the unhandled exception occurred.
Additional context

Version: <IP_ADDRESS>6
Runtime: .NET Framework 4.8.4341.0
Operating System: Microsoft Windows 10.0.19042

Hi Fernando,
As far as I remember it occurred after an update and it occurs at every startup of the app.
Strangely enough I can still use after closing the error screen.
I attached the user config file as requested.
As far as I can see it only contains the interface settings. Mainly the colors.
As a developer I’m interested to see what might be the cause.
BTW I also have the latest version of MS Visual Studio (VB) installed.
Perhaps there is a conflicting situation between the DLL’s.
Kind regards,
Berend Storm
@.***D74E1F.D705C030]
Telefoon:(050) 309 3568
WEB: www.sjabloonspecialist.nlhttp://www.sjabloonspecialist.nl/
Twitter: @SJABLOONSPECIAL
Facebook: SJABLOONSPECIALIST
YouTube: SJABLOONSPECIALIST
Skype: berendstorm
TeamViewer hulp op afstand
LinkedIn: Berend Storm
https://get.teamviewer.com/sjabloonspecialist
Dit e-mailbericht is uitsluitend bedoeld voor de geadresseerde(n). Wilt u direct contact met ons opnemen als deze e-mail bij vergissing bij u terecht is gekomen? Wij verzoeken u in dat geval de e-mail te vernietigen, de inhoud ervan niet te gebruiken en niet onder derden te verspreiden, omdat het bericht vertrouwelijke informatie kan bevatten.
Van: Fernando Andreu @.>
Verzonden: donderdag 20 mei 2021 18:47
Aan: fernandreu/office-ribbonx-editor @.>
CC: Berend Storm @.>; Author @.>
Onderwerp: Re: [fernandreu/office-ribbonx-editor] DependencyResolutionException: An exception was thrown while activating OfficeRibbonXEditor.ViewModels.Windows.MainWindowViewModel. (#160)
Hi BerendStorm,
Did this error occur when doing something in particular, e.g. after an upgrade from a previous version?
Also, if it exists, could you pass me the following file or paste its contents here?
C:\Users\bstor\AppData\Local\Fernando_Andreu\OfficeRibbonXEditor.exe_Url_ms1ab4w4nmqtiaapfpju3g3yc2fmcqx5\<IP_ADDRESS>6\user.config
It should not have any confidential information in theory, but rather things like the position of the window the last time you opened the tool, the editor color scheme, etc.
If the problem still persists, one workaround would be to delete all folders in C:\Users\bstor\AppData\Local\Fernando_Andreu (you will lose any settings you might have applied).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-845282191, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUB4NE6EZD7WJ2CA5TW6VNLTOU4J3ANCNFSM444RDTJQ.
[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-845282191", "url": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-845282191", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

It seems GitHub blocks attachments when you send them via email reply. Could you pass it via the website instead? Although, from what you say, it doesn't look that different from what I would have expected. I might just corrupt one of these files myself and see how the tool behaves and what I would need to fix.
It's definitely something I have not seen before. It seems it is not uncommon, but the solutions in there are for the developers, not for the end users. The tool attempts to upgrade those settings files from previous versions, so I wonder if that's contributing to the issue too.
In any case, if it lets you continue using the tool after the exception dialog, feel free to do so. The worst thing that could happen in theory is that your settings from previous sessions might not be persisted.

Hi Fernando,
It's no problem tot continue working with the app. I primarily wanted to report the problem.
BTW. I like the tabbed interface with multiple open files 👍
I wonder if you find the cause of the error and wait for the next update.
Regards,
Berend
Berend Storm, Sjabloonspecialist

From: Fernando Andreu @.>
Sent: Friday, May 21, 2021 10:20:15 PM
To: fernandreu/office-ribbonx-editor @.>
Cc: Berend Storm @.>; Author @.>
Subject: Re: [fernandreu/office-ribbonx-editor] DependencyResolutionException: An exception was thrown while activating OfficeRibbonXEditor.ViewModels.Windows.MainWindowViewModel. (#160)
It seems GitHub blocks attachments when you send them via email reply. Could you pass it via the website instead? Although, from what you say, it doesn't look that different from what I would have expected. I might just corrupt one of these files myself and see how the tool behaves and what I would need to fix.
It's definitely something I have not seen before. It seems it is not uncommonhttps://stackoverflow.com/questions/13298884/c-sharp-errorunrecognized-configuration-section-usersettings-stop-program-rea, but the solutions in there are for the developers, not for the end users. The tool attempts to upgrade those settings files from previous versions, so I wonder if that's contributing to the issue too.
In any case, if it lets you continue using the tool after the exception dialog, feel free to do so. The worst thing that could happen in theory is that your settings from previous sessions might not be persisted.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-846231056, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUB4NE5GW7VV37IACEIYM3TTO2577ANCNFSM444RDTJQ.
[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-846231056", "url": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-846231056", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

I can't quite determine the root cause of the error, as it looks like your settings file has the correct section but for some reason the tool does not recognise it. I wonder if language has anything to do with it, although I would expect the section names to be in English in all cases. Version 1.8 has localisation support which might inadvertently fix this too somehow by forcing your UI language to English (given that there is no Dutch translation).
So, instead, let's try to fail safe if that occurs. In the following build, if the tool has a problem reading the settings, it should hopefully delete the file and restart automatically so you may not even notice:
https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1031&view=artifacts&pathAsName=false&type=publishedArtifacts
I've tested this by adding wrong characters, changing the section names, etc. of my settings file but, as I said, I could not find the root cause of your error, so perhaps it won't work for you.
If you try that build and the problem still occurs just let me know and I will keep investigating.

Hi Fernando,
You suggested that I should download a new release.
I checked the site but I can't find a release after <IP_ADDRESS>6 (my current version) which seems to be the latest published one.
Can you send me a link to the latest installer?
My current version info:
Version: <IP_ADDRESS>6
Runtime:
.NET 6.0.0-rtm.21522.10
Operating System: Microsoft Windows 10.0.19044

Hi, 1.9.0 is the latest yeah. There have been some changes in the development builds since then, but they are unrelated to this, so there is no need to try them.
So, just to confirm: do you experience this issue with the latest version 1.9.0 too?
The reason I want to confirm this is because both the new issues mention version <IP_ADDRESS>6 instead. #177 just mentions it in the path to the settings file, so perhaps it can occur in version 1.9.0 when migrating the settings to the new version. But #199 mentions it as part of the automated bug report.

I'll test it tomorrow. It's 9.50pm now.
Outlook voor Androidhttps://aka.ms/AAb9ysg downloaden

From: Fernando Andreu @.>
Sent: Monday, December 6, 2021 9:15:05 PM
To: fernandreu/office-ribbonx-editor @.>
Cc: Berend Storm @.>; Author @.>
Subject: Re: [fernandreu/office-ribbonx-editor] DependencyResolutionException: An exception was thrown while activating OfficeRibbonXEditor.ViewModels.Windows.MainWindowViewModel. (#160)
Hi, 1.9.0 is the latest yeah. There have been some changes in the development builds since then, but they are unrelated to this, so there is no need to try them.
So, just to confirm: do you experience this issue with the latest version 1.9.0 too?
The reason I want to confirm this is because both the new issues mention version <IP_ADDRESS>6 instead. #177https://github.com/fernandreu/office-ribbonx-editor/issues/177 just mentions it in the path to the settings file, so perhaps it can occur in version 1.9.0 when migrating the settings to the new version. But #199https://github.com/fernandreu/office-ribbonx-editor/issues/199 mentions it as part of the automated bug report.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-987159348, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUB4NE5YONVFAOMGRNKJLOTUPUKUTANCNFSM444RDTJQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-987159348", "url": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-987159348", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Hi Fernado,
Being a developer myself I couldn't resist doing some research based upon the error report (containing a reference to <IP_ADDRESS>6) and your remarks.
What I found is that there were 2 subdirectories in the program directory (C:\Users?????\AppData\Local\Fernando_Andreu).
@.***
One from September 8, 2020 and one from November 22, 2021.
After invalidating the oldest subdirectory name by adding an underscore (see screenshot) and using the quickmenu
@.***  again, it generates a new directory with today's date (December 7, 2021) and opens the Ribbon Editor as expected.
What I suspect is that the 2020 directory is a remainder from an earlier installation (V 1.7) and is the first one referenced by the Quickmenu.
Problem solved at my end 8>))
I hope that this additional information helps you in improving the app even more.
Perhaps you could add some code to check for the version, or error trapping that automatically deletes files/subdirs in this directory one-by-one until it works.
Or finally generate new ones if none of them work.
BTW: I really love the multi-tab interface which makes it a lot easier to copy items between files.
Kind regards,
Berend Storm
<EMAIL_ADDRESS>Telefoon:(050) 309 3568
LinkedIn: Berend Storm
WEB: www.sjabloonspecialist.nlhttp://www.sjabloonspecialist.nl/
Twitter: @SJABLOONSPECIAL
Facebook: SJABLOONSPECIALIST
YouTube: SJABLOONSPECIALIST
TeamViewer hulp op afstand
https://get.teamviewer.com/sjabloonspecialist
Dit e-mailbericht is uitsluitend bedoeld voor de geadresseerde(n). Wilt u direct contact met ons opnemen als deze e-mail bij vergissing bij u terecht is gekomen? Wij verzoeken u in dat geval de e-mail te vernietigen, de inhoud ervan niet te gebruiken en niet onder derden te verspreiden, omdat het bericht vertrouwelijke informatie kan bevatten.
Van: Fernando Andreu @.>
Verzonden: maandag 6 december 2021 21:15
Aan: fernandreu/office-ribbonx-editor @.>
CC: Berend Storm @.>; Author @.>
Onderwerp: Re: [fernandreu/office-ribbonx-editor] DependencyResolutionException: An exception was thrown while activating OfficeRibbonXEditor.ViewModels.Windows.MainWindowViewModel. (#160)
Hi, 1.9.0 is the latest yeah. There have been some changes in the development builds since then, but they are unrelated to this, so there is no need to try them.
So, just to confirm: do you experience this issue with the latest version 1.9.0 too?
The reason I want to confirm this is because both the new issues mention version <IP_ADDRESS>6 instead. #177https://github.com/fernandreu/office-ribbonx-editor/issues/177 just mentions it in the path to the settings file, so perhaps it can occur in version 1.9.0 when migrating the settings to the new version. But #199https://github.com/fernandreu/office-ribbonx-editor/issues/199 mentions it as part of the automated bug report.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-987159348, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUB4NE5YONVFAOMGRNKJLOTUPUKUTANCNFSM444RDTJQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-987159348", "url": "https://github.com/fernandreu/office-ribbonx-editor/issues/160#issuecomment-987159348", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]


wrong dependency version in glide.lock   and .gopmfile

Gogs version (or commit ref):
master HEAD
Can you reproduce the bug at https://try.gogs.io:

[ ] Not relevant

gopkg.in/macaron.v1 locked at  7564489a79f3f96b7ac8034652b35eeebb468eb4 , but  no such ref exist. Compared go-macaron/macaron local copy refs against github history, looks all commits after 9eb6aa1af19e4076afc0763adeb65aab610a8c6e was replaced ( git push -f  or something worse ? )

You can try go get -u all for now

This fixes it:
diff --git a/glide.lock b/glide.lock
@@ -146,7 +146,7 @@ imports:
 - name: gopkg.in/ldap.v2
   version: d0a5ced67b4dc310b9158d63a2c6f9c5ec13f105
 - name: gopkg.in/macaron.v1
-  version: 7564489a79f3f96b7ac8034652b35eeebb468eb4
+  version: 4974334b10dbb6f5c0e17f4c10555ff050a16329
 - name: gopkg.in/redis.v2
   version: e6179049628164864e6e84e973cfb56335748dea
 devImports: []

Want to open a PR for that? :)

I would, but I bumped into other problems when trying to compile after that change, related to #3685. Apparently there are other places that need the interface change. Even though I feel confident that fixes the issue correctly, I'm hesitant to offer a PR that does not compile, even if if it's not related to the issue at hand.

This is still broken.

Is there anyone with commit power besides @Unknwon that can review some critical PRs?

I'm sure you're all painfully aware, but Gogs can't be installed at the moment (afaik).
Following any official install guide, for example https://gogs.io/docs/installation/install_from_source#build-from-develop-branch, the command go get -u ./...  results in

cd /home/deploy/go/src/gopkg.in/macaron.v1; git pull --ff-only
fatal: Not possible to fast-forward, aborting.
package gopkg.in/macaron.v1: exit status 128

...which then blocks go build from running with something like

../../../gopkg.in/macaron.v1/context.go:36:2: cannot find package "github.com/go-macaron/inject"

Replacing the hash as suggested above does not seem to resolve it; and neither does using the latest macaron hash (https://github.com/go-macaron/macaron/commit/826ddf13862c544525338a2deda6f57ffd1a9083).
I've been using Gogs for a while now and it's been working great, thank you all for your work! Hopefully this critical issue can be resolved soon.

This is so frustrating to the point I stopped trying to help.
@ben-burlingham I feel you, I was in the same situation you are.
You can tell that master is also broken: https://hub.docker.com/r/gogs/gogs/builds/
And yes, the suggested solution didn't do the job for me either.
My advise to you, and what I ended up doing, is using the published docker image: https://hub.docker.com/r/gogs/gogs/

@eljojo confirming yes, the Docker image does provide a fresh install instance as you reported. It will need some configuration updates to work with my current (broken) installation.
Thank you for your response and good luck to all!

@ben-burlingham @eljojo @saboya @squash @edacval
The maintainer of Gogs, @Unknwon, has been off-and-on checking in. As of now, he is probably in the 'off' state, resulting in the sea of unmerged/uncommitted PRs. If you want, you can check out go-gitea/gitea, where a bunch ol' 'velopers have forked out Gogs source and continued development on it.

Hi, the issue is still not solved. Check the docker build here: https://hub.docker.com/r/gogs/gogs/builds/bc3zhswzlnf8i348pwffcuk/

@eljojo thanks, new builds are running, should be good after few mintues.

New build does indeed work. Back on track - thank you @Unknwon!


MINOR: Apply try-with-resource to KafkaStreamsTest

In the PR #9821, @mjsax 's comment

We should use a try-with-resources clause to make sure close() is called.
Seems, other tests in this class have a similar issue. Would be good to fix all test accordingly (if you want you can also to a separate PR for it).

Let me address this before the KAFKA-5876(KIP-216) part 5.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@vitojeng -- Seems there is some conflicts. Can you rebase your PR so we can merge it?

Thanks @mjsax !
Please take a look.🙂

Thanks @vitojeng! Merged to trunk.


Added method in NewsCNN

Description
Added method to retrieve news based on type and updated documentation
Resolves: #702
Checklist

Before submitting this pull request, kindly verify that the ensuing checkpoints have been reached.

[x] Have you adhered to the repository's defined coding convention rules?
[x] Have you updated the 'documentation.md' file with the method/function documentation?
[x] Have you sent a message along with the result or response?
[x] Have you used the try-catch technique?
[x] Has the method/class been added to the documentation (md file)?

Screenshots

Additional Notes/Comments

Any additional remarks or suggestions concerning this pull request are welcome.

I certify that I have carried out the relevant checks and provided the requisite screenshot for validation by submitting this pull request.
I appreciate your contribution.

Great work @Juhibhojani !!
Do not forget to

Share your contribution on socials(twitter mainly), tag us and Clueless 🫂
Give this repository a star ✨
Follow Clueless Community on GitHub ✅


Add Step 0: Backup Your Current CCM Enviornment

Closes #221
Adds Step:0 or pre-req step to please snapshot your VM or at a minimum create a local backup of the CCM DB and your appsettings.json file

LGTM!


Support for v1

@tejashah88 do you have any thoughts on adding support for v1? I have made (private) changes to support v1 but not sure if it would be necessary to continue supporting v0 and how to tackle any backwards compatibility. Thoughts?

@marcelobern Good question! I just looked at the migration guide and it appears that most of the changes are just additions of new parameters to existing endpoints. We would still need to support v0 until Amazon deprecates it at a much later date. Since this library is technically not at version 1, we can afford to make some breaking changes, especially since I didn't expect Amazon to release a new version of their API so soon.
As for how to go about implementing the new endpoints, I was thinking of altering how the client library was instantiated, to account for the new changes and possibly future ones. Currently, it takes 2 parameters: the auth token and an optional base url. I'd propose to use an object with an authToken, version (which can take v0 or v1), and a continentCode (which can take NA, EU, or FR).
var smapiClientV1 = require('node-alexa-smapi')({
  authToken: 'auth token', // required
  version: 'v1' // optional; defaults to v1
  continentCode: 'NA'  // optional; defaults to NA
});

What do you think?

@tejashah88 works for me. I can create a pull request to see if it lines up with your thinking.
Around tokens: it took me a few hours of fooling around and testing different ways to make this work until I finally figured out how to refresh the Login with Amazon token based on refresh_token, client_id, and client_secret. So, right now, I do not even use the initial token parameter, just initialize the library and use the procedure above to invoke refreshToken() before any SMAPI call. I suspect it might make it easier for other non OAUTH2 initiated to use the lib. Thoughts?

@marcelobern By all means, go for it!
You might be right, although I don't have as much experience with OAUTH2. One option that we could add is a refreshToken() to the library, in case the token expires.

@tejashah88 just submitted the pull request.
README probably needs to be updated but I did not want to go for it before you had a chance to look over the code. Just let me know ;-)
The test cases show how to use the smapi.tokens.refresh() and I also added instructions in the test file on how to get the necessary refresh() parameters (refresh_token, client_id, client_secret), which might come handy when updating README.

@marcelobern Thank you for the pull request. I just reviewed it and it looks good so far, just needs some minor changes as listed in the my review.
As for documentation, it might be better to put it in a different file, because we don't want a huge README file. Additionally, the testing instructions can also be put into a separate file. Last thing is that we should add a changelog to this library, just in case anyone has used it beforehand.

@tejashah88 test instructions were moved to its own README under test folder.
Will update README to reflect the new token behavior you can then strike it out if you believe it got too long.
Will add changelog.

@marcelobern Great work! The only thing is that since we have breaking changes, we should release a new version as 1.0.0, especially since we've changed how the client is initialized. (i.e. Following semantic versioning)

@tejashah88 perfect, I just updated new version as 1.0.0
Please let me know if you need anything else on this and enjoy the long weekend ;-)

Aside from some final feedback in the PR, it looks great so far! I wanted to ask you if you wanted to be an active maintainer for this library, which means that you'll have publish access for npm?

Also, enjoy the long weekend as well!

@tejashah88 sure, please let me know if there are any specific guidelines you would like me to follow as a maintainer.

@marcelobern Good point! Honestly, it's more of following GitHub common sense like not committing directly to master (unless it's document changes) or follow semantic versioning when releasing a new version. I'll make a document for future contributors to follow when working with this library.

@marcelobern If you have an npm account, can you tell me what's your username so that I can give you publishing access?

I've opened PR #5 for the contributing document, as some of the links depend on #4 to be merged and if there needs to be small changes to the template.

@marcelobern Thank you! I've sent an invite for the GitHub repo and I've given write access for NPM.

Just merged PR #4 so I believe this one is closed now


Mdawn update template to save terratest artifact 172547059

Tracker story
Changes proposed in this pull request:

Adds updates config to store test metadata in CircleCI

3rd PR, Closes ticket

The go-junit bits are missing to generate the test results

I was trying to keep it language-agnostic & let the Eng Playbook do the talking. But I guess we're in the soup.

This repo lays out as much boilerplate as possible to reduce the number of steps to getting a new module up and running, so having it just work with CircleCI test metadata would be a nice win


Sprint 2 Tasks 13C&D

Allows user to iterate through all their incoming offers for their active item. Sets stateOfCompletion for rejected offer items to CANCELED, sets stateOfCompletion for accepted offer item to BARTERING. When there is an accepted item and bartering is taking place, the user will skip the "Tinder" and view the counteroffers page (currently blank, next task).
Functionality outside of scope of this task that may be needed:

Changing one's active item may need to disable all trades to that item
Outgoing offers needs to show CANCELED trades to notify user that their trade was rejected, and then delete from firebase

More stuff to add.


cla-assistant wants too many authorizations

Hi,
i earlier signed a CLA and tried to login again just now. I was greeted with a request with a request to modify the authorization (ain't going to happen). Maybe related to #77 ?

Existing access is public access
the request is for :

 Personal user data
Email addresses (read-only)
This application will be able to read your private email addresses.

 Learn more
Repository webhooks and services
Read and write access
This application will be able to read and modify repository webhooks and services (no direct code access).

 Learn more
Repositories
Public only
This application will be able to read and write all public repository data. This includes the following:

Code
Issues
Pull requests
Wikis
Settings
Webhooks and services
Deploy keys
 Learn more
Commit statuses
Read and write access
This application will be able to read and write commit statuses (no direct code access).

 Learn more
Organizations and teams
Read-only access
This application will be able to read your organization and team membership.

 Learn more
Gists
Read and write access
This application will be able to read and write your public and secret gists.

This is the set of permissions we require for the admin role to set up CLA assistant for a project and not for a contributor to an already enabled project. In case you just log in to the main route / we currently assume that you want to enable CLA assistant for a new repo.
@KharitonOff We should also check again that we need all permissions for both cases.

As @thojansen wrote we use 2 different OAuth scopes for contributors and administrators:
contributor scope:

user:email - we need it just for user identification

admin scope:

user:email - user identification
public_repo - read all public repositories in order to provide a selection of your repos to set it up
read:org - include also organization repositories into the selection
repo:status - CLA assistant sets it's status on pull requests
read:repo_hook, write:repo_hook - CLA assistant creates a pull request-hook on linked repositories to get a notification on pull request and check whether all committers have signed your CLA
gist - access to public and "secret" gist files, where your CLA should be stored

For more information look https://developer.github.com/v3/oauth/#scopes

@KharitonOff and @thojansen, issues do not vanish by closing them!  This action just makes them replicate, i.e., enforces users to create duplicate issue reports, see #97, #566 etc.
I suggest to deal with this at issue #566, until it has been fully resolved: I.e., until the CLA assistant works properly with cookies disabled in the web-browser.