testing: exclude unreachable code in test coverage

What version of Go are you using (go version)?

$ go version
go version go1.12.1 darwin/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/santhosh/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/santhosh/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/v5/44ncgqws3dg3pmjnktpt_l2w0000gq/T/go-build063045597=/tmp/go-build -gno-record-gcc-switches -fno-common"

i have code like this in my project:
const trace = false

func doSomething() {
    if trace {
        fmt.Println("some information")
    }
}

because trace is false, the coverage reports the tracing code as not covered
can such code be shown as "not tracked"
I enable trace if we are debugging some issue in our code using build tags
I can enable trace during coverage generation, but tracing output is large and it takes significant time.
I have seen types package from stdlib also uses if trace
so may be this can be taken as enhancement

Flagging statically-unreachable code seems like a useful signal to me, and whether the compiler is able to determine statically that it is unreachable is an implementation detail.
100% code coverage is usually not an appropriate goal for Go projects. Can you give some more detail as to why this particular behavior is important?

I am not targeting for 100% coverage. the code coverage numbers does not reflect expected ones. the html report generated shows all tracing code as red. so when seeing reports, I have to mentally discard all those tracing lines of code highlighted in red.
currently I am doing a workaround of enable trace variable but do not generate any trace during tests suing build tags. this keeps code coverage track those lines.

I was looking for a similar feature, not so much to reach 100% coverage, but because when reviewing coverage to determine if uncovered lines should be covered, its useful to have an annotation that says "not reachable, expected to be red". I guess I could literally put such a comment in my code, but I think it'd be pretty nice to get a report that said "92% covered, 6%uncovered, and 2% marked unreachable".
I think of uncovered code a bit like lint output or compiler warnings. Developers shouldn't have to reevaluate every time they checkout a project and run lint if the output is relevant. If its been decided that it is irrelevant, its handy to suppress it with in-line markup, and then nobody has to see the output again and then go look to see if its valid.

@sam-github agree with your rationale, would be nice to have

I'm not sure I understand the rationale behind "100% code coverage is usually not an appropriate goal for Go projects". What causes a project written in Go to need different coverage metrics than the same project written in another language such as Python or Java? Those languages support annotations to mark uncoverable regions such that you can tell at a glance that 100% of your coverable code is in fact covered.

@kstenerud, a project written in Go doesn't need different coverage metrics than the same project written in Java. (100% coverage is not usually an appropriate goal for Java projects either.)
However, a Go project usually does not require the same coverage as a project written in Python, unless the Python project is making extensive use of analyzers such as PyChecker or mypy. That is because you can rely more on the Go compiler itself to flag common issues on rare paths (such as misspelled variable names in panic statements). In that sense, the type-checker itself is a form of “test coverage”, and necessarily already covers 100% of lines — so if you're comparing to a Python project without an additional analyzer, the comparable Go coverage is effectively already 100%.

(100% coverage is not usually an appropriate goal for Java projects either.)

100% code coverage is typically not worth the time investment required, regardless of language. I agree that higher code coverage is a good goal in non-typed languages.

@bcmills Static type checking is not code testing. They are completely different things. If tests and coverage were only for type checking, then there'd be no need for unit tests in go at all.
The point of 100% test coverage with "unreachable" annotation support is so that you can run your coverage tool and see at a glance (or with CI rules) that 100% of the code that you WANT to have covered has in fact been covered. As it is now, you have to manually step through the entire report, checking every red line to make sure that it's a code path you actually don't intend to test, ON EVERY CHECKIN (and doing this automatically in your CI is impossible). This leads to human error, and libraries that aren't properly tested and will instead blow up in the wild on some edge case because getBaseFactor() deep in your library should have returned 5113 instead of 5118, but someone forgot to write a test test covering it, and it got missed in the 10,000 line coverage report.

@kstenerud

Static type checking is not code testing. They are completely different things.

They are different points in a continuum of “tools that verify assertions about program behavior”.
A type-checker verifies assertions inline in the program source about program deviations from the type system. Note that the same program may compile with type declarations of different strengths: for example, a program that uses direction-annotated channels will also compile, but with less type information, if the direction annotations are all removed.
A unit-test or regression-test verifies assertions written in the test function about program deviations from the behavior expected by the test.
You can fairly easily trade off between the two: for example, you could use the type interface{} everywhere and type-assert variables at all points of use, then write unit-tests to ensure that the assertions are correct.
So what about 100% coverage? 100% test coverage asserts a very trivial property: namely, “there exists some condition under which the line does not panic without a corresponding recover”. That is a very, very weak property — on par with “the line does not contain a type error”, and certainly not enough to be confident that the code is actually adequately-tested. So either way you end up needing to think about which scenarios you've tested — not just which lines.
Some further reading:

https://martinfowler.com/bliki/TestCoverage.html
https://www.jamesshore.com/Blog/Dont-Measure-Unit-Test-Code-Coverage.html

