contrib/implements: replace castxml with cc library

This change removes the dependency on the external castxml tool. Instead it makes use of the cc library.
After some iterations and effort, this is now completely independent from system header files, with the ceph header files being the only remaining external dependencies. The tool looks for them in the working directory, /usr/local/include and /usr/include, in that order. If necessary, this could also be made configurable in following PR.

That's true, and perhaps it just a language/wording issu but when you return to the root of the repo the readme there says:
2020-07-13 This package is no longer maintained. Please see the v3 version at
https://modernc.org/cc/v3

But I guess the authors only intend that message to apply to the non-v3 directory (?) I do see activity in the repo, and so I guess the whole thing isn't unmaintained, but that wording messes with my head.

Yes. As you can see from the wording of the readme ("This package..."), it's not written for the whole repository, it's written for the v1 package in the root directory, because that is the readme, that is also used for the package docs. If you use this kind of subdirectory convention, the only way to deprecate v1 in the docs is to write that in the readme in the root directory, which is kind of unfortunate, because it leads to this kind of confusion. Or what would you do?
Anyway, the v3 is beyond doubt very alive, as you saw in the history.

One more thing that was bothering me (and I was having trouble expressing my thoughts in words as opposed to code) was that with the new dependencies in implements importers of go-ceph would be pulling in the dependencies of "implements". I read some docs and made some patches to prove to myself this isn't necessary. See: https://github.com/phlogistonjohn/go-ceph/commits/jjm-pr596-amend
I think with either the patches there, or something functionally equivalent, and if we clean up the dockerfiles to drop the dependency on castxml I'd be good with the PR. If you'd prefer to break some of these tasks up - I think we could do that for the dockerfile cleanup, but I'm not sure I'd want to merge the go.{mod,sum} dependencies. Thoughts?

That's a good point, it was bothering me as well for a moment, but then ignored it. If it is so easy, that's great. Will do.

Ok, the go mod tidy argument is a good one. I changed it to a normal go.mod file. We have now to change into the contrib/implements directory for building, but I guess that's no problem.

But what I really don't like is, that vet and fmt are not checked anymore for that code. We now have to bloat our tooling to get that back, because even go vet ./contrib/implements doesn't work.

But what I really don't like is, that vet and fmt are not checked anymore for that code. We now have to bloat our tooling to get that back, because even go vet ./contrib/implements doesn't work.

Understood, rather than bloat I look at as the go tooling now knows there are two modules in this one repo and won't impliclity cross that boundary, so we can probably just tweak the makefile so that we have vet (on go-ceph) + vet (on implements)

I would agree if there are two modules, but there are not two modules, we just use the modules system as a kind of hack to avoid development dependencies being listed in our build dependencies. The implements tool with its 800 lines of code has zero value for the outer world. See the definition:

A module is a collection of packages that are released, versioned, and distributed together. Modules may be downloaded directly from version control repositories or from module proxy servers.

So, if we end up implementing additional Makefile targets and script lines for each internal Go tool that we use, only to avoid a single unnecessary line in the go.mod file (which otherwise has zero effect, because it would never be downloaded during normal use of go-ceph), it clearly qualifies as bloat to me. It does more harm than good. Or is there any real technical issue you see beside that the "false advertising" - as you call it - itches your eye?

A require directive declares a minimum required version of a given module dependency.
(https://golang.org/ref/mod#go-mod-file-require)

So the required directive in a go.mod file does not list the required modules for building, it lists the required minimal versions of the listed modules if they are imported by a package. Only go mod download would download all of them. But all other commands download only as required by the actual source files you are compiling. That's also why the requirements of the tests don't do any harm. So maybe all we have to do is to shift our understanding of the required directive in go.mod, and we are good?

Sorry, if I drive you crazy, but after reading a lot about this topic I am now pretty sure it's the most reasonable thing to just include it in the normal go.mod file.

I would agree if there are two modules, but there are not two modules,

I disagree. Implements is a development tool that aids in the development of go-ceph and is not part of the go-ceph library.

we just use the modules system as a kind of hack to avoid development dependencies being listed in our build dependencies.

That's a reason to keep the seperate. But they are logically distinct things.

The implements tool with its 800 lines of code has zero value for the outer world.

Which is why I wasn't so keen on putting it in its own repo.

See the definition:

A module is a collection of packages that are released, versioned, and distributed together. Modules may be downloaded directly from version control repositories or from module proxy servers.

So, if we end up implementing additional Makefile targets and script lines for each internal Go tool that we use, only to avoid a single unnecessary line in the go.mod file (which otherwise has zero effect, because it would never be downloaded during normal use of go-ceph), it clearly qualifies as bloat to me. It does more harm than good. Or is there any real technical issue you see beside that the "false advertising" - as you call it - itches your eye?

A require directive declares a minimum required version of a given module dependency.
(https://golang.org/ref/mod#go-mod-file-require)

So the required directive in a go.mod file does not list the required modules for building, it lists the required minimal versions of the listed modules if they are imported by a package. Only go mod download would download all of them. But all other commands download only as required by the actual source files you are compiling. That's also why the requirements of the tests don't do any harm. So maybe all we have to do is to shift our understanding of the required directive in go.mod, and we are good?

Sorry but I feel quite strongly about this now. I'm going to take a hard stance on it.

I would agree if there are two modules, but there are not two modules,

I disagree. Implements is a development tool that aids in the development of go-ceph and is not part of the go-ceph library.

It's certainly not part of the go-ceph libraries. But it is part of the go-ceph module, that's a difference. Exactly like the tests. Modules are about versioning software that depends on each other. The implements tool is tightly coupled to the rest of the tooling of the repo. You need it for documentation generation and for testing and you always want to use the implements version of exactly the same commit as the rest of the repo. The format of the generated files is not standardized, it must match the version of the other python tool (which is not tracked, just because it is not written in Go). They are one set. You seem to have the notion that a Go module only tracks the version dependencies of software that is "provided" to its consumers. But that notion is not correct in my eyes. It tracks the versions of all Go software that is playing together in a repository. And in that sense, the implements tool is not different to the tests and an inherent part of the repo and therefore the module. Why is it ok for you to have the testify dependency tracked in go.mod but not the implements dependencies? Both are not part of the go-ceph libraries, but required for the overall test framework.

we just use the modules system as a kind of hack to avoid development dependencies being listed in our build dependencies.
That's a reason to keep the seperate. But they are logically distinct things.

Depends on the logic. It is seperate, in a seperate packages. That's how Go seperates code. Modules is for versioning. Tests, scripts, Dockerfiles, all logically distinct things. But they all are part of one tooling to test go-ceph and create documentation for it. I don't see, why implements has a special role here, just because it happens to be written in Go.
 Just one example of many: https://cs.opensource.google/go/go/+/master:src/math/bits/make_examples.go

Sorry but I feel quite strongly about this now. I'm going to take a hard stance on it. Either we treat it as a separate module or we split it into its own repo.

Look, I'm not debating this to be a PITA, but because I sincerely think it would be not appropriate (although not the end of the world of course), due to a misunderstanding of the module concept. I think there is no debate, that what you are proposing has some cost in writing and maintaining additional infrastructure code. All I'm asking for is a reason that is worth these costs, because I couldn't find it in the end (after cleaning up my own misconceptions) and "the line in go.mod might give someone a wrong impression" didn't qualify as such a reason for me. I hope that's not too much to ask?

I would agree if there are two modules, but there are not two modules,

I disagree. Implements is a development tool that aids in the development of go-ceph and is not part of the go-ceph library.

It's certainly not part of the go-ceph libraries. But it is part of the go-ceph module, that's a difference.

I think that's probably a large part of where the disagreement lies.

Exactly like the tests. Modules are about versioning software that depends on each other. The implements tool is tightly coupled to the rest of the tooling of the repo. You need it for documentation generation and for testing and you always want to use the implements version of exactly the same commit as the rest of the repo.

I don't think that's strictly true. The tooling is certainly related to the content of the library code and there's a relationship but I don't think the relationship is a tightly coupled as that of the library code and tests. I can certainly envision a future where the rate of change in the library and tooling slows allowing for additional decoupling,

The format of the generated files is not standardized, it must match the version of the other python tool (which is not tracked, just because it is not written in Go). They are one set.

It's certainly not formalized, but I intentionally created a format that is pretty general and could potentially be used by a wider variety of tools.

You seem to have the notion that a Go module only tracks the version dependencies of software that is "provided" to its consumers. But that notion is not correct in my eyes. It tracks the versions of all Go software that is playing together in a repository.

Sorry, but I don't quite follow this part. I agree that a module is a bundle of packages and there's a relationship with the repo. I don't see a strong requirement that one repo = one module, if that's what your aiming towards. Otherwise why would go permit multiple modules in one repo?

And in that sense, the implements tool is not different to the tests and an inherent part of the repo and therefore the module

I see it more like the revive tool or other static analysis tools. But the only reason it's part of go-ceph's repo is that it had no other purpose than to help us manage our C-library ceph coverage. Which was pretty limited in scope and thus didn't, at the time, seem to justify a full blown repo for it. But do note that we added under the contrib/ dir, which indicates that even then I saw it somewhat as a seperate thing.

Why is it ok for you to have the testify dependency tracked in go.mod but not the implements dependencies? Both are not part of the go-ceph libraries, but required for the overall test framework.

I dunno if you'll believe this, but I have always been annoyed that the test code dependencies are put into those files (without even being relegated to a special section).

we just use the modules system as a kind of hack to avoid development dependencies being listed in our build dependencies.
That's a reason to keep the seperate. But they are logically distinct things.

Depends on the logic. It is seperate, in a seperate packages. That's how Go seperates code. Modules is for versioning. Tests, scripts, Dockerfiles, all logically distinct things. But they all are part of one tooling to test go-ceph and create documentation for it. I don't see, why implements has a special role here, just because it happens to be written in Go.
 Just one example of many: https://github.com/golang/go/blob/master/src/math/bits/make_examples.go

Sure, if implements was more like the a go stringify tool that was required to construct the library, I might relax my position. However, I see it more like the revive tool only that the tool also kept in our repo.

Sorry but I feel quite strongly about this now. I'm going to take a hard stance on it. Either we treat it as a separate module or we split it into its own repo.

Look, I'm not debating this to be a PITA, but because I sincerely think it would be not appropriate (although not the end of the world of course), due to a misunderstanding of the module concept.

Understood. I feel the same way. :-)

I think there is no debate, that what you are proposing has some cost in writing and maintaining additional infrastructure code. All I'm asking for is a reason that is worth these costs, because I couldn't find it in the end (after cleaning up my own misconceptions) and "the line in go.mod might give someone a wrong impression" didn't qualify as such a reason for me. I hope that's not too much to ask?

Indeed, I appreciate looking at it from costs & benefits point of view. I come to a similar conclusion when I suggest creating a separate module: the benefits outweigh the costs.  I see the costs as being: some amount of additional overhead managing a "sub-module", remembering that its there and it's own distinct thing, as well as some amount of inconvenience of having to add some additional makefile rules etc. These costs are most likley to be born by you, me, and maybe a handful of future contributors.
I see the benefit as avoiding any potential confusion between the go-ceph library itself and a thing we use to help maintain that library. Consumers of the library have a clear picture of what go-ceph the library is and what it requires. I know that there are tools out there that are analyzing projects and making use of dependency info based on go modules. I'd rather avoid any potential problems with that here here and now. (Go ahead and suggest those are poorly made tools if they only take into account the go.{mod,sum} and not the individual package imports ... but my gut says they'll be the more common case). Because there are many more potential outside consumers of go-ceph the lib (both incorporating as a lib or just scanners), I feel this outweighs the costs, and I feel so emphatically.

