Proposal: A built-in go error check function, "catch"

This is a counter-proposal to #32437
Proposal: A built-in Go error check function, catch
catch would function much like the proposed try with a few specific differences:
1.) catch is a statement, i.e. it must be on a line by itself, like panic()
2.) catch takes 1..N arguments
2a.) the first argument must be of type error
2b.) The remainder of the arguments are optional and wrap the error using the given format string and args, as if sent through fmt.Errorf.
e.g.
func getConfig(config string) (*Config, error)
    f, err := os.Open(config)
    catch(err)
    defer f.Close()
    // use f to make a c *Config...
    return c, nil
}

In this code, catch is the equivalent of
if err != nil {
    return nil, err
}

If err is non-nil, it will return zero values for all other return values, just like try.  The difference being that catch is a statement, not an expression, so you can't "hide" it on the right hand side.  You also can't nest catch inside another function, and you can't nest a function inside of catch.  This is to ensure readability of the
This makes catch just as easy to see in the flow of the code as if err != nil is now.  It means you can't magically exit from a function in the middle of a line if something fails.  It removes nesting of functions which is otherwise usually rare and discouraged in go code, for readability reasons.
This almost makes catch like a keyword, except it's backwards compatible with existing code in case someone already has the name catch defined in their code (though I think others have done homework saying try and catch are both rarely used names in Go code).
Optionally, you can add more data to an error in the same line as catch:
func getConfig(user, config string) (*Config, error)
    f, err := os.Open(config)
    catch(err, "can't open config for user %s", user)
    defer f.Close()
    // use f to make a c * Config...
    return c, nil
}

In this configuration, catch is equivalent to
if err != nil {
    return nil, fmt.Errorf("can't open config for user %s: %v", user, err)
}

And would utilize the new implicit error wrapping.
This proposal accomplishes 3 things:
1.) It reduces if err != nil boilerplate
2.) It maintains current legibility of exit points of a function having to be indicated by the first word on the line
3.) It makes it easier to annotate errors than either if err != nil or the try proposal.

For the record, I don't mind if err != nil, and all things being equal, I would rather not remove that boilerplate, since errors are just values and all that jazz.  I know many, many long-time gophers that agree.
However, if we're going to change the language, this is a much better change than the proposed try in my opinion. This maintains legibility of code, maintains ease of finding exit points in the code, still reduces boilerplate, and encourages people to add context to an error.
IMO it removes the major faults of try, which are the high likelihood of missing a call to try embedded in the right hand side somewhere when reading code, and the problem of encouraging nesting of functions which is distinctly bad for code readability.

One variation would be:

to start, catch only takes one argument
don't allow catch to take additional arguments for format string and args
after experience or experimentation, consider a future extension for a handler function as an optional second argument, such as:

func(err error) error { return fmt.Errorf("foo failed: %v", err) }
That would increase the parallel between this proposal and the current proposal for try as a builtin.

My main reason for disagreeing with that is that it couples the fmt-package into the language. i.e. to actually add this to the spec, you'd also need to define what fmt does in the spec - and IMO, fmt is far too large (conceptually) to be part of the language proper. So, IMO, the multiple-argument form you are suggesting should be removed.

That's a good point, and actually why I made 2a and 2b.  I think we could remove 2b pretty easily.  It could easily be replaced by a helper function in fmt (or user code):
// Wrap returns nil if err is nil, otherwise it returns a wrapped
// version of err with the given fmt string as per fmt.Errorf.
func Wrap(err error, msg string, args ...interface{})

then you could do
catch(fmt.Wrap(err, "error opening config for user %s", user))
It's not quite as nice, though.

@natefinch What about if i have more than two returns?
func getConfig(user, config string) (*Config, error, result)
    f, err := os.Open(config)
    catch(err)
    defer f.Close()
    // use f to make a c * Config...
    return c, nil, nil
}

It works like try from the linked issue, where using it requires that it's in a function where the last return value is of type error, and it returns zero values for everything except the error.
so like if you had
func getConfig(user, config string) (*Config, result, error)

catch(err) would return nil, result{}, err

You can simplify this a bit. Since it expects an error value, you can give it any error value. So then it can be catch err or catch fmt.Errorf(“can’t open config for %s”, user) — no need to implicitly use this error generating function and you can return any kind of error that makes sense in your situation. Though I don’t like the use of catch. It would be perfectly legal in your scheme to say something like this but it looks weird!
    If !inrange(low, value, high) {
        catch OutOfRangeError
    }

Except for the name, this would be a perfectly legitimate use at the where error conditions are first detected and even better than having to say
    If !inrange(low, value, high) {
        return nil, OutOfRangeError
    }

On IBM systems on can use a macro ABEND to abnormally terminate a task. It was a bit like panic but the name was suggestive of its intended use. catch doesn’t have that. Neither did try. I thought of returnOnError or errorReturn or just ereturn or abreturn or may be even raise as in C. Any of these work for me better than catch or try but none seem ideal.

So, it can't be a keyword, because that's not backwards compatible. So it would need to be catch(OutOfRangeError) ....
I do agree that the name might need some tweaking.  Naming is hard, and I welcome suggestions for another name that might be more appropriate.
The problem is really that it is most accurately called maybeReturn
How about yield?  Where it's keep going, or stop if something is in the way?  Also yield is to produce, like it produces the error.
f, err := os.Open(config)
yield(err)
defer f.Close()

(Ignoring its use as giving up the processor to another coroutine or thread)  yield is better than catch!
returnOnError or returnIfError exactly captures the semantics but it is a bit long.
returnIf can also work
ReturnIf(OutOfError)

Both yield and catch have very strong connotations in other languages, and I wouldn't suggest them for your proposal.  As you say, naming is hard.
But I have to disagree with this if for no other reason than its rigidity; if
catch(err, "can't open config for user %s", user)

is really just
if err != nil {
  return fmt.Errorf("can't open config for user %s: %v", user, err)
}

... it's really not that valuable.  Most of my error handling is done with github.com/pkg/errors, although I have yet to evaluate the new proposals around wrapped errors.  And others perhaps like dedicated typed errors, while others may use constants.  This solves a narrow set circumstances
But to think this through further... what happens in this case:
func DoYourThing(a string) (x string, error) {
  x = fmt.Sprintf("My thing is '%a'", a)
  // always returns an err
  err := DoSomethingBad()
  catch(err)

  return
}

func DoAThing() {
  x, _ := DoYourThing("cooking")
  fmt.Printf("%s!!\n", x)
}

@provPaulBrousseau, IMHO catch or its equivalent shouldn’t be used if you are returning an error as well as a legit value. [This is another reason I bemoan the lack of a sum type in Go. With sum type you’d use it in most cases where an error or a legit value is returned but not both. For examples such as yours, a tuple or a product type would be used. In such a language catch would only work if the parent function returned a sum type]
But if you do use catch, it would return “”, err.

@provPaulBrousseau note that my intent is that this use the new fmt.Errorf which actually does wrapping like github.com/pkg/errors (which is what we use at work, as well).  So that fmt.Errorf looks like the oldschool "just reuse the string", but it's actually wrapping under the hood.  I'll update the original post to make that clear.

oh.... and yes, just like try, catch and yield have meanings in other languages.... but this isn't other languages, it's Go. And if the name is a good one, reusing it to mean something different seems ok, IMO... especially since it's not a keyword.