@santhosh-tekuri, I've been thinking about your use-case some more.
I think the const-guarded lines really should be marked as uncovered. If you have untested lines of code that are unreachable, but that could be made reachable by changing some constant (which you do intend to change), then that code really is untested. When you change that constant and re-run the code, you might get arbitrary panics from that portion of the code, and it might not do at all what you expected it to do.
So for that kind of use-case, perhaps it would be better to use a build constraint to adjust the constant. Then you can run the tests once with and once without the matching tag, and merge the resulting coverage to find out what code is actually covered by the net effect of running the test both ways.
There are still a few cases that are legitimately genuinely unreachable — such as lines that panic due to the violation of some invariant that should be guaranteed to always hold — but even those can often be tested by intentionally violating the invariant in a program run as a subprocess. (Merging coverage profiles from subprocesses is #28235.)

(For genuinely-unreachable code that diagnoses invariant violations, see also #30582.)

@bcmills please don't patronize me; I've been writing unit tests for 20 years. Any system can be cheated. You can write good tests, and you can write bad tests, and no policy or system is going to force you. All you have at the end of the day is your own discipline, and the tools you use to help you maintain that discipline.
This isn't about some magical "100% green" badge of approval. It's about catching human error via good hygiene. If you keep a "100% coverage" policy in your CI system, you'll automatically be notified by the system that your code change is probably not covered by new unit tests to test your reason for the change. THAT's why Python does it, and THAT's why Java does it. The type system doesn't even enter into it.
Of course 100% coverage can be a weak property if that's how you treat it. But as part of a disciplined team it's a godsend.  You CAN ignore that the canary has died, or maybe nail it to its perch and say everything's fine, but some of us would rather take more proactive measures when we see warning signs, or make an informed decision that it's a false alarm (add a "don't report test coverage for this" annotation). All we want are the tools so that we CAN practice good hygiene in go, like being notified whenever we might have forgotten to test some parts of the code changes we'd planned to.

Besides agreeing with everything that @kstenerud just said, I'd like to emphasize that the following statement by @bcmills is in my opinion a very inaccurate description of what test coverage can tell us:

100% test coverage asserts a very trivial property: namely, “there exists some condition under which the line does not panic without a corresponding recover”. That is a very, very weak property — on par with “the line does not contain a type error”, and certainly not enough to be confident that the code is actually adequately-tested.

The point of covering a code path is not just to prove that it doesn't panic. It's also to prove that the code path was executed, and therefore if there is a logic mistake within that path, there is a chance that tests will notice it. If a code path has no coverage, you may wrongly think you are testing it when you're not.
It's not hard to think of situations where what appeared to be a successful test actually just means that you have not accounted for every relevant permutation of preconditions. We've probably all done this quite a few times. Take this deliberately silly example:
func F(n int, b bool) int {
    if n == 5 && b {
        return 0
    }
    return n + 1
}

If none of our tests happen to invoke F with the parameters (5, true), then we can't say whether every related piece of our code was written with a correct understanding of how F behaves— so something might break under those conditions. Of course, it's a basic principle of test design that if you know there is a specific conditional behavior like this, then you should make sure your tests cover all relevant permutations. But it is very easy to forget that. And even if you don't forget, it's also easy to write a test that at the time you wrote it exercised all the code paths... but then due to a logic change somewhere else, those preconditions no longer result in calling F(5, true).
So it is very handy to be able to look at a coverage report and see that the return 0 block is never being called in tests. That has nothing to do with thinking it might panic.
No one here has claimed that perfect coverage means your tests are perfect. The point is the converse: if there's a gap in coverage that you did not anticipate, then you know your tests are not perfect. And therefore, it's desirable to be able to exclude gaps that you're already aware of and have determined are either not significant or impossible to cover in tests, so that any new gaps stand out.

I agree with the utility and ultimately I'd be nice to have something like this in go itself, however does that have to be the first step? The impression I get isn't that go has excess developer resources, so an external tool seems more appropriate. If that gets lots of attention and usage, I'd assume chances will also be higher to get changes about this issue into go itself. I am currently only aware of https://github.com/dave/courtney that already does e.g. marking code as not tested, maybe there's other tools that could be used and extended.

Ah perfect! I'll use courtney then. TBH I'm rather surprised that Google hasn't put some effort into this kind of code coverage tool. A tool that alerts you when your code changes probably haven't been fully tested will reduce your fail rate in production, and that always makes the bean counters happy.

FWIW, I agree there should be a mechanism for explicitly marking some statements as never reachable when evaluating test coverage. In any non-trivial program there will always be some code paths that will only ever be executed in what are effectively impossible scenarios. Yet you don’t want to continue as if everything was okay if the impossible happens. So you attempt to handle the impossible case. Injecting a mock to exercise those scenarios can be difficult to justify. Note that such cases should be a negligible percentage, well under 0.001%, of all testable statements. This isn't, in my opinion, about gaming the numbers. It's about making it easy for a project to annotate the code so it is clear what code falls into the "we don't test this because it can't happen in practice, but theoretically could" bucket while making the coverage data more useful.

I agree with everything @krader1961 said. I follow a unit test approach in my TypeScript projects where I aim to have 100% test coverage, as it is easy to enforce a team to write unit tests for any code they develop. If there is of course part of the code that makes no sense to unit test, it can be excluded with annotations, those annotations are checked within a code review, and it is easier to audit in the codebase why some parts of the application are excluded. This approach looks rock solid to me because there is no discussion about what the code coverage in a project should be: you put 100% in the CI as a threshold (everything else will be rejected) and any case that should be excluded is documented within the code.
When there is no such tool available, that practice can't be enforced, and even with the most disciplined team, some tests will be missed and the quality of the application will be reduced because we are humans and we constantly need tools to aid our work. It would be grand to have that option within go itself, but I will give courtney a try in my Go conversion. But I really really miss this feature. I want robots (CI) to enforce test coverage, not humans.

+1 for a system marking code untestable
the main reason is:

external function could fail if these inputs are wrong
the inputs are tested, and the function never fails, so the panic is not coverable
could i remove the panic ? no: someone can break the input tests or something like, and I want a panic

why I prefer understanding the uncoverable code. When I write tests, I use the HTML display to see the un tested code. If this HTML contains many red code this is hard to read. I can't quick scroll looking for red line, because a lot of red lines are useless.
I propose this kind of result with all metrics:
coverage: 98% of statements, 1% untestable so 99% of total.

and yellow color in the generated HTML for code marked untestable.

Google search brought mere here, because I would like to have some parts of code ignored (not read in the report to quickly see what is missing without reading everything)

@kstenerud, a project written in Go doesn't need different coverage metrics than the same project written in Java. (100% coverage is not usually an appropriate goal for Java projects either.)

if you do not need it fine, but I find it obscure to force your personal preference to all users, since there are obvious quite some that would like to have the possibility to ignore some lines from coverage.
if you ignore it from coverage, or just from the report, is an implementation detail I do not care, but it would be nice to have usable html reports that show exactly which parts of the code (paths) needs more testing.
so what is the status of that issue, ignorance, rejected or maybe some times there will be something that allows us to get more useful html reports than the noisy reports that are now produced?

+1 for this feature. Its a standard feature in most other languages testing frameworks. Adding a comment to ignore a statement doesn't seem that hard and will be quite useful.

also chiming in here to express my support for this feature
we're usually all agreeing that 100% test coverage doesn't make sense, because we know that not all the code is really worth testing, but there is no "numbers" way of knowing how much of the code that we do want to be tested is covered, and we can't enforce any check based on that
having a native way to explicitly specify what code paths aren't worth testing and having those excluded from the coverage is a win win here, as at any point is clear what needs and what doesn't need to be tested, and what's the progress getting to that state

This is pretty obvious, but just to be clear, the ideal way for this to work would be a magic comment:
if x < 0 {
   //go:cover ignore
   panic("unreachable")
}

And then panic("unreachable") would be colored yellow in the coverage HTML.
Can someone tag this as a proposal?

@carlmjohnson, @ianlancetaylor: Many comments in this thread have already suggested adding some kind of magic comment ("its handy to suppress it with in-line markup", "annotations to mark uncoverable regions", etc.). While the original description of the issue was about having the coverage report exclude statically-determined unreachable code, the bulk of the discussion since then has been about whether it's desirable to have any way to exclude any code at all— and the responses of Go maintainers so far have been that it isn't. So I would not expect filing a second issue on that subject to produce a different response.

And, as others immediately pointed out on the newly filed issue, we already have https://github.com/golang/go/issues/34639 and https://github.com/golang/go/issues/12504, which similarly got very dismissive responses— so much so that I'm unclear on why this issue here hasn't already been closed as "won't fix". Conversely, I'm unclear on why there was so little positive response from other users on those issues (or on the latest one) when comments on this thread in favor of the idea have gotten up to 29 thumbs. Since no Go maintainer has replied here in nearly two years, I can only assume that they are either no longer seeing comments in this thread or are so unconcerned about it that they don't even see the point in closing it.

Conversely, I'm unclear on why there was so little positive response from other users on those issues (or on the latest one) when comments on this thread in favor of the idea have gotten up to 29 thumbs.

I'm going to guess that this issue received much more :+1:s because its title is much easier to find via a search (when I do a search like this, this issue is one of the top results). Assuming I guessed right, I think this issue is much more representative of the community's interest in this feature than those other two. Of course, it's biased to people who want this issue. Users that don't like the option to ignore code for coverage for whatever reason are much less likely to find this issue and give it a :-1:.
As to why this is still open (again, only my assumption): robpike said in https://github.com/golang/go/issues/12504#issuecomment-137894946

I dislike tools forcing people to annotate their code to silence them. That is, I dislike these annotations - they're not about the code, only about the tools that analyze the code.

So perhaps the team is still open to some method of allowing code to be ignored, as long as it doesn't require an annotation? I've seen suggestions for an Unreachable function similar to Rust's unreachable!() (technically that's a macro). If that's implemented, maybe it's possible that the team would find it reasonable that the coverage tool could automatically ignore blocks that call that function, which would get this issue closer to being resolved (not completely resolved as I don't think Unreachable alone is enough for the issue creator's request).

@eli-darkly I was replying specifically to @carlmjohnson 's suggestion that we turn this issue into a proposal.  Anybody can file a proposal, and all proposals will be reviewed by the proposal committee.  I was saying that this issue has enough discussion and history that I don't think that we should turn this issue into a proposal.  If someone wants to make a specific proposal, they should file a new issue.  I did not mean to suggest that that proposal issue would receive a different response.  I only meant to explain the best way to turn this issue into a proposal, since that was what @carlmjohnson was discussing.

Personally, I, like many others, do not think that 100% code coverage is a useful goal.  I definitely do not think that Go code should be contorted or commented to achieve that goal.
That said, I personally have no objection to the suggestion in the initial comment on this issue, to ignore unreachable code when determining coverage percentages.  As the coverage tools are currently being rewritten (#51430) perhaps that will be more feasible.

Personally, I, like many others, do not think that 100% code coverage is a useful goal.

This isn't about percentages, it's about having a clear picture . But even if this is purely about numbers, there are also many others who think differently. Is there really a compelling reason to force your opinion on them? As you write "personally". Fine, it's your person determination. Different people, teams and organizations gave different opinions, approaches and methods. This point is to enable not disable with the tools that are given.

The point of having a coverage tool is to guide test writing. If you run the tool and see that such and such file has 97% coverage, you have to click into the file to actually see, oh actually everything is covered, there’s just a single unreachable line. That’s fine for when you’re working, but if you leave something and come back or if someone else wants to add tests, they all have to manually “filter out” the spurious line each time.

@Goldziher My opinion is that it would be a bad for the overall Go ecosystem if Go code starts to have magic comments sprinkled around to support project-specific coverage goals.  If those goals can be achieved without modifying Go code, then I'm fine with that.
@carlmjohnson I think it could be useful to have tools that report changes in coverage percentages.  If the coverage percentage doesn't change, then all is (normally) well.

@carlmjohnson , @iamoryanmoshe
As I said, different organizations and teams have different approaches and ideas.
You're enforcing a narrow opinion on users because of your point of view.
As for the comments being "magic comments" - with all due respect that's hyperbolic. Coverage comments are regular instruction comments available in practically all major languages or testing frameworks or at least a vast majority of these, and that is a fact.
For very smart people, you seem to have very little trust in the competence and intelligence of the go user community. In my personal experience though, go developers are usually more experienced and capable than the average.

@ianlancetaylor In regards to "... Go code starts to have magic comments ...", I feel like this ship has already sailed. The Go team it self introduced some of these commend (e.g. // go:generate) and the community has adopted this e.g. with //nolint, see golangci-lint - Nolint Directive. As of today, according to Github, golangci-lint is used by 3.9k packages (which most certainly only includes open source packets). From my experience, especially with closed source company code, golangci-lint is in widespread use and with it, magic comments to handle false positives (or accepted exceptions) are common.

What can I say?  I'm personally also opposed to "nolint" comments.
//go:generate isn't great but at least it's not scattered through otherwise ordinary code.
@Goldziher The comments are "magic" because they have semantic meaning, unlike ordinary comments.  It's not a reflection of whether they are widely used.

For very smart people, you seem to have very little trust in the competence and intelligence of the go user community.

I'm sure where this criticism is coming from, but I don't think it's accurate.  I think it's poor programming practice to scatter magic comments through code.  They obscure the intent of the code.  They also easily become inaccurate.  And in the case of coverage they are being added in pursuit of a goal that I don't think is appropriate.  This doesn't have anything to with the competence and intelligence of the Go user community.  Go has always been an opinionated language.

Having the ability to have nolint or nocoverage inline comments doesn't force anyone to use them, it would still be the author's choice, so it should not impact people who don't use the feature.
I don't think its fair to describe this as a feature "searching for 100% coverage". Its almost the opposite of that... I know that areas of code are not profitably worth adding test coverage for, and what I want to do is tell my tooling (and my collaborators) to stop telling me that I didn't cover them... but I do want the tooling to tell me when I add new uncovered code, or unintentionally stop covering code that used to be tested. A pure x% doesn't tell me that, even if I tell the coverage tool to tell me if coverage goes down, it won't be able to tell me if coverage changes unintentionally, maintaining or event improving the %.
Above is the information I (and probably many others) want, the inline comments are just the only mechanism I'm aware of that would achieve that.
I also don't love inline comments as mechanism, and strive to have as few nolint comments in code as possible. I'd prefer to have the annotation be part of the tool config.
Unfortunately, to my knowledge, there is no common way to refer to a line of code in a file that remains accurate as the file changes (file+lineno obviously doesn't work). Probably there are some researchy ways possible. git can tell when code moves, so its not a totally intractable problem, in theory, but sometimes the simple pragmatic way is best. Of course, just not having the feature at all is simpler :-), but I'm hoping eventually to be able to communicate to my collaborators (and tooling) lines that are intentionally uncovered. Somehow.

What can I say? I'm personally also opposed to "nolint" comments.

I'm sure where this criticism is coming from, but I don't think it's accurate. I think it's poor programming practice to scatter magic comments through code. They obscure the intent of the code. They also easily become inaccurate. And in the case of coverage they are being added in pursuit of a goal that I don't think is appropriate. This doesn't have anything to with the competence and intelligence of the Go user community. Go has always been an opinionated language.

I think it's pretty clear, but just to be absolutely sure: is the opposition to magic comments in general, or magic comments that are specifically for coverage? Because I think it's possible to have magic comments that are useful both as compiler hints for optimization and that also hint to a coverage tool to ignore some lines.

@ianlancetaylor I'm not sure arguments of this kind can ever reach a consensus, so I don't want to belabor this, but I do want to respond to one of your points that I think is the clearest case of people talking past each other:

And in the case of coverage they are being added in pursuit of a goal that I don't think is appropriate

Variations of this opinion have been stated by Go maintainers several times, but I think that they all rely on a mistaken idea of what the "goal" is from the point of view of people who want such a feature. For instance, "100% code coverage is usually not an appropriate goal for Go projects", or "100% test coverage asserts a very trivial property: namely, there exists some condition under which the line does not panic...". And it's common in all such arguments to see related statements like "just because you have 100% coverage doesn't prove that your code is correct."
I think those are all straw men, and I and other commenters on this thread have put a good deal of effort into explaining why. Literally no one is saying that 100% code coverage is a worthy goal for its own sake, or that it proves everything is correct. It is simply a very useful way of verifying that you haven't accidentally added a logic branch that your unit tests are not covering at all, when you thought they were. I provided an example of that kind of scenario in this comment above.
Now, not everyone approaches development in that way. But it is an extremely common practice that very many developers find useful, and it is not in any way language-specific. Go is opinionated about many things, but they are generally things that are related to characteristics of the language. "I would like my builds to catch me if I accidentally forget to write any tests that exercise a particular computation in my code" is not such a thing, and to say that it's not "appropriate" for developers to have such a desire is the kind of thing an individual developer may be opinionated about, but that we generally do not want language tools to be. There are developers who don't believe you should write comments in your code at all (for reasons like "the things you say in your comments might become untrue later") but no one would seriously suggest to remove comments from the language for that reason.

@spenserblack I dislike magic comments in general.  I particularly dislike magic comments that appear inside function bodies.
@eli-darkly Thanks.  I think I do understand the intent.  At least, what you wrote doesn't change my mind.  But I think we've covered the point sufficiently.
On this topic, please see @rsc 's comments on #53271:

https://github.com/golang/go/issues/53271#issuecomment-1156758772
https://github.com/golang/go/issues/53271#issuecomment-1156759685

Go arguably needs this sort of comment MORE than most languages - the downside of requiring that every possible error be properly handled is that you get a lot of error-handling blocks for errors that aren't actually possible. I've seen lots of code following patterns like this:
func someFunc(input) error {
 thing := getValidThing(input)
 result, err := doSomethingWith(thing)
 if err != nil {
   return err
 }
 // ... do something with result ...
}

where the only way doSomethingWith will ever return an error is if you give it an invalid Thing. There is no way to get full test coverage on this function, because the error condition can't happen (and also there's no reasonable way for the compiler to detect that this is unreachable code).
My editor highlights my scrollbar in red wherever there's code that isn't covered, which is fantastically useful in most languages for making it easy to find any cases I forgot to test, but very frustrating in go because there are frequent red markings that are just noise imposed by this sort of error handling. As someone mentioned earlier, it's also really frustrating when you have files where you really do have 100% coverage apart from some cases like this - it'd be nice to know that
Also, leaving this feature out doesn't mean that there won't be "magic comments"[^1] in a lot of go code - it just means that any project devs who want accurate coverage numbers will end up inventing their own or using some third-party checker like courtney, so we get magic comments anyway except they're not standardized and they integrate poorly with other tools.
Or, even worse, you'll get novice programmers changing the example above to result, _ := doSomethingWith(thing), and thinking this is better because the red mark in their editor went away; I don't think this is something the language tools should encourage.
[^1]: I'm not sure I'd actually call // notest a magic comment. When I think of magic comments I think of things like # frozen_string_literal: true in Ruby or # -*- coding: utf-8 -*- in Python, both of which actually change the behavior of the language itself, whereas // notest or # pragma: no cover aren't language features, just annotations for utilities.

@dan-lepage I don't think that's a good example. Error handling in Go is for cases when it is possible for the code to fail. And when a failure is possible, it makes sense to have a test for it.
And in this case, I would argue that result, _ := doSomethingWith(thing) is actually the correct approach if you're 100% sure it cannot fail. Simply put, if the code can fail, you should find a way to test it. If it can't fail, you shouldn't be doing error checking in the first place.
If you want to be extra paranoid, you can use panic(err) instead of return err. So that you can catch any related programming error during development. Then it would make sense to not include that in coverage.

This is another example of why a runtime.Unreachable() that was excluded from coverage but panics on access would be nice.

If you want to be extra paranoid, you can use panic(err) instead of return err. So that you can catch any related programming error during development. Then it would make sense to not include that in coverage.

That's the situation I had in mind when I made my comment two years ago. There are a few places in the Elvish shell I've been contributing to that are "can't happen unless a logic bug exists" situation.  Such as switch statements with a default: panic() to help ensure that if an impossible condition occurs the program doesn't blithely continue on and report an error message that isn't actionable by the user. This is about ignoring blocks that aren't covered by unit tests because those blocks don't represent normal error cases (which should have test coverage).

Maybe the specific line of code panic("unreachable") (spelled exactly like that) could play the role of a magic comment. All statements in a basic block containing that statement would be ignored.
It is clear, unambiguous, doesn't litter the code unnecessarily, doesn't add API, and fails loudly if the implicit assumption of untestability is violated.

@rkollar:

In this case, I would argue that result, _ := doSomethingWith(thing) is actually the correct approach if you're 100% sure it cannot fail.

I'm 100% sure that it cannot fail as long as nobody changes the doSomethingWith function in a way that breaks it. If I just discard the error, though, then someone in the future could break doSomethingWith and someFunc would now be invisibly swallowing the error.
But at the same time I want to exclude the error handling from coverage because as long as doSomethingWith is correctly implemented it is completely impossible for me to write a test case that executes that path, and indeed if a test ever does cover that path it is a sign that something is broken.
@josharian:

Maybe the specific line of code panic("unreachable") (spelled exactly like that) could play the role of a magic comment.

The downside to this is that if someone does break the code, the only message they get is "Unreachable" instead of actually getting to see the error that broke things.
Panicking also feels more fragile to me - if someone breaks doSomethingWith later on in a really subtle way and the error makes it into production before anyone notices, I'd much rather learn about it from a user who saw something odd in their logs than from a user reporting a total crash. I suppose that's just an argument for better fault barriers, though.
But I also think that looking at the specific "unreachable code" use case and finding ways around it is sidestepping a more general point, that the ability to indicate "I have chosen deliberately not to test this block of code" is a useful feature in a variety of cases.
Here's another sadly common use case: you have just inherited a big block of poorly-designed code that's hard to test - maybe there are conditionals that will only be met if certain operations take hours, or blocks that are hard-coded to use production resources, etc. etc. And this library is already being used in production (presumably due to mistakes that other people made) and you have been tasked with adding tests for as much of it as possible. Obviously the ideal would be that nobody had made those mistakes in the first place, and the next best thing would be to redesign the library to be properly testable and properly tested (and update all the existing code that's using the current poorly-written API), but that might be weeks of effort when what you really need, right now, are some tests for as much as you can test. Then it's invaluable to be able to go through the library writing tests and confirm that every part of it is either at least minimally tested or explicitly marked as "this is not worth the effort it would take to test it right now".
I get that there are a number of strong arguments of the form "If you're writing good Go code you shouldn't need this feature", but I can't possibly be the only person who's ever had to work with existing poorly-written code[^1].
[^1]: To be clear, I'm not trying to blame all these problems on novices or junior devs - sometimes the code is poorly-written because I wrote it and managed to screwed it up. That doesn't change the fact that I might not have the time to fix it right away.
Perhaps this is drifting away a bit from the original issue of specifically excluding unreachable code, and maybe I should be lobbying for this in a separate issue, but I definitely believe there's a strong case for being able to mark code as deliberately untested, regardless of whether it's because the code is theoretically impossible to reach or because you have other reasons for not wanting to test that code right now.

This feature needs to be added to Go so its official code coverage tool will become more robust.
As other commenters here have already pointed out, having the flexibility to exclude code that doesn't need to be tested from code coverage is very useful because it reduces noise when reading code coverage reports.
I hope the Go Team changes their minds about this because it's a very practical feature to have.

I have, not too lang ago and somehow motivated through that topic here, written this blog post: The 100% test coverage topic , that gives a little bit more/additional context why it's a good idea to have an exclude possibility.
But on the other hand, since I found courtney, and this works reasonable well, plus it has some additional features, I am fine. However, having that all out of the box would be of course awesome.

+1 for flagging unreachable code

I am using https://github.com/dave/courtney just because of this issue, mainly because I have a lot of:
err := somelib.callTo3rdPartyFunc()
if err != nil {
   return err
}

it is hard to make the call to somelib.callTo3rdPartyFunc() fail, and I don't need to test the 3rd party function, from the point of view of my code, there is no need to force an error just to cover the execution of  return err statements
if go tooling ignores the coverage for such trivial return err statements that would be already an improvement without needing "magic comments"


Build against Apache Spark branch-2.1

Apache Spark 2.1 is scheduled on Late Nov 2016. It's still under development, but the main features are frozen and release branch exists.
This issue aims to build spark-llap against branch-2.1 because branch-2.1 is different from branch-2.0 in terms of the followings.

Removed

CatalogColumn SPARK-16731
HiveSharedState SPARK-17190

Changed

CatalogStorageFormat SPARK-16645
HiveSessionCatalog SPARK-17338
MetastoreRelation SPARK-16374 SPARK-17903
SubqueryAlias SPARK-17068

This resolved in https://github.com/hortonworks-spark/spark-llap/commit/534b7eeb47e1cbc415d13872ccc158203a5788d9.


Create mandatory-and-supported-os-services.md

This is the first draft for the OpenStack services lists.
related to https://github.com/SovereignCloudStack/issues/issues/528

closing this in favor of https://github.com/SovereignCloudStack/standards/pull/587


Fix delay of drawing maps after NewGame

(Fix #124, #180)
In corescript version 1.6.1, tilemap isn't displayed for a moment after NewGame. (only parallax is displayed)
In other words, drawing maps is delayed at scene starting.
Fixed!

HOLY COW guys that has to be moved to official RMMV thank you!

also, that means pixi-tilemap doesn't work properly if its inside a filter.

https://github.com/pixijs/pixi-tilemap/commit/1053aab63a7a30004ca7ab249fafb31b8cc0dfe3


Exposed services are not accessible using external IP

Hi,
I created a windows +k8s cluster on Azure Container Service. SSH to the master node and created a deployment using:
kubectl create deployment iis --image=microsoft/iis
kubectl expose deployment iis --port=80
kubectl edit svc/iis

Changed the type from ClusterIP to LoadBalancer and saved it. I got the external IP from kubectl get svc and opened the IP on browser and it worked.
Then I deleted the service & deployment and followed the same procedure to deploy and expose my own container. I got the external ip, then I curl external-ip in the master SSH terminal and it returned the response but when i opened this same external IP on my browser, its not reachable.
I tried the above mentioned commands to test iis container again and same issue for this as well now.
There is a same issue on kubernetes git - link

cc: @anhowe @JiangtianLi See upstream issue, sounds like there are enough reports that we should look into this. Can one of you take a look?

I deployed a new cluster and exposed a service and its accessible. I am not sure what was the issue but there is one thing I have noted that when I was running curl Node IP:NodePort, I was getting connection refused but now in newly deployed cluster i am getting response.

@mfaizanse If you RDP to Windows node, what is State when you run
netsh advf show publicprofile
on the old and new deployment?

How to RDP to the windows node? I tried using the public ip but was unable
to rdp.
On 08-Mar-2017 9:58 PM, "Jiangtian Li"<EMAIL_ADDRESS>wrote:

@mfaizanse https://github.com/mfaizanse If you RDP to Windows node,
what is State when you run
netsh advf show publicprofile
on the old and new deployment?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/acs-engine/issues/369#issuecomment-285099822,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJcH2dq0rjShQBWllns6WTbsJlX1IqPOks5rjt4mgaJpZM4MVK8n
.

You can follow the instructions at https://github.com/Azure/acs-engine/blob/master/docs/kubernetes.windows.md

okay. I have deleted the old deployment. But you can replicate the problem at your side using the same sequence:
Create & deploy cluster using examples/windows/kubernetes.json

kubectl create deployment iis --image=microsoft/iis
kubectl expose deployment iis --port=80
kubectl edit svc/iis
4 . Change to LoadBalancer
5 . Delete service and deployment

Now, repeat the first 4 steps and this time you won't be able to access exposed service.
P.S. I have tried the same sequence today again just to make sure but I have also deleted that cluster too.

@mfaizanse Thanks for the detailed repro steps. I have a cluster that can repro. I will investigate and update.

@JiangtianLi How to allow a container running in a pod to communicate with the outside world?
I am trying to ping www.google.com  from inside a container but getting request timeout.

@mfaizanse the ping action is blocked. you can docker exec -it xxx cmd to attach the container and run powershell && wget http://www.google.com -OutFile xxx.txt and it works.

@wangtt03 Got it. Thanks

@mfaizanse not sure if anyone find the root cause, but a similar problem is found on Linux cluster too. See issue #446 .  Worth checking the load balancer of the exposed service, if it's in 'Failed' state, then likely same issue.

@JiangtianLi What is the status of this issue?

@mfaizanse This has been resolved per fix in v1.5.3 kube-proxy/kubelet Windows binaries.

Thank you @JiangtianLi . I have tried multiple deployments and services and its working now.


Fix double-encoding of characters in titles

Remove the double-HTML-encoding of characters into HTML entities.
See https://issues.dp.la/issues/8199
The #inline_markdown method call is not necessary for <title> elements, because it's not desirable to have markup in titles -- all we need is straight text.  The #inline_markdown method encodes HTML entities, and the resulting string was being encoded one more time by Rails automatically when the view was rendered.

The #inline_markdown method call is not necessary for <title> elements, because it's not desirable to have markup in titles -- all we need is straight text.

I think the issue is that set titles themselves will occasionally contain Markdown (see, for example, the set about A Raisin in the Sun - the title is set to *A Raisin in the Sun* by Lorraine Hansberry). My guess is we also need something that will strip Markdown from the title data when it gets passed into the <title/> element.
Maybe we could use a different redcarpet renderer class, like Redcarpet::Render::StripDown?

Yes, @anarchivist has it right.  The idea was to strip the markdown characters (such as *) out of the titles in a two-step process:  First, render the HTML with inline_markdown.  Second, strip out the HTML elements with strip_tags.  This would, in theory, leave us with plain text.  But it looks like Redcarpet::Render::StripDown might be a more elegant (and less buggy) solution.

OK, @AudreyAltman and @anarchivist, that last change brings in Redcarpet::Render::StripDown.
No HTML tags are stripped, but they'll get turned into HTML entities. The assumption is that the maintainers are supposed to know to use Markup, not HTML, and things will look funny anyway if they use HTML markup in their text.

:+1: :squash:?

:ok_hand:

OK, that should be ready to merge.


Timestamps are broken

I noticed what this issue is better now.  It looks like it displays the timestamps in backwards order.  The first shout has the latest shouts timestamp.  And the newest shout has the oldest displayed shouts timestamp.

Yes, exactly same issue for me - all timestamps are in backwards order.


Autogenerate API docs from JSDoc comments

This adds the command npm run docs to generate API documentation. It doesn't appear to be that useful currently, given that solid-panes is not really a library to be used by other projects, but give it a look and see what you think.
I'm not sure if and where we'd want to publish this, so I did not include CI configuration to generate the docs and deploy it somewhere. This might be something we'd want to look at later.
Fixes #96.

True, we want to expose API documentation for the parts that will be exposed to others - this might be limited to how the data browser will expose APIs to panes, as that is probably the interface that other developers will need to care about.
Lets put this on hold for now and pick it back up when we know more of how the codebase will evolve in the coming weeks.

Also, just to note: I was hoping typedoc could reuse the types used in signatures (in TypeScript files), so that we don't need to be redundant.

I'll close this PR for now, since we have https://github.com/solid/solid-panes/issues/96 as a reminder for this later.


Add favorites

Hi, i have created a fork of retroflow in which i have added the ability to add favorites (and also added neo geo pocket color). I still have a few issues, i was wondering i you woulf like to colaborate on this? https://github.com/peterdickx/RetroFlow-Launcher/tree/Favorites

Hi Peter,
Thanks for the constribution.
Sorry for the slow response, I'm struggling to find the time and will to move forward with the project.
I've had a quick look at the code and started adding to mine from the base upwards based around the approach below.
I think it may work best if the user goes to the game info screen then presses triangle to mark the game as a favourite.
This allows people to still change view with circle.
Marking as a fav on the info screen also allows time for the favourite, all, and current system tables to be refreshed and cached.
The favourite icon could perhaps be shown to the left of the clock instead of on the boxes, (top right on the info view).
I'm happy for you to progress and release forked versions provided credit is still given to VitaHex for the original version.
There's some great ideas in the issues and requests for this fork, I'm just struggling to move forward with it.
To be honest I'm thinking anout archiving the fork, but at the moment there's some good ideas being gathered here.

I've made some progress on this using the approach I mentioned above.
It took a lot more code than I thought to update the lists quickly without reloading, but seems to be working okay.
Thanks for the pull request it gave me a bit of a head start.
Should be out in the next release.
(No date set, will bundle it with some other stuff).

Hi, thanks! the merge request was not really needed, i just wanted an easy way to share my changes to your code.


Toast is not displayed in useEffect during intial render

Hi,
Okay, I'm not sure if this is a shadcn ui issue or not ...
I'm developing Next.js 14 application with shadcn ui. I have a server action like this,
"use server";
...
export const createMessage = async (currentState) => {
  return {
    message: "Success";
  };
}

then, I have a client component
"use client";
...
const Chat = () => {

  // formState used for notification after server action
  const [formState, formAction] = useFormState(createMessage, {
    message: "empty",
  });

  useEffect(() => {
    // this logged '{ message: "empty" }' in the initial rendering
    console.log("%s", JSON.stringify(formState));
    // the toast is not display during the initial render but it will show "success" after the following form is submitted.
    toast({ description: formState.message });
  }, [toast, formState]);

  return (
    <form action={formAction}>
      <Button type="submit">Create message</Button>
    </form>
  );
}

export default Chat ;

Why the toast is not shown when the page was first loaded (and the useEffect was triggered and the empty message is logged in the console)?

The console.log function works immediately upon component render because it's a synchronous operation.
However, the toast function likely depends on the DOM being fully ready or a ToastProvider component being mounted in your app. If these conditions aren't met when the toast function is called, the toast notification might not display.
import { Toaster } from "@/components/ui/toaster"

export default function RootLayout({ children }) {
  return (

        {children}
        <Toaster /> //this component might not be ready when the toast function is called

  )
}

This explanation is based on my experience, There may be other causes for this issue but this is also a case.

@jrTilak @tjhoo Guys Toaster component is exported from '@/components/ui/sonner' and that needs to be included in index.tsx/layout.tsx(entry point of webapp). it's acutally using React.createPortal and that's why necessary for toast component to show up while having absolute positioning

im having a similar issue where <Toaster/> doesn't display toasts, But if I copy the content of <Toaster/> and paste it in my app it works fine

Try extracting the toast function from useEffect and wrap it inside a function:
"use client";

import * as React from "react";
import { toast } from "sonner";

export default function Home() {
  const showToast = () => toast("hello");
  React.useEffect(() => {
    showToast();
  }, [showToast]);
}

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

This is the answer you are looking for, based on the official sonner docs
https://sonner.emilkowal.ski/toast#render-toast-on-page-load
Render toast on page load
To render a toast on initial page load it is required that the function toast() is called inside of a setTimeout or requestAnimationFrame.
setTimeout(() => {
toast('My toast on a page load');
});

For me what worked is to put  in my _app.jsx along with timer.
_app.js
`
export default function App({ Component, pageProps }) {
return (

  <Component {...pageProps} />

  <Toaster />

</UserProvider>

)
}
`
Dashboard.jsx
`  useEffect(() => {
const timeoutId = setTimeout(() => {
toast.error('My toast on a page load');
}, 1000);
  return () => clearTimeout(timeoutId); // Cleanup the timeout on component unmount

}, []);`

Solution 1: For me, simply rendering the <Toaster /> component before {children} worked.
import { Toaster } from "@/components/ui/toaster"
export default function RootLayout({ children }) {
  return (

        <Toaster /> // Render it before the rest of the application
        {children}

  )
}

Solution 2: From docs:
useEffect(() => {
  const timer = setTimeout(() => {
     toast.info('your message here')
  }, 100);

  return () => clearTimeout(timer);
}, []);


DateTime Picker for filter

Hi,
I was looking around for a Nugget Package that support GridView and work with MVC6. I found your awesome work. However, as i notice, the Filter for DateTime type can be improved to be more user-friendly. Maybe we can have a Datetime picker dialog instead of the Equal, Less than, etc... Do you have any plan to add that feature anytime soon?
Thanks for your great work 💯

Currently grid date filter reacts to jQuery UI's datepicker and uses that if it's available.
Do you have something else in mind, that could be used to improve user experience?

I see the datetime picker now. Haven't used this package in my project though so i can't say much. I will open another issue if i find something worth to share. Thank again.


After model relationchip updates

HI.
Would be nice if you will be able enhance model regeneration.  If I add additional relations between entities model is updated or overwrite,  but order of entities in liquibase is not changed so database initialization failed. Just reorder this based on new model relationships.
thanks.

I think that this issue was corrected with the 1.1.3 https://github.com/jhipster/jhipster-uml/releases/tag/1.1.3.
Try to update and tell us if everything works.


Salsa doesn't show any outline for this source code

Testing #2218
No jsconfig.json
exports.something = function() {
    return true;
}

This issue was moved to Microsoft/TypeScript#6644


Fixed code module loading in distribution (gestaltModuleCleanup branch)

Description
This pull request fixes code modules in the gestaltModuleCleanup branch (see #484).
Testing
Set-up

Fetch my codeModuleTest module using the command groovyw module get codeModuleTest -remote BenjaminAmos

Testing that distributions work

Create a new distribution by running the command gradlew distZipBundleJREs
Go into the desktop/build/distributions/app directory and run the game
Create a new game (any ship will work)
Ensure that the words Game duration are visible in the top-left corner of the screen, following by an increasing numerical value

Testing that development builds work

Run the game (either from an IDE or using the gradlew run command)
Create a new game (any ship will work)
Ensure that the words Game duration are visible in the top-left corner of the screen, following by an increasing numerical value

Hooray Jenkins reported success with all tests good!

Thank you for showing me this. I've got a more concise solution though :)


Use ipv6 address as default when out_forward  and macOS catalina

Describe the bug
out_forward tries to connect  ::1 instead of <IP_ADDRESS> because the following code uses first value(which is ipv6 address) as the hostname.
https://github.com/fluent/fluentd/blob/8f2ea4bb26e5735b36acf5f6dc0fa5796ce4c4f9/lib/fluent/plugin/out_forward.rb#L731
https://github.com/fluent/fluentd/issues/2865#issuecomment-596321456
To Reproduce
Needs macOS catalina (I'm not sure other versions of macOS)
server
<source>
  @type forward
</source>

<match test>
  @type stdout
</match>

client
<source>
  @type dummy
  tag test
</source>

<match test>
  @type forward

  <server>
    host localhost // if it's <IP_ADDRESS> then it works well
    port 24224
  </server>
  flush_interval 0
</match>

getaddrinfo(3) returns the values in a different order on ubuntu and macOS.
# ubuntu:bionic
$ docker run --rm -it rubylang/ruby:2.6.5-bionic ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)'
[["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6], ["AF_INET6", 80, "::1", "::1", 10, 1, 6]]
$ docker run --rm -it rubylang/ruby:2.7.0-bionic ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)'
[["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6], ["AF_INET6", 80, "::1", "::1", 10, 1, 6]]

# macos:catalina
$ rbenv local 2.6.5; bundle exec ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)'
[["AF_INET6", 80, "::1", "::1", 30, 1, 6], ["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6]]
$ rbenv local 2.7.0; bundle exec ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)'
[["AF_INET6", 80, "::1", "::1", 30, 1, 6], ["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6]]

Expected behavior
Use ipv6 address  when setting localhost to host at server section of out_forward
Your Environment

Fluentd or td-agent version: at least 1.8.0
Operating system:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.3
BuildVersion:   19D76

Kernel version: 19.3.0

Your Configuration
Same as the To Reproduce
Your Error Log
2020-03-09 15:00:30 +0900 [info]: parsing config file is succeeded path="example/out_forward.conf"
2020-03-09 15:00:30 +0900 [info]: gem 'fluentd' version '1.8.0'
2020-03-09 15:00:30 +0900 [info]: 'flush_interval' is configured at out side of <buffer>. 'flush_mode' is set to 'interval' to keep existing behaviour
2020-03-09 15:00:30 +0900 [info]: adding forwarding server 'localhost:24224' host="localhost" port=24224 weight=60 plugin_id="object:eec"
2020-03-09 15:00:30 +0900 [warn]: both of Plugin @id and path for <storage> are not specified. Using on-memory store.
2020-03-09 15:00:30 +0900 [warn]: both of Plugin @id and path for <storage> are not specified. Using on-memory store.
2020-03-09 15:00:30 +0900 [info]: using configuration file: <ROOT>
  <source>
    @type dummy
    tag "test"
  </source>
  <match test>
    @type forward
    flush_interval 0
    <service>
      host "localhost"
      port 24224
    </service>
    <buffer tag>
      flush_interval 0
    </buffer>
  </match>
</ROOT>
2020-03-09 15:00:30 +0900 [info]: starting fluentd-1.8.0 pid=6735 ruby="2.7.0"
2020-03-09 15:00:30 +0900 [info]: spawn command to main:  cmdline=["/Users/yuta.iwama/.rbenv/versions/2.7.0/bin/ruby", "-Eascii-8bit:ascii-8bit", "-r/Users/yuta.iwama/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/setup", "/Users/yuta.iwama/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/bin/fluentd", "-c", "example/out_forward.conf", "--under-supervisor"]
/Users/yuta.iwama/src/github.com/fluent/fluentd/lib/fluent/supervisor.rb:796: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/Users/yuta.iwama/src/github.com/fluent/fluentd/lib/fluent/system_config.rb:132: warning: The called method `overwrite_variables' is defined here
2020-03-09 15:00:31 +0900 [info]: adding match pattern="test" type="forward"
2020-03-09 15:00:31 +0900 [info]: #0 'flush_interval' is configured at out side of <buffer>. 'flush_mode' is set to 'interval' to keep existing behaviour
2020-03-09 15:00:31 +0900 [info]: #0 adding forwarding server 'localhost:24224' host="localhost" port=24224 weight=60 plugin_id="object:ed8"
2020-03-09 15:00:31 +0900 [info]: adding source type="dummy"
2020-03-09 15:00:31 +0900 [warn]: #0 both of Plugin @id and path for <storage> are not specified. Using on-memory store.
2020-03-09 15:00:31 +0900 [warn]: #0 both of Plugin @id and path for <storage> are not specified. Using on-memory store.
2020-03-09 15:00:31 +0900 [info]: #0 starting fluentd worker pid=6749 ppid=6735 worker=0
2020-03-09 15:00:31 +0900 [info]: #0 fluentd worker is now running worker=0
2020-03-09 15:00:33 +0900 [warn]: #0 failed to flush the buffer. retry_time=0 next_retry_seconds=2020-03-09 15:00:34.095101 +0900 chunk="5a065b88ecab18d92b81f21cee90a2c9" error_class=Errno::ECONNREFUSED error="Connection refused - connect(2) for \"::1\" port 24224"

Additional context

I've checked some docker images such as: docker run --rm -it xxx ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)' command.

debian:buster
debian:bullseye
ubuntu:focal
ubuntu:groovy
debian:sid
ubuntu:bionic

These images returns [["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6], ["AF_INET6", 80, "::1", "::1", 10, 1, 6]]
but It seems that there is a case that it dpends on customization.

if /etc/docker/daemon.json enables IPv6 for docker, it will return [["AF_INET6", 80, "::1", "::1", 10, 1, 6], ["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6]], so this issue is reproducible.
If /etc/gai.conf on host is changed (precedence ::ffff:0:0/96 100 ), so even though IPv6 is enabled, this issue will not be happen. (assume that fluentd is executed on host)

@ganmacs
I'm not sure what is the expected "Use ipv6 address as default when out_forward and macOS catalina" behavior.
# macos:catalina
$ rbenv local 2.6.5; bundle exec ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)'
[["AF_INET6", 80, "::1", "::1", 30, 1, 6], ["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6]]
$ rbenv local 2.7.0; bundle exec ruby -e 'require "socket"; p Socket.getaddrinfo("localhost", 80, nil, Socket::SOCK_STREAM)'
[["AF_INET6", 80, "::1", "::1", 30, 1, 6], ["AF_INET", 80, "<IP_ADDRESS>", "<IP_ADDRESS>", 2, 1, 6]]

It indicates that IPv6 is used.
<server>
    host localhost // if it's <IP_ADDRESS> then it works well
    port 24224
  </server>

But it seems that IPv4 is expected in this comment.
It seems that IPv6 address is used on macOS catalina, but as you noted, it should be IPv4 address.
Could you explain a bit more, please?


loss render is NaN，The following problems occurred. I did not modify the training parameters. Is the training parameters wrong?

Traceback (most recent call last):
File "train.py", line 35, in
main()
File "train.py", line 32, in main
m.train(opt)
File "G:\work_document\python_work\L2G-NeRF-main\model\nerf.py", line 61, in train
if self.it%opt.freq.val==0: self.validate(opt,self.it)
File "G:\work_document\Tensorflow\Miniconda3\envs\L2G-NeRF\lib\site-
packages\torch\autograd\grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "G:\work_document\python_work\L2G-NeRF-main\model\l2g_nerf.py", line 89, in validate
super().validate(opt,ep=ep)
File "G:\work_document\Tensorflow\Miniconda3\envs\L2G-NeRF\lib\site-packages\torch\autograd\grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "G:\work_document\python_work\L2G-NeRF-main\model\base.py", line 154, in validate
loss = self.summarize_loss(opt,var,loss)
File "G:\work_document\python_work\L2G-NeRF-main\model\base.py", line 139, in summarize_loss
assert not torch.isnan(loss[key]),"loss {} is NaN".format(key)
AssertionError: loss render is NaN

python train.py --model=l2g_nerf --yaml=l2g_nerf_blender --group=exp_synthetic --name=l2g_lego --data.scene=lego --data.root=./data/blender/nerf_synthetic  --camera.noise_r=0.07 --camera.n
oise_t=0.5
Process ID: 21456
[train.py] (PyTorch code for training NeRF/BARF/L2G_NeRF)
setting configurations...
loading options/base.yaml...
loading options/nerf_blender.yaml...
loading options/barf_blender.yaml...
loading options/l2g_nerf_blender.yaml...

H: 400
W: 400
arch:

density_activ: softplus
embedding_dim: 128
layers_feat: [None, 256, 256, 256, 256, 256, 256, 256, 256]
layers_rgb: [None, 128, 3]
layers_warp: [None, 256, 256, 256, 256, 256, 256, 6]
posenc:

L_3D: 10
L_view: 4

skip: [4]
skip_warp: [4]
tf_init: True

barf_c2f: [0.1, 0.5]
batch_size: None
camera:

model: perspective
ndc: False
noise: True
noise_r: 0.07
noise_t: 0.5

cpu: False
data:

augment:
bgcolor: 1
center_crop: None
dataset: blender
image_size: [400, 400]
num_workers: 4
preload: True
root: ./data/blender/nerf_synthetic
scene: lego
train_sub: None
val_on_test: False
val_sub: 4

device: cuda:0
error_map_size: None
freq:

ckpt: 5000
scalar: 200
val: 2000
vis: 1000

gpu: 0
group: exp_synthetic
load: None
loss_weight:

global_alignment: 2
render: 0
render_fine: None

max_epoch: None
max_iter: 200000
model: l2g_nerf
name: l2g_lego
nerf:

density_noise_reg: None
depth:

param: metric
range: [2, 6]

fine_sampling: False
rand_rays: 1024
sample_intvs: 128
sample_intvs_fine: None
sample_stratified: True
setbg_opaque: False
view_dep: True

optim:

algo: Adam
lr: 0.0005
lr_end: 0.0001
lr_pose: 0.001
lr_pose_end: 1e-08
sched:

gamma: None
type: ExponentialLR

sched_pose:

gamma: None
type: ExponentialLR

test_iter: 100
test_photo: True
warmup_pose: None

output_path: output/exp_synthetic/l2g_lego
output_root: output
resume: False
seed: 0
tb:

num_images: [4, 8]

trimesh:

chunk_size: 16384
range: [-1.2, 1.2]
res: 128
thres: 25.0

visdom:

cam_depth: 0.5
port: 8600
server: localhost

yaml: l2g_nerf_blender
existing options file found (identical)
Setting up [LPIPS] perceptual loss: trunk [alex], v[0.1], spatial [off]
Loading model from: G:\work_document\Tensorflow\Miniconda3\envs\L2G-NeRF\lib\site-packages\lpips\weights\v0.1\alex.pth
loading training data...
number of samples: 100
loading test data...
number of samples: 4
building networks...
setting up optimizers...
initializing weights from scratch...
setting up visualizers...
visdom port (8600) not open, retry? (y/n) n
Setting up a new session...

Sorry, we can not reproduce the issue. You could change the random seed to see if it happens again.

Sorry, we can not reproduce the issue. You could change the random seed to see if it happens again.

@manjidada I got the same issue on blender dataset. It seems depth range will become 0 when entering the iteration loop like above, which is weird.
Therefore, I force the depth range to be scalar instead of torch tensor during validation and it work for me. Like:
class Graph(nerf.Graph):
    ...
    def forward(self, opt, var, mode=None):
        # rescale the size of the scene condition on the pose
        if opt.data.dataset == "blender":
            depth_min, depth_max = opt.nerf.depth.range
            position = camera.Pose().invert(
                self.optimised_training_poses.weight.data.detach().clone().view(-1, 3, 4))[..., -1]
            diameter = ((position[self.idx_grid[..., 0]] -
                        position[self.idx_grid[..., 1]]).norm(dim=-1)).max()
            depth_min_new = (depth_min/(depth_max+depth_min))*diameter
            depth_max_new = (depth_max/(depth_max+depth_min))*diameter
            if mode in ["train"]:
                opt.nerf.depth.range = [
                    depth_min_new, depth_max_new]
            else:
                # force scalar
                opt.nerf.depth.range = [
                    depth_min_new.item(), depth_max_new.item()]
        ...
    ....

    @torch.no_grad()
    def validate(self, opt, ep=None):
        pose, pose_GT = self.get_all_training_poses(opt)
        _, self.graph.sim3 = self.prealign_cameras(opt, pose, pose_GT)
        # force scalar
        if torch.is_tensor(opt.nerf.depth.range[0]):
            opt.nerf.depth.range[0] = opt.nerf.depth.range[0].item()
        if torch.is_tensor(opt.nerf.depth.range[1]):
            opt.nerf.depth.range[1] = opt.nerf.depth.range[1].item()
        super().validate(opt, ep=ep)

Hope for the official solution.

Thanks for pointing this out. I rescale the size of the blender objects(near/far) condition on the optimized poses as shown here. I guess the depth range becoming 0 is caused by the diameter becoming 0, but it is weird as the diameter is determined by the maximum distance between the two cameras. Does anyone have any idea?


Nullability mismatch on variables

The following query doesn't work:
new Query()
    .Repository(Var("name"), Var("owner"))
    .Select(repository => repository.Name);

"Nullability mismatch on variable $name and argument owner (String / String!)"
"Nullability mismatch on variable $owner and argument name (String / String!)"

The variables created don't match the argument's nullability.

This is still happening:
var query = new Query()
    .Repository(Var("owner"), Var("name"))
    .PullRequest(Var("number"))
    .Select(x => x.Title)
    .Compile();

Nullability mismatch on variable $number and argument number (Int / Int!)

Looks like $number is declared as non-required (Int) in the query signature although the schema expects it to be required (Int!)?

@achimkoellner exactly. I thought I'd fixed this in #67 but seems I didn't quite get it.

Actually looks like #67 did fix it.


Automated cherry pick of #3805: feat(region): Add Guest Template & Service Catalog

Cherry pick of #3805 on release/2.13.
#3805: feat(region): Add Guest Template & Service Catalog

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.13@4868184). Click here to learn what that means.
The diff coverage is 6.45%.

@@              Coverage Diff               @@
##             release/2.13   #4061   +/-   ##
==============================================
  Coverage                ?   6.91%
==============================================
  Files                   ?     508
  Lines                   ?   85735
  Branches                ?       0
==============================================
  Hits                    ?    5929
  Misses                  ?   79305
  Partials                ?     501

Flag
Coverage Δ

#aFlag
6.91% <6.45%> (?)

Impacted Files
Coverage Δ

pkg/cloudprovider/images.go
0% <ø> (ø)

pkg/mcclient/options/servers.go
0% <0%> (ø)

pkg/compute/models/guests.go
0.58% <0%> (ø)

pkg/compute/models/service_catalog.go
16.36% <16.36%> (ø)

pkg/compute/models/guest_template.go
4.26% <4.26%> (ø)

Continue to review full report at Codecov.

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


Disable IncludeSource in projects with IncludeSymbols disabled

@pranavkm @natemcmaster - Can any of you explain this change?
cc: @divega @ajcvickers

We enabled IncludeSource for symbol packages via the SDK. This broke packing a couple of projects which previously had symbol package generation disabled. I re-disabled it by turning off IncludeSource.

@smitpatel Is there anything we need to follow up on here?

@ajcvickers - No


Dataview for filtering Tasks from Pages that have a key::value on them

It would be great to have a filter that looks for tasks in files that have a key::value pair on them. I have an extensive system to "tag" files that belong to a project with "Project:: Name". I dont use tags for this because i want everything connected as a backlink to my project dashboard. and using this method for a year now.
Filtering out tasks with the tasks plugin or the dataview query works fine like that - so i dont have to #project every single task.
any way to do this now? or maybe implement that? thanks!

Hiya and thank you.  The only suggestion I can make with the current way that CardBoard works is (assuming that you have your tasks in files that belong to a specific project) to put a project tag in the front matter, as any tags in the front matter will be applied to all tasks in the document.  This may help to get you what you need (hopefully).
Outside of this though, if I understand correctly, what you would ideally like is for CardBoard to support using Dataview "tags" to build boards as an alternative to using regular #tags.  Interesting idea which I have not given any thought to as I am only a very light user of Dataview.

(note to self) also see #51

yes exactly. the Frontmatter in most files does have a "project: name" yaml
i would need to find a tool to auto tag all old and new files. but that's a good workaround. thanks!
(i do use kanban for now with more manual process. good thing here is i can "send" tasks to an inbox and drag them to various columns based on topic. this does not tag them on the source though. so semi perfect. also a workaround ;-) )

this could also be great later on to attach tasks to project members and sync over to asana or such a thing

getting off track. sorry.

Fab - thanks for getting back.  I think I know what would be needed for this.  Will leave it labelled as it is for now and have a fuller think and backlog prioritization after I have got drag and drop out of the way (which will take some time I think).
On the assign tasks to people front - I am pondering this.  I'd love to have it so you'd get a little picture of the person (perhaps I should integrate with gravatar) on a card or something - but that's something for a separate issue at some point :)  At the moment I am using #people/name tags in my vaults.  There are some things that aren't particularly satisfactory about that approach at the moment tho - specially when tagging sub-tasks for people; the bit I'm working on at the moment is to (hopefully) improve this somewhat.
Thank you again.  I will keep this issue updated as I have thoughts and when I get closer to being able to look into it properly.  All the best for 2023 :)

At the moment I am using #people/name tags in my vaults
I've create a page for each person (/Resources/_person/GivenName LastName.md) for each person and organisation (/Resources/_organisation/Organisation Name.md) that I mention in tasks or documentation, and that way my tasks look like this:

[ ] [[Acme Group]] awaiting response from [[Wile E Coyote]] regarding [[Integration of X with Y]] #pending

This means that I can go to that persons page and see all the linked references, and thus see what I'm waiting on from them.

that is a very cool system. i use something quite similar for single tasks. but most of the time it's a meeting note with the name of the person as person::name somewhere on the page .
tasks are then attached to that meeting. so i have references to all needed info (when summarizing the tasks i get the link to the file. the file has the name of the person in the filename too)
but maybe a collaboration with the programmer of the tasks plugins would be nice. it could introduce the possibility for variable new fields (next to due and start,..). best self configurable. so it would be possible to set a "people emoji" (tasks) for people key (Dataview,cardboard) for example. or a "connection" emoji for "connected task". or....

Fab - thanks for getting back. I think I know what would be needed for this. Will leave it labelled as it is for now and have a fuller think and backlog prioritization after I have got drag and drop out of the way (which will take some time I think).
On the assign tasks to people front - I am pondering this. I'd love to have it so you'd get a little picture of the person (perhaps I should integrate with gravatar) on a card or something - but that's something for a separate issue at some point :) At the moment I am using #people/name tags in my vaults. There are some things that aren't particularly satisfactory about that approach at the moment tho - specially when tagging sub-tasks for people; the bit I'm working on at the moment is to (hopefully) improve this somewhat.
Thank you again. I will keep this issue updated as I have thoughts and when I get closer to being able to look into it properly. All the best for 2023 :)

Heya, I use another variation for a workflow for tasks that are assigend to other people and projects. I also use inline dataview fields like [assigned:: [[Person]]] or [in_project:: [[Projectpage]].
So when implenenting dataview handling in cardboard it would be really greate if it is possible to use those dataview fields to create boards for people and projects and eg. have a column in the project board for each person working on that project, etc.
And thanks for the great plugin, it helps me a lot!


Is there an efficient way to store python object in a list?

What I want to achieve is accessing a list of python objects with little overhead. Originally I thought I can use
cdef class Something:
    cdef int prop
cdef vector[Something] some_list

# accessing
print(some_list[0].prop)

But I found that Python object cannot be used as template parameter. Is there any efficient way to achieve similar behavior? Maybe directly using PyObject* is an option, but I guess there will be some reference counting problems?

Use a Python list.
Note that the bug tracker is the wrong place to ask usage related questions. Use the cython-users mailing list instead.


fixed about page and rearranged items in navbar

About Page

fixed mobile spacing
added favicon and navbar logo
Fixed title

Navbar

rearranged order to home about github

I wasn't happy with the github icon options so I left that out for now

And yeah, we can revisit the Github thing later


Add Key Bridge shield for Maryland MDTA maintained section of Key Bridge and approaches

I'd like to see this shield for Baltimore's Key Bridge (below) in Americana. It is used around the project area for recognition. Here's an approximate portion that is part of the bridge facility. I'll make a relation though.

Famartin, CC BY-SA 4.0, via Wikimedia Commons

😭😭😭


Make repository names per-course configurable

Make the following repository names per-course configurable through an Advanced course configuration panel.
// Default repository names.
const (
	InfoRepo       = "course-info"
	AssignmentRepo = "assignments"
	TestsRepo      = "tests"
	SolutionsRepo  = "solutions"
)

Should be considered in connection with #314.


Weird object syntax parsing?

Hi folks, I hit this weirdness while putting together my workshop examples. The following will fail its keyset check.
(begin-tx)

(env-data
 { "multi-keyset": { "keys": [ "udon-is-good"
                               "soba-is-better"
                               "ramen-is-best" ]
                     "pred": "keys-2" }})

(env-keys [ "udon-is-good" "soba-is-better" ])

(load "02-multisig.pact")

(enforce-keyset 'multi-keyset)

(commit-tx)

But the following will pass:
(begin-tx)

(env-data
 { "multi-keyset": { "keys": [ "udon-is-good"
                               "soba-is-better"
                               "ramen-is-best" ]
                    , "pred": "keys-2" }})

(env-keys [ "udon-is-good" "soba-is-better" ])

(load "02-multisig.pact")

(enforce-keyset 'multi-keyset)

(commit-tx)

The comma before "pred" made a big difference. If not present, it's like the "pred" key-val pair wasn't even recognized. Which makes me wonder how the first example even parses.

It's a parsing/compiling bug, easily reproducible:
pact> {'a:1 'b:2}
{"a": 1}

I suspect there's a missing EOF in the compiler.

BTW this means the default keyset predicate is in effect, "keys-all", in the case above


Exceljs

close #2085

Thank you for your pr, I will code review later. It is expected to be released in version 4.3.


lakeFS samples- make cloud/own-storage default much clearer

From conversation with @iddoavn and @kesarwam : Can we use use profiles in Docker Compose so that users just do docker compose up (and avoid the problem that the Docker desktop app restart the whole stack even if only one container was launched)?

Yes, profile can solve the problem.

PR: https://github.com/treeverse/lakeFS-samples/pull/118


Shebang + /usr/bin/env not available everywhere (hacl-star-raw opam package)

The configure script that ships with the hacl-star-raw opam package relies on the shebang and /usr/bin/env to dispatch itself to bash. Unfortunately /usr/bin/env is not available on every platform.
Would it be possible to dispatch to bash directly instead? For example like this.
I know this is a little unorthodox and usually I would rely on patching the source. However, it seems that the package ships with a checksum mechanism that makes this a little awkward - maybe I am missing something.
Appreciate any input!
/cc @victor-dumitrescu

Thanks for the report. Which systems don't have /usr/bin/env? The advantage of using env (see https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my/29620#29620) is that on systems that have multiple versions of bash, it picks the one that comes first in the user's PATH as opposed to hardcoding a particular location. For instance, on OSX, /bin/bash is a version from 15 years ago whereas oftentimes /usr/local/bin/bash exists and is much more recent.
My only concern is that, say, on OSX (again), this would mean that OPAM runs the configure script with bash 3.2 whereas I (and others) would only be testing it with bash 5 and above. This might lead to inconsistencies and/or bugs not being caught. Of course this can all be addressed with better CI but it'd help to know first which scenario (without env) we're addressing here. Thanks!

For context, this is the case when using Nix. In a Nix build environment the system-level directories are completely hidden to achieve build purity. That means /usr/bin, /bin and the like are unavailable.
I don't understand your point about the advantage of env. What you're describing seems to be the standard rule to resolve commands to their executables via $PATH, no? With that, env bash is identical to bash - the former will use env to look up bash in $PATH and the latter will use the current shell (i.e. sh) to lookup bash in the $PATH and both will choose the first occurrence. Wouldn't that mean that executing bash ./configure is identical to running ./configure as long as /usr/bin/env exists?
Apologies if I am missing something obvious.

For context, I tried it locally.
$ echo $PATH
/home/ole/.opam/default/bin:/run/wrappers/bin:/home/ole/.nix-profile/bin:/etc/profiles/per-user/ole/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin:/home/ole/.cabal/bin:/home/ole/.local/bin
$ which bash
/run/current-system/sw/bin/bash
$ realpath /run/current-system/sw/bin/bash
/nix/store/98lfv62phdndldvgpxmjp634cifqmk30-bash-interactive-5.1-p8/bin/bash

$ nix-shell -p bash # Start a new shell, with a different bash in scope.

[nix-shell:~]$ which bash # Shows different bash
/nix/store/fa138pjfv8b4sg5l80ls55ynz9g4s3p9-bash-interactive-5.1-p16/bin/bash

[nix-shell:~]$ echo $PATH # In-scope bash path is the first entry. The old entry is still there but comes later.
/nix/store/fa138pjfv8b4sg5l80ls55ynz9g4s3p9-bash-interactive-5.1-p16/bin:/nix/store/9chsm1gqvvpqywz219s1rknfrzr5xjfz-patchelf-0.14.3/bin:/nix/store/jz10kjr0lnhynwxnrzv4kcwbjs5s0ri8-gcc-wrapper-10.3.0/bin:/nix/store/finlf6zyxhpqi8hp2p4fgxkgqvjp6l78-gcc-10.3.0/bin:/nix/store/drb5a0j2z8fh6bivl9aq15fbfmrx62kb-glibc-2.33-117-bin/bin:/nix/store/2w6011wwg5v6qxz182r4d0mmr3i4rxm1-coreutils-9.0/bin:/nix/store/55ayck4pllh4qallb1dbhbkrzwrrl02r-binutils-wrapper-2.35.2/bin:/nix/store/x2zbyl2l4xayv4d5is0b31plfq8xjjym-binutils-2.35.2/bin:/nix/store/dndi916j6yxzfzzj2sma2llhrlwahq06-bash-5.1-p16/bin:/nix/store/2w6011wwg5v6qxz182r4d0mmr3i4rxm1-coreutils-9.0/bin:/nix/store/pr0l0cwak2dprcvvzqvli1kkpg7k9fci-findutils-4.9.0/bin:/nix/store/c5xa1n6bl34gxfmjlqgaxdyk4i583fk5-diffutils-3.8/bin:/nix/store/jdhk02s01ca02qv083f41wz8jj25gybc-gnused-4.8/bin:/nix/store/3fvq0jjjh50vh0rlqr2xc9ya8llcj113-gnugrep-3.7/bin:/nix/store/i4mm5ycljiq465ncr29mg9bf7wn18i8c-gawk-5.1.1/bin:/nix/store/4rypjibv28cbbg21apsqnnyi3k2glzjd-gnutar-1.34/bin:/nix/store/660k06nr64g3fqndivn6brmk8ly7ivdz-gzip-1.11/bin:/nix/store/rmxjjpg43f6jssh82q29q21lzlcqzwxz-bzip2-<IP_ADDRESS>.2-bin/bin:/nix/store/xgibf1z6b7zx4h1hv3v8qw0f2n1jv4pm-gnumake-4.3/bin:/nix/store/dndi916j6yxzfzzj2sma2llhrlwahq06-bash-5.1-p16/bin:/nix/store/agfkd1d9mmcniwrvh10afn054x1n8iqi-patch-2.7.6/bin:/nix/store/45j7wibbdckl5f50bs5nq7damhy8cahp-xz-5.2.5-bin/bin:/home/ole/.opam/default/bin:/run/wrappers/bin:/home/ole/.nix-profile/bin:/etc/profiles/per-user/ole/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin:/home/ole/.cabal/bin:/home/ole/.local/bin

Sorry, I was talking about a hypothetical scenario which would be to replace the first line of the script with /usr/bin/bash -- I somehow assumed this was your preferred fix. I am actually fine with the suggested change for the OPAM file.
If @victor-dumitrescu is down for it, that's good for me!
Thanks for the suggested fix.

I managed to find a Nix-specific way to circumvent this problem. From my perspective this is now less of an issue.

For completeness' sake I am including the solution for whomever it may concern.
mkDerivation {
  # ...

  fixCargoChecksums = writeScript "fix-cargo-checksum" ''
    jq "{ package: .package, files: { } }" "$1" > "$1.empty"
    mv "$1.empty" "$1"
  '';

  postInstall = ''
    # Patch shebangs in shell scripts
    patchShebangsAuto

    # Fix Cargo checksum files (because we patched some files)
    find $out -name .cargo-checksum.json -exec $fixCargoChecksums {} \;
  '';

  # ...
}

Hi, thanks for opening the issue and sorry for the late reply. The solution you suggested seems reasonable. Just to be sure, I'd like to test it on all our other supported platforms before committing it to opam. If that's not urgent (as I think you suggest in the last comment) then I can do it next time we make a release. Would that be OK?

Yes absolutely!

@victor-dumitrescu friendly ping on this issue... since you have other changes in the pipeline, maybe worth trying out this one too? thanks!

@vapourismo Did you see that HACL* was already packaged with Nix? https://github.com/hacl-star/hacl-nix/blob/main/hacl/default.nix
Other than that, I'm no Nix expert but I often saw fellow nixers advocating for #!/usr/bin/env bash instead of #!/bin/bash, and afterward use patchSchebangs in the Nix derivation.
Hence I think the issue can be safely closed, if I'm not mistaken?

In the meantime, there is a new build process and new packages over in https://github.com/cryspen/hacl-packages/ so I'm wondering how important the portability of the configure script here still is. If so, I can commit the #!/usr/bin/env bash solution.

Closing, as there seems to be another solution for this https://github.com/hacl-star/hacl-nix


audit: allow gnome development exceptions to be for all versions

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

See https://github.com/Homebrew/homebrew-core/pull/73982
This allows the all keyword to be used instead of a version number in the allowlist. This will cause the audit to be ignored for all versions of the formula.
CC @carlocab and @tschoonj

Review period will end on 2021-03-30 at 20:45:18 UTC.

I think this should be done to the other audit exception hashes. I'll look into doing that. While I'm at it, I may also try to add the audits that check that a formula isn't in the exception list if it's not longer an exception which I've been meaning to do for a while.

Could we maybe check version.major > 40? That sounds like it'll cover it all.

Oh yeah, that's a better idea 👍
I think the other stuff is still good to have but maybe those will come in a separate PR.

Review period ended.


[BUG] Playwright seems to be slow when using Java on a MacBook M1 Max

System info

Playwright Version: v1.31.0
Operating System: [macOS Venture 13.2.1]
Browser: [All, but Edge is extremely slow]
Other info:
roy@testsmith playwright % java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

mvn version 3.9.1
Source code

[ ] I provided exact source code that allows reproducing the issue locally.

Link to the GitHub repository with the repro
https://github.com/roydekleijn/playwright-java-slow-on-mac
Steps
mvn clean test will execute the same test twice.
Expected
I expect it to be as fast as (or close to) Playwright using JS/TS.
Actual
It is much slower. Even the browser startup takes a decent amount of time. I see timings of:
23104
14800
17969
14543
The JS/TS implementation gives:
1369
1005
1114
1003
1127
Both tests are executed in headed mode.

I can confirm that there is 3x difference when running with MS Edge (~5s in node.js vs ~15s in java). Edge runs in arm64 mode under nodejs and in x86_64 translated under java (even thought it is the same universal binary). I couldn't see the difference with bundled Chromium as we download aarch64 rather than universal browser binaries.

This will be resolved automatically once we address https://github.com/microsoft/playwright-java/issues/1198 and include aarm64 build of Node.js.

awesome, thanks for your quick response, and great to see that's already taken care of.

With the fix merged it should be working now. It is scheduled for 1.33. Note that you also need to make sure that the test is running in a native arm64 jvm to not trigger Rosetta mode for universal browser binaries.

It's at least two weeks from now.

I tried V1.33, but it is still slow on Edge...

Make sure your JVM supports Apple Silicon. Can you run the following command line and go to chrome://version in the browser:
mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args="cr --channel msedge"

First line should be something like Microsoft Edge  112.0.1722.68 (Official build) (arm64)
`

113.0.5672.53 (Developer Build) (arm64)

We always install Microsoft Edge universal binaries, so my guess is that your terminal is a rosetta emulated one. It installs the right Edge but starts in x86_64 emulated mode. I'm unfortunately not able to test it, since I haven't enabled the rosetta mode on my system.

@roydekleijn what do the following two commands print for you in the terminal where you start playwright?
arch
file $(which java)

Closing per the response above, feel free to open a new issue if it doesn't work.

I reinstalled Microsoft Edge (Apple Chip), and I use v1.33. Now the timings are:
6306
2418
2608
2619
2611
2620
2027
2086
2086
2115
2096
2054
Much better.. Unfortunately not sure what the root cause was.


Fix #68 - filter out type initializer from Type.GetConstructor portable ...

This looks good and ready to go to me.

Passes all of the tests.

Will pull when we get confirmation of CLA.  I expect it to be threading its way through the system.

Fixes #240


Allow WalkDifferentStructsto take a "type predicate"

Now that we have optional types, it can avoid visiting parts of the graph using type information.

nope. its removed now. https://github.com/attic-labs/noms/commit/3863e91c17f69db4ba3621d27135ad2c44136b4a


[SOLU-2362] Deploy Gaudi Prometheus metric exporter with assumed role structure

Add support for Gaudi prometheus exporter
Signed-off-by: Yupeng Zhang<EMAIL_ADDRESS>

Exporter on Gaudi3 is now fixed we don't need a change in this PR. This is ready to be merged


Date grouping mixed with last year files

Explain the bug
When enabling Date grouping (Date Modified and Date Created), grouped files and folder is mixed with last year date modified.
To reproduce

Go to a folder with older files
Click on Sort and Group By Date Modified
All the grouped items mixed with last year date items

Expected behavior
Items grouped normally with today and yesterday date
Logfile
debug.log
Screenshots

System Information

OS Version: Windows 10 21H1 19043.1055
App version: Build from main branch from 0f53a4241323f64ccaf66d6c0e281a09349e411c commit

Thanks for reporting this, does this issue persist after manually refreshing?

Thanks for reporting this, does this issue persist after manually refreshing?

Yes, it's still shows the bug

I was about to report same issue but I see already here. Had a look at the code and I think I have a good enough fix (only checked Today and Yesterday grouping, I don't see issues with older groups)
The PR seems stuck (my first fix here not 100% sure what to do with it) but hopefully someone can review it or help me with it ;)

@IniGisah this issue should be resolved with #6134.


Import module error in spa.tsx when running react microfrontend

Describe the bug
I created a root config and application using the single-spa CLI tool and all works fine. I followed the guidelines in their docs (https://single-spa.js.org/docs/ecosystem-vite#micro-frontend-projects), as well as your readme, for adding an application for vite react ts.
I'm getting the error below inside the spa.tsx file (it's the exact code in your readme). When I try and access the standalone vite app directly it works fine. So, I think I can say for sure, that the issue is on the single-spa side. Any idea what could be causing the problem?

Project type: [ ] Root Config [x] Micro-frontend/parcel
Project Framework:  [x] React [ ] Svelte [ ] Vue [ ] Preact [ ] Other:

You're most likely using SystemJS modules in the root config project. Did you make the change to ES modules?

I see in the docs they mention that using their root config approach is recommended. Is there a way to mix their approach with SystemJS for root configs and your approach for Vite apps? Or do I have to use your Vite root config approach to get this working?

I have never tested my plug-in with SystemJS modules.  Feel free to do so.  Once a guy told me that works just fine.  This is set in Vite options, completely outside my plug-in.  It is a rollup option (the output format).  Look the setting up, and set it to 'system'.  Note, however, that Vite is incapable of serving SystemJS modules while in serve mode (npm run dev).  If you do SystemJS, you can only work locally with built projects.  Forget HMR.
Now, having said that, maybe you should follow the instructions of creating a root config project using my plug-in.  Then you'll be working with ES modules, HMR will probably work for you, and overall things will be simpler.

Thanks so much for the feedback, this is really helpful!
Just one last question, I don't see any mention of managing layouts with your root config approach (although I may have missed it). In my case I'd use a react implementation of Vite for my root config. Would I then use something like react router for handling layout instead of the single-spa layout engine?

I don't find single-spa's layout engine helpful.  I never use it.  I always do registerApplication() + start() instead.  I cannot comment on what's better or on any best practices around it.  I also dislike React very much and only do Svelte, so I cannot comment on react-router either.  This topic is up to you!
I am converting this to a discussion.  I encourage you to come back to this discussion and post your findings around this React-specific topics, so others can benefit from your experience.


The BOSH services we create do not need to update on config change

The only referenced secrets are the desired manifest and instance group
manifest.

According to @viovanov there could be a reference via Quarks ENV var support, he will come up with a test case :)


Turn on cookies by default for .NET Client

SignalR requires sticky sessions when using layer 7 load balancers. This is usually specified using cookies. Today we don't set a cookie container by default in the .NET Client which means it fails with a 404. We should turn it on by default.

cc @anurse

We just need to initialize the cookie container to a default (empty) value right? Should be trivial.

We'd want to put this in a 2.1 servicing release (for the client package).

Moving to 2.1.3.

Description
TODO: Describe the bug
Customer Impact
TODO: Describe how it affects customers. Is there a workaround? How many customers reported?
Regression from?
TODO: Fill in when it worked, when it stopped working
Risk
High/Medium/Low/Very Low
TODO: Fill in explanation of risk.

@BrennanConroy / @davidfowl can you fill that in?

BTW this fix is approved so fill in the template so we know the deal, but go ahead and check in the fix to release/2.1 ASAP, then port as needed to other branches (e.g. release/2.2, and I guess the bot will port to master).

The issue doesn't seem to be a cookie problem, and since we don't have a repro and the team that hit the issue is asleep we can't really do anything.