I think everyone will agree: current situation with dependency management is awful, in any language/platform. I believe @bradfitz correctly explained main point of conflict. Maybe vgo won't success, but to me it's obvious we have to change something (I mean not just in Go, but in general), and vgo looks very promising to give it a try.
@mattfarina We plan to try to implement a service which will automatically control is compatibility actually maintained. Integrating it with godoc, providing badges for README, using it as a proxy for go get - there are many ways how we can try to make it work good enough. Sure, @sdboyer is right about API compatibility doesn't guarantee actual compatibility, but that's a good start and should work good enough in most cases.

So it's possible that vgo might not work for many-dependency-using Kubernetes for some time, until the Go community norms shift.

Hope is not a strategy, especially when existing behaviors and expectations are already well established. Go might have had innovation tokens to spend here if we were having this discussion five years ago, and things were more amenable to influence. But by ignoring the issue for so long, it seems clear to me that tooling proposed now must meet users where they are.

What will Go do differently to avoid a problem present in all of these other languages because people are fallible?

We've been discussing some sort of go release command that both makes releases/tagging easy, but also checks API compatibility (like the Go-internal go tool api checker I wrote for Go releases). It might also be able to query godoc.org and find callers of your package and run their tests against your new version too at pre-release time, before any tag is pushed. etc.

find callers of your package and run their tests against your new version too at pre-release time, before any tag is pushed. etc.

This is not really practical for anyone who is not Google.

This is not really practical for anyone who is not Google.

With all the cloud providers starting to offer pay-by-the-second containers-as-a-service, I see no reason we couldn't provide this as an open source tool that anybody can run and pay the $0.57 or $1.34 they need to to run a bazillion tests over a bunch of hosts for a few minutes.
There's not much Google secret sauce when it comes to running tests.

With all the cloud providers starting to offer pay-by-the-second containers-as-a-service, I see no reason we couldn't provide this as an open source tool that anybody can run and pay the $0.57 or $1.34 they need to to run a bazillion tests over a bunch of hosts for a few minutes.

This requires an account with a specific cloud provider, requires that you accept a specific cloud providers terms of service (which you may or may not be able to do for legal reasons, even if most of the world treats this as if it doesn't matter), requires that you live in an area that the cloud provider services (eg. if you're in Iran and the cloud provider is in the United States you may not be able to use it due to export laws), and requires that you have the money to spend to pay the cloud provider (presumably every time you do a release). It may not be much money, but that doesn't mean everyone will be able to pay it. If we want Go to be inclusive and usable by a diverse audience this does not seem like a good solution.
/two-cents

@SamWhited MeteorJS had this working with galaxy, a built in meteor publish command to run your project in a cloud provider.  Maybe I'm misunderstanding the problem posed, but their swing at it seemed fine.

@bradfitz What if the API doesn't changes but behavior behind it does? That is a case that breaks from SemVer and impacts those that import it. How do you detect this situation? I ask because I've experienced it on more than one occasion.

open source tool that anybody can run and pay the $0.57 or $1.34 they need to to run a bazillion tests over a bunch of hosts for a few minutes.

This now touches on cost. This may feel fine for folks in a tech city in the US. What about people in Africa, Central America, or other places who are globally distributed. How are tools like this generally accessible outside the "tech elite" circles?
And, what about all the cases of not doing public cloud work? On-premise (a lot of people do it) or proprietary and having trust issues. How will this stuff work for them? If you have an in-house tool you may not want to leak to public services what imports you're using. Say you get your imports from GitHub but this service runs in Google. Do people feel ok handing their dependency tree to Google?

It might also be able to query godoc.org and find callers of your package and run their tests against your new version too at pre-release time, before any tag is pushed. etc.

Let's take Kubernetes as an example of this. Someone writes a package that's imported into Kubernetes. So a tool has to get that and run all the tests. Parts of it are designed to run on Windows and POSIX. Can we test for multi-OS/multi-arch (since Go handles that). What's that going to really look like (and cost)?
--
I think tools like this can be useful. I don't mean for folks to think otherwise. I just don't see how they solve the problem for many people. They aren't practical enough or don't fit every setup.
It feels like we're trying to solve a mathematical problem with known and controllable constraints. But, people are messy so we need fault tolerant solutions.
To quote @technosophos earlier today:

"version managers aren't actually tools for compilers or linkers or anything... version managers are for people collaborating."

For what it's worth, he's written more than one dependency manager, studied others, and talked with people who've written even more.

It feels irresponsible to accept a proposal while there are still foundational concerns outstanding on the approach. Consensus between the author and community domain expert @sdboyer seems like a reasonable minimum standard to reach before the proposal is considered accepted.

Just to pile on a bit here: we have a history around packaging which is both non-standard and sub-optimal (the go get ecosystem). It would be better to just give up on a standard package manager than to have another go get released which pushes people toward bad practices in the name of compatibility with the "standard" tool. As someone who has been using Go since its public release I find this conversation frustrating and disheartening as it seems the leadership of the Go team has not learned the lessons of the mistakes made with go get (nee goinstall).
There are reasonable and practical problems which have voiced about this proposal. We should change the proposal to address them not simply say: "working as intended." If we can't do it right for 1.11 or 1.12 or 1.13 then we should wait until it can be done right. This proposal proposes a system that behaves significantly different than most other systems and not in a good way.
The motivating reason behind MVS seems to be that the traditional approach is NP-Complete. I find that a very poor motivation.  When dealing with NP-Complete problems the main question is: "How often do the hard instances arise." With package management the answer appears to be "very rarely." We should not settle for an incomplete and unhelpful problem formulation just to avoid the NP-HARD label on the problem.
Most of the concrete points have been voiced by other people closer to the issue (@sdboyer @peterbourgon @mattfarina  etc...). My main gripe is that we are accepting this proposal when these concrete points have not been adequately addressed.

@SamWhited, you're taking issue over an optional feature of a hypothetical design. The hypothetical user who doesn't trust any cloud provider or can't use any cloud provider inside their country's firewall or doesn't want to pay can always run tests (or a fraction thereof) on their own machine over night. Or just use the go release signature checking, which gets you 95% of the way there for free.

@mattfarina, @SamWhited, let's move discussion to https://github.com/golang/go/issues/25483.

@Merovius
In @mattfarina's blog post, they describe Helm upgrading to grpc v1.4.0 intentionally, that is by the equivalent of updating go.mod. The question is not how dep or vgo avoids this problem, but rather how they enable to library author to recover from it. In the case of dep, they can release a patch that ads the grpc<v1.4.0 constraint. For users who possess no other dependency on grpc, this will just work (as it will in vgo). If a user has already updated to the latest version of helm and possesses another dependency on grpc>=v1.4.0, this constraint will cause their build to fail; not ideal, but better than subtly broken runtime behavior.
With vgo, do the Helm maintainers have any equivalent options available? If a user has upgraded grpc to v1.4.0 for any reason, MVS will always choose<EMAIL_ADDRESS>Helm will be broken, and there's nothing the Helm maintainers can do about it (sans adjusting for the changed behavior, which is often time consuming). I can't speak for @mattfarina, but that is how I read the concern raised and it's one that I share.
Simply put,vgo does not provide a mechanism to communicate anti-compatibility: it assumes import compatibility and offers no recourse when it does not hold. Helm is just one of many real-world examples where compatibility rules are not followed. With dep and similar systems, intermediate libraries can defend against (or more often, recover from) compatibility violations with upper bounds constraints while vgo offers no such defense.

@ibrasho @mattfarina
It seems like one of Russ's example in the GopherconSG talk covers a very similar (maybe identical?) scenario.
In the post above, you say that helm depends on "grpc [>= 1.0, < 1.4]". But that is not strictly accurate. I think what you mean is that some specific version of helm depends on  "grpc [>= 1.0, < 1.4]". Let's say that version of helm is 2.1.3; presumably this version of helm was released after grpc 1.4 (otherwise it wouldn't have known to mark itself incompatible with grpc 1.4). Russ's point in that talk is that the prior version of helm (say 2.1.2), presumably would not (yet) have marked itself as incompatible with grpc 1.4.
In other words, a satisfying assignment (according to dep) would've been helm = 2.1.2, grpc = 1.8. Dep could correctly choose this version assignment without error, as it satisfies all of the constraints at the given versions.