Option 2c?
catch  takes an error value. When the error value is nil
Examples:
func Foo() (int, int, error) {
  err := ....
  catch(err) // nil processing continues, !nil return 0,0, err

  user := "sally"
  err := ....
  catch(fmt.Errorf("can't open config for user %s: %w", user, err)) // note new %w flag, so it's an `error`  and an `errors.Wrapper`, nil processing continue, !nil return 0,0, <formatted error>

I like this for all the reasons you pointed out. And there is less "magic" wrt formatting, and if after a release or two it's felt that formatting should be built in it can still be added later by allowing the catch statement to take multiple arguments.
PS: catch <error> makes it look more like a statement than a function, which IMO helps with it standing out visually and is less likely to lead newcomers to think it's a function.

PS: I realize this would require a tweak to fmt.Errorf to make it return nil if the provided error is nil. So what you said with the Wrap function.  instead:
func Foo() (int, int, error) {
  user := "sally"
  err := ...
  catch errors.Wrap("can't open config for user: %s: %w", user, err)
``

catch is a statement, i.e. it must be on a line by itself, like panic()

This seems like a non-starter. Can it just be a func catch(err error, args ...interface{}) instead? That'd be the same result, and backwards compatible. That makes the biggest problem the fact that you need some static analysis to ensure that the return type of the enclosing function returns an error... (not sure how difficult that'd be to achieve in Go's compiler)

WRT Backwards compatibility (catch <error> isn't backwards compatible)..... I'd be more than happy to wait for something like this until modules becomes the default build mode ala https://blog.golang.org/go2-next-steps

At first glance, this is what try and check should have been. check is a great name (and way to avoid the baggage of catch), whether meaning "verify" or "halt/slow progress".

@apghero why is it a nonstarter?  That's basically the whole difference between this and the try proposal. I do not want a function on the right hand side of a complicated statement to be able to exit. I want it to have to be the only thing on the line so it is hard to miss.

@daved check SGTM, just not all the other bits.

This is many ways worse than try() function proposal in my opinion because it doesn't really solve the underlying goal of reducing boilerplate code.
A function with multiple error check looks like this:
`func Foo() (err error) {
var file1, err1 = open("file1.txt")
catch(err1)
defer file1.Close()
var file2, err2 = open("file2.txt")
catch(err2)
defer file1.Close()

}Vs. originally proposed try() function:func Foo() (err error) {
var file1 = try(open("file1"))
defer file1.Close()
var file2 = try(open("file1"))
defer file2.Close()
}
`
Later looks more concise and elegant in my opinion.

@ubikenobi It's always trade-offs. In my opinion, the reduction provided by try costs far too much in readability. More so when the extra "flexibility" try permits is weighed. The clarity that comes from that single newline (and possibly two columns of text) is worthwhile. The surety that comes from reduced flexibility? Even more critically so.

@apghero why is it a nonstarter? That's basically the whole difference between this and the try proposal. I do not want a function on the right hand side of a complicated statement to be able to exit. I want it to have to be the only thing on the line so it is hard to miss.

Me either. But that can be accomplished without syntax. The syntax part is the thing that breaks backwards compatibility, so why not just do what panic does and return nothing? You can't use a function that returns nothing on the right hand side of a statement, or in an expression. Therefore it's limited to the left most column of a block, which is what we're looking for.

This still would take up a keyword: catch, but only barely improve on the try variant.
While I do think this is a step forward, it still only allows "lazily" error handling.
What for users that use custom errors that use wrapping functions?
What for users that want to log for developers & operators and return human-understandable errors to the users?
if err != nil {
    log.Println("Hey operating, big error, here's the stack trace: ...")
    return myerrorpackage.WrappedErrorConstructor(http.StatusInternalServerError, "Some readable message")
}

If we plan on taking up a whole keyword, can we at least attach some function to it?
Counter proposal to the whole try or catch: do try/catch with check & handle (better keywords imho), scope specific.
Suggestion is part of the whole mix of error handling proposals: (scoped check/handle proposal)[https://gist.github.com/mathieudevos/2bdae70596aca711e50d1f2ff6d7b7cb]

This still would take up a keyword: catch, but only barely improve on the try variant.

The point is to reduce the footgun rating of a solution, not to offer an "improved" novelty.

What for users that use custom errors that use wrapping functions?

This was covered in comments.

If we plan on taking up a whole keyword, can we at least attach some function to it?

Now I'm not sure if this is a troll post. Most keywords serve exactly one function. return, if, etc.

This proposal states several times that catch(...) is a statement, like panic(...). But panic is not a statement, it's a built-in function with no return value.

@daved
Inconsistencies and unnecessary code clutter also negatively impact readability in my opinion. This is why I think catch() proposal is less readable and less safe compared to try() proposal.  I'll try to illustrate my three main concerns with a different example below.

It enables inconsistent ways (example1/2) to call catch which really hinders control flow in my opinion.
The compiler can only validate callee function to have an error as the last parameter, not the called function.
Simple coding mistakes like calling catch in incorrect order (example 2) can lead to hard to find/ dangerous bugs.

//Example 1
func Dispense() (err error) {
	var motErr= SetMotorSpeed(5)
	catch(motErr)
	var fanErr= StartFan(5)
	catch(fanErr)
	var tempErr =SetTemperature(200)
	catch(tempErr)
	var itErr = DropItem()
	catch(itErr)
}
//Example 2
func Dispense() (err error)
	var motErr= SetMotorSpeed(5)
	var speedErr= StartFan()
	var tempErr =SetTemperature(200)
	var printErr = DropItem()
	catch(motErr)
	catch(fanErr)
	catch(tempErr)
	catch(itErr)
}

As appose to catch(), with try() function (example below):

I gain consistency by ensuring every try() call behaves the same way. No need to declare err variables, or return error returns in the correct order.
Ensures both called and callee function(or method) define an error as the last return parameter.
With unnecessary code clutter motErr, catch() gone, makes machine logic vastly clear and easier to read in my opinion.
My machine code runs safer by guaranteed return on err on try(). SetTemperature() not possible without successfully calling StartFan().

func Dispense() (err error){
	try(SetMotorSpeed(5))
	try(StartFan(5))
	try(SetTemperature(200))
	try(DropItem())
}

I would like to point out that when flexibility is needed err!=nil pattern works better than both catch() and try() proposal IMO. The main goal of the original try() as a function proposal s to remove unnecessary boilerplate when flexibility is NOT needed.

If y'all want to manifest something other than try() in 1.14, you need to first
prove that try() isn't useful for the great majority of existing code.
The Go team has told us that if we can't prove that, the merits of alternatives are moot.

This still would take up a keyword: catch, but only barely improve on the try variant.

The point is to reduce the footgun rating of a solution, not to offer an "improved" novelty.

Many of the arguments again try is that it not improves anything, just dumbifies error handling.
This catch can just be written as a package that provides this as a single function. As @networkimprov  stated, as long as there's no proof that would improve the try case it's void of use.

What for users that use custom errors that use wrapping functions?

This was covered in comments.

Comments are personal discussions, not part of the proposal, the proposal only has catch with error formatting.

If we plan on taking up a whole keyword, can we at least attach some function to it?

Now I'm not sure if this is a troll post. Most keywords serve exactly one function. return, if, etc.

Return takes multiple values and it's not a function, it has a space after it, clearly marking it as a keyword.
Reserved items should be space separated just so it's clear they're not a local function.
All of this can be replaced by having a local package called: errorHandler with 1 public function: Catch.
No need to change the language for the sake of changing it (same does technically count for try() proposal).

I support this proposal above all others I've seen on the subject. It is important that any change to error handling allows each error in an e.g. function to be annotated explicitly and independently than others. Returning the naked error, or using the same annotation for every error return in a function, may be useful in some exceptional circumstances, but is not a good general practice.
I also strongly support using a keyword instead of a builtin. It is important that function-exiting flow control is not nestable within other expressions. If we have to wait until further improvements to the language allow this to be accomplished without breaking the Go 1 compatibility promise, then we should do that, rather than make the change now.

IMO, this doesn't really improve on if err != nil { ... } fmt on one line.

A more flexible one-extra-line proposal is #32611
err = f()
on err, <single_statement>

The most common error handling code I have written is the classic:
        ..., err := somefunc1()
        if err != nil {
                return err
        }
        ..., err := somefunc2()
        if err != nil {
                return err
        }

Like @ubikenobi, I think the catch solution (or the on solution just suggested) adds little value:
        ..., err := somefunc1()
        catch(err)
        ..., err := somefunc2()
        catch(err)

while try lets you focus on the code, not the errors:
        ... := try(somfunc1())
        ... := try(somfunc2())

Just as well quickly learned that r is probably an io.Reader and w is probably an io.Writer, we will quickly learn to ignore the try while reading code.
The try proposal really shines when you want to have chaining types and still support errors.  Consider:
        v, err := Op1(input)
        if err != nil {
                return err
        }
        v, err = v.Op2()
        if err != nil {
                return err
        }
        result, err := v.Op3()
        if err != nil {
                return err
        }

With try this becomes:
        result := Op1(input).Op2().Op3()

This would actually encourage this paradigm more, which I think would be a good thing.
Catch, on the other hand, make it:
        v, err := Op1(input)
        catch(err)
        v, err = v.Op2()
        catch(err)
        result, err := v.Op3()
        catch(err)

Quite honestly, if the error solution does not support chaining then its value is reduced.  If it does not eliminate the extra lines of code between statements, its value is reduced.
One scenario where try is clearly not helpful and the check proposal has a very slight advantage over straight Go is:
        ..., err := somefunc1()
        if err != nil {
                return ..., fmt.Errorf("somefunc1: %v", err)
        }
        ..., err := somefunc2()
        if err != nil {
                return ..., fmt.Errorf("somefunc2: %v", err)
        }

While catch would add some slight value, it certainly does not carry its own weight vs the existing paradigm give it's other issues.
I can contrive a solution that uses try, but it is worse than the original code because each return requires different processing.
As mentioned, the try solution can easily be extended in the future by adding additional parameters, though they need to be readable.
As for the name try, I am not super enamored with it, it will make many people think "where is the catch?".  I could suggest must, instead, but right now we associate must with a panic.  I don't know a better word choice so try is okay.  I certainly don't want something like returnOnError even though it is pretty descriptive!

@ngrilly mentioned that panic is not a statement, and that's a good point.  I'm not entirely sure what the limitations are on what we can enforce on a new builtin. If we can't make catch (or whatever we call it) a statement, making it not return a value is good enough... it still means it'll basically be on its own line.

@pborman

[try] would actually encourage this paradigm more, which I think would be a good thing.

I don't think it's a good idea to encourage returning the naked error. As a general rule, errors should be individually annotated with context before being yielded up the callstack. Although if err != nil { return err } is the trope often cited in Hacker News comments or whatever, it isn't great practice.

@peterbourgon , the proposal examples already addressed this (fmt.HandleError or something like that).  A majority of cases can be handled by a single defer call.  Probably should not call this a naked return as return err is not a naked return.  return with named return values is a naked return and probably should have never made it into the language.  If your error handling becomes to complicated (unique handling per error) then all of these solutions are not ideal and you should use standard Go.

@pborman

If your error handling becomes to complicated (unique handling per error)

My claim is that this is not complicated error handling, this is [what should be] the default way to handle errors, and that anything less is shortcuts that shouldn't generally be encouraged.

My claim is that this is not complicated error handling, this is [what should be] the default way to handle errors, and that anything less is shortcuts that shouldn't be encouraged in the general case.

I think this is an argument against try, check, handle, throw, must, or any other proposal for simplified error handling.
in truth I don't mind Go's error handling that much.  I can see try being beneficial, at least to me.  It is the least obtrusive, lightest weight, solution I have seen (it also happens to be an improved version of my second suggestion last fall, which was try foo() rather than try(foo()).
For my own code I might consider adding a function, something like HandleErrorf, that optionally wrapped the returned error with the file, function, and line number of where try was called from.  When debugging code I would turn that on so all my errors tell me where they originated (actually, the full call chain).  I think some other packages do this already.

@pborman

if the error solution does not support chaining then its value is reduced.

It seems you and I want different things.  I specifically made this proposal because I don't want to encourage people to jam more logic into a single line. I don't want to encourage method chaining. I don't want to hide away error handling. Having to write catch(err) every time your function might exit is good IMO. I want to be very explicit about what can fail and where the function can exit.

It is important that any change to error handling allows each error in a function to be annotated explicitly and independently from other errors.

@peterbourgon Most of the time, the error context is the same in the whole function. In such a case, I'd prefer to centralize the annotation in one place, instead of annotating each error independently. Russ commented about this: https://github.com/golang/go/issues/32437#issuecomment-503297387

@ubikenobi As far as I understand, your example (where only errors are returned) can be duplicated with this proposal.
func Dispense() (err error){
	catch(SetMotorSpeed(5))
	catch(StartFan(5))
	catch(SetTemperature(200))
	catch(DropItem())
}

The main goal of the original try() as a function proposal s to remove unnecessary boilerplate when flexibility is NOT needed.

And yet it is designed to facilitate flexibility. If what you suggest is true, it's flexibility can/should be reduced to only that which is necessary.
@pborman

... we will quickly learn to ignore the try while reading code.

That's the problem.
Also, function chaining is not something I'm on board to promote. It's only really useful for accumulator style types. If it's, otherwise, some machine being controlled, then the relevant functions don't need to return errors at all since "errors are value" and whatnot. I would use a container type that either provides a final error checking function, or use an error channel with the "body" being called in a goroutine.

If the error solution does not support chaining then its value is reduced. If it does not eliminate the extra lines of code between statements, its value is reduced.

I fully agree with this.

@natefinch, I think you should support no changes to the language in that case.  It does everything you want already (expect that you still need the if statement, which is even more precise if err != && err != io.EOF ...)
I would support no change to the language over check as I believe check has no real benefits over how Go is today.  My feeling is if we are going to add something to Go, the try proposal at least seems like a choice that provides actual benefit at little cost.  I actually like it and am not opposed to it going in.  If it doesn't go in, I am okay, as long as none of the other proposals I have seen do not go in, either.

@ngrilly

Most of the time, the error context is the same in the whole function.

I don’t agree. Error annotations usually are and should be unique for each received error in a function block.

@natefinch About "panic not being a statement": the proposal just needs to mention that catch is a built-in function (instead of being a statement).

I don't want to hide away error handling.

@natefinch The try function doesn't "hide" error handling any more than the catch function proposed here.

Having to write catch(err) every time your function might exit is good IMO. I want to be very explicit about what can fail and where the function can exit.

try is not different from catch on this matter: You also have to write try(err) every time the function might exit. It's also "very explicit about what can fail and where the function can exit".

@ngrilly

The try function doesn't "hide" error handling any more than the catch function proposed here.

It's position in code differs, it's flexibility differs. The difference results in noise. The noise results in it being ignored. try, as it is, will be something to locate within it's own noise. This proposal reduces the broadness of the noise down to a clear tone that is easy to parse and hard to ignore.

@peterbourgon

I don’t agree. Error annotations usually are and should be unique for each received error in a function block.

Have you read the comment from Russ I linked previously?
Russ agrees with you when you write that "error annotations should be unique for each received error in a function block". But he argues that it is the callee responsibility (not the caller responsibility) to decorate the error with the context. For example, the error returned by os.Open is "open /etc/passwd: permission denied," not just "permission denied."

I also agree with @natefinch that error chaining should not be encouraged.

Why? This is one of the main use case for similar constructs in Rust, Swift, Haskell, etc. People keep repeating try will make our code unreadable, but Rust has introduced the try! macro and then the ? operator a long time ago now, and they haven't suffered from this hypothetical problem. I fail to see why it would have worked for Rust, and it wouldn't work for us.

People keep repeating try will make our code unreadable, but Rust ...

All due respect to Rust, please don't use it as an example of readability. For it's own goals, it is clearly a great language. For the benefits that Go provides and I am drawn to, there is no comparison whatsoever.

@daved

It's position in code differs, it's flexibility differs. The difference results in noise. The noise results in it being ignored. try, as it is, will be something to locate within it's own noise. This proposal reduces the broadness of the noise down to a clear tone that is easy to parse and hard to ignore.

It's mostly an aesthetic argument. It's in the eye of the beholder.
@ubikenobi has shared earlier an example in which try seems more readable to me than catch:
With catch:
func Foo() (err error) {
	var file1, err1 = open("file1.txt")
	catch(err1)
	defer file1.Close()
	var file2, err2 = open("file2.txt")
	catch(err2)
	defer file1.Close()
}

With try:
func Foo() (err error) {
	var file1 = try(open("file1"))
	defer file1.Close()
	var file2 = try(open("file1"))
	defer file2.Close()
}

Why? This is one of the main use case for similar constructs in Rust, Swift, Haskell, etc.

I understand one of Go's fundamental principles to be that errors are not exceptional but rather common, and that the code to deal with them (i.e. the sad path) is at least as important, and often more important, than the code to accomplish the main work (i.e. the happy path). I also understand that the relative reliability and predictability of Go programs comes in large part from this principle, that errors are lifted up front and center for every expression that can generate them, forcing—or at least strongly encouraging—the programmer to deal with them in situ. Error chaining subverts this principle in the name of expediency. I don't disagree that in some cases that can be useful. But I would hate to see Go become a language where that is common. We would lose one of its most important strengths.

@ngrilly Your insistence on using var = instead of := is unsettling. ;)
A quick scan produces...
catch:
file open
catch err
defer close
file open
catch err
defer close

try:
file twcvpfn
defer close
file twcvpfn
defer close

@daved

All due respect to Rust, please don't use it as an example of readability. For it's own goals, it is clearly a great language. For the benefits that Go provides and I am drawn to, there is no relation whatsoever.

I agree that Rust as a whole is less readable than Go. But the argument is not necessarily transposable to specific features of the language, like try! and ?.

@peterbourgon

I understand one of Go's fundamental principles to be that errors are not exceptional but rather common, and that the code to deal with them (i.e. the sad path) is at least as important, and often more important, than the code to accomplish the main work (i.e. the happy path).

Rust error handling relies on the exact same principle.

I also understand that the relative reliability and predictability of Go programs comes in large part from this principle

I think the choice of words matters here: "reliability" and "predictability". The check/handle proposal and the try proposal don't affect the reliability and predictability of Go programs. These constructs are perfectly explicit and determinist. There is, maybe, a "readability" issue, but not a "reliability/predictability" issue.

errors are lifted up front and center for every expression that can generate them, forcing—or at least strongly encouraging—the programmer to deal with them in situ.

I agree with this. This is my main doubt about the try proposal. People are supposed to decorate their error with a defer statement. But they can also omit it. That said, we already have a lot of code in the wild with if err != nil { return nil, err }.

Error chaining subverts this principle in the name of expediency. I don't disagree that in some cases this can be useful. But I would hate to see Go become a language where it is common. We would lose one of its most important strengths.

It looks like the main source of our disagreement is that you (and other gophers) think each error should be decorated differently, while Russ (and other gophers including me) think the decoration can be the same for the whole function (or the whole call chain in the case of chained calls).

@daved

@ngrilly Your insistence on using var = instead of := is unsettling. ;)

LOL. I've blindly copied the code shared earlier in this thread. I've fixed it.

@Merovius

My main reason for disagreeing with that is that it couples the fmt-package into the language.

What if catch would be allowed to (re)use runtime's print only for its formatting?
    catch(err, "can't open config for user ", user, ". Uid: ", ruid)

The code is in the runtime and it will be there forever and changes needed to make a catch's sprint of it are in the 10-15 LoC range.
Overall, I can undersigned on @natefinch proposal. Once upon a time I was on the let me write it short side. Now I value clarity and locality of reading way more.
P.S. Naming is hard. And consequences of bad or just a bit off name are way more serious than we usually would like to think. Just think what if the go1 had had a "fail" instead of "error"?

If either "try" or "catch" are implicit returns, then the first thing that strikes me is that the "return" statement might be the one to enhance for this task. That may be hard to do while keeping backwards compatibility, but looking at the problem from that perspective may reveal different solutions.
The construct "return err if err != nil" (roughly) has been positively received elsewhere, I think that also needs to shift the focus towards "return" as the key principle.
I think the main thrust of Nate's "catch" suggestion is a good one: one per line, modelled on panic.
I also want to add that the existence of bare returns could be brought to bear on this discussion: what the compiler already knows may come in very handy (the last argument needs to be of type error, for example) if one feels that the return values need to be set up appropriately.
And "fail" (stolen from @ohir) may in fact be an excellent alternative:
fail(fmt.Errorf("reporting: %v", err))
although more likely to collide with existing use.
One more thing: fmt.Errorf need not be the only way to assemble an error object with a useful description, errors.Stringf(string, ...interface{}) could be a new name for the same functionality if it can avoid importing the entire fmt baggage. If not, then the code must just use fmt.Errorf sparingly.
The bit about fmt.Errorf cleverly returning nil when err == nil is not throw away either. Half the time I make the mistake of creating an err where there wasn't one, the runtime reminds me: this approach would just be a less subtle hammer.
I'm  not familiar with this medium, so please forgive the presentation.

@ohir If you look at the spec, it seems clear to me that that wouldn't be a good idea. Both in that it's implementation-defined what it does and that it is limited in what arguments it can receive. ISTM using that would be a perfect example of how a compromise usually ends up making neither of the parties happy. Really, as a regular Gopher, you should just forget print exists and not encourage its use even more :)

I like this better than the vast majority of error handling change proposals.
I had a notion this morning that I'd like to throw on the pile. There is a convention in several packages, both in the standard library and the wider ecosystem, of defining Must* variations of functions for simplicity, and... well--
Perhaps (as @pborman also alluded to already) a must keyword could be defined, as a shorthand prefix operator for functions that return one error and any number of other values, which captures the error returned and panics if it's not nil, but otherwise proceeds with the remaining return values.
To use the example from the initial proposal:
func getConfig(config string) (returnCfg *Config, returnErr error)
    defer func() {
        if r := recover(); r != nil {
            returnCfg, returnErr = nil, fmt.Errorf("config: Unexpected error: %w", r)
        }
    }()
    f := must os.Open(config)
    defer must f.Close() // Succinctly set up error handling for usually-ignored unlikely-to-error functions
    // use f to make a c *Config...
    return c, nil
}

