spec: guarantee non-nil return value from recover

Calling panic with a nil panic value is allowed in Go 1, but weird.
Almost all code checks for panics with:
     defer func() {
        if e := recover(); e != nil { ... }
     }()

... which is not correct in the case of panic(nil).
The proper way is more like:
     panicked := true
     defer func() {
        if panicked {
              e := recover()
              ...
        }
     }()
     ...
     panicked = false
     return
     ....
     panicked = false
     return

Proposal: make the runtime panic function promote its panic value from nil to something like a runtime.NilPanic global value of private, unassignable type:
package runtime

type nilPanic struct{}

// NilPanic is the value returned by recover when code panics with a nil value.
var NilPanic nilPanic

Probably Go2.

An alternative solution would be to allow recover() to be used in ,ok assignments. For that to really solve the stated problem though, that would require all call sites to be updated.
My personal leaning at the moment is in favor of the proposal as stated.

Is any program out there using nil panics intentionally? A simple search for panic(nil) doesn't give anything on my entire GOPATH besides a go/ssa/interp test. But I'm more worried about panics with variables that could/would be nil.
In any case, I agree with the sentiment and the proposed solution. Perhaps runtime.NilPanic should be clarified that it's only for untyped nils, though. For example, this case has a nil value but wouldn't be equal to nil when recovered:
var err *myError
panic(err)

FTR: I admit this is a real problem. I just prefer explicitly handling it.

Is this a real problem, though? I doubt it. What if the implementation of panic with a nil argument instead just did, panic("nil value passed to panic")? Thereby fixing the problem and diagnosing it one one stroke.

Is this a real problem, though? I doubt it.