As for my opinion, I see contrib/implements not as a part of the go-ceph module. It is a separate tool, that just coincidentally (for practical reasons) landed in this repository. It is not part of go-ceph releases as such, and could become its own project if there are interested other parties. Heavily modifying implements, or even dropping it from go-ceph completely would not affect the consumers of go-ceph in any way, and only modification to implements would not warrant a new release of go-ceph.
I understand that maintaining all dependencies used by the go-ceph project in a single go.mod file is easier. However, things in a contrib/ directory of a project usually are maintained a little differently from the 'core' components. This is a common practise across many projects, and seems to be widely understood/acceptable.
It does not hurt the go-ceph module when implements is included. But, it does not feel clean to me either. I'd rather see the dependencies maintained in a go.mod under contrib/implements.

It's certainly not part of the go-ceph libraries. But it is part of the go-ceph module, that's a difference.

I think that's probably a large part of where the disagreement lies.

I will rephrase my statement, which might be more acceptable for you: the tool implements and it's dependencies must be version pinned by the go.mod in order to provide reproducible builds, tests and CI, which is what the go.mod file is all about. So if implements would be made part of a different module, it would be necessary to use the tools.go trick in order to pin its version in the go-ceph module. This would lead to exactly the same indirect "dependency" to the cc library as a direct entry. As I said before, it is not a build dependency of the go-ceph library, but simply a version pinning for the existing dependency of our CI on the implements tool. So, yes, if the implements tool would be useful outside of go-ceph and therefore in it's own module and repo, it still would be required to pin its version in the go.mod of go-ceph.

Exactly like the tests. Modules are about versioning software that depends on each other. The implements tool is tightly coupled to the rest of the tooling of the repo. You need it for documentation generation and for testing and you always want to use the implements version of exactly the same commit as the rest of the repo.

I don't think that's strictly true. The tooling is certainly related to the content of the library code and there's a relationship but I don't think the relationship is a tightly coupled as that of the library code and tests. I can certainly envision a future where the rate of change in the library and tooling slows allowing for additional decoupling,

How does the rate of change play a role here? Even if the tool would never change anymore, the coupling comes from the fact, that for example it only operates on the hardcoded go-ceph packages, uses the "ceph_preview" tag, relies on our homegrown "PREVIEW"  and "Implements:" comment style, our preview concept in general, and is packed with go-ceph and ceph references in the produced files. Let me be blunt: It is beyond repair deeply interwoven with the go-ceph specifics and couldn't be further away from a general tool. I'm actually a bit confused that I have to argue for that, because from my perspective it looks so obvious.

It's certainly not formalized, but I intentionally created a format that is pretty general and could potentially be used by a wider variety of tools.

Even if that would be true, certainly not the implements tool itself.

You seem to have the notion that a Go module only tracks the version dependencies of software that is "provided" to its consumers. But that notion is not correct in my eyes. It tracks the versions of all Go software that is playing together in a repository.

Sorry, but I don't quite follow this part. I agree that a module is a bundle of packages and there's a relationship with the repo. I don't see a strong requirement that one repo = one module, if that's what your aiming towards. Otherwise why would go permit multiple modules in one repo?

First, I didn't say, one repo can only have one module. It is certainly possible and useful for some rare corner-cases to have more than one module per repo, but go-ceph is none one of these, and it comes with a couple of caveats, as described here. I highly recommend reading the whole chapter in the FAQ, because it gives a good overview of all the possible problems and complications of doing so.
But what I wanted to point out in this paragraph was a different thing: the go.mod file does track the versions not only of the library and its tests, but also of all other go tools that are involved with the infrastructure code within a module, as CI and generator scripts (code, documentation, etc...) for example. Either these tools are external ones, in which case you use the tools.go trick as mentioned above, or these are internal tools, in which case the versions of their dependencies are directly tracked in the go.mod file.

And in that sense, the implements tool is not different to the tests and an inherent part of the repo and therefore the module

I see it more like the revive tool or other static analysis tools. But the only reason it's part of go-ceph's repo is that it had no other purpose than to help us manage our C-library ceph coverage. Which was pretty limited in scope and thus didn't, at the time, seem to justify a full blown repo for it. But do note that we added under the contrib/ dir, which indicates that even then I saw it somewhat as a seperate thing.

Also "separate things" are meant to be tracked in the go.mod if the module depends on it in some way. So you are right, even the revive tool version should be added to the go.mod file, because CI depends on it, and a new version of revive could break CI suddenly.

I dunno if you'll believe this, but I have always been annoyed that the test code dependencies are put into those files (without even being relegated to a special section).

That's because I believe you misunderstand its meaning (as I did before). The versions of test dependencies must be tracked even, because newer versions might behave differently, so in order to have reproducible CI failures, tests must always run with exactly the same dependency code.

Sure, if implements was more like the a go stringify tool that was required to construct the library, I might relax my position. However, I see it more like the revive tool only that the tool also kept in our repo.

It is almost as relevant as the stringify tool, because it produces documentation and defines if CI is failing or not.

I see the benefit as avoiding any potential confusion between the go-ceph library itself and a thing we use to help maintain that library. Consumers of the library have a clear picture of what go-ceph the library is and what it requires. I know that there are tools out there that are analyzing projects and making use of dependency info based on go modules. I'd rather avoid any potential problems with that here here and now. (Go ahead and suggest those are poorly made tools if they only take into account the go.{mod,sum} and not the individual package imports ... but my gut says they'll be the more common case). Because there are many more potential outside consumers of go-ceph the lib (both incorporating as a lib or just scanners), I feel this outweighs the costs, and I feel so emphatically.

I try to back up  everything I claim with sources. Could you also point me to such an analyzing project, so that I better understand the problem that you are seeing here? Besides our own scripts, that would need to be extended, the above FAQ link shows several further real-world costs of multi-module-repos. So I hope you can understand that I would love to see similar evidence for the costs of an additional tracked version in the go.mod file, that is more than a gut feeling.
Of course the costs of this debate already out-weights the costs that we are discussing here, so you could argue it makes no sense. But I think it's a more general debate about different philosophies of how to keep a project "lean", so I think it's still worth the exercise as a placeholder for coming similar decisions in the future.

@nixpanic I wanted to answer to your comment as well, but I realised I would just repeat what I already wrote in my answer to @phlogistonjohn, so please refer to that one. 😉

Another interesting blog article about that topic: https://marcofranssen.nl/manage-go-tools-via-go-modules

It's certainly not part of the go-ceph libraries. But it is part of the go-ceph module, that's a difference.

I think that's probably a large part of where the disagreement lies.

I will rephrase my statement, which might be more acceptable for you: the tool implements and it's dependencies must be version pinned by the go.mod in order to provide reproducible builds, tests and CI, which is what the go.mod file is all about. So if implements would be made part of a different module, it would be necessary to use the tools.go trick in order to pin its version in the go-ceph module. This would lead to exactly the same indirect "dependency" to the cc library as a direct entry. As I said before, it is not a build dependency of the go-ceph library, but simply a version pinning for the existing dependency of our CI on the implements tool. So, yes, if the implements tool would be useful outside of go-ceph and therefore in it's own module and repo, it still would be required to pin its version in the go.mod of go-ceph.

I don't know if I'm on board with that.  I'll use the revive tool as a counterexample. First, I do not think that implements needs to be versioned with/part of go-ceph to accomplish a build task especially as it isn't used as part of the build process at all.
For the sake of clarifying what I mean by build - I mean the essential steps needed by a codebase to consume (make use of) go-ceph. So from my POV the topic of reproducible builds is not directly relevant to this discussion.  Like revive, implements is used to ensure a certain level of code quality.  Something to assist us and our contributors - following the policy that we created - so we added it to the CI. Projects consuming go-ceph don't need to know anything about implements.