Ideally (I think), this would combine with some solution I haven't thought of for the problem of named return values being very easily shadowed (which seems to be a separate common complaint) so that this somewhat-common formulation of deferred panic-handling is easier to write.

@jesse-amano The must keyword you propose doesn't differentiate between a standard error returned by a function call, and a real panic triggered by a bug in your code.

Yes, the thought more-or-less aligned with the same thinking that drove earlier incarnations of the try proposal, and is at least as flawed. I also concur with earlier remarks that a keyword is in principle a more drastic change to the language than "merely" a magic built-in function like try.

So, it can't be a keyword, because that's not backwards compatible. So it would need to be catch(OutOfRangeError) ....
I do agree that the name might need some tweaking. Naming is hard, and I welcome suggestions for another name that might be more appropriate.
The problem is really that it is most accurately called maybeReturn
How about yield? Where it's keep going, or stop if something is in the way? Also yield is to produce, like it produces the error.
f, err := os.Open(config)
yield(err)
defer f.Close()

and then it could be
yield(OutOfRangeError)

which looks better to me

catch(X) is also not backwards compatible, since code can have already defined a method catch()

@pborman,

Just as well quickly learned that r is probably an io.Reader and w is probably an io.Writer, we will quickly learn to ignore the try while reading code.
The try proposal really shines when you want to have chaining types and still support errors. Consider:
        v, err := Op1(input)
        if err != nil {
                return err
        }
        v, err = v.Op2()
        if err != nil {
                return err
        }
        result, err := v.Op3()
        if err != nil {
                return err
        }