I've had to deal with it at least twice. net/http had hangs when people panicked with nil.
@mpvl was talking about error handling the other day and was showing some examples of how defensive code should ideally look like (and how it's hard to get right), and he forgot the nil panic case, showing it's even harder than it seems.

What if the implementation of panic with a nil argument instead just did, panic("nil value passed to panic")? Thereby fixing the problem and diagnosing it one one stroke.

That's what I'm proposing, except with a variable (which could have a String method with that text). But I'm fine (but less fine) with it being that string value exactly, as matching on strings is a little gross.

This proposal makes total sense--for a language which prides itself on its simplicity and obviousness, it is perplexing that the only way to check for a panic(nil) in a recover is by using some other variable. I can't possibly think up a situation when someone would call panic(nil) on purpose anyhow.

While I believe that this is a very good thing to be able to handle, I think that a , ok pattern would be a bit better. If I panic(nil) then in a language like Go, I would want nil to be the recover() value.
So then recover would look like:
defer func() {
    if e, ok := recover(); ok {
        // do recovery stuff
    }
}();

@deanveloper I like your idea for being backwards compatible.

The proper way is more like: […]

That turns out not to be correct either: runtime.Goexit can terminate the goroutine without a recoverable value, but that pattern (and the variant as written by @cznic) would incorrectly report a panic where no panic occurred.
(https://play.golang.org/p/yS1A1c5csrR)
As far as I can tell, there is no way for a defer to distinguish between panic(nil) and runtime.Goexit(), which to me suggests that at least one of them should be removed.

As far as I can tell, there is no way for a defer call to distinguish between panic(nil) and runtime.Goexit(), which to me suggests that at least one of them should be removed.

As it turns out, we can use the fact that a runtime.Goexit() cannot be recover'd to distinguish it from panic(nil), via a “double recover sandwich”:
https://play.golang.org/p/TsmlVqfkP_T

if you want to check for it, then, instead, don't do it.

Perhaps you're using a badly-written library, and you don't have control over it. I've seen worse before :man_shrugging:

Our team spent 3 hours today hunting down what we now know to be a panic(nil) call. The problem is that panic(nil) is valid yet undetectable since recover() only returns the value that was panic-ed.
This proposal as-is would work as the common if recover() != nil { pattern would see a non-nil value. Therefore, has my vote. (Some internal type would work too, as long as it is not nil)
Making recover() return two values (the panic-ed value and whether a panic occurred) as mentioned several times would make more sense, However, changing recover() will undoubtedly be rejected for being non-backward compatible. Or too complicated if made magical (like map and range that provide one or two values, depending how you use it).

Sometimes. people may call panic(nil) for success. See the case 3 in this article.

@go101, eliminating code like that would be an added bonus.

I agree this pattern is some weird. But I think panic(nil) should be treated as an unexpected feature.
Another use case (also some weird, ;D):
func doSomething() (err error) {
	defer func() {
		err = recover()
	}()

	doStep1()
	doStep2()
	doStep3()
	doStep4()
	doStep5()

	return
}

// panic with nil for success and no needs to continue.
// panic with error for failure and no needs to contine.
// not panic to continue.
func doStepN() {...}

which is much less verbose than
func doSomething() (err error) {
	continue, err := doStep1()
	if !continue {
		return err
	}
	continue, err := doStep2()
	if !continue {
		return err
	}
	continue, err := doStep3()
	if !continue {
		return err
	}
	continue, err := doStep4()
	if !continue {
		return err
	}
	continue, err := doStep5()
	if !continue {
		return err
	}

	return
}

// if err is not nil, then shouldContinue must be true.
func doStepN() (shouldContinue bool, err error) {...}

@go101, this is quickly going off topic. All that code might be amusing to some, but it's not code we want to enable or encourage.

I agree.

The proposal as-is could be conditionalized on the Go version specified in the go.mod file, to be be fully backwards-compatible.

@neild, the go version specified in the go.mod file applies to individual packages, not the binary as a whole. What happens if a go 1.13 package passes nil as an interface{} to a go 1.15 package, which then invokes panic with that as its argument?

@bcmills Simplest approach I can think of: panic always converts nil to runtime.NilPanic. In a pre-go1.15 package, recover converts it back into nil.
So if a go1.13 package passes (interface{})(nil) to a go1.15 package which panics, that's the same as panic(runtime.NilPanic). However, if a go1.13 package recovers from that panic, it sees nil.

I came across the problem of panic(nil) the other day. I think I generally like both proposals here. Independent of those, however, I'd also propose we include checking panic values as a go vet check. I suspect a common reason this would occur in the wild is a copy/paste mistake like
x, err := doThing()
if err != nil {
	panic(err)
}
if x == nil {
	panic(err)
}

I've seen code along these lines before, when dealing with odd cases where both return values of a function might be nil in some case. The second panic was copied to quickly handle x being nil after realizing the possibility, but not taking care to switch to a new value to panic with.
While doing one of the proposals above would be great for robustness, I think a vet check would help catch the simple mistakes like this one. I've got a sketched out change that adds it as a step to the existing package nilness. It seems like a good fit: it already built up all the requisite facts, so the work was just looking at the panics. The tests I've written seem like it detects the common cases I'd care about, as well.
The change is here: https://github.com/stephens2424/tools/commit/3817b808a2d7b6515559b16a088aa978aa7d8598
If the idea sounds good, I'll tidy it up into a real CL.

@stephens2424 seems promising. If it isn't too much work, please do mail a CL.

I've uploaded the change, cleaned up a bit and with a real commit message. In the past few days, I've realized a couple points, however.
First, as is, this change will not be included by go vet. I see some information that suggests it might be available in golangci-lint, and less convincingly, in gopls and some odd copy of go vet. (As an aside, the difference between importers in godoc.org and pkg.go.dev is interesting.) I gather that the reason this analysis pass is not in go vet is because the SSA form is too expensive to compute, and I doubt this new feature adds enough value to tip that scale. I think this new feature makes sense to exist in the pass, though, and it'll get picked up by tools if they do decide to add this analyzer.
Second, it occurred to me that, if it's practical, reversing this analyzer, making it much more strict, could be an interesting alternative approach. That is to say: the analyzer would require that panic values be provably non-nil, requiring authors to add specific checks when there's any ambiguity. If it works, I think it could be a viable solution to this issue on its own, or possibly with some attention to getting wider adoption of the analyzer. I'm still new to working with the SSA form, though, so my experimentation with the idea is a little slow going, and I might be getting ahead of myself with this even being possible. Fun to learn it though! It seems very powerful!

I have a slightly ugly suggestion for this.  Add a new builtin:
func recover2() (v interface{}, ok bool)

This is a backward compatible change, and provides a way for newly written code to be able to check whether a panic(nil) happened.

@darkfeline Why add recover2 instead of just allowing err, ok := recover()?

@mdempsky I'm not sure that's possible, given that recover is a normal function, not a keyword.  If it is possible, then allowing recover() to have one or two return values depending on context would be better, yes.

@darkfeline it's not a normal function, it's a builtin function. Builtin functions often have special behaviors that cannot be represented by normal functions (ie make and new can take a type as an argument)
The most obvious solution would be to have both a runtime.gorecover and runtime.gorecover2, and the compiler can easily replace the recover() call with either gorecover or gorecover2 depending on the lvalue(s), similarly to how mymap[key] is changed to runtime.mapaccess1 or runtime.mapaccess2 depending on the lvalue(s).
One potential issue to this is documentation in the builtin package, I'm not exactly sure what the "signature" of builtin.recover would look like. Although that may be only a minor issue.

I'm not sure that's possible, given that recover is a normal function, not a keyword.

Yes, it's possible. Recover is a built-in function, and built-in functions have whatever behavior we specify for them. Most of the built-in functions have some behavior that couldn't be emulated with a normal function.

@deanveloper I see.  I didn't realize you couldn't do this, although it's obvious in hindsight.

@deanveloper, I see two (related) problems with the , ok approach:

A whole lot of Go code has already been written without it, and generally the authors of that existing code were not expecting recover to return nil during a panic.

I would bet that existing Go developers will forget that it exists, and therefore not use it, leading to the same problem as (1) in new code.

So I think the , ok approach is only viable if we remove the non-, ok form from the language entirely, and that seems like a more drastic remedy than just disallowing panic(nil) (which is almost never used intentionally today).

@bcmills What do you think of my analysis in https://github.com/golang/go/issues/25448#issuecomment-596190187?
I don't think not being able to fix existing code means we should not add a straightforward way to correctly handle this case for new code.
Also, there are many cases where using a single valued recover is correct:
func foo() {
    defer func() {
        v := recover()
        if v, ok := v.(myError); ok {
            // do stuff
        }
    }()
    // do stuff
}

@darkfeline, I think that analysis overlooks @neild's insight in https://github.com/golang/go/issues/25448#issuecomment-565220299.
New code could set a new go version in its go.mod file, and check for v == runtime.NilPanic (which should be rare anyway), which would still give intuitive behavior for the simpler v != nil test to mean “was there a panic?” (as folks empirically assume it means today).
That wouldn't necessarily leave a way for new code to produce a nil recover() result in legacy callers, but I would expect the cases where that is necessary to be vanishingly rare anyway: the main use-case of panic(nil) today is likely to sneak past existing (buggy) nil-checks, and I think we should encourage upstream fixes rather than sneaky workarounds.

And, FWIW, I don't think that example of a single-valued recover is actually “correct”: if you recover an error other than myError, that code will silently swallow it rather than propagating it, which may leave the program in an arbitrarily corrupted state (especially if the panic was due to an unexpected nil-dereference).
A more-correct version typically looks something like:
func foo() {
    defer func() {
        v := recover()
        if v, ok := v.(myError); ok {
            // do stuff
        } else if v != nil {
            panic(v)  // lost the stack trace, but at least we can propagate the panic... 🤷
        }
    }()
    // do stuff
}

But then we're back to needing to distinguish panic(nil) from other cases.

I think the simplest fix is what I proposed in https://github.com/golang/go/issues/25448#issuecomment-565220299:
If the Go version in go.mod is greater than some version, then recover returns runtime.NilPanic instead of nil when recovering from panic(nil). The only user-visible change is to the recover function.
If you want to panic(nil), you still can. If you want to handle nil panics, you can by explicitly checking for runtime.NilPanic.  Older code is unaffected.

Any chance this fix will see the light of day?  I burned something like 4+ hours debugging what turned out to be a panic that was passed a nil interface...

Another problem I have realized with runtime.NilPanic: the ways that panic-recover is detailed in the spec, so how would we document how panic(nil) works? The spec shouldn't depend on the standard library. Perhaps we could attach Implementation detail: If a panic is called with a nil argument, the return value of recover may be a sentinel value that can be found in the standard library, usually at runtime.NilPanic. I'm not really a fan of this solution, though.
@bcmills

I see two (related) problems with the , ok approach:

A whole lot of Go code has already been written without it, and generally the authors of that existing code were not expecting recover to return nil during a panic.

I don't really see this as an issue - we can't reasonably go about "fixing" already written code.

I would bet that existing Go developers will forget that it exists, and therefore not use it, leading to the same problem as (1) in new code.

This could be solved by putting this in go-lint (and maybe eventually vet?), and it would be relatively easy to add to go fix as well.

The spec shouldn't depend on the standard library.

The spec already mentions the runtime package: "Execution errors such as attempting to index an array out of bounds trigger a run-time panic equivalent to a call of the built-in function panic with a value of the implementation-defined interface type runtime.Error."
https://go.dev/ref/spec#Run_time_panics
My proposed change would be something like this in the section https://go.dev/ref/spec#Handling_panics: "If panic's argument was nil, the return value of recover is the implementation-defined value runtime.NilPanic. This type satisfies the predeclared interface type error."

Retitled to reflect @neild's suggestion most recently in https://github.com/golang/go/issues/25448#issuecomment-599760022: if go.mod indicates a new enough Go version, then recover() in that module always returns a non-nil value. If there is an active panic(nil), recover returns runtime.NilPanic.
If we do make this change, it seems like perhaps we should change the result of recover() during runtime.Goexit as well, so that recover (called from a deferred function) returning nil guarantees that the function that did the defer is returning normally.

If we do make this change, it seems like perhaps we should change the result of recover() during runtime.Goexit as well,

I don't think that we should change recover to return a non-nil error during runtime.Goexit. Lots of existing code today follows the pattern:
func … (err error) {
	defer func() {
		if v := recover(); v != nil {
			if recoveredErr := errorFrom(v); recoveredErr != nil {
				err = recoveredErr
			} else {
				panic(v)
			}
		}
	}()
	⋯
}

Changing runtime.Goexit to return a non-nil error in case of runtime.Goexit would cause a function like this one to panic in case the function body calls testing.TB.SkipNow, whereas previously it would have successfully skipped the test.

(In an out-of-band conversation, @aclements suggested that perhaps we could add a func Goexiting() bool to package runtime to more easily detect that condition, but that seems like it should be a separate proposal.)

Instead of keying off go.mod to make the change, a strategy more in keeping with our existing practice would be to simply make the change but have a GODEBUG to turn it off, with perhaps that GODEBUG set automatically when the go version is too old. That's kind of the opposite of what Damien suggested but it has a clearer expectation for what happens in old versions. This approach would only be reasonable if we were confident that panic(nil) happens exceedingly rarely in existing code, so that changing the behavior would break very little. Do we have any data about that?

The nice thing about GODEBUG is we can do it now. If we key off go.mod in this way then really we should be waiting for #55092.

What makes GODEBUG better than go.mod for use now?  Without #55092, both are advisory and silently fail to take effect on older Go versions. Even with #55092, a version in go.mod will silently fail to take affect on versions predating toolchain-upgrade support.

@DeedleFake, it's a runtime change as much as a language change, and the effect is difficult to contain. In terms of my recent Compatibility talk, it seems to me a bit like the net.ParseIP change.
By difficult to contain, here's an example of what I mean. Suppose we key off go.mod version so that different parts of the program see different views of the recover. Then what happens if new code does the usual
if e := recover(); e != nil {
    log.Println(e)
    panic(e)
}

when a panic(nil) is happening? I assume that e == runtime.NilPanic. But then what happens in the caller's view of the re-panicked value? Does panic(runtime.NilPanic) cause recover() == nil higher up the stack in older code? This seems very complicated and subtle.
It would be less complicated and subtle to say that panic(nil) becomes panic(NilPanic) program-wide as of Go 1.X, with a compatibility mode for programs declaring an earlier Go version.
The fine-grained compatibility might be important, but I would only head down that path if we had evidence that it was necessary. So do we have evidence that people are depending on the current panic(nil) behavior?

Panicking crosses package boundaries. Whether one goes into the body of if v := recover(); v != nil { ... }  in a package Q relies on the behavior of a panic(nil) in a [transitively-] imported package P.
I am not sure Q really should be relying on this behavior, but it is an argument that this is a program-wide setting.

I don't think the rules need to be complicated:

panic(nil) and panic(runtime.NilPanic) are identical.
For a nil panic, recover returns nil or runtime.NilPanic depending on the go.mod.

From a user-visible perspective, the only change is to recover, and the change is isolated to programs selecting a recent Go version.

I remain skeptical of the fine-grained behavior. If the coarse-grained version suffices, I think that will be more understandable for everyone. It will also be a guarantee that (in the absence of the GODEBUG setting) none of the code in a program is depending on the old panic(nil) behavior, which moves the ecosystem forward.
Again, all of this depends on understanding current uses of recovered panic(nil).

So do we have evidence that people are depending on the current panic(nil) behavior?

I found a few:
https://github.com/golang/tools/blob/db5eae21789c24629aaad3552348d4effec7135d/gopls/internal/lsp/source/hover.go#L898-L904
https://github.com/coreos/coreos-assembler/blob/255ff1dbaa6c095742babd3b4f187308f442ebb3/mantle/harness/harness.go#L499-L501
https://github.com/huacnlee/mediom/blob/9fc7f3bed2dae2440025a262b30a1ca2464e903a/app/controllers/app.go#L30-L33

Looking for panic(nil) in my 2020 Go corpus, the vast majority of hits are in forks of go-ethereum, where panic(nil) seems to have been used as shorthand for panic("impossible"). None of the recover calls in that code base appear to know about it.
Looking at the three @DeedleFake found:

The lsp one is far too clever. Any non-nil value could have been used just as well. It was only introduced very recently, in https://go.dev/cl/416880 by @adonovan.
The coreos one is a copy of package testing (with the license inexplicably changed) and working around the problem of panic(nil).
The huacnlee one is interesting. It appears that revel has a top-level panic handler for each request, like net/http does, and this panic(nil) is making the revel request processing stop, but in a way that doesn't trigger the "print a 500 error" logic. There's no indication in revel/revel that this is a supported behavior, though: panic(nil) does not appear in that code base.

The lsp one is far too clever. Any non-nil value could have been used just as well.

That's fair. In this case there's already a change pending to convert it to use (local) returns instead of panic/recover, but as I noted in that CL, although the transformation is an effective micro-optimization in this hot function, it is in general fraught with subtlety that is avoided by panic/recover, so I wouldn't want to dissuade people from using nonlocal returns in all cases.

Using non-local returns is fine; using panic(nil) for them is more questionable. :)

net/http's top-level panic handler doesn't distinguish between no-panic and panic(nil), so it essentially treats panic(nil) as a way to make request processing stop without logging a stack trace.
I have no idea whether this is intentional behavior or not. It's not documented. The documented way to abort a handler without logging an error is panic(http.ErrAbortHandler).

Pretty sure I wrote that recover block, and I did not intend panic(nil) to stop request processing without logging a stack trace.

 If anyone is interested, please feel free. I will post about a few of them in the next comment.

I did look at some of the hits posted in my previous comment. In general what I see most often is panic(nil) used as a panic(don't care) - some value was needed, it doesn't matter, it's not checked later, and nil was convenient. For example:
There were many hits in tsavola/gate but they were removed by tsavola/gate@51a7d14842, so I've removed them from the list above. Similarly the hit above in zrepl was removed in zrepl/zrepl@e7aa08564.
The hits in ziutek seem to be used as panic("unreachable"), especially after a for {} loop, suggesting that they predate Go's current, more precise 'missing return' handling.
The hit in k8s.io/ingress-gce seems to be a panic("impossible"). I added a print and then ran the code using 'go run ./pkg/composite/gen' and the print didn't trigger.
The hits in pkliczewski/containerized-data-importer (whole program since deleted) looked like:
if *crdFile == "" {
	klog.Errorf(getCrdVersionCmdHelp)
	klog.Error("No crd manifest provided on command %v", getCrdVersionCmd)
	panic(nil)
}

(in func main itself). That's a strange use of panic(nil) but it wouldn't be broken at all by rewriting to a non-nil panic value.
The one in kubevirt is similar, again from package main:
operatorCsv, err := csv.NewClusterServiceVersion(&csvData)
if err != nil {
	panic(nil)
}

Then there is the "matched" panic(nil) against recover. This code from feyeleanor/jittery is the most succinct example of the pattern:
func Throw() {
	panic(nil)
}

func Catch(f func()) {
	defer func() {
		if x := recover(); x != nil {
			panic(x)
		}
	}()
	f()
}

This is essentially what the x/tools CL did too. The code needed a sentinel value to match its own panics, and it overly cleverly chose 'nil' as that sentinel.
Then there are the misuses where this pattern is used but only by clients. Any code that does a recover to look for its own sentinel will be fooled by panic(nil) into executing the stopping half of a non-local goto without intending it. The behavior of panic(nil) in net/http is one example of this.
Another example of potential misuse is the recent break and continue support in text/template. That is implemented by panic(walkBreak) and panic(walkContinue) in the template execution, and a recover checks for them. Range starts with:
defer func() {
	if r := recover(); r != nil && r != walkBreak {
		panic(r)
	}
}()
defer s.pop(s.mark())
val, _ := indirect(s.evalPipeline(dot, r.Pipe))

This means that if the user-defined functions invoked by s.evalPipeline call panic(nil), the template range loop will break without executing anything. Using panic(nil) as an early range abort was never intended by the author of that code (me). Similarly there's another recover to implement range continue, so panic(nil) in the body execution will behave like a "continue", again unintentionally.
Or suppose a program was using the Throw/Catch code above and did a Catch(func() { ... template execution ... }) and then did Throw() inside a user-defined function to give up on the template execution. That will have stopped working as of Go 1.18 when the break/continue recovers were introduced. This feels a bit like the math/rand discussion, where a completely reasonable change in one package (template) can break code being executed by another (Throw/Catch). I conclude that this Throw/Catch pattern is just wrong. If you need a sentinel, you should use your own private one, not nil. The per-module recover behavior aims to keep code like Throw/Catch "working" but it's just fundamentally flawed.
I'm encouraged by the fact that of the handful I looked at, a few had already been rewritten not to use panic(nil). I'm not sure whether people are enabling the nilness checker in gopls, or maybe whether staticcheck reports panic(nil), or something else, but people are fixing their code. I think we should be aiming toward being able to assume program-wide that recover doesn't return nil during panics, not just assuming it per-module.

Great point that unexpected panic(nil) coming out of a dependency could result in a spurious "catch": it's not just "overly clever", it's unsoundly optimistic about the stability of dependencies.

I'm encouraged by the fact that of the handful I looked at, a few had already been rewritten not to use panic(nil). I'm not sure whether people are enabling the nilness checker in gopls

FWIW, the nilness checker is currently enabled by default in gopls because SSA construction is either slow or memory hungry. If it's only the latter, our planned optimization work may make it viable to run it by default.

If anyone would like to see what the effect of replacing panic(nil) with a non-nil panic in their own code bases, you can patch CL 452555 into your Go toolchain.

There were many hits in tsavola/gate but they were removed by gate-computer/gate@51a7d14842, so I've removed them from the list above.

I refactored that code after finding this issue.

For what it's worth, I patched this change into Google's internal Go toolchain and ran our internal test suite and didn't find a single broken test. I also searched for panic(nil) in our internal code and found just a few. They all appear to be bugs that would be unaffected or improved by nil turning into a non-nil value.
Based on looking at open-source and Google's internal code, the most common mistake seems to be
if err != nil {
    panic(nil)
}

I assume code like that meant panic(err). The most common "non-mistake" seems to be writing panic(nil) for an impossible condition where you just want a panic and don't care about the panic value. In both cases the nil turning to a non-nil is fine and actually preferable since it doesn't get mishandled by recover clauses looking for a specific non-nil error and re-panicking other non-nil errors.
In retrospect, recover should have returned (any, bool). Too late now. Rewriting panic(nil) is the next best fix.

I don't understand the logic of the behaviors of panic(nil) or recover() are controlled by the go.mod files in the caller modules. Aren't the behaviors controlled by the go.mod file in the containing module (aka. the std/builtin module here) of the panic and recover functions?
My personal opinion is that, sometimes, the benefits of keeping some bad compatibilities are much lower than breaking them. The same opinion is for https://github.com/golang/go/discussions/56010

sorry, s/lower/higher

sorry again, the initial description is right. :D

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Is recover() returning an optional second ok bool, like map get and channel receive, out of the question? Maybe because it’s a function?

It sounds like this will break very little, but we do want to add a GODEBUG to make sure people can update the toolchain without getting the associated breakages until they bump the go version in go.mod.
Let's say GODEBUG=panicnil=1 means panic(nil) is okay, and GODEBUG=panicnil=0 means it is rewritten to something else. Then the idea would be in Go 1.21, if go.mod of the main module says go 1.21 then panic(nil) becomes panic(&runtime.PanicNil{}). But if you leave it at 'go 1.20' then you still get the old behavior. And even after you 'go 1.21' you can still add //go:debug panicnil=0 to package main. (This is following #56986.)
Does anyone object to this plan?

So post-go1.21 modules always get the new behavior, while pre-go1.21 ones are conditionalized on GODEBUG.

Without #55092 (now #57001), nothing stops a module being built with Go 1.20 from otherwise building a dependency that says go 1.21. So even post-1.21 modules would still sometimes get the old behavior while the older toolchain is still in use.
So I think the GODEBUG setting would actually provide a more consistent transition: if you are building with “Go 1.20 semantics”, you always get the 1.20 behavior, and if you are building with 1.21 semantics, you get the 1.21 behavior.

Without https://github.com/golang/go/discussions/55092 (now https://github.com/golang/go/issues/57001), nothing stops a module being built with Go 1.20 from otherwise building a dependency that says go 1.21.

If the module references runtime.PanicNil, then it won't build with Go versions that don't support the new semantics.

I don't think we have evidence that we need to further complicate the compatibility story. GODEBUG=panicnil=0 is a big hammer to get back to old semantics in a new toolchain. We think this will be so rare that even that won't be needed hardly ever. But we include it just in case.
It seems unlikely that code both needs compatibility with an older toolchain and needs to catch panic(nil) in certain packages written for the newer version of Go. When you update from the older toolchain to the newer toolchain, by definition you don't have any packages written for the newer toolchain yet.

The current proposal is that starting in Go 1.21 (say),
panic(nil) turns into panic(&runtime.PanicNil{}) during panic (so a variable that happens to be a nil interface does it too, not just the literal text panic(nil)).
panic(nil) is always OK, but recover() returns &runtime.PanicNil{} instead of nil after this change.
If GODEBUG=panicnil=1 then this change is disabled and panic(nil) causes recover() to return nil as it always has.
Assuming #56986 happens too in Go 1.21, this behavior would only change in modules that say 'go 1.21' in the work module (top-level go.mod). So when you update from Go 1.20 to Go 1.21, without changing any go.mod lines, you'd still get the old panic(nil) behavior. When you change your top-level go.mod to say go 1.21 then you get the new behavior, in the whole program.

Does anyone object to accepting this proposal?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@DeedleFake, both approaches have the dependency problem: if we make the fix global then you are dependent on dependencies to correct any breakages, and if we make the fix per-module then you are dependent on dependencies to update their code to get fixed behavior. We have to weigh the two sides and decide which should be preferred.
For the specific case of panic(nil), the evidence is that there is a lot of code out there subtly broken today, which this change will fix, and there is hardly any code out there depending on panic(nil) showing up as a recover of nil, which this change will break. So the balance came out in favor of a global fix.
It is worth noting that making just about any change at all to Go at this point requires that same balance, so it will almost always also motivate a global fix like this.
There is also the problem of changing behavior based on where a function call is located, which in general is expensive and confusing. For this specific case an argument can be made that recover is already aware of its caller in a very specific way, and what's the harm in one additional way. But that argument would not apply to other cases, and I am not even convinced the situation warrants it here. It certainly wouldn't be the precedent we want in general, as I explained on https://github.com/golang/go/issues/56986#issuecomment-1380394504.

One minor change from the accepted proposal: writing the text in the spec it turns out to be simplest to say that panic(nil) causes a run-time error, in which case the type should be runtime.PanicNilError, not runtime.PanicNil.

For the specific case of panic(nil), the evidence is that there is a lot of code out there subtly broken today, which this change will fix, and there is hardly any code out there depending on panic(nil) showing up as a recover of nil, which this change will break. So the balance came out in favor of a global fix.

This is a good point. I still don't like the change being global, but it is definitely true that there is almost definitely more code out there failing to handle a recover from a panic(nil) properly than code that depends on it. I don't think there's a lot of code producing nil panics, though. It can only happen if you do purposefully call panic(nil) or pass it a nil interface. It's true that code that uses it might be relying on the recover() behavior of other modules that are then updated to use the new behavior, thus breaking the code creating the nil panics, but that's the whole point of module versions. If module A depends on a specific version of module B, then that version of module B will continue working as module A expects because it's literally the same code. Making the change global will break that version connection, effectively making it pointless.

As a point of reference, libraries which already explicitly handled nil panics may need to make changes like https://github.com/go-check/check/pull/136 to treat a nil and *runtime.NilPanicError result as equivalent.

I don't think we explicitly decided the question of whether to change net/http to continue to accept panic(nil) as an alias for panic(http.ErrAbortHandler) in Go 1.21 programs (that is, programs that set go 1.21 in their go.mod file).
That is, I don't think we decided whether to include a change like the one in this file from the draft CL:
https://go-review.googlesource.com/c/go/+/452555/1/src/net/http/server.go
Given that we have the GODEBUG and that http.ErrAbortHandler has existed since Go 1.8, I am inclined to leave that change out. The only impact will be that panic(nil) will cause new logging on servers running in Go 1.21 mode.

In the past, using panic(nil) was a clever way to jump to the deferred function calls without triggering the logic that would usually get triggered on a non-nil panic. In the code I'm working with, we relied on this behavior to reduce the occurrence of if err != nil { return err }, which had streamlined our code quite a bit without any negative side-effects. This worked wonderfully and didn't trigger any recover logic that was undesired, until Go 1.21.
My question regarding this is the following:
Will the GODEBUG=panicnil=1 option be supported for the forseeable future ? Should we expect this to get deprecated ?

According to https://go.dev/doc/godebug#go-121 there is no plan to remove the panicnil GODEBUG setting.
That said, you can keep using panic to get out of code, just use something like
var ignorePanic byte

func mayPanic() {
    ...
    panic(&ignorePanic)
    ...
}

func callsCodeThatMayPanic() {
    defer func() {
        if r := recover(); r != nil && r != &ignorePanic {
            // handle real panic
        }
    }()
    ...
}

Great, thank you!
My question was more about handling this via a module, and making that module "safe to use" (i.e., it would not inadvertently trigger any properly-written logic regarding recover()).
Consider the following error handling package:
package errhndl

...

func Catch() {
    err := recover()
    if err != nil { // panic if the argument passed to panic was not nil
        panic(err)
    }
}

func Wrap(err error) *errWrapper {
    return &errWrapper{
        err: err,
    }
}

func (w *errWrapper) OnErrThrow(retErrAddr *error) {
    if w.err != nil {
        *retErrAddr = w.err
        panic(nil)
    }
}

Now, assume the above package is used in the following functions:
package somepackage

import "some/module/pkg/errhndl"

// the function whose error we want to handle
func mayReturnError() error {
    return errors.New("oops, something happened")
}

// one example of error handling
func someOtherFunction() (e error) {
    defer errhndl.Catch()
    ...
    // here, OnErrThrow() jumps to the deferred functions, stopping the panicking sequence
    // at either the nearest Catch(), or any recover() encountered before it.
    errhndl.Wrap(mayReturnError()).OnErrThrow(&e)
    ...
}

In this case, if the errhndl package is widely used, there might be cases where some logic needs to occur on a real panic, as follows:
func thisFunctionIsMoreComplex() (e error) {
    defer errhndl.Catch()
    defer func() {
        if err := recover(); err != nil {
            ...
            log.Errorf("oops, some error occurred")
            ...
        }
    }()
    // here, OnErrThrow() jumps to the deferred functions, stopping the panicking sequence
    // at either the nearest Catch(), or any recover() encountered before it.
    errhndl.Wrap(mayReturnError()).OnErrThrow(&e)
    ...
}

Prior to Go 1.21, the OnErrThrow() and Catch() worked flawlessly with existing recover() logic written for non-nil panic values. A real panic would trigger the recover logic, but a panic(nil) was just a way to skip to the deferred functions without triggering any logic related to non-nil values returned by recover().
Historically, recover() and panic() have been a bijection: what was passed to panic() was returned by recover() unmodified. Following that line of thought, calling panic(nil) intentionally and expecting a non-nil value from recover() should have been considered a misuse of the panic-recover mechanism. In my opinion, this should have been treated as a bug, not as a feature needing preservation. I might be wrong; we all have opinions. I am happy to discuss other points of view.
Am I understanding this correctly, that the main goal of this change was to ensure that developers using panic(nil) are shown a runtime error, to encourage/force them to fix their mistake? And that as such, using the GODEBUG=panicnil=1 setting will remain supported for the foreseeable future, and will not be frowned upon?

@the-zucc First I want to say, in case it wasn't clear, that we aren't going to reverse this decision.  There were many years of discussion and a lot of analysis of existing Go code, as you can see in the issue comments.
General Go style is that code should not panic across package boundaries, and code should not try to recover panics that they are not expecting.  I think you are suggesting a different Go style.  That is fine, of course, but I think it's reasonable to suggest that people who want to use that style should use a special error sentinel to mean "panic but no error."  You already have to use an errhndl package; it's not unreasonable to panic with a sentinel value defined in errhndl.  One could argue that that is actually easier to understand for the code reader.
The main goal of the change is that panic(nil) doesn't work as expected with typical uses of recover.  And many cases of panic(nil) are actually mistakes.  See the discussion at https://github.com/golang/go/issues/25448#issuecomment-1322542892.
Note that almost nobody will see this discussion.  It's more useful to discuss Go changes in a forum rather than the issue tracker.  See https://go.dev/wiki/Questions.


Disable filter and unset range on bins, start, and end change on a histogram dataview

Extracted from https://github.com/CartoDB/deep-insights.js/blob/96c5b72846d5c6c13c97c10260f435ba60f6b538/src/widgets/histogram/content-view.js#L314-L315 since
this should apply for all histograms, including time-series (which is also why start and end are included)
Required to solve https://github.com/CartoDB/deep-insights.js/issues/244 (PR: https://github.com/CartoDB/deep-insights.js/pull/253)
@alonsogarciapablo can you review?

Left a minor comment :+1:


Heap based router queue (#63)

What does this PR do?
Change a type of requests queue in router to handle them more efficient
Cherry-picked from habana-dev

@regisss please review


fix: fix merge conflict during ceremony week by blocking cron snapshot/timestamp

Adds a check to detect PROD ceremony branches within 1 week of the job running. Automated workflows are blocked to ensure no merge conflict.
Adds docs in ORCHESTRATION.md with reference and asking to ensure a recent run BEFORE the ceremony. The ceremony itself triggers a snapshot/timestamp so we should be good here, since we have a 2 week window and we will be ensuring that the jobs are run each week (before ceremony, from the ceremony, the week after)
Adds a dry-run option to the workflow, so that I can pre-test my check.

Fixes https://github.com/sigstore/root-signing/issues/693

Summary

Release Note

Documentation

Good catch on the wip!


data: LeonNunes

Changes proposed

Added a file with my profile details.

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Hey @SaraJaoude  apologies I got confused, will update!

Thanks for updating! Looks good


update to Ubuntu 22.04 config template & support client TLS

This PR updates the pgbouncer.ini.j2 template based on the latest config in Ubuntu 22.04 and adds support for several variables required to enable TLS in the pgbouncer client. Most of the changes are comments and additions, and I tried to maintain backwards compatibility.

Thanks @tobiasmcnulty
I don't use this anymore. Happy to merge this though, but it might be better using your own fork anyway


Weight update during Evaluate (Testing)

Is there a way to switch between doing updates during the evaluation phase (testing).

Currently in the GraphManager. evaluate( ... ) weights are freezed?

Hi @nitsanluke, the evaluation phase (as the name suggests) is used for evaluating the last learned policy, resulting from the last training period. If wanted, you can either decrease the number of episodes or environment steps that are being executed at each evaluation phase in the ScheduleParameters defined in the preset.

@galleibo-intel Thanks for the information. So in the evaluation phase, there aren't any online updates to the model is what you are confirming. Because online learning models generally are updating in the test as well. Thanks!


allow retries for GetIP when issuing cert

This will help in the case that a driver does not have an IP yet.  Ideally the driver should not continue the Create until it does, but in some cases this call can fail.
Fixes #600

/cc @nathanleclaire

One nit but after that; LGTM
Given that we run into eventual consistency issues like this all over the place, we should start thinking about some kind of GetValueWithRetries(pollFunc poller, maxRetries int, sleepInterval time.Duration) method.  That's for another time, though.

@nathanleclaire +1
I was thinking that too since calls to GetIP on the driver itself could
fail.
thx!
On Tuesday, February 24, 2015, Nathan LeClaire<EMAIL_ADDRESS>wrote:

One nit but after that; LGTM
Given that we run into eventual consistency issues like this all over the
place, we should start thinking about some kind of GetValueWithRetries(pollFunc
poller, maxRetries int, sleepInterval time.Duration) method. That's for
another time, though.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/machine/pull/602#issuecomment-75837426.

@nathanleclaire +1

@md5 @nathanleclaire updated


getOwner doesn't return the context for the route

.

So you are trying to access an engine route from within the <AppHeader /> component which is located outside of the engine (in the host app)? Is this correct? If so, this kind of goes against the concept of engines, they are supposed to be isolated. The main supported way for host <-> engine communication is via shared services.

.

.


⚠ Bofrost.at has degraded performance

In 6590eab, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1511 ms

Resolved: Bofrost.at performance has improved in 991a016.


FALCON-1898 Build fails on assembly:assembly when using maven-assembly-plugin version 2.6

Thanks for catching it @bvellanki .   +1

LGTM +1

Thank you for review @vrangan  and @vramachan. I will commit this to unblock jenkins builds. If there is a cleaner way to solve the error, we will revisit the issue in future.


chore(test): format test failure output for expectObservable

Description:
While migration, testScheduler accepts built in assertion assert.deepEqual from chai, but it doesn't provide readable output for marble testing. Reintroduced previous custom matcher amended following chai's assertion manner.
*Before

*After

I love you, @kwonoj. :heart:

:cupid:

Merged with acab696, :sparkles:


Error reading metadata

Possible related to this similar issue
Here's a small reproduction:
. Create a new library project
. Paste this code:
namespace Library1

type Class1() =
  static member inline ($) (r:'R, _) = fun (x:'T) -> ((^R) : (static member method2: ^T -> ^R) x)
  static member inline method1 x = Unchecked.defaultof<'r> $ Class1()

. Compile, then reference the dll
#r @"Library1.dll" ;;

unknown(1,1): warning FS3186: An error occurred while reading the F# metadata node at position 3 in table 'ivals' of assembly 'Library1, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'. The node had no matching declaration. Please report this warning. You may need to recompile the F# assembly you are using.

unknown(1,1): warning FS3186: An error occurred while reading the F# metadata node at position 4 in table 'ivals' of assembly 'Library1, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'. The node had no matching declaration. Please report this warning. You may need to recompile the F# assembly you are using.

--> Referenced 'Library1.dll'

This was working fine before, in all F# versions, even in a beta (or may be it was a pre-release) version of F# 4.0 I tested some months ago was working fine, but now it doesn't and I have a project that is throwing many warnings like this when used from another project. Still they work fine but apart from the warnings the compile time increased, probably related to this.

FWIW this commit into F# 4.0 changed a debug-mode assertion into a warning https://github.com/Microsoft/visualfsharp/commit/e5cdef919d43fc527ca412688af21d10f36f063a#diff-c357695ff5c54532cf4bebc7af8ac2aa
The warning can be safely ignored for now but the extra information you've given will help us fix the underlying problem.

Fixed by https://github.com/Microsoft/visualfsharp/issues/674


Mongo ObjectId mapping issue in swagger mapper

Hi,
Swagger is not able to map Mongo ObjectId correctly. My model class looks something like this:
public class Person implements Serializable {
@org.jongo.marshall.jackson.oid.Id
@ObjectId
private String id;    // internal mongo db id
...
Swagger gives me response something like this:
  "_id": {
    "date":<PHONE_NUMBER>000,
    "time":<PHONE_NUMBER>000,
    "timestamp":<PHONE_NUMBER>,
    "new": false,
    "timeSecond":<PHONE_NUMBER>,
    "inc": 402653369,
    "machine": 808430687
  }

Instead I expect something like this:
"_id": "406b5b3de4b8dde5f3000000"
I have seen already existing issues and tried following things but nothing seems to work.

Using @ApiModelProperty(dataType= "string") annotation of my id field but it's not working.
I tried using Overriding model in my bootstrap servlet but no help.

import com.wordnik.swagger.converter.*;
String jsonString = "{" +
" "_id" : "ObjectId" "+
"}";
OverrideConverter converter = new OverrideConverter();
converter.add(ObjectId.class.getName(), jsonString);
ModelConverters.addConverter(converter, true);
But it's not working, may be I'm doing it wrong way.

I also tried using Typeconverter but didn't solve the issue:
  ```
  TypeConverter typeConverter = new TypeConverter();
  typeConverter.add("_id", "string");
  ModelConverters.addConverter(typeConverter, true);
  ```

Anyone who has faced the same issue and able to find any work around for this, please revert.
Thanks

Try to use OperationFilter:
`
public class SwaggerOperationFilter : IOperationFilter
{
private readonly IEnumerable actionsWithUpload = new[]
{
//add your upload actions here!
nameof(TestController.Image),
nameof(TestController.Import),
nameof(TestController.AnswerImage),
nameof(TestController.ImportResults),
nameof(AccountController.Photo),
nameof(UserController.Photo)
};
    private readonly IEnumerable<string> objectIdIgnoreParameters = new[]
    {
        nameof(ObjectId.Timestamp),
        nameof(ObjectId.Machine),
        nameof(ObjectId.Pid),
        nameof(ObjectId.Increment),
        nameof(ObjectId.CreationTime)
    };

    public void Apply(Operation operation, OperationFilterContext context)
    {
        operation.Parameters = operation.Parameters.Where(x =>
            x.In != "query" || objectIdIgnoreParameters.Contains(x.Name) == false
        ).ToList();

        if (actionsWithUpload.Contains(operation.OperationId))
        {
            operation.Parameters.Add(new NonBodyParameter
            {
                Name = "uploadedFile",
                In = "formData",
                Description = "Upload File",
                Required = true,
                Type = "file"
            });
            operation.Consumes.Add("multipart/form-data");
        }
    }
}

`
and
               options.OperationFilter<SwaggerOperationFilter>();


Add string support to throws

I added the possibility to pass in the error message as string to the throws method.
Example
test('test it', t => {
	t.throws(throws, 'foo bar');
	t.end();

	function throws() {
		throw new Error('foo bar');
	}
});

Benefit
If you want to test the returned error message you either should use a regex or a validation function. The validation function spoils the test file in my opinion, and the regex is, well yeah, it's a regex. People have to escape some characters and a string just looks cleaner.
Downside
Not sure if it is a downside, but it's not standard assert stuff which might confuse people. Although, I don't really see it as downside, it's more an improvement.
// @sindresorhus @vdemedes @kevva @Qix-

should does this and to be honest it's the only way I could see reliably testing for expected exceptions. Expecting an exception but not specifying which one introduced a few regressions before I realized I needed to specify the message.

Not sure if it is a downside, but it's not standard assert stuff which might confuse people.

It's not. We only use the core assert so not to duplicate code. If anything can be done better, we'll do it. Also the core Node.js people have said assert is done and won't change anymore.

:+1: from me.

Also the core Node.js people have said assert is done and won't change anymore.

One of my problems with the Node team. /offtopic

Things can always be done better!

@Qux- In their defense it was a mistake to expose it as it was only really meant to be used to test core, from what I've read.
Also why ideally almost everything should be in user-land so it can be individually versioned and evolved.

That makes sense.

:+1: Thanks Sam :)

No problem, always happy to contribute ;).
Any idea when these latest changes (string support in throws, promise fix in throws) will be released? They are needed in pageres and gh-user :). (and many others off course)

@SamVerschueren Hopefully today. Just want to get in the two open PRs. Any help reviewing https://github.com/sindresorhus/ava/pull/120 welcome ;)

That's not an easy one :). Will have a look at it later today.


ninja: 1.11.1 -> 1.12.0

Description of changes
Update ninja to 1.12.0
Changelog: https://github.com/ninja-build/ninja/compare/v1.11.1...v1.12.0
Remove patch large fs for since it is merged to v1.12.0 (https://github.com/ninja-build/ninja/pull/2203)
Closes https://github.com/NixOS/nixpkgs/issues/303406

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg build ninja

@ofborg build ninja

@ofborg build ninja

@ofborg build pkgsi686Linux.ninja

@ofborg build ninja

@ofborg build pkgsi686Linux.ninja

@ofborg build ninja

@ofborg build ninja

@ofborg build ninja

@ofborg build ninja

@ofborg build ninja

@NickCao ofborg eval is failing, even after multiple rebase. I can't seem to figure out what's wrong from the logs. I can successfully build locally and using ofborg here though.

@ofborg eval

This seems to somehow break meson.

This seems to somehow break meson.

Should be fixed by https://github.com/mesonbuild/meson/commit/1b9eb6f3134d61c5ea0026ac95d807aab812c414

Should be fixed by mesonbuild/meson@1b9eb6f

Should I make a PR to fetch the referenced commit as a patch to meson? Should allow building it I believe.

Should I make a PR to fetch the referenced commit as a patch to meson? Should allow building it I believe.

Just add that to this PR.

Looks like coreutils is failing at checkPhase.
============================================================================
Testsuite summary for GNU coreutils 9.5
============================================================================
# TOTAL: 653
# PASS:  486
# SKIP:  166
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See ./tests/test-suite.log
Please report to<EMAIL_ADDRESS>============================================================================
make[4]: *** [Makefile:22562: tests/test-suite.log] Error 1
make[4]: Leaving directory '/build/coreutils-9.5'
make[3]: *** [Makefile:22670: check-TESTS] Error 2
make[3]: Leaving directory '/build/coreutils-9.5'
make[2]: *** [Makefile:22930: check-am] Error 2
make[2]: Leaving directory '/build/coreutils-9.5'
make[1]: *** [Makefile:22447: check-recursive] Error 1
make[1]: Leaving directory '/build/coreutils-9.5'
make: *** [Makefile:22932: check] Error 2

Likely because of recent update to 9.5. https://github.com/NixOS/nixpkgs/pull/299945
Pinging @LeSuisse @dasJ

Hard to tell from just this sumary but if this a Musl & coreutils thing see #304856

@ofborg build meson

@ofborg build ninja

Hard to tell from just this sumary but if this a Musl & coreutils thing see #304856

FAIL: tests/shred/shred-exact.sh
# XFAIL: 0
# FAIL:  1
FAIL: tests/shred/shred-exact
FAIL tests/shred/shred-exact.sh (exit status: 1)
# XFAIL: 0
# FAIL:  1

@LeSuisse Looks like this exact test is failing.

@ofborg test coreutils

I see you used hash for the file before fetchpatch edited it (which is the difference from fetchurl).

@vcunat Thanks for the fix!
I am having trouble locally building meson, coreutils check is failing for some reason locally
And ofborg can't build as it can't apply the commit patch. Weird. Any sugggestions will be helpful.

The thing is I see no such errors, when I run nix build .#meson it just proceeds to download deps and starts building then fails at coreutils checkphase, not at meson patchphase. Tested from this branch ninja.

coreutils is way too early, so you won't get near trying to build meson.

coreutils is way too early, so you won't get near trying to build meson.

So, what would be the solution to this problem? How do I safely apply this patch? It fails in nix CI, as you can see.

@ofborg eval
@ofborg build meson
@ofborg build ninja

@vcunat @NickCao  ofborg was able to successfully build meson with the patch.

At this point I'd rather wait a while after NixOS 24.05 is forked off.

@ofborg eval
@ofborg build ninja
@ofborg build meson

@ofborg eval
@ofborg build ninja
@ofborg build meson

@vcunat since 24.05 have been branched-off already, I guess it's time to move this PR forward?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3981


Manually deploy and test BAF supplychain express server and application on Hyperledger-Besu network with solidity supplychain smartcontract.

Description
As a developer I want to deploy and test BAF supplychain application so that the  besu network can be fully tested and ref. application integration can be done.
Acceptance Criteria

Use network deployed using BAF Hyperledger besu.
Build, deploy and test existing express server and application on besu node
Test and add postman collections for besu express api
Create further automation stories from the findings of this story

The chart to deploy express-app for quorum can be resused to deploy the express-api on the besu network, and the same chart is used in this task to deploy the express-app for besu, It failed to fetch the node_identity  which is the node address.

The null value is the result of api retuning the empty string.

The api is returning the node address in quorum, but for besu it returns an empty response as per the documentation.

After hardcoding the node address  in the chart It is working for the general api's ie., the node-Organization and node-organizationunit api, as these api do not interact with smartcontract.
The createContainer api is failing with an error message.

Tried to invoke the addContainer and getSingleContainer functions from the chaincode using a JS script with the web3-eea module, using the function abi signature. was able to sent a successfull transaction with eth_sendRawTransaction with a transaction reciept and successful 0x1 status code, But didnt got any response from the smartcontract. The smartcontracts can be debug using emitters. The log in the transaction reciept is empty.
output of addContainer:

output of getSingleContainer:


Pull events from Airtables

Feature
Why is this feature being added?

What should your feature do?

Not going to use Airtable to control this.


Is it viable to make the inner field in the Mat structure public?

I understand why it's restricted to the crate and it makes sense.
However, I'm writing an integration in rust with the dlib library and it'll be very handy if that field were public. It will make much easier the connection between dlib and opencv. Another possibility would be to have a method that returns it, possibly marked as unsafe.
That being said, again, I understand why that's not desirable. And in such a case, I'll just fork the project and maintain that version for this particular case.
Thanks!

OK, let me give you more detail of the problem:
I'm using this library to do some processing of the image. After that processing, I have a Mat. That Mat is a face. I want to detect the features of the face as a vector of 68 points.
C++ has a brilliant library called dlib that does that. But it has it's own data structure to represent images, whose format isn't necessarily the same as opencv's. It provides, though, a handy function to convert a Mat to its data structure.
I built a basic binding to dlib, but now I'm facing the problem that I don't have how to interconnect this library with my bindings to get the features.
I have some options to solve this problem:

Rewrite all in C++. I'll have to learn C++ :). And frankly, I'm quite comfortable in rust.
I make the your CMat trait and the inner field public, create a bind to that handy function and I pass inner in my code.
I copy a bunch of code from your library into my bindings to dlib and/or I reimplement a lot of what you already have here.
Something else?

Option 2 works (I tested it from this fork: https://github.com/AgustinCB/cv-rs). However, is horrible and I understand why you don't want to apply that change here.
There's another option: dlib is a huge library and I could probably create more bindings and modify all I'm doing with cv-rs to use dlib purely. That would be a lot of work and I wanted to avoid it (hence this thread) but I think at this point it's the solution.
Do you have any other suggestion?
P.S.: Congrats for the library, by the way. Not only is extremely useful and easy to use, it was trivial to me to understand and modify the code being a n00b in Rust.

Okay, I see your considerations, and you have a huge need in this.
It requires a lot of thinking, but now I see a somewhat way to achieve your goal. We can make CMat public, and implement unsafe impl Into<CMat> for Mat . In this case you will be able to create CMat from Mat without breaking types as well as not exposing inner in public as well as marking it unsafe to make sure that no one will do if it's unnecessary.

P.S.: Congrats for the library, by the way. Not only is extremely useful and easy to use, it was trivial to me to understand and modify the code being a n00b in Rust.

Glad to hear it. I hope you will love rust 😺

That's perfect! Thanks. I'm reading about the Into interface, seems like a good match (although some initial experimentation showed me that you can't mark the implementation as unsafe...).

@AgustinCB on the other side, I don't see why it should be marked as unsafe, because it doesn't do anything dangerous. If you want to get a useless zero-sized type then it's your choice. But the rest if the idea is the same. You implement a trait that allows you to destruct a high-level abstraction into the lower one.
Rust philosophy says that it's safe to get an object pointer, it's unsafe to deal with it ;)


Sigh/recreate profiles

Delete and recreate the profiles instead of simply updating it to include new devices.  This ensures the profile matches all of the parameters' requirements.

Hey @icecrystal23, would you mind giving a little bit of background as to why you would like sigh to work this way? It feels like if updating the devices is all that is intended, there would be no reason to delete and recreate the profile. Also, do you think this could break people's flows if they are modifying profiles that were not initially created by sigh?

We wanted to have a simple build script to create-or-update a list of provisioning profiles that we want sigh to manage.
We end up with a list of commands like this
sigh --app_identifier com.mycompany.appname --team_id TEAMID --username<EMAIL_ADDRESS>--output_path provisioning-profiles --skip_certificate_verification --ignore_profiles_with_different_name --skip_install --force --cert_id CERTID --adhoc --provisioning_name com.mycompany.appname AdHoc

sigh --app_identifier com.mycompany.appname --team_id TEAMID --username<EMAIL_ADDRESS>--output_path provisioning-profiles --skip_certificate_verification --ignore_profiles_with_different_name --skip_install --force --cert_id CERTID --provisioning_name com.mycompany.appname AppStore

sigh --app_identifier com.mycompany.appname --team_id TEAMID --username<EMAIL_ADDRESS>--output_path provisioning-profiles --skip_certificate_verification --ignore_profiles_with_different_name --skip_install --force --cert_owner_name 'User Name' --development --provisioning_name com.mycompany.appname Development

When we run this with sigh as it is now, it often ends up creating brand new profiles (with a timestamp on the end) instead of updating the existing profiles.
The first change makes sure sigh is able to find invalid profiles, so that it can update existing ones instead of creating new ones unnecessarily.
The second change ensures that instead of simply updating the profile, it is recreated from scratch to the exact specifications of the command issued.  Otherwise if the certificate or some other thing changed, it might update the profile with new devices but still be in a different state than was requested by the command.
These changes ensure that sigh --force correctly creates the requested profile, and doesn't unnecessarily create new profiles.

Hey @icecrystal23! Apologies for the delay here! Would love to get this merged, is it possible you could write a test or two to validate the behavior? Thanks! 🐙 !

Hi there @icecrystal23. It looks like @ohwutup was looking for some test to be written so we can merge this PR. Could you take care of that?
If you don't plan to continue work on this PR please let us know so that we may close it. Thank you!

Yeah, let me look into that.

I added some tests.  Let me know if that's what you had in mind.  If not, please let me know specifically what you want demonstrated in the test code.

Yeah, I'll clean up my commits too

Now I am getting this when I try to run bundle exec rspec.  Any hints?
$ bundle exec rspec
bundler: failed to load command: rspec (/Users/tracyk/.rbenv/versions/2.2.5/bin/rspec)
NameError: uninitialized constant Sigh

Thanks again @icecrystal23 🎉

Thanks @icecrystal23 for this. We've been having issues because the profiles used in our project (i.e. match AdHoc com.company.target) have been invalidated when new devices are added and the new profiles have a different name due to the date being appended (i.e. match AdHoc com.company.target<PHONE_NUMBER>). Now, because the original profiles specified in our Xcode project are no longer installed by match, the project has to be updated to use the new profiles because the names have changed. Very inconvenient.


Facial Expression Synthesis on CelebA

Can you share the trained facial expression synthesis model？I understand that expression synthesis on RaFD dataset cannot be released, but what about expression synthesis on CelebA？Thank you!

I have already obtained RaFD dataset, but I cannot train the effect in the paper. I really need a model of facial expression synthesis on celeba to do a comparative experiment. Can you send me the pretrained model? My mailbox. Thank you!

Hi,
Have you solved the facial expression synthesis on celeba yet? If you have,  could you kindly share the code or what you have done? Thank you.
tsly

also interested in a pretrained model for this

me too

Me too

I'm also interested for this.
Please share at<EMAIL_ADDRESS>if you got it.

I am also interested in a pre-trained model for facial expression synthesis on CelebA. Please share if you have it<EMAIL_ADDRESS>Thank you.


Make vehicle restriction path cost configurable

(also removed "on deactivated advaned AI" because that debug message part was wrong)

integrated! Many thanks :)


Image component - add more detail to quality prop

Hi, I think it would be useful to know more about the quality prop for the Image component. I know it's a number, but unsure what are good (recommended) "quality" numbers. Also, what is the default value?
Page: https://docs.astro.build/en/guides/integrations-guide/image/#image-

Hi @arturogh, thanks for this, and I agree!
I'm going to reach out to @tony-sull on this one for some clarification, and I think that would be a really helpful addition to our docs. Thank you!

Related, re the <Picture /> component, we should confirm with @tony-sull that quality is not an attribute you can use on it, as it seems to be the only one that is only available for <Image /> (without a corresponding equivalent, e.g. format/formats, width/widths, height/sizes. (Or, whether we just don't mention it in the docs and it should be added?)
Also maybe of interest: this workaround with getImage posted in support:
(from this Discord thread: https://discord.com/channels/830184174198718474/1033947574136225893/1033994531533770774 )

By the looks of things the Picture component doesn't utilise quality. I'm not sure if this is done by design or I've missed something?
The good news is you can get around this by using getImage and it mirrors the current Picture component with the added benefit of using quality and setting image dimensions on

---
import { getImage } from '@astrojs/image';

// Set some defaults
const imgSpec = {
  src: "...",
  alt: "...",
  width: 320,
  aspectRatio: 1,
  quality: 80,
  format: "jpg", // quality doesn't seem to work without format being set
};
---

<picture>
{
  ["avif", "webp", "jpg"].map(async (format) => {
    const { src } = await getImage({ ...imgSpec, format });

    return <source type={`image/${format}`} srcset={`${src} ${imgSpec.width}w`} />
  })
            }
  <img {...(await getImage(imgSpec))} loading="lazy" decoding="async" />
</picture>

Closing this issue as Tony and I did discuss quality and tried to improve the wording as best we could, but there's not much more helpful we can add at this time.


Make help text editors readonly

I noticed that "Command Line Help" and "User Command Help" open in editable controls, which is not useful. This change fixes that and also removes a file path that (I think) was accidentally included in a comment.

@vancem @swgillespie

👍


Fix typo in Building an Onchain App

What changed? Why?
Fix typo in Building an Onchain App
Notes to reviewers
How has it been tested?

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


Fix SO_REUSEADDR and SO_REUSEPORT in bind_socket

Delete SO_REUSEADDR = 0 and SO_REUSEPORT = 0 set after binding,
as that options also need to be set when socket.listen call is performed
to have an effect.

Codecov Report

Merging #2 into master will decrease coverage by 0.34%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master       #2      +/-   ##
==========================================
- Coverage   80.58%   80.23%   -0.35%
==========================================
  Files           5        5
  Lines         170      167       -3
  Branches       18       18
==========================================
- Hits          137      134       -3
  Misses         24       24
  Partials        9        9

Impacted Files
Coverage Δ

aiomisc/utils.py
68.88% <66.66%> (-1.95%)
:arrow_down:

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 242573d...d0e1031. Read the comment docs.

Pull Request Test Coverage Report for Build 17

5 of 6 (83.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 83.981%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

aiomisc/utils.py
5
6
83.33%

Totals

Change from base Build 16:
-0.2%

Covered Lines:
143

Relevant Lines:
167

💛  - Coveralls


Max and Min on Array

@logaretm
I have a mini question regarding min max validators.
Let's say that I followed the instruction and I am using $_veeValidate correctly (looks like I am doing it right - I validate and get the right results).
I am trying to validate a taginput (an input that gets tags). Each tag should be an email, and the validator works smoothly and clean on the email validation. It correctly validates each email in the array of values.
Instead when I use the max validation, and set it to X, the validator counts the characters on the whole array instead of limiting the count on each single item. Meaning that if in my first tag I consume X characters I am done, the validator doesn't reset the count on the next tag.
Is this something made by design? I mean there is some specific reason that I am missing for which this behavior is desirable? Or is a small bug?
I also implemented the validation in a more direct way, calling the validate method inside of a function responding to a component event. This works pretty much in an identical way ( a bit more of code), and allow me to change and interact with the tag properties (for example to change their color upon error). Again also in this scenario, the email validator behave correctly, instead max or min no.
I looked the code for max and min, and I didn't see any array option, this let me thought that probably there is some design reason that I am not getting.
Could you please help me to understand a bit better?
Thank you so much.

Currently, min and max rules do not handle arrays, I will mark this as an enhancement. Thanks!


Refactor method to explicit helper. Fixes #253

This PR refactors method creating the User model instance in controller to silence compiler warnings (as per the issue description):

change method name to be more explicit about method role
update method use in controller

With this change running:
kpm build

in HelloMvc sample project will output no warnings:
Build succeeded.
    0 Warnings(s)
    0 Error(s)

Time elapsed 00:00:02.4029731

I've already signed Microsoft CLA.
Thanks!

CLA confirmed. (Sorry for the delay, was in Hawaii :palm_tree: :palm_tree: :palm_tree:)

Thanks Eilon.
Sorry @peterblazejewicz just noticed your change to master branch. Could you send your change to dev branch instead?

I want to close this PR in favor of this with better history:
https://github.com/aspnet/Home/pull/268
Thanks!


pretraining esm2_t33_650M_UR50D

Could we kindly provide the config and data preprocessing script to reproduce the pretraining of esm2_t33_650M_UR50D ?

Hi!
We are sorry we cannot provide such script because all our data preprocessing aims to engage AF2 predicted structures into our training dataset. But ESM-2 leveraged only sequence data for pre-training. We recommend refering the original paper of ESM-2 for more details, including both training hyperparameters and dataset construction.
Best regards,
Jin

Could we use this to reproduce the pretraining of SaProt_650M_AF2?
python scripts/training.py -c config/pretrain/saprot.yaml
Got this error, any ideas?

huggingface_hub.utils._validators.HFValidationError: Repo id must be in the form 'repo_name' or 'namespace/repo_name': 'weights/PLMs/SaProt_650M_AF2'. Use repo_type argument if needed.

I guess that's because you didn't put the checkpoint at right directory. You could move the SaProt checkpoint to weights/PLMs and try again.


Investigate defining colour scheme in Nix

Consider defining our own colour scheme and creating a home-manager module which will write this out to fzf, Vim, tmux, Alacritty, Xresources, etc.

Fixed in f31b5cbbf5ad074d553b1756a36eff2882b4142b.


CB-10438 disable TLS 1.0 and 1.1 on the IPA LDAP server

By default TLS 1.0, 1.1 and 1.2 is enabled on the LDAP server running on IPA.
TLS 1.0 and 1.1 are considered unsecure so as part of this PR they are disabled.
The end result will look like this:
nmap --script ssl-enum-ciphers -p389,636 localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2021-01-19 09:44 UTC
Nmap scan report for localhost (<IP_ADDRESS>)
Host is up (0.000026s latency).
Other addresses for localhost (not scanned): <IP_ADDRESS>
PORT    STATE SERVICE
389/tcp open  ldap
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|       NULL
|_  least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

have you tested it with freeipa HA?

have you tested it with freeipa HA?

have you tested it with freeipa HA?

Yes

have you tested it with freeipa HA?

Yes


panic with values from background job

The shell panics when a background job tries to send on the values channel:
⬥ { sleep 1; put boom } &
⬥ panic: send on closed channel

goroutine 2875 [running]:
src.elv.sh/pkg/eval.valueOutput.Put(0xc00050d080, 0x0, 0x0, 0x4443880, 0xc000295000, 0x4454901, 0x0)
	src.elv.sh/pkg/eval/port.go:280 +0xa5
src.elv.sh/pkg/eval.put(0xc0002da5b0, 0xc00038a550, 0x1, 0x1, 0x0, 0x0)
	src.elv.sh/pkg/eval/builtin_fn_io.go:95 +0xbe
reflect.Value.call(0x44549c0, 0x4509520, 0x13, 0x44e25b7, 0x4, 0xc00036ea50, 0x2, 0x2, 0x2, 0x18, ...)
	reflect/value.go:476 +0x8e7
reflect.Value.Call(0x44549c0, 0x4509520, 0x13, 0xc00036e810, 0x2, 0x2, 0x1, 0x2, 0x43ab3dc)
	reflect/value.go:337 +0xb9
src.elv.sh/pkg/eval.(*goFn).Call(0xc00013f960, 0xc0002da5b0, 0xc00038a520, 0x1, 0x1, 0xc00036e5d0, 0x0, 0x1)
	src.elv.sh/pkg/eval/go_fn.go:227 +0x658
src.elv.sh/pkg/eval.(*formOp).exec(0xc0002474a0, 0xc0002da5b0, 0x0, 0x0)
	src.elv.sh/pkg/eval/compile_effect.go:377 +0x9a2
src.elv.sh/pkg/eval.(*pipelineOp).exec.func1(0x456e9a0, 0xc0002474a0, 0xc0002da5b0, 0x0, 0xc00038a500, 0xc000295000, 0xc0004281b0)
	src.elv.sh/pkg/eval/compile_effect.go:122 +0x3f
created by src.elv.sh/pkg/eval.(*pipelineOp).exec
	src.elv.sh/pkg/eval/compile_effect.go:121 +0x22c
Exception: elvish exited with 2
[tty 3], line 1: elvish

If you run any nontrivial elvish code in the background, this can easily snag you.

I reported this bug fifteen months ago in issue #1069. I closed my issue three months ago because it seemed to be fixed.  I did not pinpoint the specific change that fixed this bug. I simply verified that I could no longer reproduce this failure when I closed my issue three months ago. However, I can reproduce the bug using my scenario and this one today using an Elvish program built from source as of the time I write this comment.


ModelItem ordering fixes

Fixes to ModelItem ordering, resolves gh-320:

Sort DataElements by index by default
Don't sort by index where listing across multiple parents or including imported items
Add tests

Failing test not related.


Check if Ash.Domain requires authorization

Contributor checklist
Issue #81

[x] Bug fixes include regression tests
[x] Features include unit/acceptance tests

🚀 Thank you for your contribution! 🚀


About search algorithm

Thanks for your grate work
I am new to this profession, so I have some basic questions about VIPNAS:
As stated in the paper, VIPNAS searches five dimensions to find the optimal structure. But there is no mention of what kind of policy to adjust the model. For example, the author said that the current frame and the next frame will use different structures, so what policies or conditions are the structure adjustments based on? In short, the model is adjusted based on what changes
Sorry for my basic question
Best

"what policies or conditions are the structure adjustments based on? "
---Are you asking about what aspects of the model can be changed?
---> The five dimension search space includes network depth, width, kernel size, group number, and attentions.
The goal of network search is to find the best model with lowest flops.

Have you ever trained vipnas_res34?
Do you have pre-trained nas_res34 network weights?


Adds object oriented, synced version of Analysis objected

Closes #19

Codecov Report

Merging #20 into master will increase coverage by 2.89%.
The diff coverage is 98.92%.

@@            Coverage Diff             @@
##           master      #20      +/-   ##
==========================================
+ Coverage   92.97%   95.87%   +2.89%
==========================================
  Files          15       15
  Lines         242      315      +73
==========================================
+ Hits          225      302      +77
+ Misses         17       13       -4

Impacted Files
Coverage Δ

pyns/api.py
98.5% <100%> (+7.73%)
:arrow_up:

pyns/models/predictor.py
100% <100%> (ø)
:arrow_up:

tests/test_analysis.py
100% <100%> (ø)
:arrow_up:

pyns/models/base.py
86.66% <100%> (ø)
:arrow_up:

pyns/models/dataset.py
100% <100%> (ø)
:arrow_up:

pyns/models/user.py
100% <100%> (ø)
:arrow_up:

pyns/models/analysis.py
92.75% <97.87%> (+8.75%)
:arrow_up:

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 1ddbb5c...a339be4. Read the comment docs.


Revert "Update dependency org.apache.maven.plugins:maven-compiler-plugin to v3.13.0" MERGEOK

Reverts vespa-engine/vespa#30677
This breaks pipelines that has maven 3.6.2

FYI, @baldersheim


object endpoint to find internal links for resources

From dev readme:
High Level Sequence /object endpoint
Prez provides a /object endpoint as an endpoint that supplies any information known about a given URI. If an annotated
mediatype is requested, prez will additionally provide all system links for endpoints which can render the object. The
high level sequence for this endpoint is as follows:

Get the URI for the object from the query string
Get the class(es) of the object from the triplestore
Use prez's reference data for endpoints to determine which endpoints can render this object, and, a template for
these endpoints, specifying any variables that need to be substituted (such as parent URIs).
Get the object information from the triplestore, using an open profile, and in parallel any system information needed
to construct the system links.
Return the response

The same functions that are used to do the above have been generally applied to annotated responses. Any annotated response from prez will now:

Find any URIs in the initial response from the triplestore
Find the classes for these URIs
Use the (new) prez endpoints graph (reference_data/endpoints/) to find endpoints that can deliver the class(es), and, get a template for these endpoints, specifying any variables that need to be substituted (such as parent URIs).
Go back to the triplestore to populate the endpoint templates.
Return the original response + prez:links

Other minor changes:

Add endpoint reference data to support system link generation (reference_data/endpoints)
Rename inbound/outbound children/parents to focus to/from child/parent terminology to align with SHACL. Rename general_class to base_class. Resolves https://github.com/RDFLib/prez/issues/101
Add <focus_uri> prez:endpointComponentURI <uri_used_in_endpoint> for parent CURIEs in endpoints such that the URIs of parents are included in the response, and get annotated, such that labels are available for breadcrumbs.

Can confirm. I have the same issue as @jamiefeiss.

I have a fix coming, should be tomorrow.

Thanks Jamie I'll take a look.
On Mon, 28 Aug 2023, 17:41 Jamie Feiss, @.***> wrote:

@.**** requested changes on this pull request.
After some local testing, I've found two issues:

For a skos:Concept page, the prez:endpointComponentURI triple seems
to be missing:

aarr:chair a skos:Concept ;
dcterms:identifier "aarr:chair"^^prez1:identifier ;
dcterms:provenance "Developed for this Agent to Agent Roles @.*** ;
rdfs:isDefinedBy https://data.idnau.org/pid/vocab/aarr ;
skos:broader aarr:member ;
skos:definition "The presiding officer of an assembly, meeting, committee, or @.*** ;
skos:inScheme https://data.idnau.org/pid/vocab/aarr ;
skos:prefLabel @.*** ;
skos:scopeNote "Organisation to Person relations" ;
prez1:link "/v/vocab/vcb:aarr/aarr:chair" .

For a skos:Collection page, a server error occurs: AttributeError:
'list' object has no attribute 'name', which points to this line:

https://github.com/RDFLib/prez/blob/4d5a0ba0bdcae67323d2373fed655c2aa05e6697/prez/services/generate_profiles.py#L90
where the problem seems to be a missing class in the SPARQL query:
VALUES ?class {}
—
Reply to this email directly, view it on GitHub
https://github.com/RDFLib/prez/pull/145#pullrequestreview-1597661411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACQUSNXFSDPJY7PKTRKH4A3XXRDTVANCNFSM6AAAAAA3J63ICA
.
You are receiving this because you authored the thread.Message ID:
@.***>

@jamiefeiss both fixed now - note I've switched to the dcterms:identifier to include parent URL components / their labels. From the updated notes:
Add a triple: of the form: <endpoint_component_uri> dcterms:identifier "{curie_id}"^^prez:identifier for parent CURIEs in endpoints such that the URIs of parents are included in the response, and get annotated, such that labels are available for breadcrumbs.

@edmondchuc I think I've addressed the feedback (just the single suggested change) let me know if I've missed something otherwise will merge

thanks Jamie, not sure if these changes caused that issue, in any case I'd like to merge this in before this PR gets any larger. Could you raise an issue separately? I'll address it when making the filter addition to search.


StackViewer - The sort order in the byname tab should remain after making an update

I'm working in a stack viewer where I need to sort by Inc descending. After I find frames that I have analyzed, I remove them and then concentrate on the rest. When I start looking for other frames, I need to click the Inc column to sort by Inc instead of the default (which is Exc). It would be nice if the sort column didn't change between updates.

I believe this was fixed in #179

Duplicate of #173.


[AutoPR mariadb/resource-manager] MariaDb: updated readme and added java readme

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/6288

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/5800


Error: remote trust data does not exist for docker.io/library/ubuntu: <IP_ADDRESS>:4443 does not have trust data for docker.io/library/ubuntu

Dear all, I am building a docker image and using this notary on localhost:4443. I am getting this error when I docker build. What am I doing wrong please?
rkmode=default&rm=1&shmsize=0&t=leexha%2Ftest%3Alatest&target=&ulimits=null: Error: remote trust data does not exist for docker.io/library/ubuntu: <IP_ADDRESS>:4443 does not have trust data for docker.io/library/ubuntu
in my /etc/profile, I have done the following
export PATH=$PATH:/usr/local/go/bin
export DOCKER_CONTENT_TRUST=1
export DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE="XXX!"
export DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE="XXX!"
export DOCKER_CONTENT_TRUST_SERVER=https://<IP_ADDRESS>:4443

When you run docker build, it tries to verify the image you are building from using the content trust server you specified.  There is no trust data for the official ubuntu library in your content trust server.  You would have to either sign the image yourself on your local notary server or override the DOCKER_CONTENT_TRUST_SERVER to be https://notary.docker.io for the docker build command specifically.


Media player showing "id"+ appname?

Issue
In some cases, when the app is started from the TV it has a id + app name in the mediaplayer:

When i open the card for more details, it's showing the correct source with the ID.

My configuration:
   app_list: '{"YouTube": "111299001912", "Netflix": "11101200001", "Plex": "3201512006963", "Videoland": "3201810017074"}'
Did i do something wrong, or is this a bug?
System

arch
x86_64

dev
false

docker
true

hassio
true

os_name
Linux

python_version
3.7.6

timezone
Europe/Amsterdam

version
0.106.5

virtualenv
false

Samsung TV Tizen  v1.4.1

@mike9011 Hi Mike, Can you please give me the apps ids of kpn and nlziet if possible ? Thanks very much

@mike9011 Hi Mike, Can you please give me the apps ids of kpn and nlziet if possible ? Thanks very much


fix(avm-simulator): L1TOL2MESSAGEEXISTS opcode

The opcode should check for the value at the given leaf index.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#5807  👈
#5805
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @fcarreiro and the rest of your teammates on  Graphite

Benchmark results
Metrics with a significant change:

note_successful_decrypting_time_in_ms (8): 256 (+24%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
772
772
772

l1_rollup_calldata_gas
6,844
6,820
6,844

l1_rollup_execution_gas
587,325
587,301
587,325

l2_block_processing_time_in_ms
1,446 (+2%)
5,264 (+1%)
10,284

note_successful_decrypting_time_in_ms
:warning: 256 (+24%)
616 (+5%)
1,005 (+11%)

note_trial_decrypting_time_in_ms
56.5 (-48%)
28.6 (-69%)
22.0 (-13%)

l2_block_building_time_in_ms
13,457 (+1%)
53,026 (+1%)
104,329

l2_block_rollup_simulation_time_in_ms
13,225 (+1%)
52,176 (+1%)
102,648

l2_block_public_tx_process_time_in_ms
5,782 (+1%)
22,676 (+2%)
44,997 (+1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
15,412 (-4%)
28,911 (-5%)

note_history_successful_decrypting_time_in_ms
1,244 (-4%)
2,364 (+3%)

note_history_trial_decrypting_time_in_ms
48.8 (-23%)
131 (+38%)

node_database_size_in_bytes
18,698,320
35,110,992

pxe_database_size_in_bytes
29,859
59,414

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
155 (+2%)
44,725
26,424

private-kernel-inner
163
72,200
26,424

private-kernel-ordering
111 (-1%)
51,090
39,297

base-parity
40.9 (+1%)
128
311

root-parity
7.13
1,244
311

base-rollup
16,293 (+1%)
110,820
957

root-rollup
47.3
4,551
821

public-kernel-app-logic
89.5 (-1%)
48,175
40,933

public-kernel-tail
124 (-1%)
60,044
7,385

merge-rollup
6.84 (-4%)
2,760
957

public-kernel-teardown
85.4 (-1%)
48,175
40,933

public-kernel-setup
84.1 (-1%)
48,175
40,933

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.9 (-2%)
17.8
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.6
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.637 (-2%)
0.549
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
50.9 (-1%)
81.0
264 (+2%)
501
997 (+2%)
1,949
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
96.0
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.522 (-1%)
0.499
0.480 (+1%)
0.468
0.472 (+1%)
0.467
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
60.1
120 (+1%)
383 (+2%)
740
1,487 (+2%)
2,901 (-1%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
105
207
691
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.532
0.539 (+1%)
0.517 (+1%)
0.509
0.513 (+1%)
0.505 (-1%)
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
67.4

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
109

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.589

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
41,029
528,895

Transaction size based on fee payment method

Metric
native fee payment method
fpc_public fee payment method
fpc_private fee payment method

tx_with_fee_size_in_bytes
905
1,161
1,377

Transaction processing duration by data writes.

Metric
0 new note hashes
1 new note hashes
2 new note hashes

tx_pxe_processing_time_ms
1,193 (-1%)
801
3,450 (-1%)

Metric
1 public data writes
2 public data writes
3 public data writes
4 public data writes
5 public data writes
8 public data writes

tx_sequencer_processing_time_ms
499 (-1%)
332
902 (-1%)
418 (-1%)
1,502
489 (-1%)

Merge activity

Apr 17, 2:05 PM EDT: Graphite rebased this pull request as part of a merge.


Feature request: tf.contrib.Predictor - add an optional ConfigProto argument to the constructor

The tf.contrib.Predictor subclasses are useful to quickly run inferences, but at the moment it's impossible to configure the tf.Session instance used for inference, because it is created in __init__ without the possibility to pass a config to it.
My suggestion is then to add the explicit argument config to Predictor's subclasses' init functions and pass it to the Session constructor.
Note that, technically, for the {Contrib|Core}EstimatorPredictor classes one could already have a session_config defined in estimator.config.session_config, so perhaps this could be the fallback value when using these classes.

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
TensorFlow installed from
TensorFlow version
Bazel version
CUDA/cuDNN version
GPU model and memory
Exact command to reproduce

added the fields requested

Nagging Assignee @tatianashp: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@GPhilo Thank you for your suggestion. It would be great if you could help us by working on this and submitting a PR. Let us know if you need further clarification. Thanks!