Exactly like the tests. Modules are about versioning software that depends on each other. The implements tool is tightly coupled to the rest of the tooling of the repo. You need it for documentation generation and for testing and you always want to use the implements version of exactly the same commit as the rest of the repo.

I don't think that's strictly true. The tooling is certainly related to the content of the library code and there's a relationship but I don't think the relationship is a tightly coupled as that of the library code and tests. I can certainly envision a future where the rate of change in the library and tooling slows allowing for additional decoupling,

How does the rate of change play a role here? Even if the tool would never change anymore, the coupling comes from the fact, that for example it only operates on the hardcoded go-ceph packages, uses the "ceph_preview" tag, relies on our homegrown "PREVIEW" and "Implements:" comment style, our preview concept in general, and is packed with go-ceph and ceph references in the produced files. Let me be blunt: It is beyond repair deeply interwoven with the go-ceph specifics and couldn't be further away from a general tool. I'm actually a bit confused that I have to argue for that, because from my perspective it looks so obvious.

The the list of packages that implements reads could be set in a configuration file. The strings it looks at in the comments could be specified on the command line as regexes. The build tags it uses could pe set as environment variables.
When we invoke revive in the CI we tell it to use the configuration file that has the checks we care about enabled. The cli and the config file are a stable-enough interface so that we don't have to worry much about when the code of
revive changes. When I thought it would be useful to know what parts of the ceph api was implemented in go-ceph it was convenient to add it directly to the go-ceph tree. However, I would assume that other projects could make use
of a C/cgo comparator tool - a more generic version of implements could do that.
So that's my long-winded way of saying I don't think the source code of go-ceph and implements are as inexorably linked as you suggest.
Would it help if I created a proof-of-concept version of implements that lives outside the go-ceph repo and is more generic?

It's certainly not formalized, but I intentionally created a format that is pretty general and could potentially be used by a wider variety of tools.

Even if that would be true, certainly not the implements tool itself.

Sorry, I don't follow the sentence well. Are you saying that implements is not  very generic today? I agree. However, I'm saying that it could be changed into external tool that is more generic tomorrow. Also, I don't think that an external tool has to be totally generic but I think suggesting it can be made generic strengthens my argument.

You seem to have the notion that a Go module only tracks the version dependencies of software that is "provided" to its consumers. But that notion is not correct in my eyes. It tracks the versions of all Go software that is playing together in a repository.

Sorry, but I don't quite follow this part. I agree that a module is a bundle of packages and there's a relationship with the repo. I don't see a strong requirement that one repo = one module, if that's what your aiming towards. Otherwise why would go permit multiple modules in one repo?

First, I didn't say, one repo can only have one module. It is certainly possible and useful for some rare corner-cases to have more than one module per repo, but go-ceph is none one of these, and it comes with a couple of caveats, as described here. I highly recommend reading the whole chapter in the FAQ, because it gives a good overview of all the possible problems and complications of doing so.

Sure. I have looked at it before but I have re-read it to refresh it in my mind and in case something changed.
I'm really not sure about "but go-ceph is none one of these". I'm suggesting that go-ceph's repo contains a second, separate but very useful, go codebase. This is somewhat similar to the point:
One additional use case for having multiple go.mod files in a single repository
is if the repository has files that should be pruned from a module. For
example, a repository might have very large files that are not needed for the
Go module, or a multi-language repository might have many non-Go files.

Note that I emphasize the first sentence in that quote. The subsequent statements are an example  of the first.

But what I wanted to point out in this paragraph was a different thing: the go.mod file does track the versions not only of the library and its tests, but also of all other go tools that are involved with the infrastructure code within a module, as CI and generator scripts (code, documentation, etc...) for example. Either these tools are external ones, in which case you use the tools.go trick as mentioned above, or these are internal tools, in which case the versions of their dependencies are directly tracked in the go.mod file.

This is not how we use something like revive today. I'm not seeing the appeal of something like this.

And in that sense, the implements tool is not different to the tests and an inherent part of the repo and therefore the module

I see it more like the revive tool or other static analysis tools. But the only reason it's part of go-ceph's repo is that it had no other purpose than to help us manage our C-library ceph coverage. Which was pretty limited in scope and thus didn't, at the time, seem to justify a full blown repo for it. But do note that we added under the contrib/ dir, which indicates that even then I saw it somewhat as a seperate thing.

Also "separate things" are meant to be tracked in the go.mod if the module depends on it in some way. So you are right, even the revive tool version should be added to the go.mod file, because CI depends on it, and a new version of revive could break CI suddenly.

Now that's really surprising to me. Excuse the ad abusurdium here, but if I was to add a add a bash script to the CI that used used a recent-ish feature of gnu grep, would you want a way to express that we use bash and a particular version of
grep that to go.mod as well?

I dunno if you'll believe this, but I have always been annoyed that the test code dependencies are put into those files (without even being relegated to a special section).

That's because I believe you misunderstand its meaning (as I did before). The versions of test dependencies must be tracked even, because newer versions might behave differently, so in order to have reproducible CI failures, tests must always run with exactly the same dependency code.

I am starting to think I better understand where you are coming from, but that's not the I am accustomed to. Tracking every possible dependency, especially in something language specific like go.mod, seems like "boiling the ocean" to me.
I also thought that go install was now the preferred way of installing go binaries. I note that the go module docs for go install say that it ignores the current go.mod. If you want a specific verson of a go binary the syntax is go install <pkg>@<version> IIRC.

Sure, if implements was more like the a go stringify tool that was required to construct the library, I might relax my position. However, I see it more like the revive tool only that the tool also kept in our repo.

It is almost as relevant as the stringify tool, because it produces documentation and defines if CI is failing or not.

I see the benefit as avoiding any potential confusion between the go-ceph library itself and a thing we use to help maintain that library. Consumers of the library have a clear picture of what go-ceph the library is and what it requires. I know that there are tools out there that are analyzing projects and making use of dependency info based on go modules. I'd rather avoid any potential problems with that here here and now. (Go ahead and suggest those are poorly made tools if they only take into account the go.{mod,sum} and not the individual package imports ... but my gut says they'll be the more common case). Because there are many more potential outside consumers of go-ceph the lib (both incorporating as a lib or just scanners), I feel this outweighs the costs, and I feel so emphatically.

I try to back up everything I claim with sources. Could you also point me to such an analyzing project, so that I better understand the problem that you are seeing here? Besides our own scripts, that would need to be extended, the above FAQ link shows several further real-world costs of multi-module-repos. So I hope you can understand that I would love to see similar evidence for the costs of an additional tracked version in the go.mod file, that is more than a gut feeling.

Let me emphasize that I'm concerned about potential issues and don't  want to overly stress the importance of the particular example I'm thinking of. However, I will send you a direct mail with some additional context so you know what I'm talking about. I am concerned about the potential issues and the uncertainty of "falsely advertising" the relationship between implements and go-ceph. Because I am attracted to using metaphors: I'm looking for a place to build my house and there's a nice spot that I can't be confident isn't on flood plain so I'm avoiding building there even if its a tad bit harder to build on the hill. (Plus sometimes I just have to trust my gut.)

Of course the costs of this debate already out-weights the costs that we are discussing here, so you could argue it makes no sense. But I think it's a more general debate about different philosophies of how to keep a project "lean", so I think it's still worth the exercise as a placeholder for coming similar decisions in the future.

I don't think it's been too bad. I think it might be easier to have a group discussion on this soon though. I'd appreciate it if @nixpanic  and @agarwal-mudit would read up on our arguments & counterarguments so that we can discuss together at some point soon (Monday Dec. 17 we have a meeting scheduled, but we can also do a one-off if needed).
I agree it's good to hash things like this out sometimes even though it's "painful" in the moment. I think that this is a bit of an "iceberg" issue, there's a lot under the surface. While I want the improvements to the code I also want to feel I/we have a good grip the known and potential costs rather that just merging it to avoid the unpleasantness of disagreement.

So from my POV the topic of reproducible builds is not directly relevant to this discussion. Like revive, implements is used to ensure a certain level of code quality. Something to assist us and our contributors - following the policy that we created - so we added it to the CI.

Also the CI runs should be reproducible, not only the pure "payload build". That's why we are using containers for example.

Projects consuming go-ceph don't need to know anything about implements.

That's correct. But go.mod does not only contain information for the consumers of go-ceph.

The the list of packages that implements reads could be set in a configuration file. The strings it looks at in the comments could be specified on the command line as regexes. The build tags it uses could pe set as environment variables. When we invoke revive in the CI we tell it to use the configuration file that has the checks we care about enabled. The cli and the config file are a stable-enough interface so that we don't have to worry much about when the code of revive changes. When I thought it would be useful to know what parts of the ceph api was implemented in go-ceph it was convenient to add it directly to the go-ceph tree. However, I would assume that other projects could make use of a C/cgo comparator tool - a more generic version of implements could do that.

What you are describing here is basically a new tool. The current implements tool is highly specific, and that is the basis on which we should make the decision. While I doubt it makes sense to make it a generic tool, because the generalizeable parts are too small, let's talk about this, if and when we have a generic tool. There is nothing stopping us from moving the tool in its own repo, once we have it.

Would it help if I created a proof-of-concept version of implements that lives outside the go-ceph repo and is more generic?

I don't think that is something that needs proof, of course it's possible to build generic tools. It rather needs purpose, which I don't see. We have a specific tool, that is sufficient for our needs.

Are you saying that implements is not very generic today? I agree. However, I'm saying that it could be changed into external tool that is more generic tomorrow.

Then let's handle that tomorrow. ;-)

One additional use case for having multiple go.mod files in a single repository
is if the repository has files that should be pruned from a module. For
example, a repository might have very large files that are not needed for the
Go module, or a multi-language repository might have many non-Go files.