With try this becomes:
        result := Op1(input).Op2().Op3()

Actually it becomes
         result := try(try(try(Op1(input)).Op2()).Op3())

Finding out which try failed would be a trying exercise! In this single expression there are quite a few basic blocks!

  Good catch (no pun intended.)
While not suggesting this, it seems like:
result := try(Op1(input)).try(Op2()).try(Op3())

would be more readable but would complicate the semantics of try a bit.  I guess it would say that try(r.f()) and r.try(f()) are equivalent.  I haven’t thought about it enough to think if this introduces ambiguity.
In any event, the point is you don’t care which try failed (which is actually one of the reasons Go did not have try-catch).  If you care you use the well understood if statement.  I still see the proposed catch in this thread as of nearly no value as it still causes a visual break and only limits a slight amount of boilerplate.  If something is added I think the proposed try is probably the most reasonable path.
Of course, if try is added, you can continue to use an if statement.  Go does not eliminate all personal choice and style.

I came here to propose a very similar solution. I do think this proposal is simpler and clearer than the try(...) proposal put forward by the Go team, and would have least impact on existing code and style conventions, while cutting a lot of boilerplate. It could also elegantly handle inline wrapping if required.
I'd use check as the name, catch has too many other connotations (and is used elsewhere by the calling function, not the one throwing). I would prefer if you could pass an optional wrapped error as a second argument, to allow neatly wrapping errors in one line. That would get rid of problems with requiring fmt etc. and make the proposal simpler. You could even use a function returning error as the second argument then.
To show some examples, which I think it improves:
f, err := os.Open(filename)
if err != nil {
	return …, err  // zero values for other results, if any
}

becomes:
f, err := os.Open(filename)
check(err)

And the much longer example from the overview goes from:
func CopyFile(src, dst string) error {
	r, err := os.Open(src)
	if err != nil {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
	defer r.Close()

	w, err := os.Create(dst)
	if err != nil {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if _, err := io.Copy(w, r); err != nil {
		w.Close()
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	if err := w.Close(); err != nil {
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
}

to this shorter example where the extra 1 line for error handling helps a lot with clarity when compared with the try example IMO, and even optionally replace the if err := xxx; err != nil { pattern with something simpler:
func CopyFile(src, dst string) error {
	r, err := os.Open(src)
        check(err, fmt.Errorf("copy %s %s: %v", src, dst, err))
	defer r.Close()

	w, err := os.Create(dst)
        check(err, fmt.Errorf("copy %s %s: %v", src, dst, err))

        _, err :=  io.Copy(w, r)
        check(err), func() error {
		w.Close()
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}())

        err := w.Close()
        check(err), func() error {
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}())
}

The main reason I like this proposal is that it doesn't obfuscate the function calls like os.Open(src), w.Close() as try would, and the error handling starts on the line after, as now, but can be shorter if required (even in the case of annotation, but especially when there is no annotation). I don't want fewer lines of code at the expense of clarity, so one extra line at times vs try is a win in my book. This proposal gets rid of the bit people don't like (verbose error handling), and leaves the rest of the code alone.

That expects a level of function overriding that isn't a part of the Go paradigm.  Your check prototype can accept 1 argument (of type error) or 2 arguments (of type error and something that looks like a defer, except that it returns an error whereas defers are non-parameterized).  Go doesn't support "optional" arguments, and this isn't quite variadic.

@provPaulBrousseau Go does support optional arguments in certain built-in functions, and this would be a built-in function. You can make(map[int]int),  make([]int, 5) and make([]int, 0, 5).
WRT @kennygrant's example: isn't that actually more verbose than just using an iferrnil?

I think this is not much better than the try proposal. All we need is to be able to write if err { ... }  without having to put != nil.

I guess you should close this proposal as the one to keep it simple and keep it as it is got way more positive attention... :hankey:

I think this is not much better than the try proposal. All we need is to be able to write if err { ... }  without having to put != nil.

Thank you sir, I do think Go should allow implicit casting from nil interface to bool.

I think this is not much better than the try proposal. All we need is to be able to write if err { ... }  without having to put != nil.

Everyone seems to have a different opinion on error handling ;)
I'd be fairly happy with that solution too - allow if err {} on one line, and simple error handling would be a lot more succinct. Not sure all the heat and noise around this issue is warranted, but I would prefer a solution that shortens error handling and doesn't insert itself into the happy path instead (as try does).

I'm just gonna throw this out there at current stage. I will think about it some more, but I thought I post here to see what you think. Maybe I should open a new issue for this?
So, what about doing some kind of generic C macro kind of thing instead to open up for more flexibility?
Like this:
#define returnIf(err error, desc string, args ...interface{}) {
	if (err != nil) {
		return fmt.Errorf("%s: %s: %+v", desc, err, args)
	}
}

func CopyFile(src, dst string) error {
	r, err := os.Open(src)
	returnIf(err, "Error opening src", src)
	defer r.Close()

	w, err := os.Create(dst)
	returnIf(err, "Error Creating dst", dst)
	defer w.Close()

	...
}

Essentially returnIf will be replaced/inlined by that defined above. The flexibility there is that it's up to you what it does. Debugging this might be abit odd, unless the editor replaces it in the editor in some nice way. This also make it less magical, as you can clearly read the define. And also, this enables you to have one line that could potentially return on error. And able to have different error messages depending on where it happened.

@nikolay

All we need is to be able to write if err { ... }  without having to put != nil.

It's a much larger change than try. It would imply to change the language spec to accept implicit casting from nil to bool, not just in if, but everywhere (an exception for if would be really weird). The implicit casting could introduce hard to track bugs. And we would still need to change gofmt to format this on 1 line instead on 3.

@Chillance You're essentially proposing to introduce an hygienic macro system in Go. This opens another can of worms.
An issue was created proposing this: https://github.com/golang/go/issues/32620.
Here is what it looks like in Rust: https://doc.rust-lang.org/1.7.0/book/macros.html.

@ngrilly Yeah, I'm sure there other things to consider for the macro way. I just wanted to throw it out there before things are added too quickly. And thanks for the link issue. Great to see others brought it up too. Naturally, if macros would be overused it could get complicated, but then you have to blame yourself writing the code like that I suppose... :)

@Chillance I'm personally opposed to adding hygienic macros to Go. People are complaining about try making the code harder to read (I disagree and think it makes it easier to read, but that's another discussion), but macros would be strictly worse from this point of view. Another major issue with macros is that it makes refactoring, and especially automated refactoring, so much harder, because you usually have to expand the macro to refactor. I repeat myself, but this is a whole can of worms. try is 1 year old toy compared to this.

@ngrilly My initial thought with Go macros is that they would be simple, shorter tidbits. And you would use those in the function to make it easier to read. That is, not overuse macros. And, use if for simpler things that you don't want to repeat, such as error handling. It is not suppose to be very large, because then just use a function I suppose. Also, having a macro, doesn't that make refactoring easier as you have one place to change things instead of maybe many in the function?

@Chillance The problem with macros is that tools (especially refactoring tools) have to expand the code to understand the semantics of the code, but must produce code with the macros unexpanded. It's hard. Look at this for example in C++: http://scottmeyers.blogspot.com/2015/11/the-brick-wall-of-c-source-code.html. I guess it's a little bit less hard in Rust than in C++ because they have hygienic macros. If the complexity issue can be overcomed, I could change my mind. Must be noted it changes nothing to the discussion about try, since Rust which has macros, has implemented a strict equivalent of try as a built-in macro ;-)

Why not use existing keywords like:
func ReadFile(filename string) ([]byte, error) {
    f, err := os.Open(filename)
    return if err != nil
    defer f.Close()
    return ioutil.ReadAll(f)
}

No new language rule for implicit bool(err != nil)
So other conditions than err != nil are also possible:

    f, err := os.Open(filename)
    return if errors.Is(err, os.ErrNotExist)

return without named values is already in the language
Only implicit magic is returning err when used in the if statement, but explicit return values could be used like:

    return x, y, err if err != nil

A more complicated example doesn't seem to have advantages in terms of readability compared to the traditional if clause, though:
    f, err := os.Open(filename)
    return nil, errors.Wrap(err, "my extra info for %q", filename) if errors.Is(err, os.ErrNotExist)

This seems to be nothing more than an equivalent to a macro such as the following:
#define catch(a) if a != nil { return }
Why not just make macros a feature and let users implement their own shorthands?

@fabian-f

Why not just make macros a feature and let users implement their own shorthands?

Because we have no time to learn every other library's own flavor of Go just to be able to comprehend what is it doing. We've been there, done that @ C, we've been suffocated by it in C++. RiP Rust was such a wünderkid until got the feature-fever and passed away.
I wish not the same with Go.

Could even shorthand the decoration
#define catch(a, msg) if a != nil { return fmt.Errorf("%s: %w", msg, a) }

...and possibly will send user keys to the moon in yet other decoration you'll skim over.

@natefinch
I humbly inform you that I reused the catch word for my #32968 check proposal.
I would be really glad to see your opinion there, too.
The check abstract:
func check(Condition bool) {} // built-in signature