@balasanjay
Helm's version doesn't fundamentally change the example<EMAIL_ADDRESS>might declare a dependency on<EMAIL_ADDRESS>and the user of helm might have a dependency on<EMAIL_ADDRESS>directly or through some other package. In this scenario, MVS fails and installs<EMAIL_ADDRESS>and<EMAIL_ADDRESS>Besides, this example assumes that the user intentionally updates to<EMAIL_ADDRESS>(and thus<EMAIL_ADDRESS>and perhaps even<EMAIL_ADDRESS><EMAIL_ADDRESS>etc before the problem is uncovered.
MVS intentionally disallows exclusions from intermediate dependencies to achieve its theoretical goals:

Negative implications (X → ¬ Y, equivalently ¬ X ∨ ¬ Y: if X is installed, then Y must not be installed) cannot be added...

For this example, we need to express, if X=helm>= 2.1.3 is installed then Y=grpc>=1.4.0 must not be installed, which we cannot do by design.
In effect, only the top-level package and bottom-level users have any recourse if compatibility rules are broken. Intermediates like Helm must work with all future versions of any dependencies, which, to me, significantly reduces the value proposition of such libraries.
Perhaps this will encourage better behavior in heavily uses libraries like grpc and aws-sdk-go because the full brunt of any breakage will be felt by all parties and will be more difficult to work around. However, it's not always that easy. What if the "breakage" is not really breakage, but a legitimate change in behavior that has unintended consequences for some user, but is helpful for others? That type of thing is not uncommon and upstream authors would be rightfully hesitant to revert a change in that scenario.

I don't think I was nearly as clear as Russ. Let me try again.
Initially, the state of deps looks like this.
Helm 2.1.2: grpc >= 1.0
Then, grpc 1.4 is released. The developers of Helm realize there is an incompatibility, and so push a new version of Helm:
Helm 2.1.3: grpc >= 1.0, < 1.4
I start a new app that depends on Helm and some new feature of grpc (for the sake of argument). I list the following deps:
Helm >= 2.0.0
grpc >= 1.4
The claim above was that dep would notice the inherent conflict, and report an error.
But Russ pointed out that that's not true, because there is a version assignment with no conflicts. Specifically, dep could choose to use helm 2.1.2 and grpc 1.4. According to dep, this is a valid assignment, because helm 2.1.3 is the one that is incompatible with grpc 1.4, whereas 2.1.2 is compatible with all grpc >= 1.0.
In other words, dep could validly choose to "fix" a conflict, by downgrading to a version that hadn't yet recorded the conflict. If you have immutable versions, then this seems inevitable. Therefore, it seems that dep would also mishandle https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/.

@balasanjay Sure, but eventually Helm puts out 2.2.0 with a neat new feature you want, and you try to upgrade, and then the problem kicks in.
(I'm cautiously optimistic that this will work out ok if vgo has a well designed UX for making people aware that their MVS outcome has a "conflict" of this form. By "well designed" I mean that it encourages people to deal with the issue instead of just being OK with lots of warnings all the time.)

I certainly agree that there are situations where dep will detect a conflict, but just wanted to be clear that it is not the one presented in that blog post (or atleast, not with the version requirements as currently presented).
And FWIW, I think its reasonable to question the effectiveness of a safeguard if it breaks on a relatively simple example of a conflict.
For the record, I tracked down Russ's example (it is pretty much identical to this one, to an impressive degree): https://youtu.be/F8nrpe0XWRg?t=31m28s

Alarming news. Here comes the golang civil war: Team @rsc vs Team @sdboyer

Re: minimal version selection, I'm having trouble figuring out how to resolve the following situation:
Imagine a popular library in maitenence mode, e.g. v1.2.3 has been out for quite a over a year with no changes. Many other libraries depend on it.
A developer comes along and realises a speed optimisation to make in v1.2.3. It speeds the library's core function up by 10x, with no API change! This is released as v1.3.0.
How do dependees end up getting this update? They can work with v1.2.3, but v1.3.0 is evidently better.

@daurnimator

How do dependees end up getting this update?

Each application would need to set 1.3.0 as the minimum version to use.

The problem is, and always has been, that MVS only solves an illusory problem (avoiding SAT), ...

Respectfully, IMHO the SAT solution is a non-solution, therefore for me, MVS solves a very real problem.

IMHO the SAT solution is a non-solution, therefore for me, MVS solves a very real problem.

Would love to understand the reasoning behind that, if possible?

Would love to understand the reasoning behind that, if possible?

It's the same reasoning that's behind preferring Go's regexp to PCRE, ie. not alowing a program to depend on an algorithm having quadratic/exponential worst case complexity.

We should keep in mind that vgo will just replace go get nothing more nothing else. We should compare vgo with go get and not vgo with something that doesn't exist. "Worse is better" ! Let's focus now on the implementation details.

FWIW, it is IMO completely possible to introduce upper bounds without having a full SAT solver - it is just not possible to have the generated solution be optimal or to guarantee that an existing solution will be found. If need be, you can

Make it possible to specify upper bounds
Ignore them when solving via MVS
Check the found solution against all the bounds and croak if it doesn't fit (this is the key difference: Traditional approaches would try to find a different solution instead)

This would then mean you get the advantages of MVS (a simple algorithm without pathological runtimes), preserving the possibility to mark incompatibilities and detect them statically but you are giving up the guarantee of always finding a solution if one exists. Though it can be argued, that the solution you would find, isn't actually a solution anyway, because the incompatibility is still there, just unknown to the algorithm.
So at least to me, it would seem that it's perfectly possible to retrofit some way to get upper bounds unto MVS. I'm still not convinced it's actually needed, but should that turn out to be the case, it can always be added later. Making the "MVS is fundamentally unfit" assertion problematic. But I still might misunderstand the problem. And there may be a failure scenario better illustrating it?
@sdboyer No worries. As I said, I completely understand that this is not your dayjob and I appreciate the time you are taking to participate. It's still a practical issue of "if we don't know the arguments, we can't talk about them". I can imagine that you are just as frustrated with the whole situation as I am :)

It's the same reasoning that's behind preferring Go's regexp to PCRE, ie. not alowing a program to depend on an algorithm having quadratic/exponential worst case complexity.

@cznic I'm of the opinion that dependency management is not only a technical problem, it's intertwined with social constraints and considerations. So I'm not sure comparing it to regular expressions (a purely technical implementation issue) and favoring an algorithm basically based on time complexity is a fair approach.
I see some people favoring MVS because it's simpler and easier to reason around and that's an understandable consideration if it resolves the other aspects of the problem at hand.
I'm was wondering if people have other reasons to prefer it over an SAT-based algorithm.

I was wondering if people have other reasons to prefer it over an SAT-based algorithm.

@ibrasho MVS don't need a lock file.

I'm was wondering if people have other reasons to prefer it over an SAT-based algorithm.

Personally, my reasons are

It unifies lock-file and manifest into one file, which can largely be computer-edited. Meaning less noise while still getting reproducible (or "high-fidelity") builds in the common case. AFAICT this is something unique to MVS. As one of my main frustrations with other package managers is the toil of having to edit manifest files, this is huge to me.
Gradual repair will be easier/made possible. As I'm a strong believer in this approach to solve the distributed development problem, this is also important for me.
It may help the ecosystem to collectively stay close to HEAD for most libraries. This is largely speculation and depends somewhat on the tooling available. But if a "pull everything to the latest version" is sufficiently simple, it can increase the cadence with which newer versions of libraries are tested against each other in production.
It achieves all of this while preserving or surpassing the desirable qualities of other approaches, AFAICT. Upgrades only happen if desired. And binary packages will continue to build even if the build of some of their dependencies gets broken in a new version, giving the author time to work on a fix.

Especially this last part is sort of ironic. Because this exact quality was painted as extremely important in @sdboyer's last post - but at this point, I still believe vgo to be strictly better in this regard than traditional approaches.

@Merovius
"It unifies lock-file and manifest into one file"

this isn't entirely true as manifests are effectively scattered all over your files, as import statements effectively act as manifests.

@docmerlin When I said "manifest", I meant a file listing all the modules you are depending on with their appropriate versions (in particular, it contains strictly more information than the import statements, otherwise you wouldn't need it). In the case of vgo that would be go.mod, in the case of dep it's Gopkg.toml. You could also call that the config file for the dependency solver. If you consider a different term more appropriate, feel free to substitute that for manifest, when you are reading my comment.
Note, that it is pretty normal for there to be both a file listing all dependencies and a list of explicit imports (that are a potentially strict subset of the dependencies) per file. In particular, all Go dependency managers I'm aware of do that. Other approaches also use a lock-file which describes specific, precise versions to use to ensure reproducible builds. And the distinguishing feature of MVS I was referring to, is that this file is not needed, because it can be uniquely derived from the manifest/dependency-solver-config/go.mod file.

@cznic the focus on the complexity classes of MVC vs a SAT-based approach in isolation doesn't make sense (as I think @sdboyer writes somewhere -- we get caught up talking about it because it is one of the few things we can name/identify).
@bradfitz's suggestion in #25483 to address some of the concerns with vgo (which I think is a initially crazy but maybe great practical solution) involves running the tests from arbitrary users of your API before a release.  This is an NP-complete problem in general, but in practice might be a great solution (just like gps2).
So on the one hand we have SAT-based package management algorithms, and on the other hand we have an algorithm in NL that forces us to do NP-complete work later on (or time out, which is what any practical SAT solver would do for adversarial lock files).

(deleted + reposted from my personal account)
@cznic the focus on the complexity classes of MVC vs a SAT-based approach in isolation doesn't make sense (as I think @sdboyer writes somewhere -- we get caught up talking about it because it is one of the few things we can name/identify).
@bradfitz's suggestion in #25483 to address some of the concerns with vgo (which I think is a initially crazy but maybe great practical solution) involves running the tests from arbitrary users of your API before a release. This is an NP-complete problem in general, but in practice might be a great solution (just like gps2).
So on the one hand we have SAT-based package management algorithms, and on the other hand we have an algorithm in NL that forces us to do NP-complete work later on (or time out, which is what any practical SAT solver would do for adversarial lock files).

the focus on the complexity classes of MVC vs a SAT-based approach in isolation doesn't make sense ...

I'm not sure where the term 'focus' comes from. It's just that if there are two algorithms available, one's worst case is quadratic or worse and the other is linear od better, I chose the later and avoid the former. I'd call it a principle, not focus.

... suggestion in #25483 to address some of the concerns with vgo ...

Seems like issue #25483 is not related to vgo. Typo?

It's just that if there are two algorithms available, one's worst case is quadratic or worse and the other is linear or better, I chose the later and avoid the former.

@cznic sure, usually if two algorithms give you the same results you want the one with lower complexity (although this isn't even always so cut and dry - Python uses insertion sort for small inputs because despite having worse complexity bounds, it has better constants + runtime up to a point).
In this case (MVS vs. SAT-based algorithms), the results differ on-purpose and have broad consequences.  I'm suggesting that because of this you can't just compare the algorithmic complexity, you need to consider their wider impacts.

Seems like issue #25483 is not related to vgo

The first line in that issue is a link to Brad's comment in this issue: https://github.com/golang/go/issues/24301#issuecomment-390788506 .  While this tool will be useful outside of vgo, it seems like it is being considered largely to mitigate some of downsides of MVS (in my opinion/understanding).

Oh, at the summit Russ did share one of the reasons, at that time, he didn't like a SAT solver. He wanted a solution with fewer lines of code because he didn't want the Go Team at Google on the hook for maintaining that much code. I remember that specifically because I did some LOC comparisons between dep, glide, and other tools after that to get a better picture of the differences.
 If the issue is one of resources should Go be under a foundation and people from other organizations become involved in ownership of it? That's another way to add resources to maintaining the toolchain.

@natefinch max version restrictions nudge MVS out of it's very clever avoiding-SMT-solver territory.

I think @natefinch means max versions as a final check/filter. Once MVS has done its job, vgo would error if any of these max-version restrictions were not satisfied. That still doesn't get us into SAT solver territory.

  You're trying to use two libraries that state categorically they require incompatible versions of a library.  A will break with 1.6, B will break with 1.7. The end.
You need to either convince the dependency author to fix the bug (if it's a bug), convince one of the library authors to release a new version that is compatible with the new dependency version, or fork a whole bunch of stuff and fix it yourself.
There's no good answer.  But there's no tooling in the world that can fix this for you, either.

@sdboyer

The problem is, and always has been, that MVS only solves an illusory problem (avoiding SAT),

I can't speak to your private conversations with Russ, but “avoiding SAT” seems like a strawman argument to me. “Avoiding SAT” is no more a goal than “using SAT”: neither has any concrete impact on users.
As I see it, the concrete problems that MVS solves are:

making builds reproducibile by default,
building as close to the tested versions as feasible, and
avoiding spurious rejections.

We get to a better ecosystem by creating tools that help us to spend our limited tokens on useful collaborations - not by creating brittle tools that punish us for participating in the first place.

I agree. But I want to take a closer look at your assumptions: which tools “punish” participation and why?
One of the examples you gave in your post was, “Our project depends on<EMAIL_ADDRESS>right now, but it doesn’t work with<EMAIL_ADDRESS>or newer. We want to be good citizens and adapt, but we just don’t have the bandwidth right now.”

The first (implicit) assumption you're making is that you (or your users) have had the time and bandwidth to test your project exhaustively against all releases of its dependencies.¹ For some projects, that assumption in and of itself may not hold: by setting the expectation that everyone tags upper bounds when they discover incompatibilities, you end up “punishing” maintainers who don't have the bandwidth to test for regressions and update bounds on potentially all of their releases.
In contrast, under MVS, maintainers are only obligated to declare one thing: “We tested thoroughly against<EMAIL_ADDRESS>and it worked.” If your users don't do anything to disrupt that, they build against<EMAIL_ADDRESS>and everything continues to work as it did before.
Under MVS, breakage only occurs at the time of an explicit upgrade. That's a significant benefit: if your user upgrades some other dependency so that it pulls in<EMAIL_ADDRESS>and breaks their use of your package, then they can simply back out that upgrade until you have time to fix it, or until the maintainer of X has time to correct the incompatibility. And given the right expectations, the latter may be much more likely than the former: notching out<EMAIL_ADDRESS>may turn out to be needless busy-work if<EMAIL_ADDRESS>restores compatibility.

The second assumption you're making is that every incompatibility that affects any part of your module affects all users of your module. If the part of your package that breaks under<EMAIL_ADDRESS>is a little-used function, why hold back your users from upgrading X in their program that doesn't even call it?
You could argue that if some parts of the module don't depend on other parts, they should be separate modules, but that again forces extra work onto package maintainers: if I only have the bandwidth to test and upgrade periodically, I may only have the bandwidth to maintain one module, not a whole complex of fine-grained modules with fine-grained dependencies.

¹ In general, detecting incompatibilities with dependencies requires you to test against the cross product of all releases of those dependencies: it's possible that your particular use of<EMAIL_ADDRESS>is fine, but it breaks in combination with some other package you depend on. For example, perhaps you and your dependency require incompatible options in a global configuration.

they can simply back out that upgrade

That assumes this is a compiler error or something similarly highly visible.  It's a lot more likely to be a subtle behavior bug that isn't immediately apparent. You update, run your tests, and all looks good.  Maybe a timeout that was 10 seconds is now 30, and that throws off the timeouts in the rest of your stack when under load.  You wouldn't notice until it's running in production (something similar happened to us with a change in mgo a few years ago).

If the part of your package that breaks under<EMAIL_ADDRESS>is a little-used function, why hold back your users from upgrading X in their program that doesn't even call it?

Because they probably won't know if they are or aren't using that function if it's a transitive dependency, and who's to say that some unused codepath won't get suddenly activated down the road when you change your code? So that broken function is now getting called.  It's far better to trust the library maintainer who is an expert at understanding their own library, that if they say it doesn't work with 1.7, don't build with 1.7.

That assumes this is a compiler error or something similarly highly visible. It's a lot more likely to be a subtle behavior bug that isn't immediately apparent.

There are subtle bugs lurking in nearly every version of nearly every software package. We don't generally mark releases as completely unusable just because we've found one such bug; instead, we fix it in a later point release.
What makes this particular class of bug special?

who's to say that some unused codepath won't get suddenly activated down the road when you change your code?

That's exactly the MVS argument: if you change your code, then you detect the breakage at that revision, and you can update the version constraints at that revision too.
That does imply that, as a user, it is easier to bisect failures if you upgrade your dependencies one-at-a-time rather than in bulk, but that's true of changes in general: the smaller your changes, the more precisely you can bisect them, regardless of whether they are changes to your code or its dependencies.

What makes this particular class of bug special?

It's not just a bug.  It's bigger than that. The library author, who is the foremost expert on their code, has told the world "yo, version 1.7 of X breaks my stuff in ways that are so bad, just don't even build with it".
Clearly, unless it's a compiler error, it's a judgement call. If 99 of your functions panic, but one doesn't... is that just a bug?  Or is it a complete incompatibility?  What if it's just one function that panics?
At some point, a human has to make that decision.  I would much rather deal with a pre-emptive declared incompatibility that occurs at build-time, than worry about an undeclared major problem making it into production.

It's not just a bug. It's bigger than that. The library author, who is the foremost expert on their code, has told the world "yo, version 1.7 of X breaks my stuff in ways that are so bad, just don't even build with it".

There is another way for a library author to express this: Write a test that fails when used with an incompatible version of X. This will have the advantage of requiring no changes to the library if X releases a fixed version, as well as catching any future regressions.

To summarize ( likely poorly) it seems like the main technical argument against vgo is that there needs to be a way for libraries to declare globally respected constraints on their own dependencies.
Why not have both sides agree to sanction a competing proposal that explores how GPS2 could fit in with the parts of vgo both sides like and makes the minimal and necessary changes to accomplish its goals otherwise. Then, merge the vgo experiment in the meantime and revisit the proposal before vgo merges mainline?
As someone who struggled with many dependency tools in the past I am excited for vgo but remain open and excited to read the arguments pro adding global version constraints. So FWIW, as a "community" member I feel well represented by the vgo solution far.

Just throwing this out there:

That assumes this is a compiler error or something similarly highly visible. It's a lot more likely to be a subtle behavior bug that isn't immediately apparent. You update, run your tests, and all looks good. Maybe a timeout that was 10 seconds is now 30, and that throws off the timeouts in the rest of your stack when under load.

This is an issue in software in general. NPM (the other versioning tool I personally have the most familiarity with) uses an SAT solver combined with a community that has strongly embraced semver, and this problem still exists. The reality is there is no magic wand: at some point the developer must be aware of the dependencies they use (yes, including transitive) and put in the time to properly test the code for which they are ultimately responsible. My employer can't be the only one where we are required to justify every library we use, including transitive libraries, for legal and other reasons.
Honestly, to my eye, a lot of the complaints towards vgo seem to be "it's not perfect, therefore it won't work". Let's not fail to implement a good solution for want of a perfect solution.
To me, it seems very aligned with the overall Go philosophy for the core team to provide a tool that is good in most situations, leaving it to the community to provide more advanced and/or specific tooling.

@malexdev There may be a problem with your actors in the argument that:

Let's not fail to implement a good solution for want of a perfect solution.

dep is a good solution today. One that was created by the community working together. vgo, as started earlier, makes a couple assumptions:

That no one will ever break from semver, even by accident
That we will need to rework the existing codebases in the existing ecosystem

vgo is more based on the "perfect solution" in a "perfect world" while dep works today following what already works in other programming languages ecosystem while being fault tolerant.
You can see this in the history of the package management problem space I just wrote up.

To summarize ( likely poorly) it seems like the main technical argument against vgo is that there needs to be a way for libraries to declare globally respected constraints on their own dependencies.

I agree with this summary.

Why not have both sides agree to sanction a competing proposal that explores how GPS2 could fit in with the parts of vgo both sides like.

At this point, I remain unconvinced that GPS2 is a necessity or even a good idea. The ability you lined out above can be retrofitted to vgo on top of MVS (like this or this). Personally, I'm hoping that @sdboyer's next blog post will contain good arguments against MVS itself, but right now, I don't really see any reason for a different algorithm - especially one that would cost significant UX advantages of vgo.
Though, to be fair, I also don't see any reason against experimenting with that.

dep is a good solution today.

I'm not sure I agree. I haven't used it myself, but on slack there where several people complaining about issues that seem directly traceable to its SAT solving approach. And I do know that I'm very unhappy about deps overall design (leaving aside the question of the dependency solver itself, so general workflow and UX).

That no one will ever break from semver, even by accident

I am sorry, but I have asked repeatedly for justification of this statement and didn't get any. Why would vgo assume this in any way, shape or form more than dep? I fundamentally disagree with this statement. It is an assumption made to explain the algorithm. Just like if you'd explain dep's algorithm, you'd explain the assumptions built into semantic versions. At worst, they show the same breakages if you fail to comply with those semantics.

I think in general it makes sense to distinguish between different pieces of what we are talking about. Some of the complaints are regarding SIV, some MVS and some the general vgo-shell. For example, it is true that MVS can't handle upper version bounds, but that does not mean that vgo couldn't handle upper version bounds. SIV requires changing lots of code out there (by rewriting import statements), but again, that does not even necessarily mean vgo would require that. Though to be clear, I also don't think it's that big of a deal, as long as we can migrate. Which AFAICT we can.

I just watched @rsc's GopherConSG opening keynote about versioning. He addressed the scenario where a dependency introduces a breaking change, and compared how vgo and dep would handle it, which seems to be the main concern here. (It's a great watch.)
If I understood his point correctly, dep may break the build as well if a maximum version limitation is used to avoid a bad version. I'd be very interested to see this point addressed by those here who are concerned that vgo falls short of dep in this regard.

@willfaught To us, dep breaking the build when a maximum version limitation is used to avoid a bad version is considered a success! This is what we want to happen. Russ correctly notes that this problem is not resolved automatically. A constraint on Helm>2.0.0 is not going to upgrade the user automatically to<EMAIL_ADDRESS>but it would work successfully (downgrade grpc or trigger a build failure if that's impossible) if the user explicitly depended on "Helm==2.1.4". Personally, the first thing I usually try when encountering an issue with a library is forcing an update to the latest version. With Dep, this would inform me of the failure introduced by GRPC 1.4.0. With vgo, the only way for Helm to communicate this to me is through documentation.
To repeat the point because it continues not to be understood: neither dep nor vgo can prevent this problem from occurring or provide a foolproof solution. Rather, dep allows Helm to communicate that the problem exists, whereas vgo does not..

To summarize ( likely poorly) it seems like the main technical argument against vgo is that there needs to be a way for libraries to declare globally respected constraints on their own dependencies.

I would add some color to this summary in that these constraints are needed to deal with the unhappy path of when compatibility rules are violated. vgo establishes the import compatibility rule and then proceeds to develop a solution assuming that rule is always followed. In this idealized world, the need for upper bounds is limited or even nonexistent. In the real world, this will not happen: developers will release updates that break compatibility, either intentionally or otherwise.
I think @Merovius is on to a workable solution. MVS would proceed as specified, then after resolution is complete, vgo would check each resolved package for exclusions. If any are found, these are reported to the end user, who can choose to either alter their dependencies so as to meet these constraints or choose to override and ignore the constraints. I'm been on the flip side of this too and sometimes you know better than the maintainer; it works for your application and that's all you care about.
This restores a path for intermediary libraries to communicate an incompatibility to end users. To repeat the helm example yet again:
<EMAIL_ADDRESS>Helm @2.1.2
<EMAIL_ADDRESS>GRPC @1.3.5
==> User upgrades to<EMAIL_ADDRESS>intentionally.
User: Helm @2.1.3<EMAIL_ADDRESS>("Helm updated, so I can finally use grpc 1.4!")
Helm: GRPC @1.4.0
==> Bug detected! User is seeing some problems with Helm, so check for a new version.
User<EMAIL_ADDRESS><EMAIL_ADDRESS>Helm: GRPC @1.3.5, weak GRPC <1.4.0
User sees a warning that GRPC 1.4.0 is rejected by the install of<EMAIL_ADDRESS>Since Helm is broken for me and that's what I'm trying to fix, I remove my dependency on GRPC 1.4.0 (sadly loosing some useful functionality) and rerun MVS. This time, MVS resolves GRPC to 1.3.5 and Helm to 2.1.4, rechecks all the weak constraints, finds they hold, and I'm done.

@willfaught To us, dep breaking the build when a maximum version limitation is used to avoid a bad version is considered a success! This is what we want to happen.

The point made in the talk is that vgo is no worse than dep in this scenario. In his example, the build isn't broken in the sense that dep can't find a solution; it's broken in the sense that dep does find a solution, and that solution includes the bad version, resulting in the same bad situation we wanted to avoid.
You really should see the video, which walks through an excellent example, but here's the gist as I understood/remember it:

Package versions are immutable
To add a maximum version limitation to an existing dependency for your package, you have to publish a new version of your package.
It's possible that dep will choose the previous version of your package in order to satisfy all requirements, in which case your new maximum version limitation will not be present. This allows the bad version to be used after all.

I mostly agree with the proposal to add maximum version exclusions, but I do have this worry: Suppose I put in my library "use gRPC >1.4, <1.8" then in gRPC 1.9, the authors decide, "you know what, Helm was right, we made a breaking change in 1.9, we're reverting to our prior behavior." Now people trying to import Helm+gRPC won't be able to use 1.9 until Helm releases a version that says "use gRPC >1.4, except 1.8.0, 1.8.1, 1.8.2, but 1.9+ is cool".
In other words, maybe exclude grpc 1.8 is sufficient because we won't know if gRPC 1.9 will be incompatible or not until it's published, at which point  Helm can either add it to the exclude list or not.

I know essentially nothing about this space.  But from reading the discussion here, it sounds like the biggest disagreement boils down to how to detect erroneous cases.  That is, both MVS (vgo) and SAT (dep) handle normal situations more or less well, perhaps not identically, but well enough.
SAT provides an ability that MVS does not: using SAT, the author of the library package P1 can declare "P1 requires P2, and works with P2Version > 1.1 and P2Version < 1.4".  MVS can only declare "P1 requires P2, and works with P2Version > 1.1", and can not express the restriction "P2Version < 1.4".  In the normal case, this doesn't matter.  It only matters if some operation tries to upgrade P2 to version 1.4.  In that case, SAT will report an error, while MVS will not.  When using MVS, if the incompatibility is not a compilation error, it may cause a failure long after the fact.
No doubt the SAT supporters see other major problems with MVS, but so far this is the one that I understand.
I think it's worth noting that if the restriction expressions are themselves versioned--if they are part of a specific release of P1--then in the normal course of events, before P2 version 1.4 is released, P1 version 2.2 will happily say "P2Version > 1.1".  It is only when P2 version 1.4 is released that the P1 authors will notice the incompatibility, and release P1 version 2.3 with "P2Version > 1.1 and P2Version < 1.4".  So if you are using P1 version 2.2, neither SAT nor MVS will report any problem with upgrading P2 to version 1.4, although it will fail in some possibly subtle way.
In other words, while it makes perfect sense for a release of P1 to list minimum compatible versions of P2, if the release does work correctly with the most recent version of P2, then it does not make sense for a release to list maximum compatible versions.  The maximum compatible version will be either conservative, and therefore increasingly wrong as newer and better versions of P2 appear, or if P2 changes in some incompatible way in the future, will fail to specify that requirement since at the time of the release it doesn't exist.
So if we want to have a system that defines anything other than minimum version requirements, then those requirements must not be part of a specific release, but must instead be part of some sort of metadata associated with the package, metadata that can be fetched at any time without updating the package itself.  And that means that the operation "update this package" must be separate from the operation "check whether my current package versions are compatible."
I would claim further--and this is definitely more tenuous than the above--that if "check whether my current package versions are compatible" fails, that it is in general unwise to trust any tool to resolve the problem.  If the compatibility problem can not be solved by the simple operation "upgrade every relevant package to the current version", then it requires thought.  A tool can guide in that thought, but in general it can't replace it.  In particular it seems very unwise for a tool to start downgrading packages automatically.
So if we think in terms of

a way to define package metadata describing package incompatibiliities
based on that, a tool that reports whether your current packages are compatible

then perhaps some of the major differences between MVS and SAT become less important.

Thanks for saying that so well Ian. To follow up, once we have established versions and vgo, we absolutely want to have a new godoc.org (maybe a different name) that records additional information about packages, information that the go command can consult. And some of that information would be pair-wise incompatibility that the go command could report as warnings or errors in any particular build (that is, reporting the damage, not trying to hide it by working around it). But having versions at all in the core toolchain is the first step, and that, along with just minimal version requirements and semantic import versioning, is what has been accepted in this issue.

We are committed to landing this as smoothly as possible. That will require additional tooling, more educational outreach, and PRs to fix issues in existing packages. All that was blocked on accepting this proposal, since it seemed presumptuous to move forward without the overall approach being accepted. But the proposal is accepted, and work will start landing more aggressively now that the uncertainty is over.

I had the same thought about external info for version compatibility... since version compatibility must be constant across , it doesn't need to be in source control (and in fact being in source control is a definite disadvantage as stated above).  It would be nice if there were a proposed solution for this, since it definitely seems to be the one major problem with MVS as proposed.

It's awesome to see the discussion moving organically in this direction. It has been a one central thrust of my concerns, and it makes it so much easier to explain foundational issues when folks are already most of the way to it.
@ianlancetaylor, i think you're spot on with this observation about needing to be able to make changes to constraint information on already-released versions. As @rsc indicated, such a service is something we've discussed/i suggested in our meetings. We could do it with godoc.org, or something else, sure. But i actually don't think it entails a separate service, and it would be better without one. I made a quick reference to this in the piece i published on Friday (just up from that anchor). If nothing else, in a service, there are questions that then have to be answered about whose declaration of incompatibilities should show up in warnings, which means handling identity, and how we scope declarations to particular situations in the depgraph. Keeping the declarations inside metadata files means we don't have to worry about any of that. But more on that in a sec.
What's really important here is this point, though maybe not the way you intended it:

perhaps some of the major differences between MVS and SAT become less important.

The suggestion of a meta-tool that does this search - yes, that's a SAT search - as a solution to the problems folks are identifying is telling. It's pretty much exactly what we'll have to turn dep into, if MVS goes ahead as described. And the first thing to note there is that, if we're so concerned about these incompatibilities that we're talking about a search tool, then what we're actually saying is that MVS becomes just a step in a larger algorithm, and the grokkability benefits go right out the window.
Except it's worse than that, because no amount of meta tooling can get around the baked-in problem of information loss that arises from compacting minimum and current versions together. The big result of that is cascading rollbacks, which means that actually trying to remediate any of the incompatibilities in this list will very likely end up tossing back other parts of the dependency graph not-necessarily-related to your problem. And, developers won't be able to follow an update strategy that isn't harmful to others.. (Oh, and phantom rules, but that's just an MVS side effect in general).
This is why i've asserted that MVS is an unsuitable intermediate layer on which to build a higher-order tool like this - "not fit for purpose." It's clear that folks believe these incompatibilities will occur, so MVS Is just taking a hard problem and making it harder.
If instead, we unify the problem of an "incompatibility service" back into a metadata file, then i believe it's possible, using only a simple set of pairwise declarations, to achieve the same effect. (This is a draft of the concept, but it increasingly seems to hang together)
It would entail that parts of MVS change, but MVS could still run atop the information encoded there. That'd mostly be useful if incompatibilities truly go nuts, and you want to just avoid all of them. But the primary algorithm would start from a baseline that looks like MVS, then switch to a broader search (to be clear, MVS itself should still be considered search), without the possibility of moving into absurdly old versions.

@sdboyer

The suggestion of a meta-tool that does this search - yes, that's a SAT search

Can you be more specific? The sentence you quoted is right after Ian suggesting a tool to report whether the selected versions are compatible - and to the best of my knowledge, that is the main alternative suggested here (it certainly is what I intended above). That problem most definitely is not a search and it's trivial and doesn't require solving SAT (it is just evaluating a boolean formula for a given set of values, not trying to find values that satisfy it).

Right, simply reporting that there are some known-incompatible values in the formula does not require solving SAT. Taking any action on that basis, such as for a tool that assists in the process of finding a result with no such values in it.
I quoted that sentence not because i think it is indicative of people having accepted search as always necessary, but because if we believe that reporting those such conditions is important, then it is because we believe it is likely we will encounter such scenarios.
the problem is, once the plausibility and the importance of addressing those cases gets established, it looks like folks then make the erroneous jump that "we can just do all the search things on top of MVS, and it'll be fine." we can, but such attempts become much trickier to deal with because of the useful possible paths that MVS cuts off, by design.
On May 28, 2018 4:02:13 PM EDT, Axel Wagner<EMAIL_ADDRESS>wrote:

@sdboyer

The suggestion of a meta-tool that does this search - yes, that's a
SAT search

Can you be more specific? The sentence you quoted is right after Ian
suggesting a tool to report whether the selected versions are
compatible - and to the best of my knowledge, that is the main
alternative suggested here (it certainly is what I intended above).
That problem most definitely is not a search and it's trivial and
doesn't require solving SAT (it is just evaluating a boolean formula
for a given set of values, not trying to find values that satisfy it).
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/golang/go/issues/24301#issuecomment-392595150

I quoted that sentence not because i think it is indicative of people having accepted search as always necessary, but because if we believe that reporting those such conditions is important, then it is because we believe it is likely we will encounter such scenarios.

To be clear: The suggestion of retrofitting upper bounds in this way is purely reactive to concerns brought up and to show that it can be done (to critically question the claim that MVS is fundamentally unfit for purpose). It seems a bit unfair to take that concession and willingness to compromise as proof that we think you were right all along.
To me, that claim (that MVS is unfit and an essentially irreversible step in the wrong direction) is what I am personally challenging and the lens I am reading your arguments through. One of those arguments was, that it's a feature if we can declare incompatibilities and have the version selection algorithm fail when they are encountered. Another fair argument is, that if they occur, it would be nice to have the algorithm be able to solve them for us (which would indeed require a SAT solver).
However, while I think those are valid and fair concerns, I don't believe they pass the bar of proving to me that MVS is fundamentally unfit. I still believe MVS as a starting point brings good and important features to the table. And that if those concerns turn out to cause significant pain in practice, there are still lots of ways we can iterate on that - from adding upper bounds (whether as part of go.mod or as a separate service) with pure failures up to and including adding a full SAT solver and lock files at some point. I.e. I agree with you that those things will happen, but a) am (maybe naively) optimistic that they won't cause as much pain as you are anticipating and b) that they are solvable problems even when we start off with MVS.

It occurs to me that something outside of source control determining compatibility would change the determinism of an MVS system. If you have foo >= 1.5.0 as a constraint in one lib, and another lib has foo >= 1.6.0. Then put those two in a binary and they choose 1.6.0. In MVS this is all you need for a repeatable build.  it'll always choose 1.6
But if you add external compatibility to the mix, then you could update that first library  to say it's not compatible with 1.6, and then the algorithm would choose 1.7, even though the code hasn't changed... Which means you'd need a lock file again.
For reference, I don't think a lock file is a bad thing.  It's nice to have an explicit list of exactly what you need to build.  And that should make it fast. No magic logic needed.

@natefinch If the application's go.mod file was updated to require v1.7.0 because the external compatibility tool indicated v1.6.0 was incompatible, you wouldn't need a lock file. Because specifying v1.7.0 lives in the go.mod file the author could also add a comment saying why v1.7.0 is being used and that information would be useful to readers.

@leighmcculloch , if any files in app are updated then it is a different build and totally outside the scope of "reproducible build without lockfile" problem.
out-of-band compatibility information is proposed to reflect how knowledge develops: no incompatibilities were known at release time, but then it became apparent and extra information is published regarding already released versions. IMHO by definition this approach leads to a change how dependencies are pulled, otherwise why have this extract incompatibility information at all?

@redbaron @natefinch
The point of the incompatibility information is for authors of libraries to communicate incompatibility information to their users. Whether that information is used at build or at release time is a different question.
In vgo's case, the current idea is to only display warnings (or potentially croak). But notably not to let it influence the choice of of versions used (as that would require solving SAT). So it actually doesn't matter, you can use it at either or both and it will fulfill it's duty just fine, while retaining the property of repeatability¹.
In dep, this information is only used at release time and then recorded to a lock file, which is used at build time. So it seems that we are considering a release-time use "good enough" anyway, at least when it comes to concerns of vgo vs. dep.
I still don't think we have to actually answers those questions right now, though.

[1] Personally, I'd argue that using it at release time and only if -v is used at build time is better, because a user shouldn't have to decide whether a warning is actionable or not.

@rsc wrote:

To follow up, once we have established versions and vgo, we absolutely want to have a new godoc.org (maybe a different name) that records additional information about packages, information that the go command can consult. And some of that information would be pair-wise incompatibility that the go command could report as warnings or errors in any particular build (that is, reporting the damage, not trying to hide it by working around it).

I'm wondering if it is necessary to record pair-wise incompatibility. The way I see it currently is that any incompatibility between module A@vN and module B@vM is really because B made an incompatible change from some version vL where L < M.
If module B did not make an incompatible change, then module A just has a bug. If it did, then the issue is about B itself, not about the pairing of A and B.
So ISTM that any public repository of module metadata can record only incompatibilities of any module with previous versions of itself, which may make the problem more tractable. These incompatibility reports are quite similar to bug reports, although they're not resolvable because once a version is published, it cannot be changed.
When you upgrade your module versions, the go tool could consider the metadata and refuse to consider a version that's incompatible with any currently chosen version. I think this avoids the need to solve SAT. It could also decide that a given module has too many incompatibility reports and refuse to add it as a dependency.
A set of tuples of the form (module, oldVersion, newVersion, description) might be sufficient.

the go tool could consider the metadata and refuse to consider a version that's incompatible with any currently chosen version

Of course, this doesn't work when you're adding several dependencies, which between them end up requiring using mutually incompatible versions, because the new versions aren't part of the existing module, but there might be a reasonable heuristic available. It's not crucial AFAICS, because dependencies should be added relatively rarely.

I worry that go release is becoming this discussion's "sufficiently smart compiler". What can users concretely expect from go release in Go 1.11/12? I think that makes a difference for what reasonable expectations around MVS/SVI are.

Thanks for the energy so many of you have brought to Go and this proposal in particular.
The first goal of the proposal process is to "[m]ake sure that proposals get a proper, fair, timely, recorded evaluation with a clear answer." This proposal was discussed at length and we published a summary of the discussion. After six weeks and much discussion, the proposal review committee - stepping in as arbiter because I wrote the proposal - accepted the proposal.
A single GitHub issue is a difficult place to have a wide-ranging discussion, because GitHub has no threading for different strands of the conversation and doesn't even display all the comments anymore. The only way a discussion like this works at all is by active curation of the discussion summary. Even the summary had gotten unwieldy by the time the proposal was accepted.
Now that the proposal is accepted, this issue is no longer the right place for discussion, and we're no longer updating the summary. Instead, please file new, targeted issues about problems you are having or concrete suggestions for changes, so that we can have focused discussions about each specific topic. Please prefix these new issues with “x/vgo:”. If you mention #24301 in the text of the new issue, then it will be cross-referenced here for others to find.
One last point is that accepting the proposal means accepting the idea, not the prototype implementation bugs and all There are still details to work out and bugs to fix, and we'll continue to do that together.
Thanks again for all your help.

There's more work to be done (see the modules label) but the initial module implementation as proposed in this issue has been committed to the main tree, so I am closing this issue.


[MM-9937] [MM-9938] slash command response parameters update

These params were added per the following PRs:
https://github.com/mattermost/mattermost-server/pull/9878
https://github.com/mattermost/mattermost-server/pull/9836
I noticed that trigger_id is missing from the params in the documentation. Is this something that should be documented for custom slash commands?

Both related PRs have been approved now. This is ready for review.

@lieut-data updated with requested changes


TypeError: Parameters to generic types must be types. Got <BaseTypes.PhoneNumber: 5000>.

C:\Users\john\RFGuess>python main.py
Traceback (most recent call last):
File "C:\Users\john\RFGuess\main.py", line 2, in
from ui.slots import *
File "C:\Users\john\RFGuess\ui\slots.py", line 18, in
from Generators.GeneralPIIGenerators import *
File "C:\Users\john\RFGuess\Generators\GeneralPIIGenerators.py", line 4, in
from Parser.GeneralPIIParsers import *
File "C:\Users\john\RFGuess\Parser\GeneralPIIParsers.py", line 3, in
from Parser.PIIParsers import *
File "C:\Users\john\RFGuess\Parser\PIIParsers.py", line 608, in
class PIIToTagParser:
File "C:\Users\john\RFGuess\Parser\PIIParsers.py", line 750, in PIIToTagParser
def parsePhoneNumToTagDict(cls, phoneNum: str) -> typing.Dict[BasicTypes.PIIType.BaseTypes.PhoneNumber, list]:
File "C:\Programs\Python\Python39\lib\typing.py", line 275, in inner
return func(*args, **kwds)
File "C:\Programs\Python\Python39\lib\typing.py", line 827, in getitem
params = tuple(_type_check(p, msg) for p in params)
File "C:\Programs\Python\Python39\lib\typing.py", line 827, in
params = tuple(_type_check(p, msg) for p in params)
File "C:\Programs\Python\Python39\lib\typing.py", line 164, in _type_check
raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Parameters to generic types must be types. Got <BaseTypes.PhoneNumber: 5000>.

Hi, it seems like you are using a python interpreter older than 3.9, just move to 3.11 and this problem will disappear.


Remap postinstall to npx godmode install --all

This should just be used for testing and creating core methods but the compiled contracts should not be apart of source

Closing bc we don't want this as an automatic postinstall for all users downloading godmode

Closing bc we don't want this as an automatic postinstall for all users downloading godmode


Fix bad link rendering

These files are not links, render them as code instead.
Signed-off-by: James Slagle<EMAIL_ADDRESS>As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date:

[x] README in the role
[x] Content of the docs/source is reflecting the changes

/approve


fix: release pipeline

fixes #327

Description of changes

Added workflow_dispatch so that we can manually run If release pipelines fail sometimes. or in any other case
Updated to checkout@v3, not a required change. But things should be updated to LTS.
Updated to<EMAIL_ADDRESS>which fixes all our pain of weird versioning, not working in forks, etc.
Added Path Filters provided by GitHub Actions by default. So it will trigger this release action only when it detects changes on the main branch and installer directory.

Hey Siddhant, thanks for the PR!
After reading the docs of the paulhatch/semantic-version GH Action, I believe the proposed change won't fix the pipeline 😬. It will just change from vMAJOR.MINOR.PATCH to vMAJOR.
Not sure how we can test this also 🤔, maybe we want to 3 test it in a separate repository first

maybe we need to use different release action. Also, I can test in out in my fork.

It will just change from vMAJOR.MINOR.PATCH to vMAJOR

The reason to do that was same since it will create 0.3 -> 0.4 instead of 0.3+1. So that the current Release action would create a new release instead of updating it existing assets.

It is working now, updated my README w/ explaining all the changes. Tested here on my fork:

Thank you @Siddhant-K-code for looking into this 🙏


Require scalaVersion

@tpolecat wrote https://twitter.com/tpolecat/status/789288986258931712:

I think sbt should not start up unless you specify scalaVersion. Beginners think it uses the "installed" Scala which leads to suffering.

This would break the existing behavior where the build would function without any build files, which allows things like sbt new. Additionally not all sbt projects are Scala projects.

Will have to workaround it for sbt new, but the plan is to require sbt.version in project/build.properties (possibly by prompting the user to confirm to create one).
With regards to non-Scala projects, I think perhaps we need to just leave scalaVersion undefined, which is fine for non-Scala projects.

Link to requiring sbt.version: #754 and #2668

Yeah, I realize there are some corner cases. But I think at least some kind of mechanism that checks for the version would help people out. I spent some time with a frustrated doobie user last night who honestly though he was using 2.11 but was actually using 2.10 (which requires the paradise plugin for some generic derivations but not others, so he was seeing random implicit not found errors).

Not defaulting scalaVersion would make it fail early. The question is how it badly explodes..
@tpolecat do you feel like trying it out for 1.0.x?

I'd suggest starting without scalaVersion, but not providing Scala libraries by default. (Basically the opposite of autoScalaLibrary := false).
It would be a lot more consistent with other possible library dependencies like Guava, Apache Commons or Spring which are not added "just in case".
This would make it much easier for SBT to gain more adoption outside of the Scala ecosystem.

scala-library isn't added "just in case", it's added because sbt, even though sbt supports non-Scala projects, it started as a Scala build tool. So I think autoScalaLibrary defaulting to true is correct.

Do we have no larger ambitions than being a "Scala" build tool?
As an example, Gradle has been very successful not being a "Groovy" build tool.

It does, that's why I said started.
It's definitely used mostly for Scala projects over any other language, so defaulting to true makes sense.

It's definitely used mostly for Scala projects over any other language, so defaulting to true makes sense.

Isn't that confusing cause and effect?

I don't think sbt isn't used mostly for Java projects because of this default value.
Not having autoScalaLibrary at all would be detrimental to any uptake in other languages, but that's not the case here.
If over the next few years sbt successfully gains a huge number of non-Scala users then for 2.0 we should reconsider this choice. For now I don't think it's a good idea.

If over the next few years sbt successfully gains a huge number of non-Scala users then for 2.0 we should reconsider this choice.

I think it's sure as hell that this won't ever happen if non-Scala devs are treated as second-class citizens.

Not sure this is related but the default scalaVersion is 2.12.7 with sbt 1.2.6. Should this be changed to 2.12.8, the latest production version?

It's already changed for the next production version: https://github.com/sbt/sbt/pull/4509.  It just hasn't been released (unless you're running sbt 1.3.0-M1, but I don't recommend it seeing as both the supershell and update have some serious issues.)

Thanks, @dwijnand

If we think about this as removal of having an implicit scalaVersion, maybe I should start displaying warnings.

Currently (as of sbt 1.6.2) the default is 2.12.15. I would suggest:

default to latest 2.13.x release at the time

(one could also argue for defaulting to latest 3.x)

printing a warning when it does so

The sin of sbt 1.x, is that it was released in 2017, and sbt 2.x hasn't been developed. sbt 1.x should keep the build semantics, which means defaulting to 2.12.
If we ship sbt 2.x with Scala 3 in the build definition, the implicit scalaVersion will be Scala 3, which at some point will also be called old.
The only way to avoid being tied to an old Scala version, is to not allow blank Scala version as suggested by this issue.

I see. Well, a warning would be nice, at least.


Event Details Page: Add edit , delete, archive, and attend buttons (UI only)

@Ali-7s An update to this issue is that we should add text labels for the edit, delete and archive buttons, for ease of use for the user.
Here's an updated visual:


ci: update image targets and node.js version

Changes
Summary of changes included in this PR:

[ ]
[ ]
[ ]

Issues Completed

Closes #
Closes #

CC - @traviskosarek @calebcartwright

Oh Windows...


Node occasionally crashes on mainnet

Don't know how big of a deal this is because a restart normally fixes, but this happens pretty regularly (about once every hour):
...
new block: 5976345<PHONE_NUMBER>
new block: 5976346<PHONE_NUMBER>
Processing 1 logs
Fatal Error, shutting down servers { Error: SQLITE_CONSTRAINT: CHECK constraint failed: nonnegativeBalance errno: 19, code: 'SQLITE_CONSTRAINT' }
Fatal Error: { Error: SQLITE_CONSTRAINT: CHECK constraint failed: nonnegativeBalance errno: 19, code: 'SQLITE_CONSTRAINT' }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `node ./build/runServer`
npm ERR! Exit status 1
...

Unsure why that nonnegativeBalance constraint wouldn't hold with mainnet data--any ideas what could be causing?
For context, I'm running in a container with the augurproject/augur-node:core-1.0.0-20 docker image, with ETHEREUM_WS pointing at Infura.

Not actually using the augur app, but was using the second-most up-to-date docker image here: https://hub.docker.com/r/augurproject/augur-node/tags/
I'll close this for now and reopen if I keep seeing it.


Not able to interact with Team. Conflicting UI messages

I was recently added to a Team. I can't see other members or interact with them.
$ keybase team request-access <redacted>
▶ ERROR You are already a member of this team (code 2665)

https://www.dropbox.com/s/2v9y2hz7sowpqhr/Screen Shot 2019-03-07 at 6.41.36 AM.png?dl=0
https://www.dropbox.com/s/5ryvf3rf3tlv708/Screen Shot 2019-03-07 at 6.41.19 AM.png?dl=0
https://www.dropbox.com/s/b28r22p9pid8kfp/Screen Shot 2019-03-07 at 6.45.14 AM.png?dl=0
my log id: 7a47dc856e9dd3f31deb581c

This resolved itself sometime in the last 2 hours. Hopefully this report is useful for future UX improvements. I'm closing it now, but I would be happy to provide additional information if you would like.

We'll take a look, thanks for the report.


Got stuck with running phase 3

I tried to run the given command:
./benchmark.sh run --workload unet3d --num-accelerators 4 --results-dir unet3d_results --param dataset.data_folder=unet3d_data
But got this:
Error executing job with overrides: ['workload=unet3d', '++workload.workflow.generate_data=False', '++workload.workflow.train=True', '++workload.dataset.data_folder=unet3d_data', '++workload.workflow.profiling=False', '++workload.profiling.profiler=none']
I'm not sure which configurations to change or how to debug this. Please help, thanks!

I tried the ones below and it worked. However, when I run phase 4, I got this:
2023-12-21 23:02:35 Error: Directory structure results/unet3d/2023-12-21-22-58-30/summary.json is not correct. It has be in format result_dir/run(1..n)/host(1..n)/summary.json


Integrating Sentry outside request context in AdonisJS

Hi, everyone!
I am using Sentry integrated with the IoC Container and HttpContext in my AdonisJS application. The installation and configuration of Sentry are working perfectly to capture errors within the HTTP request context. However, I have no idea how to integrate Sentry outside of this context, specifically in asynchronous methods and jobs.
Below is an example of a job I am using:
import { Job } from '@rlanz/bull-queue'

export default class TestJob extends Job {
  static get $$filepath() {
    return import.meta.url
  }

  async handle() {
   // How do I log a message in Sentry?
   }

  async rescue() {}
}

Can anyone guide me on how to access the Sentry service outside the request context, in asynchronous functions and jobs?
Thank you!

I arrived at the following solution, but I don't know if it is correct:
import { inject } from '@adonisjs/core'
import { Job } from '@rlanz/bull-queue'
import { Sentry } from '@rlanz/sentry'

@inject()
export default class TestJob extends Job {
  constructor(protected sentry: Sentry) {
    super()
  }

  static get $$filepath() {
    return import.meta.url
  }

  async handle() {
    console.log(this.sentry.getUser()) // test sentry
    return
  }

  async rescue() {}
}

Is the only way to access the sentry out of context through injection?

I arrived at the following solution, but I don't know if it is correct:
import { inject } from '@adonisjs/core'
import { Job } from '@rlanz/bull-queue'
import { Sentry } from '@rlanz/sentry'

@inject()
export default class TestJob extends Job {
  constructor(private sentry: Sentry) {
    super()
  }

  static get $$filepath() {
    return import.meta.url
  }

  async handle() {
    console.log(this.sentry.getUser()) // test sentry
    return
  }

  async rescue() {}
}

Is the only way to access the sentry out of context through injection?

Hey @joaosilva0345! 👋🏻
Yes, it is the way!

Thank you.

I tried to do the same in a command, but calling super() is a bit more complex. @RomainLanz do you have an idea of how I might access Sentry from a command? startApp is set to true, which I thought could load it up automatically for me.

You can inject inside the run method directly!
export default class CustomCommand extends BaseCommand {
  static commandName = 'custom:command'
  static description = ''

  static options: CommandOptions = {
    startApp: true,
  }

  @inject()
  run(action: TheServiceIWantToInject) {
    // ...
  }
}

Oh, this is neat! Thank you @RomainLanz!


Add pallet-contracts support as a pallet-evm Runner

This adds basic pallet-contracts support by implementing it as a pallet-evm Runner.
We implement Runner::call and Runner::create, but not Runner::create2, because the latter is never directly called in an Ethereum transaction.
The implementation of Runner::call is straightforward. For Runner::create, we "abused" the init field to hold a SCALE encoded tuple (code: Vec<u8>, init_data: Vec<u8>, salt: Vec<u8>), and implemented it that way.

Question: Does this mean that the frontier can support ink contact with the Ethereum RPC layer?

Any updates here?

This was only an experiment. We decided to go down a different route. Instead of adding support to frontier we are creating a solution more similar what Acala is doing: Having a stand alone proxy translation server that  translates Eth RPC to Substrate unchecked extrinsics. This will allow it to work without adding support to each client.
Please note that even with that it will not work with ink! out of the box. Ink needs support for Ethereum ABI to make this any useful.

Won't go on. Close it.


Margins for the gBar.

Describe the bug
Im currently editting the C++ to my liking and I seem to be unable to effectively adjust the padding on the sides of the bar so that it seems to be floading instead of flush with the side of the monitor. I was able to do this but all the widgets are spread out. I was wondering if there is a better way to do this than what I am doing or if you could add a easier way to adjust the margins!
What doesn't work? Please be as precise as possible.
Setting padding in css doesnt work. I dont know if Im doing it right tho.
Steps to Reproduce
Bellow I will show What I did to get to the point where the widgets are super spread out. This is in the Widgets.cpp
void Widget::ApplyPropertiesToWidget()
{
    // Apply style
    auto style = gtk_widget_get_style_context(m_Widget);
    gtk_style_context_add_class(style, m_CssClass.c_str());
    for (auto& cssClass : m_AdditionalClasses)
    {
        gtk_style_context_add_class(style, cssClass.c_str());
    }

    gtk_widget_set_tooltip_text(m_Widget, m_Tooltip.c_str());

    // Apply transform
    gtk_widget_set_size_request(m_Widget, m_HorizontalTransform.size, m_VerticalTransform.size);
    gtk_widget_set_halign(m_Widget, Utils::ToGtkAlign(m_HorizontalTransform.alignment));
    gtk_widget_set_valign(m_Widget, Utils::ToGtkAlign(m_VerticalTransform.alignment));
    gtk_widget_set_hexpand(m_Widget, m_HorizontalTransform.expand);
    gtk_widget_set_vexpand(m_Widget, m_VerticalTransform.expand);

    // Adjust margin properties
    gtk_widget_set_margin_start(m_Widget, 10);
    gtk_widget_set_margin_end(m_Widget, 10);
    gtk_widget_set_margin_top(m_Widget, 5);
    gtk_widget_set_margin_bottom(m_Widget, 5);

    if (m_OnCreate)
        m_OnCreate(*this);
}

Expected behavior
I thought that I would be able to change the widget padding or margins and the other widgets would adapt. Idk there must be a better way right?
Screenshots/Error logs
Disregard the two bars one of them is the one on startup. just look at the 2nd one. I haven't worked too much with the css because I believe it isnt something that cant be fixed with a simple padding or width tag. anyway here is a screenshot of what it looks like. IDK how to take a screenshot on arch yet but I took a pic on my phone. Please Let me know if there is an easier way to do what Im trying to do. Ive spent Entirely too much time working on this lol. I also want to add in the end here that I think this is one of the coolest things to make. I congratulate you on this my guy its awesome. Its so minimal and just makes sense. I dont understand why there arnt more widgets and stuff like this. Anyway, just let me know if there is anything you found or anything I can do to aid in this fix. IF you font get to it no big deal I just would like to have a floating bar!!!

Widget::ApplyPropertiesToWidget is a function, which is called when creating a widget (as in element of a window, not as the bar itself), so the hardcoded margin is applied to every element. If you really want to do this in C++ (which I don't recommend), then you can have a look at src/Bar.cpp and then call SetVerticalTransform/SetHorizontalTransform on mainWidget with Transform::marginBefore/marginAfter as the margin
Though it can also be done with css (Which I'd recommend):
.bar {
	margin-top: 20px;
	margin-left: 20px;
	margin-right: 20px;
}

It worked man thanks so much and keep making amazing stuff


[QUESTION/POSSIBLE USER ERROR]: AXI-Stream VVC byte_endianess not working?

Explanation and question
How does the byte_endianness work with regards to the t_axistream_bfm_config and its associated VVCs?
It seems to have no effect on the output and input of the VVCs whenever I change it?
I have tried both FIRST_BYTE_LEFT and FIRST_BYTE_RIGHT (the others as well actually), but there is no change in byte order in Modelsims wave window?
It's probably a user-error on my part or something I have misunderstood.
Some configurations
32-bit bus interface but I use t_slv_array's with octet width in and out of the VVCs.
  constant my_axistream_bfm_config : t_axistream_bfm_config := (
    max_wait_cycles                => integer'high,
    max_wait_cycles_severity       => ERROR,
    clock_period                   => -1 ns,
    clock_period_margin            => 0 ns,
    clock_margin_severity          => TB_ERROR,
    setup_time                     => -1 ns,
    hold_time                      => -1 ns,
    bfm_sync                       => SYNC_ON_CLOCK_ONLY,
    match_strictness               => MATCH_EXACT,
    byte_endianness                => FIRST_BYTE_LEFT,
    valid_low_at_word_num          => 0,
    valid_low_multiple_random_prob => 0.5,
    valid_low_duration             => 0,
    valid_low_max_random_duration  => 5,
    check_packet_length            => false,
    protocol_error_severity        => ERROR,
    ready_low_at_word_num          => 0,
    ready_low_multiple_random_prob => 0.5,
    ready_low_duration             => 0,
    ready_low_max_random_duration  => 5,
    ready_default_value            => '0',
    id_for_bfm                     => ID_BFM
  );

i_rx_vvc : entity bitvis_vip_axistream.axistream_vvc
    generic map (
      -- When true: This VVC is an AXI4 Stream master. Data is output from BFM.
      -- When false: This VVC is an AXI4 Stream slave. Data is input to BFM.
      gc_vvc_is_master => false,
      gc_data_width    => 32,
      gc_user_width    => 1,
      -- (Note: STRB_WIDTH = DATA_WIDTH/8)
      gc_id_width             => 1,
      gc_dest_width           => 1,
      gc_instance_idx         => 1
      gc_axistream_bfm_config => my_axistream_bfm_config
    )
    port map (
      clk              => csi_th_clk,
      axistream_vvc_if => axis_vvc_rx_if
    );

How to reproduce
Instantiate a "tx" and "rx" VVC, connect to a DUT (can be just a FIFO or a dummy black box transmitting the input to the output) and try all byte_endianness possibilities.
Solution for now
Implemented a "swap" function which swaps the bytes to desired byte order.

Hi,
Thank you for your message. We appreciate your report and our team will investigate the issue promptly.
Best regards,
Marius

Hi,
The config byte_endianness in AXI-Stream has 2 possible values: LOWER_BYTE_LEFT and LOWER_BYTE_RIGHT (FIRST_BYTE_LEFT and FIRST_BYTE_RIGHT are the same and will be removed, while LOWER_WORD_LEFT and LOWER_WORD_RIGHT are not used here).
The purpose of this config is to change the order of the bytes inside the array elements of a t_slv_array, e.g.
variable v_data_array_4_byte  : t_slv_array(0 to 1)(31 downto 0);

v_data_array_4_byte := (x"11223344", x"AABBCCDD");
axistream_transmit(AXISTREAM_VVCT, C_MASTER_IDX, v_data_array_4_byte, "4 bytes transmit");

With LOWER_BYTE_LEFT config, the order will be:
# UVVM: ID_PACKET_DATA                   125.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"11", byte# 0. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   125.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"22", byte# 1. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   125.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"33", byte# 2. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   125.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"44", byte# 3. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   142.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"AA", byte# 4. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   142.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"BB", byte# 5. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   142.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"CC", byte# 6. '4 bytes transmit'  [10]
# UVVM: ID_PACKET_DATA                   142.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"DD", byte# 7. '4 bytes transmit'  [10]

Whereas with LOWER_BYTE_RIGHT, the order will be:
# UVVM: ID_PACKET_DATA                   175.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"44", byte# 0. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   175.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"33", byte# 1. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   175.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"22", byte# 2. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   175.0 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"11", byte# 3. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   192.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"DD", byte# 4. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   192.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"CC", byte# 5. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   192.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"BB", byte# 6. '4 bytes transmit'  [16]
# UVVM: ID_PACKET_DATA                   192.5 ns  AXISTREAM_VVC,2                axistream_transmit(8 words[8b])=> Tx x"AA", byte# 7. '4 bytes transmit'  [16]

Is this how you intended to use it?

Hi.
Thanks for the response and sorry for late response. A lot going on.
Will follow up and check out suggestions.
Kind Regards

Hi, any updates on this issue?

Hi, any updates on this issue?

Hi. Have not had time. Sorry. Will check it out this week.

I

UVVM: ID_PACKET_DATA                   192.5 ns  A

Yes. This was the intention. But I did not seem to change the output as I would have expected. I have not been able to check it out any further since I mentioned the issue. But I was able to test it in the latest version and it worked as expected. I do not mind closing this issue. If anything I can reopen it at a later stage.
Sorry for the very late reply.
Kind Regards

Alright, then we can close this issue. Feel free to reopen it if needed.


Editor sometimes randomly "freezes" and alt+tab fixes it

Godot version
v4.1.1.stable.arch_linux
System information
Godot v4.1.1.stable unknown - Arch Linux #1 ZEN SMP PREEMPT_DYNAMIC Wed, 13 Sep 2023 08:37:16 +0000 - Vulkan (Compatibility) - Mesa Intel(R) UHD Graphics (TGL GT1) () - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads)
Issue description
Usually when I'm dealing with nodes and node logic, the engine "freezes". I say that in quotation marks, since it doesn't really freeze but no button or UI element responds to my inputs. With the nature of this bug in mind, here are the things I found out:

It doesn't happen while using the code editor, or at least I haven't seen that happen.
Whenever it happens, clicking randomly seems to fix it, though Alt+Tab works way better. It reliably fixes it 100% of the time.
Alt+Tab works even if you have no other applications open in the workspace.
I don't remember it happening with my previous DE (KDE Plasma)

Extra system information
I have a hunch that this is DE-specific, so I'll put my full neofetch output here:
>> neofetch
      /\         p@PC
     /  \        ----
    /\   \       OS: Arch Linux x86_64
   /      \      Host: Nitro AN515-57 V1.19
  /   ,,   \     Kernel: 6.5.3-zen1-1-zen
 /   |  |  -\    Uptime: 1 hour, 48 mins
/_-''    ''-_\   Packages: 1061 (pacman)
                 Shell: zsh 5.9
                 Resolution: 1920x1080
                 DE: Xfce 4.18
                 WM: Xfwm4
                 WM Theme: Alternate
                 Theme: Adwaita-dark [GTK2], Breeze [GTK3]
                 Icons: Adwaita [GTK2], breeze-dark [GTK3]
                 Terminal: xfce4-terminal
                 Terminal Font: Monocraft Medium 9
                 CPU: 11th Gen Intel i7-11800H (16) @ 4.600GHz
                 GPU: NVIDIA GeForce RTX 3050 Ti Mobile
                 GPU: Intel TigerLake-H GT1 [UHD Graphics]
                 Memory: 4009MiB / 15771MiB

Steps to reproduce

Open a project.
Work on it for a while.
Editor becomes unresponsive, Alt+Tab fixes it.

Minimal reproduction project
I'll upload one if necessary.

UPDATE: I could also replicate it with Hyprland.


SwiftCompilerSources: support Undef.parentFunction and PlaceholderValue.parentFunction

After support in the C++ SIL (https://github.com/apple/swift/pull/71879), we can implement parentFunction for those values in swift, too. It simplifies a few things.

@swift-ci test

@swift-ci test

@swift-ci test


TrinPod Inference: more triples returned than test expects

With the TrinPod system, we infer new triples from RDF data as well as create state and attribute objects that are returned to the application.  Because of this, more triples are returned in the test than current tests expect.  For the time being, we consider it a pass if all required triples are returned in the test and ignore the extra triples that are returned.  Maybe tests could just focus on confirming all required triples are present.
As a key issue with RDF is how to mangage changing states over time, and the fact that a triple can't do that alone, other systems will likely also provide solutions to this problem.

latest test code fixed this issue - one pull away from success it seems

latest test code fixed this issue - one pull away from success it seems


Type Hints for Lightning Core

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos, doc improvements)
[x] Did you read the contributor guideline?
[x] Did you make sure to update the docs?
[ ] Did you write any new necessary tests?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

What does this PR do?
Follow up on #912 and discussed in #887.
Not high priority.
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

Let's wait until #833 is merged because I did minor documentation changes.

Hello @awaelchli! Thanks for updating this PR.

In the file pytorch_lightning/core/lightning.py:

Line 145:101: E501 line too long (104 > 100 characters)
Line 224:101: E501 line too long (101 > 100 characters)
Line 374:101: E501 line too long (107 > 100 characters)
Line 578:101: E501 line too long (104 > 100 characters)

@hanbyul-kim @Borda
I get many warnings when compiling the docs. Funny thing, the number of warnings changes everytime I run make html.
Most of them are import problems. I tried changing my path variable, didn't help.
WARNING: autodoc: failed to import module 'trainer.training_loop' from module 'pytorch_lightning'; the following exception was raised:
cannot import name 'LightningModule' from 'pytorch_lightning' (/home/adrian/repositories/pytorch-lightning/pytorch_lightning/__init__.py)

It is also happening on master. Should I open an issue or do you know a quick fix?

@hanbyul-kim @Borda
I get many warnings when compiling the docs. Funny thing, the number of warnings changes everytime I run make clean and make html (inside the docs folder).

if does not compile always everything, it uses a cache so if you clean in between compilations you will have the same number...

Most of them are import problems. I tried changing my path variable, didn't help.

have you rebased on master after #833 there was most of the imports resolved

It is also happening on master. Should I open an issue or do you know a quick fix?

That would be great! :robot:

will happily rebase on request :)

@williamFalcon ^^

It looks rather good; I like it. Maybe an appropriate next step would be to add a type checker such as mypy as as CI step?

hey there, we have added GPU CI test, so could we kindly ask to rebase/merge master which will trigger these tests so we do not need to test it manually... Thx for your understanding :robot:

It looks rather good; I like it. Maybe an appropriate next step would be to add a type checker such as mypy as as CI step?

good idea, do you want to send a PR? :]


32-bit pylsd-nova - ImportError: Cannot load dynamic library. Did you compile LSD?

I tried installing this on another Windows computer and now I keep getting this ImportError whenever pylsd is imported. May need to switch to a different library if no fix is available.

Yeah im having the same issue here

pylsd is not supported in python 3, that's your issue. Ill see if I can find a fix

I'm using pylsd-nova, which does have python 3 support. This works fine on my computer running Windows and python 3.8, but not on a computer at my school running the same thing.
There's another py3 fork called ocrd-fork-pylsd. Can you try using that instead and see if it makes any difference?
pip uninstall pylsd-nova
pip install ocrd-fork-pylsd

Sure Ill give it a go, I tried to use pylsd-nova but I am running python 3.6 and it didn't work; could be something up there.

Just tried now and it didn't import, gonna try use pylsd-nova on python 3.8.5

I have the same error, and had the same results from trying ocrd-ford-pylsd =(

Switching to python 3.8.5 hasn't helped. I'm gonna see if I can figure out why

I don't have experience with python, but I found this StackExchange question, does it help? https://stackoverflow.com/questions/52288690/pyinstaller-unable-to-import-pylsd-while-creating-exe-file

Yeah I've just noticed that its looking for a lib called lsd and I can't find one on pypi. There is a lsd lib but its for converting currencies

The issue is coming from pylsd-nova as ocrd-pylsd-fork does not have this issue. But it has its own issues. A little confusing and the person who made pylsd hasn't responded to any of the issues that people have flagged since 2018

shoot. Is there another library we can use?

I dont think so, but I've just noticed that it uses c++ and c and so maybe its got something to do with that. I don't have either installed with visual studio so I'm gonna install and see if it fixes anything

I think I have found the issue, I am on x86 and pylsd is looking for a dir called win32/x86/lsd.dll but for some reason there is only win32/x64/lsd.dll @n0spaces may be on x64 and that's why its working for him.

Looking into that, I found this article: https://stackoverflow.com/questions/27816562/what-does-struct-calcsizep-exactly-mean
If it will fix the problem, could we / how do we change the line 'if sys.maxsize > 2 ** 32:' to 'if struct.calcsize('P') > 5:'  (also very new to Git =)

Ill give it a go when I'm back at my pc

So I can change it, but we will need to include it in the repo or maybe make a fork of it or something. Dont fully know how that would work either

So, have you found any solutions?

Since pylsd isn't compatible with Windows 32-bit versions of Python, right now the solution is to just use 64-bit Python instead. AFAIK the only thing stopping pylsd from working on 32-bit Python is a missing lsd.dll file for x86, so I'll see if that's something that can be compiled.

quick question, i had this problem until i downloaded 64bit version, now where do i put the image i wanna meme (input.png)?

@thunderkai Glad to know it's working. The image can be wherever you want, you just have to make sure it's in your current directory in the terminal or use the full file path in the command.
gsbl C:\path\to\input.png C:\path\to\output.mp4
Also if you have any questions that aren't relevant to this issue, please open a new one and ask there.

Im gonna try with 64 bit

https://github.com/AndranikSargsyan/pylsd-nova/issues/1 Pylsd has been upgraded to support x86

Awesome! I just pip uninstall pylsd-nova and pip install pylsd-nova and it works perfectly!

That update has fixed it! Nice work everyone

requirements.txt still forces pylsd-nova 1.0.0 to be installed. I'll fix that tonight and release a new version.
Also FYI pip install --upgrade pylsd-nova should also work.
Thanks for the help everyone!

Yeah, and if you are using pycharm you can go to setting > project interpreter > PROJECT_NAME > pylsd-nova and click the triangle on the right bar to upgrade. Pycharms project management is very useful.

I found this repo through the opened issue on pylsd-nova repository. Really nice meme generator :D By the way, you can get better line segments by playing with lsd parameters via pylsd-nova's binding. For example you can try to change scale parameter like this segments = lsd(im_gray, scale=0.4). There are many other parameters described in pylsd-nova's readme file which you can try.

Thanks! Yeah I know there's a lot that can be improved, I just haven't gotten around to it yet.
Closing as I updated requirements.txt and uploaded a new release to pypi.


RD2: Hide Upgrade Page When RD2 Upgrade Is Completed More Than 7 Days

As a user who is already on Enhanced Recurring Donations, I do not need to see a section to upgrade to Recurring Donations.
Critical Changes
Changes
Issues Closed
Community Ideas Delivered
Features Intended for Future Release
Features for Elevate Customers
New Metadata
Deleted Metadata

W-7780247