Note that I emphasize the first sentence in that quote. The subsequent statements are an example of the first.

As the examples clarify, this is about files that take a long time to scan or download. Both is not the case for the implements tool. If you only refer to the first sentence you have to have another good argument why to prune the files, which is the very debate we are having here. I'm saying, there is no good reason, in the opposite, it's very useful to keep it inside.

This is not how we use something like revive today. I'm not seeing the appeal of something like this.

Well, the "best practice" of using a tools.go file to track tool versions in the go.mod file does explicitly mention linters and vet as well:

Go modules support tools (commands) as dependencies. For example, you might need to install a tool to help with code generation, or to lint/vet your code.

(https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md)
Or our colleague @bwplotka:

You really want to pin version of ALL the tools your project depends on!

(https://www.bwplotka.dev/2020/bingo/#always-pin-the-version)
Here are some example projects that I found with a quick search, that all include linters in their go.mod file. (You can also find many examples for other checker tools like goimports, gofumpt etc.)
https://github.com/pyroscope-io/pyroscope/blob/main/go.mod#L49 (revive)
https://github.com/google/fscrypt/blob/master/go.mod#L12
https://github.com/manifoldco/healthz/blob/master/go.mod#L5
https://github.com/tendermint/tendermint/blob/master/go.mod#L17
https://github.com/pomerium/pomerium/blob/master/go.mod#L24

Also "separate things" are meant to be tracked in the go.mod if the module depends on it in some way. So you are right, even the revive tool version should be added to the go.mod file, because CI depends on it, and a new version of revive could break CI suddenly.

Now that's really surprising to me. Excuse the ad abusurdium here, but if I was to add a add a bash script to the CI that used used a recent-ish feature of gnu grep, would you want a way to express that we use bash and a particular version of grep that to go.mod as well?

We do that: containers. go.mod can only pin Go tools. So we are pinning other software in other ways. It's a matter of fact, that every language comes with their own package manager and dependency systems, so there is no other way to do that.

I am starting to think I better understand where you are coming from, but that's not the I am accustomed to. Tracking every possible dependency, especially in something language specific like go.mod, seems like "boiling the ocean" to me.

It's not about every possible dependency, because most dependencies are quite static and can be part of the CI container. But all the "moving parts", that is all the code that is installed and managed by the go tools, should be pinned with the Go method for doing so.

Because I am attracted to using metaphors: I'm looking for a place to build my house and there's a nice spot that I can't be confident isn't on flood plain so I'm avoiding building there even if its a tad bit harder to build on the hill. (Plus sometimes I just have to trust my gut.)

But despite the gossip of the villagers about the place being cursed, the analysis of the soil shows, that there hasn't been a flood since centuries.  ;-)

I don't think it's been too bad. I think it might be easier to have a group discussion on this soon though. I'd appreciate it if @nixpanic and @agarwal-mudit would read up on our arguments & counterarguments so that we can discuss together at some point soon (Monday Dec. 17 we have a meeting scheduled, but we can also do a one-off if needed).

Sure! I guess you mean Dec. 13?

Sure! I guess you mean Dec. 13?

Ugh. I don't know where 17 came from. Yes, 13 is right.

Thanks for coming back to this. The new patch looks good on first glance. I'll do a full "second look" at the full PR as soon as I can.


fix: slow shutdown & leaked resources

fix zombie processes when the main process doesn't gracefully exit
fix slow shutdown
fix some unclosed resources
fix leaked some leaked mp processes (pipe & Queue)
add a moving avg to the default cpu_load_fnc

cc @egoldschmidt

going to use socketpair to create asynchronous/non-blocking IPC communication before merging this PR


Project description: rendering of  in lists ugly

Given the following HTML structure in a project description:

The rendering is poor:

This requires updating warehouse/static/sass/blocks/_project-description.scss

Screenshot Required: This issue will require an update to the visual design of the site. To help our team give you faster feedback, include a screenshot in your Pull Request.

Hello, I would like to help with this issue

@Kohdz  Yes, please go ahead and grab this issue! At least within Warehouse, our rule is: If there is not a corresponding pull request for this issue (visibly linked by issue number/PR number), and it's not marked as assigned to anyone, it is up for grabs. So in cases like this, you don't even need to ask. :) Just comment and say that you're starting to work on it, and link in a comment to your work-in-progress branch once you start.
As always, if you have questions along the way as you work on this, please feel free to ask them here, in #pypa-dev on Freenode, or the pypa-dev mailing list. Thank you!


Wild memory consuming and 100% CPU usage while editing a small file.

It allocates the memory until there's nothing left. No time to terminate.
Platform: Ubuntu 14.04, Mint 17.1, Gnome-shell 3.10.4

What Atom version are you using?  Does this happen in safe mode (atom --safe)?  If so, it would be awesome if you could share the file you're editing.

Version: 0.201. Yes, it happens with safe mode and with or without plugins. The file is a starter Scala source(hello world for further editing).