check(err != nil)
{
    ucred, err := getUserCredentials(user)
    remote, err := connectToApi(remoteUri)
    err, session, usertoken := remote.Auth(user, ucred)
    udata, err := session.getCalendar(usertoken)

  catch:               // sad path
    ucred.Clear()      // cleanup passwords
    remote.Close()     // do not leak sockets
    return nil, 0,     // dress before leaving
      fmt.Errorf("Can not get user's Calendar because of: %v", err)
}
// happy path

check(x < 4) // implicit: last statement is of the sad path
  {
    x, y = transformA(x, z)
    y, z = transformB(x, y)
    x, y = transformC(y, z)
    break // if x was < 4 after any of above
  }

Last one already compiles at playground.

@Merovius [about print/println]

If you look at the spec, it seems clear to me that that wouldn't be a good idea. Both in that it's implementation-defined what it does and that it is limited in what arguments it can receive.

You're right. I was about reusing print short implementations for rudimentary sprint - its too cumbersome though.

I agree with @Merovius that we can't put fmt.Errorf into the language proper.  I think that reduces this proposal to the single argument case.  It then seems to me that this is isomorphic to the try proposal (#32437) except that try (here called catch) does not return any values.  Does that seems correct?
Of course, then the new built-in doesn't help with error annotation, which is one of the objections that people raise about try.
The name catch doesn't seem right to me for this.  It doesn't catch anything.  Seems like check would be a better choice.

@ianlancetaylor

Of course, then the new built-in doesn't help with error annotation, which is one of the objections that people raise about try.

As a fallback position regarding the fmt concern, the proposal author had suggested passing in a handler to check (using your suggested term for catch)  in https://github.com/golang/go/issues/32811#issuecomment-506461203 above:
So under that alternative, a wrapping example could be:
f, err := os.Open(config)
check(fmt.ErrorHandlerf(err, "error opening config for user %s", user))

A similar-in-spirit solution would be to have an error handler as an optional second argument to check for in place error annotation (e.g., as suggested by @eihigh in https://github.com/golang/go/issues/32437#issuecomment-499294383):
f, err := os.Open(config)
check(err, fmt.ErrorHandlerf("error opening config for user %s", user))

Some of the concerns that have been raised in the discussion about the try proposal (#32437) include:

concern about in-place error annotation or wrapping.
concern about control flow visibility, including the risk of not noticing an exit point.
concern about the amount of complexity per line.

As far I understood the discussion, I think this proposal targets all three of those.
One final question / comment: if a builtin such as check was to be introduced without returning any values, it seems there would be at least a possibility to allow it to return values in the future in a backwards compatible way?  In other words, if this particular proposal was to be pursued, it seems that check could be introduced without the ability to nest check, but the door would still be open to allow nesting of check as a follow-on change if experience suggests it is needed?

@thepudds

f, err := os.Open(config)
check(fmt.ErrorHandlerf(err, "error opening config for user %s", user))

FWIW, this code would also work with try. The changes between the other proposal and this one would seem to be:  a) rename try to check and b) remove the return value.
The former seems fairly minor.
The latter seems more significant and will essentially require the builtin to be used in a statement context. Rolling out try (or check) in two separate phases as you suggest actually sounds pretty good to me.

As I understand it, the proposal as it stands is:

Add a new builtin function check.  This function takes a single argument of type error.  It may only be called in a function whose last result parameter is of type error.  If the argument to check is not nil, then it immediately returns from the calling function, returning its argument as the last result.  Other results remain as they are; if unnamed, they are the zero value of their type.

Add a new function fmt.ErrorHandlerf.  This takes a value of type error, a formatting string, and other arguments.  If the first argument, of type error, is nil, then fmt.ErrorHandlerf returns nil.  Otherwise it returns the result of calling fmt.Errorf on the arguments.  Maybe the first argument is also passed to fmt.Errorf, though I'm not sure quite how that part works.

The advantage is that the block if err != nil { return ... } turns into a single statement, and there is some support for wrapping errors using fmt.ErrorHandlerf.  We could also add new similar functions as needed.
A disadvantage is that the fmt.ErrorHandlerf function is always called, although it would return very quickly after not doing anything.
The proposed check functionis similar to the earliertryproposal (#32437) (which could also have used the suggestedfmt.ErrorHandlerf) except that check, unlike try`, cannot be used in an expression.
Does this seem like a correct summary of the current state?  Thanks.

That is my understanding.
However, this was a counterproposal to try, which has been discarded. I don't think this proposal actually solves that much, I mostly did it as a compromise between people that wanted something like try, and those that thought try would hurt readability too much.

Do you want to withdraw the proposal?  The votes on it aren't all that great.

I'm happy to withdraw it given the votes.

Thanks.


2 MutatingWebhookConfiguration have the same name (helm-chart)

Describe the bug

Both MutatingWebhookConfiguration seem to have the same name ({{ .Chart.Name }}-webhook)
https://github.com/sse-secure-systems/connaisseur/blob/master/helm/templates/certificate_webhook-conf.yaml
Expected behavior

Different names for https://github.com/sse-secure-systems/connaisseur/blob/master/helm/templates/certificate_webhook-conf.yaml#L20 and https://github.com/sse-secure-systems/connaisseur/blob/master/helm/templates/certificate_webhook-conf.yaml#L51
or
only one definition for MutatingWebhookConfiguration

@Anna-Katona is that related to an actual problem or bug? How does it affect usage of Connaisseur?
The MutatingWebhookConfiguration you are pointing to specifies to hooks that are needed for installation order reasons and were introduced in ADR-5. Please check there for more information on the section. The earlier  approach was described in ADR-1. I am not certain we could name the hooks differently as one has to superseed the other to allow proper installation. Should be easy enough to test though...

This is expected behavior. The webhooks need to be installed after the Connaisseur deployment, otherwise they may block Connaisseur itself. This only works with helm hooks, but using them the resources using the hooks are no longer part of the regular chart and thus are not deleted when using helm uninstall. Thus the trick is to have an additional webhook with the same name, that overwrites the other one, which has a hook-delete-policy set, so it gets deleted.


Multipart Message Boundary String

Me and multipart requests again...
I need to generate a multipart request with the following header:
content-type: multipart/form-data; boundary=XXXsubpartXXX

So this means I need to tell the server already in the header which boundary string will be used in the body.
Since clj-http generates boundary strings automatically, is there any way to get this boundary string before the http message is sent, so I can add it to the header?
The other way of dealing with this would be for me to specify a boundary string myself. Is that possible?
Btw I found this: https://groups.google.com/forum/#!topic/clojure/JGCKVAqP6h4
But it didn't really help me since I don't really want to generate the body myself.

Closing as there has been no progress on this in four years, the linked message contains a workaround. If anyone else would like this or disagrees let me know and I'll be happy to re-open it.


Monorepo

Switching from a full NextJS app to a monorepo with a NextJS app and a separate API server. The API server will be used to store & serve the data and the NextJS app will be used to display the data.

Deployed backend to Heroku.


fn_update_check: line 288: syntax error: unexpected end of file

The update script seems to be bugged
fn_update_check: line 288: syntax error: unexpected end of file

Do you upload it by hand??? Maybe an "Enter" is missig or you save it wrong. For me it works without problems.
When you are on Linux install dos2unix and convert the file.
Then restart it again ;)

I did'nt upload it by hand, the script downloaded it directly from github. dos2unix does'nt solve the problem and an "Enter" at the end too.

Which command do you use, when erroro occour??

./insserver update
I tried with starbound server and but same error too but it's the same function for all scipts so.
Maybe someone could try to backup fn_update_check and delete it so that the script download it again for seeing if the same error occurs

Interesting. I was working on this last night and I thought it was working. Delete the functions dir and try again. If it still fails again it may be my fault :-)

I deleted the functions folder and it failed again ^^.

Thanks I will investigate

Should now work. Delete functions again and let me know :)

Yes it works now :D


Allow user use few login accounts in one step authentication

I think we can improve mobile app.
Now it just iterate through keyHandles which belong to specified issuer and applicationId
It make attempt to get U2F  authentication request for each keyHandle.
Once it find valid keyHandle It do authentication.
But instead of iteration we can just show list of keyHandles and tell user to select right one.
We only need to show this dialog if there are more than one keyHandle associated with issuer and applicationid.

We can use:
http://developer.android.com/intl/ru/training/articles/keystore.html
Android Keystore provider feature that was introduced in Android 4.3 (API level 18).
Hence after fixing this issue oxPush2 should work on Android devices >= 4.3

I think the best way for this case is using only one keyHandle for one server to avoid saving redundant keys

I think subject of this issue is out of date.
New new one will be simpler. Going to change it

IOS version already adopted for it, Android I think too


Work around missing offsets in initial data load

I hope this doesn't mask an actual problem with the data being shipped.
Fixes #87

I presume you're still looking for the underlying cause here?

Also, should you decide to merge this in, a version bump would be awesome!

Should we anticipate a merge on this soon?

I no longer care about DoctorKafka.


Disabled modifier

Is the :disabled modifier implemented? I could not find anything about it in the docs or anywhere, and I tried using it, and it does not seem to work. Is it planned?

Its planned and technically implemented in the latest versions, but <TextArea /> uses enabled={false} instead of the standard disabled prop. I'm not sure how to handle that in a generic nice way yet

Its planned and technically implemented in the latest versions, but <TextArea /> uses enabled={false} instead of the standard disabled prop. I'm not sure how to handle that in a generic nice way yet.
React Native RFC to address the problem: react-native-community/discussions-and-proposals#496

@marklawlor Is it supposed to work with Pressable? I cannot get it to work. Sample code that does not work on the latest version:
<Pressable className={'disabled:bg-gray-400'} disabled>
  <Text>Submit</Text>
</Pressable>

The pressable does not have a gray background, even though disabled is true.

We are closing all pre-v4.1 issues now that v4.1 is released. If the problem is still happening with the latest v4.1, please open a new issue and reference this one in the description.


Added Rust books.

What does this PR do?
Added Rust books.
For resources
Description
These are free books for Rust.
Why is this valuable (or not)?
They are free and openly available, mostly on GitHub.
How do we know it's really free?
They're available openly on the internet.
For book lists, is it a book? For course lists, is it a course? etc.
They're books.
Checklist:

[x] Read our contributing guidelines
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction)

Followup

Check the output of Travis-CI for linter errors!

great additions!

Fixed!


feat: hide trace tree for evaluate

Hide trace tree by default for evaluation calls.
Internal notion: https://www.notion.so/wandbai/Default-trace-tree-state-should-be-collapsed-based-on-heurisitics-816a79c376f64b59bdf2bcab8491fc0c?pvs=4

i like the new helper to update multiple search params, but I cant seem to get the drawer to open without the trace view open already. I tried going to evaluate-evaluate or evaluate-predict-and-score(from the notion photo) Though i could be doing something wrong


TestHelper.toHomeRelativeString(Path p) that translates a Path "/Users/usrname/some/dir/file" to "~/some/dir/file"

Problem to solve
In messages or documentations, we often need to show paths. For example,new TestHelper(this.getClass()).getProjectDir().toAbsolutePath() would return the full path of a project directory, like
/Users/kazruayam/github/unittest-helper/lib
And new Testhelper(this.getClass()).getOutputDir().toAbsolutePath() would return the full path of the "output" directory, like
/Users/kazurayam/github/unittest-helper/app/test-output
As you see, my personal name kazurayam is included in the path information and exposed. ... I am concerned about this exposure.
Solution
When I write a documentation, I want to hide my personal name. I do not like to expose it public. Rather I want to translate the paths into "Home Relative path" that starts with tilde (~), like

~/github/unittest-helper/lib
~/github/unittest-helper/app/test-output

So I want the TestHelper class to provide methods which translate a Pathe object to a String which is Home Relative if the path can be acutally relative to the $HOME.

static String TestHelper.toHomeRelativeString(Path p) return a String prepended with ~ if the path is under the $HOME

done at the v0.1.2


Migrate applicationsinsights  to track2

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

applicationsinsights

Please update extension VERSION to 0.1.13 or 0.2.0


Graph name should be the default base name of the export file.

Right now a graph name is specified when the graph is created but it is not used. When exporting a graph without a specified name, we pick a random name. We should pair these two values and use the name for the filename on export.

I made this update. The graph name will now be the base name of the export file unless you specify a destination when exporting the graph. It will still save to a temp folder.
If you attempt to specify a full file name as the graph name, we will get DOT parse errors. I may experiment with ways to work around this later. I am closing this one for now.


메인 브런치로 잘못넌거 수정

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fixed a bug in unescaping webhook secret

@jasonblais I am not sure there was a prior (1.0) ticket on this, couldn't find it.
Also added /jira webhook command to see a URL custom-fit to the current channel.

There wasn't a Jira ticket, it was reported here https://github.com/mattermost/mattermost-plugin-jira/issues/33


Sweep: React Native: URLSearchParams.toString() in

User Encountered: https://medplum.slack.com/archives/C057GEVQCRE/p1690420519646039

When calling exchangeExternalAccessToken() it ends up inside fetchTokens(). Inside React Native, body ends up being {}. I have remedied this with a yarn patch, to explicitly formBody.toString(). But we don't want to maintain that, especially on a minified file.
Line in question: https://github.com/medplum/medplum/blob/07e54140091c7cff30767af1340916599adcdbd6/packages/core/src/client.ts#L2862

@sweep-ai In file packages/core/src/client.ts in the method fetchTokens, can you change this line:
body: formBody,

To this:
body: formBody.toString(),

Most implementations of fetch handle the case where body is an instance of URLSearchParams.  Apparently that is not the case in React Native.

@sweep-ai In file packages/core/src/client.ts in the method fetchTokens, can you change this line:
body: formBody,

To this:
body: formBody.toString(),

Most implementations of fetch handle the case where body is an instance of URLSearchParams.  Apparently that is not the case in React Native.

Fixed in https://github.com/medplum/medplum/pull/2563


chore(main): release 1.4.5

:robot: I have created a release beep boop
1.4.5 (2022-11-29)
update