Is the file by any chance in your home directory?
(Also, if you update to Atom 0.204.0, there's been a large performance improvement that may help your issue)

No, in my "Workspace" folder. I'll install the new version.

Just to make sure: is this the file you're editing?
object HelloWorld {
  def main(args: Array[String]) {
    println("Hello, world!")
  }
}

I copy/pasted that into Atom (Ubuntu 15.04) and tried randomly typing letters, inserting newlines, deleting, undoing, etc. but memory usage stayed constant.

Something similar(Main == HelloWorld). I don't need to do anything for it to be frozen. Not even touching Atom.

I can't install the new one because it requires npm1.4 and I've 1.3.10. When installing the latest with the official site's instructions it fails.

Can't reproduce it with version 0.205.0-5389156.

All right, that's good to know :smile:.  Glad upgrading fixed your issue!

Thanks for helping!


now logs with --since and --until not working

When specifying a time with now logs using --since or --until, neither produce the result I expect.
This has the same effect as if --since isn't specified, showing the most recent logs
now logs --since=2019-06-11T01:00:00.000Z <alias>
This has no effect - no logs are shown:
now logs --until=2019-06-11T01:00:00.000Z <alias>
Quotes around the time make no difference.
This bug makes working backwards through logs to find something effectively impossible.
Additionally, specifying the number of lines to output produces incorrect results in my current state:
-n 200 returns 199 results
-n 1000 returns 990 results
-n 990 returns 980 results
-n <any number over 1000> returns 990 results

No response to this? Should I contact support@ instead?

Additionally, --query doesn't appear to do anything - it always returns the most recent log entries.

Hello @eAi ,
Yes, reaching out to us at support is always the best approach. My apologies for the delay.
Regarding logs, I believe log drains is the best alternative for what you need to achieve.
If you have any further questions, please ask them on zeit.co/support


avoid contributing to dropped exceptions during finalization

(see https://github.com/python-trio/trio/issues/1559)

Pull Request Test Coverage Report for Build 118

16 of 16 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 95.825%

Totals

Change from base Build 113:
0.1%

Covered Lines:
482

Relevant Lines:
503

💛  - Coveralls


Scores Plugin refactor

I really didn't like the old code. It should be cleaner now.
Moved blocks of code to their own functions, and made a Game class to pass around, helping store the data

I'll let ya know when I'm done. I gotta wait until Saturday say i can see what the API looks like then

Found a better API, restarting from scratch again.
Will create fresh PR tomorrow


Mass-media console update

About the PR

A few minor changes:

Command access allows to delete any articles, regardless of who the author is.
Added sound, and popup, when deletion is denied
Updated mass-media console interface

Most likely, the latest news update...
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl: Misha_Unity

tweak: Command access allows to delete any articles
tweak: Updated mass-media console interface

censorship :trollface:


Add named cache invalidation index

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

Comparison is base (13944a1) 71.35% compared to head (1fcc717) 71.56%.

Files
Patch %
Lines

invalidator.go
91.66%
3 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #40      +/-   ##
==========================================
+ Coverage   71.35%   71.56%   +0.21%
==========================================
  Files          28       28
  Lines        1658     1681      +23
==========================================
+ Hits         1183     1203      +20
- Misses        399      402       +3
  Partials       76       76

Flag
Coverage Δ

unittests
71.56% <91.66%> (+0.21%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


timezone on clock module

Hi,
Nice project thanks ! It would be nice to be able to set the timezone on the config file so we don't have to bother to set the TZ env var and reload the session, wdyt ?
Cheers

Also, the possibility of adding multiple clocks in different timezones would be a plus!

I misunderstood this one as being about displaying the current timezone in the clock widget, which can already be done with %Z of course.
At the moment, waybar does not detect system timezone changes, but this should be fixed soon (see https://github.com/Alexays/Waybar/issues/479). By default, the clock should reflect the system's timezone.
So this feature chiefly adds

[...] the possibility of adding multiple clocks in different timezones [...].

I'd be happy to work on this (specifically, being able to specify the TZ for a particular clock module), and I think the easiest way to make this happen would be to bring in Howard Hinnant's tz.h -- is adding a new dependency for this ok?


JP page does not render due to storing new terms

Sentence 情報さえ集めればどんどんお金も集まってくる。 gives a blank screen, obviously it shouldn't.

The code needs a fix.  In branch wip_365, the unique tokens are pulled out from the tokenized text correctly:
creating unique toks ['情報', 'どんどん', '集まっ', 'て', 'も', 'さえ', 'くる', 'ば', '集めれ', 'お金']

Note "集めれ" in the above.
Now, when these are passed to the Term constructor, the term is still getting parsed, as a result we end up with these Terms:
all_new_terms = [<Term None '情報'>, <Term None 'どんどん'>, <Term None '集まっ'>, <Term None 'て'>, <Term None 'も'>, <Term None 'さえ'>, <Term None 'くる'>, <Term None 'ば'>, <Term None '集め_れ'>, <Term None 'お金'>]

Note <Term None '集め_れ'> -- so the new term doesn't match the source word.  Basically, we need to create the new terms, but absolutely not reparse the text.

Launched in 3.3.0.


jacobian access

closes #143
This function now allows to get the Jacobian function and disentangles the small signal analysis from the simulation
cc. @cuihantao this is the feature you requested.

Yeah, we need to add docs to this later

Thanks!!


Address Component

Create a component of address that:
I must receive the chain's IService so it can get the IAddressService and validate the address.
It must validate the address using the IAddressService.validateAddress

[ ] Button Paste
[ ] Validate address
[ ] Upload image and read the QR Code from the image
[ ] Address book

This will be implemented as part of send flow


Moved text on 404 screen above image.

Moved the text on the 404 screen above the image.
To address display issues caused by the text interacting with the existing CSS I placed the image in its own img tag which is sized using the bootstrap responsive image and cleaned up the unused CSS.
Closes #1484

Not sure why CI failed.  Tests are all green locally and I certainly didn't change anything in the Validators.

I will try to rerun and see if it was just a blip

And it's good


Adding attachments complains about mediatype

Hi,
I am getting 415 when trying to add attachments using the method bellow. Do you have any unit tests or examples on how this should be used?
https://github.com/MrRefactoring/confluence.js/blob/738dc5688d37e97073c5c62d0394ddc57ccaa402/src/api/contentAttachments.ts#L82

Hi @tester22! Sorry for the late response, could you please provide an example of how you use this method?

So I took a look and got you :)
Yeah, looks like it's wouldn’t work

Fixed in v1.5.0. If you still have problems with adding attachments check e2e.test.ts file

Thanks!
It works great now!


Add UoN to supported institutions

Works great with University of Nottingham (which uses echo360.org.uk), didn't have to change a thing.
Is it possible to detect video in single video page rather than course page?
You saved me a couple of hours worth of coding. Thanks 👍

Hi @imaginebreake
Thanks for confirming that its working for you!
It is possible, as most of our devs have finished uni, we don't have access to echo360, feel free to fork this repository and submit a Pull request.


tomli violates PEP517 Build Requirements

The PEP517 Build Requirements specifically disallow dependency cycles:

Project build requirements will define a directed graph of requirements (project A needs B to build, B needs C and D, etc.) This graph MUST NOT contain cycles. If (due to lack of co-ordination between projects, for example) a cycle is present, front ends MAY refuse to build the project.

Where build requirements are available as wheels, front ends SHOULD use these where practical, to avoid deeply nested builds. However front ends MAY have modes where they do not consider wheels when locating build requirements, and so projects MUST NOT assume that publishing wheels is sufficient to break a requirement cycle.

Thanks for the issue!
I'm sure you're well aware of the problem by now. That is, packaging requires reading TOML but there is no TOML parser in the stdlib so build backends either vendor a parser or resort to this dependency cycle. This is a bit of an (unfortunate) exception that we have until stdlib can parse TOML.
The cycle could be solved on Tomli side by vendoring flit_core and using it as build backend but... my intention with Tomli was to write the best pure Python TOML parser, not to end world hunger, solve Python packaging, or anything else. :smiley:
My understanding is that flit author (takluyver) also thinks that this special casing is best solved on flit's side, so I suggest we have a little patience and see what conclusion they arrive at.

so build backends either vendor a parser or resort to this dependency cycle

Well from my understanding this means tomli at least at the moment is not a PEP517 compliant package, wouldn't one option to be to just switch to the setuptools PEP517 backend until flit figures out what they want to do?

Hmm, maybe. I'm not sure if that'd be great twist for the PEP517 Python bootstrap story though, as setuptools has its own dependency cycle with wheel, has dependencies (although bundled) and may depend on Tomli in the near future.
One way to currently avoid the cycle (in case it helps you) is to restrict flit_core to versions >=3.2,<3.4. They are supported by Tomli as build backend and do not depend on Tomli.

I'm not sure if that'd be a great twist for the PEP517 Python bootstrap story though, as setuptools has its own dependency cycle with wheel, has dependencies (although bundled) and may depend on Tomli in the near future.

From what I can tell setuptools does not actually depend on wheel, as long as setuptools vendors tomli I don't think there would be an issue, it seems to be a significant improvement for bootstrapping compared with flit.

One way to currently avoid the cycle (in case it helps you) is to restrict flit_core to versions >=3.2,<3.4.

Wouldn't that then mean any package depending on flit_core >=3.4 would not be buildable?

They are supported by Tomli as build backend and do not depend on Tomli (which arguably also means the title of this issue may not be fully accurate 😉).

Well tomli currently has requires = ["flit_core>=3.2.0,<4"] so it's at least the case right now that tomli is not PEP517 compliant.

as long as setuptools vendors tomli I don't think there would be an issue

Here it boils down to:

Tomli's build backend (flit_core) has so far chosen to not vendor in the belief that it is the lesser evil.

I.e. takluyver has made the decision to not vendor in the belief (at least at the time) that it is the best trade-off overall. I honestly trust his judgment in this way more than my own. So if you want things to change, please go pester him not me :smile:

I.e. takluyver has made the decision to not vendor in the belief (at least at the time) that it is the best trade-off overall. I honestly trust their judgment in this way more than my own.

So it's unclear if flit_core itself violates PEP517 build requirements since tomli is not actually a build dependency for flit_core but rather a runtime dependency, however tomli definitely violates PEP517 by depending on flit_core since tomli is a runtime dependency of flit_core and thus transitively a build dependency of tomli.  I wrote a validator for build to help detect these invalid pep517 requirements.

Also, with setuptools as backend, you still need that build frontend, which as I mentioned very likely depends on Tomli, so I'm not sure this makes bootstrapping any easier.

It works pretty good with setuptools since it has a non-generator setup.py shim for bootstrapping, see #155.

Yeah I didn't mean to imply anything about whether flit_core violates PEP517 or not. My point is that due to conditions I laid out in my first post this cycle may be a necessary exception. An alternative being that many packages vendor a TOML parser, but apparently that was deemed to be the worse alternative by packaging experts.

Also, with setuptools as backend, you still need that build frontend, which as I mentioned very likely depends on Tomli, so I'm not sure this makes bootstrapping any easier.

Bootstrapping works much better with setuptools since it has a non-generator setup.py shim for bootstrapping, see #155.

But that is not PEP517 bootstrapping. Then you resort to the legacy build system. If you are happy to bootstrap like that, why not just run the following to build Tomli
python3 -c 'from setuptools import setup; setup(name="tomli", packages=["tomli"], package_data={"": ["*"]}, version="2.0.0")' sdist bdist_wheel

It should work perfectly already with no changes made to the repository.

Yeah I didn't mean to imply anything about whether flit_core violates PEP517 or not. My point is that due to conditions I laid out in my first post this cycle may be a necessary exception. An alternative being that many packages vendor a TOML parser, but apparently that was deemed to be the worse alternative by packaging experts.

I really don't see why there should be an exception here when simply using setuptools instead of flit_core seems to fix the issue, the PEP is also pretty clear that this is a hard requirement(ie MUST NOT) as it says This graph MUST NOT contain cycles. which is different from say a recommended behavior(ie SHOULD) like Front ends SHOULD check explicitly for requirement cycles.

But that is not PEP517 bootstrapping.

It also has PEP517 bootstrapping support which uses this and doesn't have a circular dependency issue:
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

Then you resort to the legacy build system. If you are happy to bootstrap like that, why not just run the following to build Tomli

By using the empty setuptools shim you basically get guaranteed identical behavior with PEP517 bootstrapping above as both effectively are configured with setup.cfg, so this prevents any behavior divergence better between the two.

It also has PEP517 bootstrapping support which uses this and doesn't have a circular dependency issue:

Yeh, but then you need the PEP517 frontend that depends on Tomli: we have the same cycle again. There really is no way around the fact that PEP517 needs TOML parsing and that we dont have until Tomli is built. I may not have the energy to write in this issue after this post, but as Ive said before, Id like to wait for what takluyver does with flit. The command I provided can be used to do legacy build of Tomli and is trivial to modify to fetch version number dynamically from pyproject.toml, .bumpversion.cfg or init.py file.

Yeh, but then you need the PEP517 frontend that depends on Tomli: we have the same cycle again.

There are PEP517 frontends without a circular tomli dependency issue(due to vendoring)...like pip.

There really is no way around the fact that PEP517 needs TOML parsing and that we dont have until Tomli is built.

Not all PEP517 frontends have a direct dependency on the tomli pypi package so this is useful for those frontends.

I may not have the energy to write in this issue after this post, but as Ive said before, Id like to wait for what takluyver does with flit.

That would mostly fix the boostrapping issue with tomli(at least for flit_core), however there are other advantages to using setuptools such as making it easier for other build tools to install tomli without running into the circular dependency issue, also setuptools is effectively bundled with a python install while flit_core is not which makes it more suitable for bootstrapping.

The command I provided can be used to do legacy build of Tomli and is trivial to modify to fetch version number dynamically from pyproject.toml, .bumpversion.cfg or init.py file.

Using flit_core still leaves PEP517 bootstrapping broken though due to the dependency cycle, this fixes both issues.

There are PEP517 frontends without a circular tomli dependency issue(due to vendoring)...like pip

Yeah as Ive stated, I do understand that vendoring TOML parsers is an alternative and how this is a trade-off and how an active decision to not vendor has been made.

Using flit_core still leaves PEP517 bootstrapping broken though due to the dependency cycle, this fixes both issues.

The command has nothing to do with flit_core, it interacts with it in no way at all. It should fix both your issues.

Yeah as Ive stated, I do understand that vendoring TOML parsers is an alternative and how this is a trade-off and how an active decision to not vendor has been made.

So based on my understanding of the situation if flit_core does not decide to vendor tomli then tomli would need to move off of flit_core to be PEP517 compliant. I guess @takluyver should maybe comment on how this should be resolved.

The command has nothing to do with flit_core, it interacts with it in no way at all.

I realize that.

It should fix both your issues.

It still however leaves tomli with a broken PEP517 dependency cycle at the moment.

xref: https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068/73?u=astrojuanlu

It also has PEP517 bootstrapping support which uses this and doesn't have a circular dependency issue:

To be clear, setuptools absolutely does have a circular dependency on wheel when bootstrapping with PEP 517.  setuptools needs wheel to build a wheel of itself and wheel needs setuptools to build itself.

To be clear, setuptools absolutely does have a circular dependency on wheel when bootstrapping with PEP 517. setuptools needs wheel to build a wheel of itself and wheel needs setuptools to build itself.

Are you sure? I don't see wheel listed here.

Oh, it's wheel specific and comes from here I guess.

If the circular dependency in setuptools would be resolved then yes, it would perhaps be better to use a backend which allows declaring project metadata in a format other than TOML.  But then you'd need twice the number of backends to bootstrap Python's packaging stack, because Flit has been or will be adopted by other foundational dependencies. We should look at this whole thing... holistically instead of trying to fix issues as they crop up in each one of these dependencies.  If we want to bootstrap our foundational dependencies with Flit then we all need to switch to Flit and we need to come up with a solution for building and installing wheels that works for all of them.

We'll go with the vendoring option in flit_core.
Please don't pester @hukkin about this. I'm the one who introduced the dependency cycle, and I'm the one working on a packaging tool. We're already having a discussion about it at https://github.com/pypa/flit/pull/483 (and other Flit issues and PRs), which @hukkin is already involved in. Opening more issues feels more like shouting at us to pay attention to your problem than like it actually moves a solution forwards. I'm sorry I haven't responded quicker, but Flit isn't my job, and it's not always what I want to do in the evening after work.

setuptools needs wheel to build a wheel of itself and wheel needs setuptools to build itself.

I've updated my dependency cycle checker so that it is able to catch the wheel cycle violation as well now.

Please don't pester @hukkin about this. I'm the one who introduced the dependency cycle, and I'm the one working on a packaging tool. We're already having a discussion about it at pypa/flit#483 (and other Flit issues and PRs), which @hukkin is already involved in. Opening more issues feels more like shouting at us to pay attention to your problem than like it actually moves a solution forwards.

Great, sorry about the noise, was throwing around different potential solutions to see what would be acceptable as there's a lot of potential ways to fix this issue that I've come across, closing this as a viable solution seems to have been decided on at least for resolving the flit_core+tomli dependency cycle.


Every node should receive the block exactly once and hence no duplicate messages

Currently, CHUNK packet includes height value but it is not used by broadcast algorithm. As per that duplicated messages are noticed on each broadcast.  It needs to follow the concept from the spec strictly in order to achieve O(log n) steps per a propagation, respectively no duplicates in a network with honest participants (as it is the case with testbed)
A simple example for L = 4 can be seen in Figure 2: node ID 0 = 1111
initiates a broadcast in the network, and sends four CHUNK messages
with heights h = 0 . . . 3 to one random node picked from each of the
respective buckets B i , i = 0 . . . 3. The receiving nodes repeat this
procedure, again issuing messages to nodes from bucket numbers
less then their assigned height.

If we assume constant transmission times, honest network partici-
pants, and no packet loss in the underlying network, the propaga-
tion method just discussed would result in an optimal broadcast
tree. In this scenario, every node receives the block exactly once and
hence no duplicate messages would be induced by this broadcast-
ing operation.

Additionally, the TestBroadcastChunksMsg should ensure that:

CHUNK is received by all network nodes
All nodes receive the CHUNK message only once


As a User I want simple default paragraph styles

I'm submitting a ...

[x] feature request

What is the current behavior?
All <p> tags have a default attribute: max-width: 70rem

A a user this is somewhat baffling.  In its current state there needs to be a removal/override on <p> tags.  While this is fine for Harmonium documentation, this should not be the default for the framework.
Scenario 1 - as a Harmonium user

[ ] When I add a p tag
[ ] Then it does not have a max-width attribute

For bugs: please provide steps to reproduce and tell us a little about your environment (e.g., what OS and version of the package you're using)
give us enough information to properly diagnose the bug
What is the expected behavior?
tell us what you think should happen instead of what's happening now
For feature requests: why should the behavior change?
explain why your feature request is a good idea
Other information (we love stack traces!)

Seems like this was probably put in there based on the idea that long lines are hard to read and making the right thing (readable paragraphs) easier than the wrong thing (full-page paragraphs)?

Seems like this was probably put in there based on the idea that long lines are hard to read and making the right thing (readable paragraphs) easier than the wrong thing (full-page paragraphs)?

IMO. The framework should act an agnostic system and allow a designer/engineer to make decisions about accessibility. Also this is the max-width of the container, which could cause other issues.

I agree with Steve here. At the very least, maybe we make that max-width a var that can be easily updated?


Terrain rendering issues with TAA/FSR (flickering)

Terrain3D version
v0.9.0
System information
Godot v4.2.1 - Windows 10, Forward+/Vulkan GTX 1060 6GB
Is the issue reproducable in the demo?
Not applicable
Issue description
Jittering/flickering can be seen/observed on the Terrain if TAA or FSR 2.0 is enabled. (With TAA it is less noticeable, with FSR its more pronounced)
Here a demonstration:
I set 3D scaling to FSR 2.0 and reduced the resolution scale to 0.1 (to make this really pronounced.)
https://www.youtube.com/watch?v=mKjPz8nHW2U
At first thought that this is a general Godot issue, howerver in the video only the terrain surfaces are flickering. (Other static geometry looks fine.)
I assume that this is due to the snapping/reposition behaviour of the 3D terrain renderer given that this flicker happens in a fixed intervall while moving. At least FSR to my knowledge requires a velocity buffer to reconstruct the image. The repositioning of the terrain might interfere with the FSR implementation casing incorrect reconstruction.
Not entirely sure how the velocity tracking in Godot is implemented. If we store the previous transform of the last frame (to calculate the delta for the velocity buffer each frame) one fix would be to artifically override the last transform state in case of a reposition to trick the image reconstruction on applying the correct velocity. (Have to check how Godot handles this internally.)
Can't test this with the demo project as of right now. (Having issues with godot not wanting to enable the addon on new projects due to parsing errors in the addons gd scripts. Will update this once i figure out what is going on.)

Thanks for the report. I haven't used either yet. Is it the mesh or the textures flickering? Show it in wireframe mode, and checkerboard and grey debug views. Your trees flicker just as much.

Here a video with the default terrain grid texture and with enabled collision mesh:
https://www.youtube.com/watch?v=JJZRwbQwQiI
The trees flicker constantly (even stationary) as they have a material with alpha transparency + alpha clipping enabled.  (without FSR is already really aliased + i'ts a really low resolution scale for demo purposes so it looks especially bad here.) However the terrain flickering shows a different behaviour. (It flickers only while moving in fixed interfals.)
You can also see that the grey grid texture on the cubes to the left are always stable while the floor is constantly jittering.
Hence my assumption that this is related to the velocity buffer issue.

It's very likely that this is a motion vector problem. The height of the vertex is determined by its world position so when the terrain moves with the camera the position of the vertex will move and this will not write to the motion vector buffer. This is a problem since the fragment sample position moves too. Since TAA and FSR2 expect pixel colours to remain constant with a constant velocity it's reprojecting the previous sample from before the camera moved causing the blurring/flickering. I'm not sure if it's possible to fix this without outputting the velocity in the shader which is not currently supported. My TAA understanding isn't the best so I may be incorrect here or get some terminology wrong.

I just tried FSR 1.0 and 2.2 in Godot 4.2.1 with the Terrain3D demo and they display perfectly fine on my NVidia 3070.
However when trying to load a project or a new terrain on my system it reports errors:
ERROR: Condition "p_job.uavMip[i] >= mip_slice_rids.size()" is true. Returning: FFX_ERROR_INVALID_ARGUMENT
   at: execute_gpu_job_compute_rd (servers/rendering/renderer_rd/effects/fsr2.cpp:418)

It also repeats these when moving the mouse around, and the decal mouse cursor doesn't show.
I just helped a user on discord who was having Godot crash with FSR 2.2 enabled on his NVidia 3080 while adding Terrain3D, with these errors:
ERROR: Width must be equal or greater than 1 for all textures
   at: (drivers/vulkan/rendering_device_vulkan.cpp:1722)
ERROR: Condition "texture.is_null()" is true. Returning: FFX_ERROR_BACKEND_API_ERROR
   at: create_resource_rd (servers/rendering/renderer_rd/effects/fsr2.cpp:240)

He probably needs to upgrade his drivers.
So, in conclusion, FSR 2.2 in Godot is not ready for production use. Even if it works for you, you have no idea if it will be stable on end user machines. We could possibly put some test conditions in Terrain3D to avoid problems if we know the triggers. However, the back end in the engine clearly has bugs which need to be identified, reported, and fixed on their end.
My recommendation is to not use it until it's much more stable.

Regarding TAA: I do see occasional flickering in the demo in some sections of the rock texture, not all. It's minor. If I zoom up the textures so they're pixelated and set the filtering to nearest, it triggers TAA artifacts much more.
In Op's case, it looks like all of the textures are chosen specifically to conflict with TAA. If I put the texture on a mesh it looks fine. As @InitialCon wrote, the difference is that the terrain mesh moves around. Put the viewport in wireframe mode and you can see that when you laterally move the camera the mesh moves constantly. There's, very little TAA artifacts if the camera moves vertically only.
So TAA is likely not going to work. FSR seems fine in the demo, but maybe not with other textures, and is unstable anyway.
For now use MSAA or FXAA.

I've observed that the motion vectors just shoot all over the place with the terrain (and nothing else), so it's a MV issue that's breaking TAA and FSR

Wrobot's latest jungle demo uses TAA in 4.3 with Terrain3D and it looks great. Terrain textures are stable. Very few artifacts in lighting only, unrelated to Terrain3D.
It also tests fxaa, msaa, and FSR. No issues on my 3070.

I'm looking in the Motion Vector Debug view in 4.3 on an AMD Radeon RX 6600, and I'm getting this:

The MVs randomly flicker like that, and it's only happening for the terrain, while other things provide proper motion vectors such as that box
Do also note, that at times the terrain seems to be providing proper MVs too, it just keeps going completely crazy every handful of frames

Interesting fact I've just discovered, the Motion vectors go crazy differently for different LODs, if you scroll from side to side when looking from top down on a flat terrain and look at the MV view, you'll be able to see the different LODs represented in the Motion vectors

This combined with the fact this is showing up mostly during actual camera movement, and only when the Terrain is aware of the camera, I'd say the culprit of these wacky MVs is the Clip map poisition updating

https://www.reddit.com/r/godot/comments/1bmcv9x/shader_motion_vectors_godot_421/
https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/internal_rendering_architecture.html#temporal-antialiasing

Motion vectors are generated on the GPU in the main material shader. This is done by running the vertex shader corresponding to the previous rendered frame (with the previous camera transform) in addition to the vertex shader for the current rendered frame, then storing the difference between them in a color buffer.

Perhaps we can look at the motion vector code in the main shader and invert it, or empty the color buffer when TAA is enabled.
Or perhaps we need a godot proposal to expose an API in the renderer to control the motion vectors to either:

insert an inverse vector to neutralize the motion
override the vector
apply a mask to cull the terrain from motion vector calculation

https://github.com/godotengine/godot/pull/77523 may be the answer to this problem, as it'd disable motion vector generation, which if I understand it correctly, in the case of FSR would mean it'd Fall back to Derived Motion Vectors that wouldn't suffer from this problem

77523, disabling motion vectors does not help and makes things worse.


expanding documentation - including test suites

Hello,
Being able to add test suites with the gulp-webdriver module was a little tricky. I looked at the options you linked to and it seemed that I would just be able to pass in the same suites object that's defined in the config file, which wasn't the case. I thought this addition to the documentation would help save others time in the future. Thanks for considering this pull request!
Shane

ping @sprovostLTG

Closing due to inactivity


WebsiteAgent Question

What is the purpose of this exception? https://github.com/cantino/huginn/search?utf8=✓&q=extract+MUST+have+the+same+number+of+matches+for+each+extractor&type=Code
I would like to extract multiple pieces of data from websites that may not consistently have each piece of data that I am trying to extract.
Is there a workaround? What problem is raising this error preventing?
Thanks (:

Hey @brianpetro, this would be a good thing for us to improve.  The basic idea is that we expect each matcher to have the same number of matches so that we can group them into events.  See #990.

Closing in favor of #990 and #1128.


[Feature Request]: How do I actually build the Extractinator? Add it to the docs

Is your feature request related to a problem?
No;
Solution(s)
Add the recipe for building the Extractinator to the docs, I have no idea how to build it on survival;
Describe alternatives you've considered
No response
Mod Version
2.1.0
Mod Loader Version
1.19.4
Mod Loader
Forge
Additional context
No response

You should be using JEI/REI/EMI. I'll add it to the readme as well.


Update 09-bootstrapping-kubernetes-workers.md

Command 'sudo tar -xvf containerd-1.1.0.linux-amd64.tar.gz -C /' overwrite /bin/  directory. After reboot system doesn't boot correctly.

I don't think it looses binaries in /bin, but I can confirm that ownership of /bin changes from root root to 2000 2000 when following the steps as given in the tutorial
cgeretz@worker-2:~$ ls -l / | grep bin
drwxr-xr-x   2 root root  4096 Dec  3 16:13 bin
drwxr-xr-x   2 root root  4096 Dec 11 22:09 sbin
cgeretz@worker-2:~$ {
>   sudo mv runsc-50c283b9f56bb7200938d9e207355f05f79f0d17 runsc
>   sudo mv runc.amd64 runc
>   chmod +x kubectl kube-proxy kubelet runc runsc
>   sudo mv kubectl kube-proxy kubelet runc runsc /usr/local/bin/
>   sudo tar -xvf crictl-v1.12.0-linux-amd64.tar.gz -C /usr/local/bin/
>   sudo tar -xvf cni-plugins-amd64-v0.6.0.tgz -C /opt/cni/bin/
>   sudo tar -xvf containerd-1.2.0-rc.0.linux-amd64.tar.gz -C /
> }
crictl
./
./flannel
./ptp
./host-local
./portmap
./tuning
./vlan
./sample
./dhcp
./ipvlan
./macvlan
./loopback
./bridge
bin/
bin/containerd
bin/ctr
bin/containerd-shim-runc-v1
bin/containerd-shim
bin/containerd-release
bin/containerd-stress
cgeretz@worker-2:~$ ls -l / | grep bin
drwxr-xr-x   2 2000 2000  4096 Sep 20 20:53 bin
drwxr-xr-x   2 root root  4096 Dec 11 22:09 sbin

Great suggestion. I've updated this section based on your feedback. I'm now extracting the binaries into a local direction then moving them.


Added Comb Sort

Added the files for Comb Sort, a more time efficient version of Bubble Sort. Let me know how it looks, and if there is anything to update/change (and why preferably 👍).

@kelvinlauKL Can you check this over? Let me know if there are any issues.

@srutstein21 Sorry for the wait, I've went over the PR!
Did you know Swift already has a swap method introduced at the global scope? I've removed yours since they're essentially the same. Let me know if I should revert it if you had another reason for it.
Thanks for the contribution! I've merged this.


[web] tried to call a non-function, such as null: 'dart.global.firebase.storage'

Im using Firebase plugin for web and managed to work with firestore and authentication. Now, Im trying to enable firebase storage but when i instanciate Storage gives me this error
tried to call a non-function, such as null: 'dart.global.firebase.storage
for firestore and authentication I use :
import 'package:firebase/firebase.dart' as fb;
import 'package:firebase/firestore.dart';

 fb.Auth _firebaseAuth = fb.auth();
  Firestore _firestore =fb.firestore();

for Storage :
   fb.Storage storage = fb.storage();

Same issue faced here.

I have solved it
please check my answer on stackoverflow

@mohamed6996 Awesome! Thank you for finding a solution. I think it's safe to close it.

i have these in my index.html

but my
import 'package:firebase/firebase.dart' as fb;
import 'package:firebase/firestore.dart';
fb.Auth _firebaseAuth = fb.auth();
Firestore _firestore =fb.firestore();
gives me this
TypeError: dart.global.firebase.storage is not a function

Same here... your answer is not working :)

make sure all the versions match up. i'm using 7.5.0 here. prior to this, i was using a different storage version. hope it that helps

@santhonydo Thanks, my other js files were not of same version so it gave me the error. Making all them same version makes the issue solve.


Include time period on requests show page

I had included the time period in the view spec and developed against that. However, there was no suitable value specified in the factory, resulting in a false positive. I fixed it now @julisa99.

Coverage remained the same at 100.0% when pulling c442e298625b8d00811145f92ba4f0f41d2d84cb on 392_request_detail_complete into 15342a316b09d39fa2d17bed811f68cca9ae73fb on dev.

Coverage remained the same at 100.0% when pulling 2f5f725ca83d6e97b9c3e9a729ffbfa837fa6859 on 392_request_detail_complete into c3a9d6f5abccf829978000cd7de22c7e6aecd965 on dev.


Update README

Is your feature request related to a problem? Please describe.
I saw new users/ newcomers found difficulty to set up the project locally. And also the current README is not looking good and doesn't provide the complete information and functionalities of the whole project.
Describe the solution you'd like

Update README which gives a clear and concise description of the project.
Write the proper steps to set up and test the project on the local system.
Use badges which help in increasing the readability of the Readme

I can work on this

Closing due to inactivity.


Unclear documentation with Backend host headers

Quoted from a stack overflow post:

After going through the Quickstarts and Tutorials and figuring that everything should be setup correctly there is a section under Concepts Backends and backend pools that explains more about the host headers, specifically that “Most app backends (Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the domain of the backend. However, the frontend host that routes to your backend will use a different hostname such as www.contoso.azurefd.net. If your backend requires the host header to match the backend host name, make sure that the backend host header includes the host name backend.”

The offhanded comment above regarding if your backend host requires the host header to match the backend was not enough for me to realize that it should not be the same and it was tech support that finally determined that the backend host header should be blank in order to pass the correct header information.

It's unclear how to correctly configure the Backend host header for my scenario and as quoted above, others are also confused. I've read this statement so many times and it's just not making sense.
My scenario includes a Front Door w/ customer domain name, and custom non-front door managed certificate.  I have two regions with an app service plan.  In West region I have servers mapped to www-west.azurewebsites.net.  In the East region I have servers mapped to www-east.azurewebsites.net.  I'm have the frontend/domains configured to route sub domain for www.customdomain.com for both http - https and /*.
My backend pool is configured by selecting my app server and it pre-fills the remaining form content.  Though I do select the correct west or east webapp.  It's unclear in what scenario the "Backend host header" should be blank, match the Backend host name 'www-west.azurewebsites.net` or be something else.
When I leave it blank so that my custom domain name for host header is used, my site complete breaks and says not found.  Even though, multiple documentation I've found indicates this is the correct setting.  When I leave it matching the Backend host name www-west.azurewebsites.net the site routes correctly, EXCEPT, when the URL omits the trailing slash.  In this case, I'm being routed to www-west.azurewebsites.net  with a / appended to the end. It loads, but, clearly, this is not using my custom domain.

It's unclear how this common scenario should be configured. (I'm assuming this is the most common scenario)
It's unclear why Front Door always adds a trailing / to every request.

This two paragraphs confusing:

Most app backends (Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the domain of the backend.

I'm running Azure Web Apps behind my Front Door and so these host headers should match which they do now, to the backend hostname.  "Most" is very uncertain and not helpful for those learning and trying to apply this into a production environment.

However, the frontend host that routes to your backend will use a different hostname such as www.contoso.net.

This also, matches my scenario, as "www.customdomain.com" is a different hostname and so I should leave it blank?  It's almost as if there is supposed to be another sentence to accompany this statement.  The name doesn't match because it comes from a custom domain header, yet, no explanation of what to do.

If your backend requires the host header to match the backend hostname, make sure that the backend host header includes the hostname backend.

These three paragraphs take turns contradicting one another.  Both options fail for different reasons.
Then we get to the section for Configuring immediately after.  Where it's like someone had to get home for dinner, and left out all of the details.  Adding rational by each form of entry would be useful, at least with host header parts.  Screenshots of before and after covering different scenarios would be really helpful.

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

ID: 3e3cc5d9-df26-b935-9e59-c31c9ad8573b
Version Independent ID: a06afd84-585a-fae2-ead4-c53f85f0dffb
Content: Backends and backend pools in Azure Front Door
Content Source: articles/frontdoor/front-door-backend-pool.md
Service: frontdoor
GitHub Login: @sharad4u
Microsoft Alias: sharadag

@awentzel , Appreciate your patience. This issue has been assigned to the respective content author for updating the document accordingly.

Can confirm this is confusing. We just spent a few days with azure support learning the error "SSLHandshakeError" means we cant use an IP address for the host name and an fqdn for the host header for HTTPS.
Apparently IIS 10.0 is among the backends that require the host header and host name to match.
I scanned the documentation and found no indication the host name and host header needed to match. I did find this sentence though...

Most app backends (Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the domain of the backend.

Consider this instead,

Typically app backends (IIS, Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the host name of the backend.

Add the other popular microsoft backend that fits this "most app backends"
I am not suggesting we list every backend that requires the hostname and host header to match, but IIS is a pretty popular backend solution supported by Microsoft.
Most vs typically, meh whatever.
All the app backends mentioned are microsoft web services, add some other typical app backends that also have this requirement for better context. Apache, NGINIX, lighthttpd. Or, simply say

for best results, ensure the host header matches the host name

Also, a troubleshooting section that mentions common errors such as SSLHandshakeError and what it means,
I thought an SSLHandshake was a problem negotiating protocol and cypher suite, not a miss match of hostname/hostheader.

#reassign: gunjanj

@awentzel I apologize no one has responded to this request of yours. Azure Front Door has been redesigned with the release of the newer tiers. Has this problem persist since then? I would like to work with you on resolving this issue if it still remains for you.

Hi @duongau ,
I have similar problem.
I have one front door with many custom domains attached to it. All of them point to one backend pool with one app service.
I want my custom domain to be attached to my backend app service. I tried to use empty value for backend host header but still the same.
For example: when I enter www.xyz.com I want to get xyz.com in my backend service instead of myfrontdoor.azurefd.net.
Is that possible and how to do it?
Thank you.


Fast Way to switch between multiple open Sessions

Is your feature request related to a problem? Please describe.
I often use multiple open sessions in parallel - sometimes multiple users on the same machine, sometimes multiple sessions on different machines - and most times both the one and the other (for configuration purposes). ;-)
To switch from one session to another, I currently have to tap twice on back (first tap for closing the virtual keyboard, second one to leave the current session), then one further tap for selecting the targeted session.
Describe the solution you'd like
It would be great to switch between open(!) session by a horizontal swipe.
This action should be configurable (on/off) in ConnetBot's Settings - for those who do not like this feature.
A limited screen area (e.g. the upper third of the screen) where the function is restricted to would also be a nice option.
A rotating order would be preferable (could be configurable as well), i.e. when reaching the last open session, a further swipe switches to the first open one and vice versa.
Describe alternatives you've considered
Alternatively, a row of tabs on the screen's top would be helpful in order to switch quickly between open sessions, i.e. a kind of "tabbed browsing" (respectively "tabbed SSHing").
If place isn't sufficient to display a tab for every open session, tabs should be horizontal scrollable as well.
Additional context
I think a combination of both methods would be very excellent, both independently configurable.

Lost labels "feature" & "enhancement", don't know why.
:-(

Today I recognized that the swiping feature is already implemented, so I'm closing that issue.
I really don't know why it didn't seem to work before - sorry for Inconvenience.
Maybe in going to open new tasks for "tabbed SSHing" and rotating swipe.


test flake: tests fail with SIGSEGV

I changed a print to a println in a PR, and CI/CD failed with the following message:
error: test failed, to rerun pass '--test tests'

Caused by:
  process didn't exit successfully: `/target/i686-unknown-linux-musl/debug/deps/tests-a33ec2ad312d30b4` (signal: 11, SIGSEGV: invalid memory reference)
Error: The process '/usr/share/rust/.cargo/bin/cross' failed with exit code 101

You can view the failed test run here: https://github.com/uutils/coreutils/pull/1890/checks?check_run_id=2177569781
I don't have any idea what would have caused this and there doesn't appear to be any more information, but it seems bad that there's a flake in the tests.

Since this failed on i686 musl, I wouldn't be too surprised if some of the unsafe code in uucore (or maybe even one of our dependencies) makes assumptions that only work with glibc or x86_64 musl.  The test that passed right before the segfault uses unsafe code in uucore.


fix: tooltip: fixes tooltip toggle on mobile devices

SUMMARY:
Adds mobileDetector utility to detect iOS or Android user agents is isIOS() and isAndroid()
Adds mobileDetector unit tests
Updates Tooltip to read user agent and determine if hover trigger is allowed
Fixes Popup hover trigger to not dismiss when hovering off the reference element on to the Popup itself
Mobile:
https://github.com/EightfoldAI/octuple/assets/99700808/c58f7361-a3bb-48a5-a32a-64415f0c7d3c
Desktop:
https://github.com/EightfoldAI/octuple/assets/99700808/21e681da-7b41-479a-aafb-f5251ffe714f
GITHUB ISSUE (Open Source Contributors)
https://github.com/EightfoldAI/octuple/issues/665
JIRA TASK (Eightfold Employees Only):
ENG-58436
CHANGE TYPE:

[x] Bugfix Pull Request
[ ] Feature Pull Request

TEST COVERAGE:

[ ] Tests for this change already exist
[x] I have added unittests for this change

TEST PLAN:
Pull the PR branch and run yarn and yarn storybook. Verify the Popup and Tooltip stories behave as expected.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@447d2a1). Click here to learn what that means.
Patch has no changes to coverable lines.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #668   +/-   ##
=======================================
  Coverage        ?   84.81%
=======================================
  Files           ?      881
  Lines           ?    17917
  Branches        ?     6405
=======================================
  Hits            ?    15196
  Misses          ?     2649
  Partials        ?       72

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Don't use JSON.stringify in the default logger.js hook

Sweet, thank you. Will go out with the next release.


Implement ansible-lint in CI to run same process as ansible-galaxy import

Issue Type

Repository enhacement

Is your feature request related to a problem? Please describe.
Currently, CI is based on ansible-test which is originally designed for core modules and Python content. Roles are not covered by this tool during ansible-galaxy import.
It means rating and some issues might not be caught prior import process.
Describe the solution you'd like
ansible-lint is another tool designed for roles and which is run during import process.

Implemented with PR #157


Deployment Stacks

Are Deployment Stacks supported?

@9Rune5 We’ve added support for Deployment Stacks in the new GitHub Action: https://github.com/azure/bicep-deploy.

@ljtill That is a GitHub Action, is there any counterpart for Azure DevOps pipeline?


Prevent one-man coinjoins

Do not sign coinjoin transactions where we are the only participant. Example: https://mempool.space/testnet/tx/9a9a9028b1fb4b64d721a77d4aa2c3c9974d958a79126eafc2dfd86df753d2fb

https://github.com/zkSNACKs/WalletWasabi/pull/7216

Do not sign coinjoin transactions where we are the only participant.

Why should we do that?

#7633 addresses this mixing with self case https://github.com/zkSNACKs/WalletWasabi/pull/7216#issuecomment-1030420342

Why should we do that?

This was poorly explained so, let me try again:  Do not sign coinjoin transactions where we are the only participant AND there is only one output. Because in that case I would be paying mining and coordination fees to reveal my wallet to the entire world.

This was poorly explained so, let me try again: Do not sign coinjoin transactions where we are the only participant AND there is only one output. Because in that case I would be paying mining and coordination fees to reveal my wallet to the entire world.

But by doing that aren't we exposing the links between our inputs to the coordinator (the entire world)? https://github.com/zkSNACKs/WalletWasabi/pull/7216#issuecomment-1030014813

The coordinator already know there is only one participant in this case but at least we don't reveal it to the world and do not pay for that.

but at least we don't reveal it to the world

AFAIU whatever the coordinator knows is considered to be known by the entire world right? So in this unfortunate scenario the user's coins are revealed to the entire world anyway and we only prevent paying for that.

Fixed by https://github.com/WalletWasabi/WalletWasabi/pull/13239