update (30fa11a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/School-of-Website-Engineering/Rosy-DR-Code-Ling/releases/tag/v1.4.5 :sunflower:


Fix Redmine #6097

Based on my suggestion here:
https://forum.pfsense.org/index.php?topic=110698.msg618503#msg618503

merged, thanks!


Structured data

Description (required)
Some tickets were targetting structured data and then merged to it after structured data was merged

@macgills After this PR is merged, maybe we can resolve #3504

@misaochan merging as the tickets already had approval

@madhurgupta10 fire away


Workfiles: add dropdown to select existing subversion string

Feature
in Workfiles, you can specify subversion string when saving file. This is arbitrary string. It would help to be able to select from existing in dropdown menu then writing every time from the scratch.

[cuID:25xn3bh]

Or maybe preserve it from previous versions; https://github.com/pypeclub/OpenPype/issues/2626


Organization Website URL is set as Text

"Organization Website URL" input is set as text should be url and there is no validation for the value.

the validation exists and it works, could please retry after clearing the cache and let us know if still see this issue

You can see the type is not set as URL
https://github.com/omnistrate/saasbuilder/blob/5520834f51e8ec0470150efd460a51969e40df72/src/features/ProfileSettings/components/ProfileForm.jsx#L124

Ok, I see the fix you can close the issue


Allow team names with spaces

Gitea version (or commit ref): 1.4.0
Git version:N/A
Operating system:Docker
Database (use [x]):

[ ] PostgreSQL
[X] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No

Log gist:

Description
Is it possible to allow team names with spaces in them? Github allows this, so having it in Gitea would help me with mirroring our Github organisation to our Gitea instance. Can't imagine why spaces aren't allowed...
...
Screenshots

Probably related (there seems to be something quite broken with team names): if you put dashes in a team name (instead of spaces, the logical choice), the team is auto-completed when composing an issue, but upon preview/send it ends up as plaintext and no notifications are sent out.


autopopulated search for "cppdbg" has no results on the extensions marketplace

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.64.0 (snap)
OS Version: debian sid

Steps to Reproduce:

Do not have vscode-cpptools installed
Open a project with a launch.json that includes a configuration of type "cppdbg"
Try running/debugging
See this message Configured debug type 'cppdbg' is not supported

Click the "Install cppdbg Extension" button

see no results

i opened an issue on the extension repo (https://github.com/microsoft/vscode-cpptools/issues/8798) and it was closed as a dupe of (https://github.com/microsoft/vscode-cpptools/issues/8023) where @WardenGnaw wrote:

However, if you believe you should be able to find the C++ debugger by searching cppdbg, the extensions pane is owned by VS Code. Please file an issue in their repo: https://github.com/microsoft/vscode/issues

@Tyriar could you please reopen this?

@briaguya-ai good catch, thanks for filling this.
@wardengnaw can you add the string "cppdbg" to the extension short description? That way the extension will show up as a search result - workaround until Marketplace improves search relevance.
fyi @mayankmaheshwari18 @roblourens


Default wallet should be random

Hi. Sad story short. In the beginning of this year (2021) I was new in crypto world. I've found this repository to create my first ethereum wallet in offline mode. I use MacOS. I've run command
# '123445asdff' was my password (not real one)
java -jar target/epwg-0.4.0-SNAPSHOT.jar -d data -p $(read -s -p "123445asdff"; echo $REPLY)

I already do not remember all details but somehow it gave me the wallet file. Then I mined there for 3 months with one low-end GPU on 2miners (0.1 eth) and later  on ethermine (0.01 eth) pools. Then I changed my wallet on new one (because I've bought couple mid-range new GPUs) and haven't used this wallet for a while. Today I remembered that I have some Ethereum money/coins and wanted to send it to my second wallet and here I've found out the saddest thing ... the wallet that was generated is wallet as the wallet on main page (readme) - my password wasn't used but default one as on screenshot. And someone has generated the same wallet/password/privatekey and used it to transfer my ethereum to another wallet, it can be seen on etherscan (https://etherscan.io/address/0x47f71c6ee2e7d538c7554ec650bd7e536dc9057b).
This is my fault for sure. To prevent this for happening seems there should be added some randomness when password is not provided or empty, or something unexpected has happened.
This is not my main account, just didn't want that my colleagues see how stupid I was )
Thank you.

thanks for your story. i feel sorry for you. the non-randomness was actually on pupose from my side as it allows to easily verify if you get the same address every time.
i'll ask around and depending on the outcome update either the codebase as suggested - or - add a more explicit warning to the readme.
i'm also in the process to switch to a more recent repository [1] for the same functionality. please check it out if you're interested.
[1] https://github.com/cryptojorg/cryptoj.lib


(PUP-3930) Optimize failed_dependencies?

I profiled puppet agent --test on one of my servers using stackprof
[1] on Ruby 2.1.
Something like 30% or more of the time was spent in
Puppet::Graph::SimpleGraph#upstream_from_vertex, called from
Puppet::Transaction#failed_dependencies?
It turns out that, while evaluating the resource graph, when considering
a resource, we look at the complete set of transitive dependencies to
evaluate whether any of them have failed. This is hugely expensive, and
moreover, is wasted work in the success case where no resources fail.
Instead of all that work, this patch pushes the work to the failed
nodes; When a node fails, we transitively walk the dependents of that
node, and mark them as having failed dependencies, and then check that
flag directly when considering whether to skip a node later.
On my test system, this patch drops puppet agent --test runtime from
about 40s to about 23s.
[1] https://github.com/tmm1/stackprof

CLA signed by all contributors.

Wow! Great sleuthing.

@nelhage thanks for the contribution - looks very promising!

I'm not sure if this will be an issue, but we need to consider what happens with dependent resources that are dynamically generated on the agent, e.g. a file resource with recurse => true. With this PR, is there a possibility that the parent will fail, and not yet have any dependents to mark as failed? Will this cause those child resources to be omitted from the report?

That's a very good question. I unfortunately couldn't get a great sense from my read of the code so far as to when and how dependencies could get adding during traversal of the graph, so I can't answer with confidence whether that's a problem. Are there docs I can read or specific pieces of the code you could point me at?
Another model would be to populate the dependency_failed boolean as-we-go, based on "did any immediate dependency fail, or itself have a failed dependency?" I think that should play nicer with graph updates during application, and I could prototype that out if it seems more promising.

Ping @kylog

I still need to make time to review this.

Apologies for the long response cycle. We've been cranking away hard on puppet 4. I haven't forgotten about this but just have been under water. Hoping to circle back to this soon.

Pushed a fix that (I hope) resolves the issues with dynamically-generated resources. @joshcooper if you have any suggestions for how to improve the test case, I'd love to hear it.

Ping @kylog Would be rad to have you or another senior dev take a look again, this part of the puppet code scares me ;)

I just tested out this patch in one of Dropbox's puppet environments, and we also experienced a significant performance boost, so it'd be great if this made it in.

@nelhage I know of at least two ways for a resource to dynamically generate resources. There's resource.generate, which the tidy, user, resources, and maillist types use, and resource.eval_generate, which file uses.
I don't remember why we have two, and why we didn't name those methods better...
Also the catalog is accessible to a type, e.g. https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/file.rb#L336, and therefore its provider, so a custom module could make arbitrary changes to the catalog. I think @ffrank has some examples of that.

@joshcooper Thanks for the pointers! I did some digging this weekend and the previous patch did in fact have some bugs; The current version is robust at least to the simple file test case I tried, and should handle mutation in general more gracefully, by incrementally tracking state as we apply the catalog, so we only rely on the invariant that dependencies are processed before their dependents.

@nelhage the other thing to watch out for are "deferred" resources: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/graph/relationship_graph.rb#L112-L138. While puppet is applying a catalog, it may encounter a resource that is not suitable, because the provider is missing a prerequisite, e.g. package, command, etc, that puppet hasn't yet installed. So puppet will defer evaluation of the resource until "later". But even in that case, the invariant should hold. More something to watch out for.

@joshcooper Did you mean to close this, or was that a mis-click?

so sorry, I'm going to step away from the keyboard now!

I mentioned that this improved my Puppet runtimes by ~2x. Last night I constructed a microbenchmark to really show off the win here.
I created puppet manifests with N resources in a linear chain, of the form
`node default {
  notify { "message 0": }
  notify { 'message 1': require => Notify['message 0'] }
  notify { 'message 2': require => Notify['message 1'] }
  notify { 'message 3': require => Notify['message 2'] }
  notify { 'message 4': require => Notify['message 3'] }
  notify { 'message 5': require => Notify['message 4'] }
}

I then ran both puppet master and my branch on those manifests for a range of N from 1 to 5000. I ran each test 5 times and took the average application time (As reported by pupet via "Notice: Applied catalog in X.XX seconds" – thus excluding compilation time), and graphed the result:

The data clearly shows that upstream's application time is quadratic in the depth of the dependencies, and while it's hard to be positive, my branch appears to restore linear or near-linear behavior.

That's awesome, nice work on the visualisation @nelhage!

Resources from eval_generate do not seem to pose an issue either.
$ bundle exec puppet apply -e 'file { "/this/wont/work": ensure => "file" } -> file { "/tmp/tree": mode => "640", recurse => true } -> notify { "post": }'
Notice: Compiled catalog for geras.fritz.box in environment production in 1.17 seconds
Error: Could not set 'file' on ensure: No such file or directory - /this/wont/work at 1:
Error: Could not set 'file' on ensure: No such file or directory - /this/wont/work at 1:
Wrapped exception:
No such file or directory - /this/wont/work
Error: /Stage[main]/Main/File[/this/wont/work]/ensure: change from absent to file failed: Could not set 'file' on ensure: No such file or directory - /this/wont/work at 1:
Warning: /Stage[main]/Main/File[/tmp/tree]: Skipping because of failed dependencies
Warning: /Stage[main]/Main/File[/tmp/tree/a]: Skipping because of failed dependencies
Warning: /Stage[main]/Main/File[/tmp/tree/b]: Skipping because of failed dependencies
Warning: /Stage[main]/Main/File[/tmp/tree/c]: Skipping because of failed dependencies
Warning: /Stage[main]/Main/Notify[post]: Skipping because of failed dependencies
Notice: Applied catalog in 0.23 seconds

If a dependency of those fails, everything fails. If just a generated resource fails:
$ bundle exec puppet apply -e 'file { "/tmp/tree": mode => "640", recurse => true } -> notify { "post": }'
Notice: Compiled catalog for geras.fritz.box in environment production in 1.17 seconds
Notice: /Stage[main]/Main/File[/tmp/tree]/mode: mode changed '0700' to '0750'
Notice: /Stage[main]/Main/File[/tmp/tree/a]/mode: mode changed '0600' to '0640'
Error: failed to set mode 0600 on /tmp/tree/b: Operation not permitted - /tmp/tree/b
Error: /Stage[main]/Main/File[/tmp/tree/b]/mode: change from 0600 to 0640 failed: failed to set mode 0600 on /tmp/tree/b: Operation not permitted - /tmp/tree/b
Notice: /Stage[main]/Main/File[/tmp/tree/c]/mode: mode changed '0600' to '0640'
Warning: /Stage[main]/Main/Notify[post]: Skipping because of failed dependencies
Notice: Applied catalog in 0.23 seconds

The dependent resource fails even though only an eval_generated resource was erroneous.

@ffrank This is probably my own confusion, but I can't tell if you're reporting an issue on this branch or confirming it works-as-expected.
But to be explicit about what I see, I see identical behavior as best as I can tell in terms of which resources are evaluated and which are skipped, in both of your examples, between master and this branch.

Yes, I'm confirming that it works as I'd expect.
I wish we had a way of verifying that this won't alter the semantics of any possible transaction, but I believe we have covered the more important edge cases now.
:+1:

Thanks for doing the work to verify this, @ffrank!
@joshcooper do you have any other concerns before we label this for merge?

ah, I see you mentioned deferred resources. I can probably put together a test of that

I'm :+1: on this :smile_cat:
Unless Josh has anything else to say I think we can flag this for merge

@joshcooper we're giving you a few more days to respond, and if we don't hear back from you on this, we'll go ahead and merge it

@joshcooper: Restored reporting of the list of failed dependencies.
I feel pretty good that the tests in fa219b2 address the propagation of failedness through intermediate nodes, but lmk if you still think I should add more tests.

@nelhage I think it'd be good to have the test for propagation just for completeness' sake.

@nelhage also, it would be nice to see an acceptance test for verifying the reports generated haven't changed with this new error handling code. If you aren't comfortable with Beaker tests I'm happy to give you pointeres there.

@branan Ok, I can write that the propagation test. I've never worked with Beaker or the acceptance tests, so some pointers on how to write that second test would be great.

@nelhage We've got a ton of documentation at https://github.com/puppetlabs/beaker/wiki. Running the tests for Puppet is fairly well documented in docs/acceptance_tests.md
For this particular test, it should be as simple as running an agent and comparing the report to a known-good one. The high-level test structure is something like

create an environment with a manifest that contains a propagating failure
setup master to store the report on-disk using with_puppet_running_on
run the agent against your environment
compare the generated report to the expected result (you can do this by cating the file using beaker's on <host> helper, and parsing the YAML or JSON yourself in your beaker test)
cleanup the environment you created

@nelhage we're going to pull this in, and file a separate ticket to add an acceptance test that we'll handle internally. Thank you for your contribution!

@joshcooper Thanks! I spent a while this weekend trying to get the acceptance tests running in Vagrant, but it seems like the documentation had bitrotted slightly and I ran into some possibly-unrelated Vagrant problems.
I did notice that https://github.com/nelhage/puppet/blob/32e2bf2733ac8a2472dcfffa35fab8dcd52ec1df/spec/integration/transaction_spec.rb#L333 already tests the A->B->C case where C fails; It could be worth adding some assertions that the internal state is correct at the end, but that does verify that we don't apply 2nd-level dependents of failed nodes, as @branan asked.

@joshcooper do you have a plan for pulling this one in? Is something you'd like to see in the stable branch?

@melissa I tried to bring it in last planning session, but we're busy with the upgrade module work. Hopefully, it will make the next planning session.
I think puppet 4.1 is due out soon (likely before this is merged), and I don't think we want to introduce this change in a 4.1.z release, so I think master (4.2) is appropriate.

@nelhage Looks like we're very close to getting this merged.  Based on your comments above for testing the A->B->C case, would it be possible to add those missing assertions to this PR to satisfy the test coverage?

@peterhuene pushed in 62bd744; lmk if there's anything else you think should go there.

@nelhage This has been merged to master and should appear in Puppet 4.2 (4.1 is almost out the door).  Thanks for the contribution and the great profiling work as well!

Nice find. Yay stackprof.


As IDIM, I want to be notified when there's a new BCeID request so that I can take action to complete it.

to be added once we have shared client journey experience


[Bug] API Version Service Provider Google

Describe the bug
this one

it doesn't work when use v1beta

Docs https://ai.google.dev/docs/api_versions

However, the network request indicates that all calls are using the v1beta version, instead of the API version you provided.
For instance, in the image below, I used the v1beta and v1 versions to hold conversations, respectively. However, all web pages used the v1beta version to conduct conversations.

However, the network request indicates that all calls are using the v1beta version, instead of the API version you provided.
For instance, in the image below, I used the v1beta and v1 versions to hold conversations, respectively. However, all web pages used the v1beta version to conduct conversations.

it's because of this
export const Google = {
  ExampleEndpoint: "https://generativelanguage.googleapis.com/",
  ChatPath: "v1beta/models/gemini-pro:generateContent",
  VisionChatPath: "v1beta/models/gemini-pro-vision:generateContent",

  // /api/openai/v1/chat/completions
};

Also This repository hasn't been fixed for a long time and is essentially unmaintained, as @fred-bf is the only one managing it.

Also,

[!NOTE]
The Google Service Provider is still unstable unlike OpenAI. This instability is not due to Google itself. You can see more details here.

However, the network request indicates that all calls are using the v1beta version, instead of the API version you provided.

For instance, in the image below, I used the v1beta and v1 versions to hold conversations, respectively. However, all web pages used the v1beta version to conduct conversations.

it's because of this

export const Google = {

  ExampleEndpoint: "https://generativelanguage.googleapis.com/",

  ChatPath: "v1beta/models/gemini-pro:generateContent",

  VisionChatPath: "v1beta/models/gemini-pro-vision:generateContent",

  // /api/openai/v1/chat/completions

};

Also This repository hasn't been fixed for a long time and is essentially unmaintained, as @fred-bf is the only one managing it.

So in pull request #4192, I can only simply modify the code to solve the problem I encountered (or cover up the problem). After all, refactoring this part of the code is a bit too difficult for me now😢

However, the network request indicates that all calls are using the v1beta version, instead of the API version you provided.

For instance, in the image below, I used the v1beta and v1 versions to hold conversations, respectively. However, all web pages used the v1beta version to conduct conversations.

it's because of this
export const Google = {

  ExampleEndpoint: "https://generativelanguage.googleapis.com/",

  ChatPath: "v1beta/models/gemini-pro:generateContent",

  VisionChatPath: "v1beta/models/gemini-pro-vision:generateContent",

  // /api/openai/v1/chat/completions

};

Also This repository hasn't been fixed for a long time and is essentially unmaintained, as @fred-bf is the only one managing it.

So in pull request #4192, I can only simply modify the code to solve the problem I encountered (or cover up the problem). After all, refactoring this part of the code is a bit too difficult for me now😢

It's only refactoring support v1 and v1beta instead of only v1beta

It's only refactoring support v1 and v1beta instead of only v1beta

I'm preparing for a test recently. After my test is over, if no one has solved it, I want to give it a try.

It's only refactoring support v1 and v1beta instead of only v1beta

I'm preparing for a test recently. After my test is over, if no one has solved it, I want to give it a try.

nice

@Rubuark it's better to trying


panic: assignment to entry in nil map

Which version are you using?
v0.17.17
Which operating system are you using?

[ ] Linux amd64 standard
[x ] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[ ] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue
panic: assignment to entry in nil map
Describe how to replicate the issue

The connection from the publisher to the camera is not stable. Publisher tries to connect to the camera  and i got this bug.
Did you attach the server logs?

yes
panic: assignment to entry in nil map
goroutine 323 [running]:
github.com/aler9/gortsplib.(*ServerStream).readerAdd(0xc00044e680, 0xc0001a4500, 0x2, 0x0)
/go/pkg/mod/github.com/aler9/gortsplib@v0.0.0-20220219215154-bc9be686d962/serverstream.go:163 +0x37a
github.com/aler9/gortsplib.(*ServerSession).handleRequest(0xc0001a4500, 0xc00060f0e0, 0xc000114c80)
/go/pkg/mod/github.com/aler9/gortsplib@v0.0.0-20220219215154-bc9be686d962/serversession.go:706 +0x1892
github.com/aler9/gortsplib.(*ServerSession).run.func1(0xc0001a4500)
/go/pkg/mod/github.com/aler9/gortsplib@v0.0.0-20220219215154-bc9be686d962/serversession.go:280 +0x365
github.com/aler9/gortsplib.(*ServerSession).run(0xc0001a4500)
/go/pkg/mod/github.com/aler9/gortsplib@v0.0.0-20220219215154-bc9be686d962/serversession.go:372 +0x125
created by github.com/aler9/gortsplib.newServerSession
/go/pkg/mod/github.com/aler9/gortsplib@v0.0.0-20220219215154-bc9be686d962/serversession.go:215 +0x2ef
Did you attach a network dump?

no

fixed in v0.19.2.


When an error happens during a usb transfer, don't emit an error.

Remove the device instead.
Change-Type: patch

Why is this change necessary? And why would we want to ignore errors in the second stage, without communicating the failure?

Why is this change necessary? And why would we want to ignore errors in the second stage, without communicating the failure?

@jhermsmeier this error will happen if you unplug the rpi zero during the 2nd stage.
We only want to signal that this device is detached. Emitting an error on the adapter is useless because:

we don't know on which device the error occurred
we don't care (we only want to know that the device is no longer available) -> detach event instead of error
currently etcher will stop the device scanner if any error occurs, this is not a fatal error, other devices will get discovered if plugged in.

currently etcher will stop the device scanner if any error occurs,

well, we should definitely fix that, and maybe just fix that instead of swallowing errors here, I think

@jhermsmeier we expect that devices might be unplugged.
We're not swallowing the error here, we expect it and we react in consequence: we emit a 'detach' event.

a detach event is def. not an error imo, approved


Add KPI for developer portal traffic

Summary
This KPI focuses on how to understand your developer doc-creation efforts.

Hi, I've updated this PR to resolve the conflicts. 😀

Awesome - thanks so much for the contribution!


MAGT MiniMaps: zoom in around point

We want to ensure that the minimaps are zoomed in to roughly-local scale, it seems like they may be pretty zoomed out right now (not sure, lacking spatial context makes it a little hard to spot).

I spent a bit of time looking into this and even by pushing a Leaflet marker into a feature group and attempting to fit the bounds of the maps to that feature, we do not get different bounds when clicking on the map to get mini maps for all of the returned data. I believe we are getting a pretty well-localized mini-map and without the surrounding context in some of these locations, can be difficult to determine simply by viewing it.
We are using the Leaflet library appropriately and allowing the software to make those determinations such as using the fitBounds function for polygons and the panTo function for lat / lon coordinates for markers.
Should we close this ticket or is there more thought that should be put into this? A forced zoom resolution for points, etc?

I think this ticket can be closed.  I agree that for broader polygons, the zoom scale looks about right.  And now with point queries focusing in on the nearest HUC12, that takes care of my sense that things were too zoomed out for point queries.


release-update: upgrade hwloc to 2.8.0

Strip out references in hwloc/config/hwloc.m4 to a file that does not exist
utils/hwloc/test-build-custom-topology.sh.in
In order to update to latest stable hwloc 2.8.0

Not hard to reproduce the build error, but the output is so cryptic I can't tell what the actual issue is.

Looks like -Werror=vla is getting passed down into the compiler used by the configure tests inside hwloc.  This causes a warning about a variable-length array used in the code in their C99 tests to be treated as a failure.  Which means hwloc thinks we aren't using a C99 compiler and so it bails out.

Looks like -Werror=vla is getting passed down into the compiler used by the configure tests inside hwloc. This causes a warning about a variable-length array used in the code in their C99 tests to be treated as a failure. Which means hwloc thinks we aren't using a C99 compiler and so it bails out.

I can reproduce this locally. Can we just drop the -Werror=vla?

Strip out references in hwloc/config/hwloc.m4 to a file that does not exist
utils/hwloc/test-build-custom-topology.sh.in In order to update to latest stable hwloc 2.8.0

The update-hwloc.sh script handles these. When a new error appears during an update, you can add it to one of the lists at the top of the file.

Looks like -Werror=vla is getting passed down into the compiler used by the configure tests inside hwloc. This causes a warning about a variable-length array used in the code in their C99 tests to be treated as a failure. Which means hwloc thinks we aren't using a C99 compiler and so it bails out.

In the past, we've patched hwloc to disable this configure test. The instructions at the end of update-hwloc.sh say to review the git history of hwloc/ and squash any such patch commits into the update. The commit in question no longer applies cleanly so I kept an updated one separate this time.

Strip out references in hwloc/config/hwloc.m4 to a file that does not exist
utils/hwloc/test-build-custom-topology.sh.in In order to update to latest stable hwloc 2.8.0

The update-hwloc.sh script handles these. When a new error appears during an update, you can add it to one of the lists at the top of the file.

Looks like -Werror=vla is getting passed down into the compiler used by the configure tests inside hwloc. This causes a warning about a variable-length array used in the code in their C99 tests to be treated as a failure. Which means hwloc thinks we aren't using a C99 compiler and so it bails out.

In the past, we've patched hwloc to disable this configure test. The instructions at the end of update-hwloc.sh say to review the git history of hwloc/ and squash any such patch commits into the update. The commit in question no longer applies cleanly so I kept an updated one separate this time.

All good points, I failed to understand all the elements of the script and the followup commits.


error C2118: negative subscript (ntexapi.h)

Brief description of your issue
After running "build_debug.cmd" I get these errors:
ERROR] (1) D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6494,1): error C2118: negative subscript (compiling source file kphmsgdyn.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6494,1): error C2118: negative subscript (compiling source file kphmsg.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6495,1): error C2118: negative subscript (compiling source file kphmsgdyn.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6495,1): error C2118: negative subscript (compiling source file kphmsg.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6497,1): error C2118: negative subscript (compiling source file kphmsgdyn.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6497,1): error C2118: negative subscript (compiling source file kphmsg.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6494,1): error C2118: negative subscript (compiling source file kphdyn.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6495,1): error C2118: negative subscript (compiling source file kphdyn.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj] D:\Process Hacker 2\systeminformer-master\phnt\include\ntexapi.h(6497,1): error C2118: negative subscript (compiling source file kphdyn.c) [D:\Process Hacker 2\systeminformer-master\kphlib\kphlib_um.vcxproj]
Steps to reproduce (optional)
No response
Expected behavior (optional)
No response
Actual behavior (optional)
No response
Environment (optional)
No response

Are you compiling with VS2022?

error C2118: negative subscript

Your VS is failing this check for some reason:
C_ASSERT(sizeof(KUSER_SHARED_DATA) == 0x738);

Running .cmd file it says this about vs:
VisualStudio: VisualStudio/17.1.1+32228.430
Yes I have VS2022 (I also have VS Build Tools 2017) installed and trying to compile it manually it gives me the same error but x  (prob for every file)

Updated Visual Studio 2022 to 17.3.6+32929.385 still having this issue

still having this issue

CI is passing without this issue and none of us can reproduce the error:
https://github.com/winsiderss/systeminformer/actions/workflows/msbuild.yml

trying to compile it manually it gives me the same error

It's very likely your Windows SDK installation is corrupted and generating invalid binaries with invalid structures. You should uninstall the Windows SDK and then uninstall Visual Studio to reset the installation (repair install won't reset the Windows SDK) then reinstall.