errors: add support for wrapping multiple errors

For the most recent version of this proposal, see: https://github.com/golang/go/issues/53435#issuecomment-1191752789 below.

This is a variation on the rejected proposal #47811 (and perhaps that proposal should just be reopened), and an expansion on a comment in it.
Background
Since Go 1.13, an error may wrap another by providing an Unwrap method returning the wrapped error. The errors.Is and errors.As functions operate on chains of wrapped errors.
A common request is for a way to combine a list of errors into a single error.
Proposal
An error wraps multiple errors if its type has the method
Unwrap() []error

Reusing the name Unwrap avoids ambiguity with the existing singular Unwrap method. Returning a 0-length list from Unwrap means the error doesn't wrap anything. Callers must not modify the list returned by Unwrap. The list returned by Unwrap must not contain any nil errors.
We replace the term "error chain" with "error tree".
The errors.Is and errors.As functions are updated to unwrap multiple errors. Is reports a match if any error in the tree matches. As finds the first matching error in a preorder traversal of the tree.
The errors.Join function provides a simple implementation of a multierr. It does not flatten errors.
// Join returns an error that wraps the given errors.
// Any nil error values are discarded.
// The error formats as the text of the given errors, separated by sep.
// Join returns nil if errs contains no non-nil values.
func Join(sep string, errs ...error) error

The fmt.Errorf function permits multiple instances of the %w formatting verb.
The errors.Split function retrieves the original errors from a combined error.
// Split returns the result of calling the Unwrap method on err,
// if err's type contains an Unwrap method returning []error.
// Otherwise, Split returns nil.
func Split(err error) []error

The errors.Unwrap function is unaffected: It returns nil when called on an error with an Unwrap() []error method.
Questions
Prior proposals have been declined on the grounds that this functionality can be implemented outside the standard library, and there was no good single answer to several important questions.
Why should this be in the standard library?
This proposal adds something which cannot be provided outside the standard library: Direct support for error trees in errors.Is and errors.As. Existing combining errors operate by providing Is and As methods which inspect the contained errors, requiring each implementation to duplicate this logic, possibly in incompatible ways. This is best handled in errors.Is and errors.As, for the same reason those functions handle singular unwrapping.
In addition, this proposal provides a common method for the ecosystem to use to represent combined errors, permitting interoperation between third-party implementations.
How are multiple errors formatted?
A principle of the errors package is that error formatting is up to the user. This proposal upholds that principle: The errors.Join function combines error text with a user-provided separator, and fmt.Errorf wraps multiple errors in a user-defined layout. If users have other formatting requirements, they can still create their own error implementations.
How do Is and As interact with combined errors?
Every major multierror package that I looked at (see "Prior art" below) implements the same behavior for Is and As: Is reports true if any error in the combined error matches, and As returns the first matching error. This proposal follows common practice.
Does creating a combined error flatten combined errors in the input?
The errors.Join function does not flatten errors. This is simple and comprehensible. Third-party packages can easily provide flattening if desired.
Should Split unwrap errors that wrap a single error?
The errors.Split function could call the single-wrapping Unwrap() error method when present, converting a non-nil result into a single-element slice. This would allow traversing an error tree with only calls to Split.
This might allow for a small improvement in the convenience of code which manually traverses an error tree, but it is rare for programs to manually traverse error chains today. Keeping Split as the inverse of Join is simpler.
Why does the name of the Split function not match the Unwrap method it calls?
Giving the single- and multiple-error wrapping methods the same name neatly avoids any questions of how to handle errors that implement both.
Split is a natural name for the function that undoes a Join.
While we could call the method Split, or the function UnwrapMultiple, or some variation on these options, the benefits of the above points outweigh the value in aligning the method name with the function name.
Prior art
There have been several previous proposals to add some form of combining error, including:
https://go.dev/issue/47811: add Errors as a standard way to represent multiple errors as a single error
https://go.dev/issue/48831: add NewJoinedErrors
https://go.dev/issue/20984: composite errors
https://go.dev/issue/52607: add With(err, other error) error
fmt.Errorf("%w: %w", err1, err2) is largely equivalent to With(err1, err2).
Credit to @jimmyfrasche for suggesting the method name Unwrap.
There are many implementations of combining errors in the world, including:
https://pkg.go.dev/github.com/hashicorp/go-multierror (8720 imports)
https://pkg.go.dev/go.uber.org/multierr (1513 imports)
https://pkg.go.dev/tailscale.com/util/multierr (2 imports)

How does walking up the tree work? Is it depth-first, i.e. Unwrap() to []error and then fully walk each resulting tree, or is it breadth-first, i.e. Unwrap() to []error and then do each of those before unwrapping them and doing the next set. I assume that it's depth-first, as that's simpler, but breadth-first could also make sense.

How does walking up the tree work in errors.Is() and errors.As()?

Depth-first. Unwrap to an []error and walk each error in the list in turn. This is what every existing multierr implementation I looked at does.

This would also subsume #50819 and I imagine any other similar proposals.
Maybe it should wait for a generic iteration standard, but should there be some errors.Each function that goes through each link in the chain? My suspicion is there’s not much to do besides As-ing and Is-ing, but it does seem like an absence, since there will be some internal function that works like that, which could potentially be exported.

Is and As are separate implementations for efficiency reasons, so there's no internal Each function. This proposal does make the case for an exported Each or similar stronger, since iteration becomes more complicated.
We should probably wait and see what happens with generic iteration, however.

Does Unwrap return a reference to the internal slice in the error?
If so, that would make the internal slice reference externally mutable, which seems unfortunate (but not a dealbreaker).
If not, and it returns a copy, then it would allocate, which also seems unfortunate (but probably not a dealbreaker).

Does Unwrap return a reference to the internal slice in the error?

Unspecified, but the contract for it says that the caller must not modify the slice, so it may.
Perhaps Split should copy the result into a new slice. This would leave Is and As potentially allocation-free, while adding a layer of safety (and an allocation) to the relatively unusual case of manually inspecting the individual errors.

This strikes me as a significant step forward in figuring out the multi-error question. Thank you!
The only part of this that doesn't seem entirely spot-on is errors.Split.
What is the use case for errors.Split?
Figuring errors.Split would be used like errors.Unwrap, I grepped through the code sitting around on my laptop and found only a single use of errors.Unwrap. It was used to check recursively whether any error in the chain satisfied a predicate. It would be interesting to analyze other uses in a larger corpus.
Walking an arbitrary error tree using errors.Split and errors.Unwrap will be annoying. I wonder whether a callback-based errors.Walk that walks the entire error tree would be a better API. There are a lot of details to specify for such an API, but with a bit of care, it could be more powerful and flexible than errors.Split. It could be used to implement errors.Is and errors.As. And it sidesteps questions about ownership and modification of returned error slices.
(The details about errors.Walk include things like: Does it call back for all errors, or only leaf errors? Does it use a single callback like io/fs.WalkDir or separate pre- and post- callbacks like golang.org/x/tools/ast/astutil.Apply? Does it support early stopping?)
On the topic of slice copies, a minor question. Does errors.Join make a copy of the variadic arg? I'd argue for yes, and ameliorate the pain a bit by adding a small default backing store to the struct. Aliasing bugs are miserable.

I find that the main reason I unwrap my own multierrors is so that I can report them separately to my logging service or display them as a list in a CLI. The original xerrors formatting proposal was dropped for being too complicated but I think that an easy to use error walking mechanism might make it easy to let users figure out how they want to display and format all the suberrors on their own.

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

If I hadn't read the comments, I might have thought that after the "Join" error, I could use "Split" to parse it out.
"errors.Split" does the same thing as "errors.Unwrap", but deals with multiple errors. So instead of "Split" which is the opposite of "Join", it should be "UnwrapMultiple" or "Walk" which is more appropriate.

The errors.Unwrap function is unaffected: It returns nil when called on an error with an Unwrap() []error

Since there is no reaction to multiple error conditions, the naming should also be differentiated, such as ”UnwrapMultiple“.

What is the use case for errors.Split?

We need to provide some reasonably convenient way to get at the underlying errors of a multierr. Perhaps Split isn't the right API here (although I still feel pretty good about it), but we need something.

I wonder whether a callback-based errors.Walk that walks the entire error tree would be a better API.

Perhaps there's a case for such an API, but I think it's distinct from this proposal. Accessing the component errors of a multierr is different from a full tree walk.

Does errors.Join make a copy of the variadic arg?

Yes.

I'm 100% on

defining Unwrap() []error
changing Is/As to support the new Unwrap
updating fmt.Errorf to allow multiple %w

If those were the only things accepted I'd be happy and it would be more than enough to allow external multierrors to interoperate with each other and std.
I do think there 100% does need to be a tree walking API—but it's too early to decide what that looks like. Once the protocol above is enshrined in errors, it's simple enough to experiment with that outside std.
I'm not 100% sold on the name for Split but there should probably be such a func in std, regardless of name, to pair with Unwrap. I don't think it would be much of an impediment if this weren't included, however.
I'm not really sold on Join. I see the utility of including a basic multierror in std, but just gluing the errors together with a sep seems like it could get messy when multierrors get composed. I think, like a tree walking API, it should be left out and experimentation allowed to continue outside std for now.

We need to provide some reasonably convenient way to get at the underlying errors of a multierr.

I'm not so sure that we do.
For uses (testing?) in which you really specifically want to unwrap from an error that has an Unwrap() [] method, you can use a type assertion. (errors.Unwrap is less than 10 LOC, and consists entirely of a type assertion.)
But I suspect that almost nobody wants specifically to unwrap a multi-error exactly one layer deep. Rather they want to ask the general question "what errors are in this tree?". So I think that's the right form of API to add. And I think it'll get created internally anyway to implement Is and As.
Maybe this proposal should simply omit Split?

I grepping in my own dependencies and grabbed all the uses. I ignored the standard library, static analyzers, linters, and then pulled all the uses that were not in tests. Here they are:
x/tools uses errors.Unwrap to get to the innermost error, without regard for the structure of what is above it. I suspect that this could would be better served by being able to evaluate a predicate on every error in the tree.
aws-sdk-go uses errors.Unwrap to recursively evaluate a predicate on every error in the tree, with early stopping.
containerd uses errors.Unwrap in a way that I find confusing and might be buggy. It uses it to peel back exactly one layer of wrapping and then compares this to a particular error using string matching. This is fragile (if another wrapping layer gets introduced) and would probably be better served by a way to check every error in the tree.
containerd uses errors.Unwrap again to peel back exactly one layer of wrapping. It looks like errors.As would be a better fit here; I don't see any reason why exactly one layer is the right answer here.
jwt uses errors.Unwrap to implement Is. In this case, errors.Unwrap is unnecessary, because e is known to have a concrete type that implements Unwrap; the code could call e.Unwrap directly instead.
I then grabbed two uses in tests at random:
errwrap uses errors.Unwrap specifically to test that it is compatible with how the standard library defines errors.Unwrap. It has no actual use for errors.Unwrap or opinion about its behavior.
pgconn uses errors.Unwrap in a test. It looks like it would be equally well served by errors.As.
So far, I see no evidence that anyone cares much about the structure of the error tree. It looks to me like they are all: misusing the API (evidence that the API is wrong); using the wrong API (evidence that the API is wrong); using the API pointlessly; or using the API to evaluate a predicate "anywhere along the error chain".

That's useful data; thanks.
We don't have error trees right now; we have an error chain. We can't tell whether people will care about the structure of trees by looking at how they work with linear chains.
It'd be interesting to look at use of existing multierr packages to see how often multierrs are converted back to lists of errors.

It'd be interesting to look at use of existing multierr packages to see how often multierrs are converted back to lists of errors.

I agree. Can I leave that for you to do? I've exceeded my time allotment for this for a while. :)

I'm 100% on

defining Unwrap() []error
changing Is/As to support the new Unwrap
updating fmt.Errorf to allow multiple %w

If those were the only things accepted I'd be happy and it would be more than enough to allow external multierrors to interoperate with each other and std.
I do think there 100% does need to be a tree walking API—but it's too early to decide what that looks like. Once the protocol above is enshrined in errors, it's simple enough to experiment with that outside std.

I agree with you very much, we should focus on the original core API supporting the multiple error model first, and then expose the complexity to the user. Before that, we can experiment with Join, Split, Walk, etc.

I agree. Can I leave that for you to do? I've exceeded my time allotment for this for a while. :)

I'm going to go look, but probably not until next week. Had a few days of meetings, and I'm now exhausted and behind on everything. :)

I'd like to help encourage my team to use errors.Is (or evens errors.As) for testing instead of using text-based comparisons. While researching to provide best practices I created the following code for use in the Golang Playground:
https://gist.github.com/BenjamenMeyer/ef9926913dcc3b165da8f25a459442a9
I was quite surprised that errors.Unwrap would only extract the first layer (may be I'm doing something wrong?) but then came across this proposal. Honestly, IMHO most are looking to be able to use the errors.is and errors.As APIs to test a full error chain reliably instead of having to decode a string, which could be unreliable.
Love the proposal here but would certainly be happy with something that would allow errors.Is to detect any given error is part of the provided error when built up from several in a row - e.g returning an error up from a lower level in the code to a higher level several times and being able to see the lower error is there.
NOTE: The code in the gist is just a sample for this explicit behavior. Consider the list of errors representing the layers of the code with the singular error what the code actually sees in the tests; yet it fails to be able to detect the lower level errors.
HTH

182/5981 = ~3%
I clicked haphazardly through the list. I ignored instances that were part of multierr implementations, which was a fair few of these. I saw three major clusters in what remained:

Log each error individually. I'm a bit puzzled by this, insofar as it means that you lose the context that all these errors occurred in a single unit. And because I'm puzzled, I can't tell whether people would rather go exactly one level deep (why would you?) or would rather log all leaf errors (you'd lose structure, but then again you already are). I kind of suspect that this may primarily reflects difficulties in formatting multi-errors, rather than a desire to extract a one-level-deep slice.
Check whether a predicate applies to any element of the slice. This seems best served by some kind of Walk.
Write a test assertion that a particular set of errors occurred. I don't know whether testing error tree equality is in scope.

My take-away is that there isn't much of a case for extracting an []error exactly one level deep...but I didn't believe that in the first place, so there could definitely be confirmation bias here. :) Probably worth doing your own analysis too.

My take-away is that there isn't much of a case for extracting an []error exactly one level deep...but I didn't believe that in the first place, so there could definitely be confirmation bias here. :) Probably worth doing your own analysis too.

Since the current built-in Unwrap only goes one-level deep by default, preserving it that way would minimize code breakage while having Split() []error to get the full tree would allow the additional use-cases for those that want it for tree walking or anything else.

Log each error individually. I'm a bit puzzled by this, insofar as it means that you lose the context that all these errors occurred in a single unit. And because I'm puzzled, I can't tell whether people would rather go exactly one level deep (why would you?) or would rather log all leaf errors (you'd lose structure, but then again you already are). I kind of suspect that this may primarily reflect difficulties in formatting multi-errors, rather than a specific desire to extract a one-level-deep slice.

In a previous project I worked on folks generated their own multi-error and dumped each out individually to minimize log space - but it meant you had a bunch of logs lines that made up the entire single log message. This would probably be another good use of tree walking.
In a current project I see folks comparing to a string b/c you can't by default go more than one level deep (see my example from https://github.com/golang/go/issues/53435#issuecomment-1168913889) and yes it's super fragile (especially if one tries to add translations into the mix) but it's due to current limits. Fixing the multi-error functionality would probably help most of these eventually go away as folks update the projects and learn about the functionality.

Write a test assertion that a particular set of errors occurred. I don't know whether testing error tree equality is in scope.

If errors.Is() and errors.As() could detect the individual errors desired then it shouldn't be necessary to test for tree equality as part of this effort. If desired it could be addressed in the future, but the implementation would be simple enough - perhaps best left for when two slices could be easily compared via a generic.

I agree that the data seems to indicate that unwrapping one level of []error is rare, and that in the rare cases that it is done the justification is often dubious.
Looking back over the above discussion, I think there are three major questions.

Should we provide Join?
@jimmyfrasche says:

I see the utility of including a basic multierror in std, but just gluing the errors together with a sep seems like it could get messy when multierrors get composed. I think, like a tree walking API, it should be left out and experimentation allowed to continue outside std for now.

Looking at some existing multierr implementations:

github.com/hashicorp/go-multierror formats as a * bulleted list with a header line.
go.uber.org/multierr joins the errors with ; , and formats %+v as a * bulleted list with a header line.
tailscale.com/util/multierr formats as a - bulleted list with a header line.

https://go.dev/play/p/zwGWvtR0IHW
It seems as if existing implementations have converged on providing a list with one error per line, as an option if nothing else. This may argue that Join is the wrong API here.

Should we provide Split?
@josharian says:

So far, I see no evidence that anyone cares much about the structure of the error tree. It looks to me like they are all: misusing the API (evidence that the API is wrong); using the wrong API (evidence that the API is wrong); using the API pointlessly; or using the API to evaluate a predicate "anywhere along the error chain".

I think that the evidence from calls to "go.uber.org/multierr".Errors supports this argument. It feels very strange to me to not provide a simple way to unpack a multierr, but I'm convinced that this API is an invitation to misuse. The rare cases that actually need to unpack one level of a multierr can use a type assertion and call the Errors method directly.

Should we provide a tree walking API?
None of the existing multierr implementations I've looked at provide this. If this is useful, we should demonstrate it outside the standard library first.

One additional pattern I saw for Errors() was as a way to append additional errors to an existing list of errors. Essentially re-flattening the list. Maybe not worrying about the distinction of Join(";", Join(";", i, j), k) and Join(";", i, j, k) simplifies something else? Not really sure why though.

FWIW A clever use of Join can cover some of the headerline cases Join("\n  *", errors.New(headerline), errs...). This will compose terribly with trees though. Maybe we need a format for Join that is tree friendly?

Maybe not worrying about the distinction of Join(";", Join(";", i, j), k) and Join(";", i, j, k) simplifies something else?

That's how the Tailscale multierr package works. The reasoning is that it lets you write code that builds it incrementally:
var me Multierr
// ...
me = Multierr(me, err)
// ...
me = Multierr(me, err)
// ...
return me

In this case case, the final return will return nil, a single error, or a multierr composed purely of the non-nil errors encountered along the way.
I almost wrote this earlier. But I didn't, when I realized that this is effectively equivalent to:
var errs []error
// ...
errs = append(errs, err)
// ...
errs = append(errs, err)
// ...
return errors.Join(errs)

The only difference is that, as originally proposed, Join doesn't return the sole non-nil error directly in the case in which there is exactly one non-nil error. But that could be changed. :)

FWIW A clever use of Join can cover some of the headerline cases

I think for that you want: fmt.Errorf("THE HEADER: %w", errors.Join(errs)).

Should we provide Join?

If we don't, there is no standard way to go from a slice of errors to a single error. fmt.Errorf supporting multiple %w verbs is awesome, but only supports a fixed number of errors.
I think we need some API that goes from an unknown number of errors to a single error. It could be one-shot (take in a slice) or incremental (add errors one at a time), because this is a very common use case.
I don't have strong feelings about exactly what that API is. I was happy with Join and would probably be happy with others as well.

I very much like the simplicity of a join function that takes a []error and returns an error, as opposed to an append function which adds more errors to an existing one. I think join is the right API for the standard library. Append opens too many questions about tree structure and allocations.
The sticky question is what the text of a joined error should be. The nice thing about Join(sep, errs) with an explicit separator is that it has no opinion; the user remains under full control of the error text. The problem with it is that existing implementations have a clear preference for bulleted lists of errors, which you can't do with just a separator. So perhaps we can't get away from the need to be somewhat opinionated about error text.

If we don't, there is no standard way to go from an unknown number of errors to a single error (or nil). fmt.Errorf supporting multiple %w verbs is awesome, but only supports a fixed number of errors.

How about expanding %w to something like:

%Nw - Nth error in the list, or nil if the list isn't that long, following the pattern of %Nd formatting of numbers
%w - single, top most error, equivalent of %0w
%#w - all errors (though of %*w but since #v is already for verbosity, why not use it with %w too?)

Then you could:
fmt.Errorf("%w: had some error due to %1w", err, err)
fmt.Errorf("Had errors: %#w", err)

I very much like the simplicity of a join function that takes a []error and returns an error, as opposed to an append function which adds more errors to an existing one. I think join is the right API for the standard library. Append opens too many questions about tree structure and allocations.
The sticky question is what the text of a joined error should be. The nice thing about Join(sep, errs) with an explicit separator is that it has no opinion; the user remains under full control of the error text. The problem with it is that existing implementations have a clear preference for bulleted lists of errors, which you can't do with just a separator. So perhaps we can't get away from the need to be somewhat opinionated about error text.

func (err error) Join(sep string, errs []error) error

Then sep could be -, \n\t-, etc as opposed to just making sep a single rune.
$0.02 FWIW

My main argument against Join/Split is that it's easy to punt that decision to 3rd party implementations to work out the details before anything gets enshrined in the Go 1 compatibility agreement. Defining the interface and how Is/As work is enough to let everything work together and experiment.

Third party implementations have been around for a while. Is there anything more that's going to be worked out in them so far as error text goes? Or to put it another way, what new information do we think we're going to get?
Options I see:

Drop Join.
I don't like this option. I think there's compelling evidence that Split isn't necessary, but combining a list of errors into a single error is not just a common use case, it's fundamental to every current use of multierrs.

Join with a user-provided separator, as in my original proposal. Simple and unopinionated, but out of step with common practice of formatting multierrs as a bulleted list. You can still join with "\n" for one error per line, which might be good enough.

Join with an opinionated separator. The Error text separates errors with ;  and %+v formats as a multi-line bulleted list.
I worry that this might conflict with using %+v to add stack information to errors in the future. (Proposed for 1.13; subsequently withdrawn, but perhaps we'll want to take another stab at it someday.)

Join with an opinionated separator, formatting as a multi-line bulleted list by default.
The argument in favor of this approach is that two out of three third-party implementations surveyed already do this, and glomming many errors into a single line is gets quite unreadable very quickly. I think I'm coming around to this being the right approach.

I don't have a strong opinion about the difference between 3 and 4. For bullet lists, I think the package would need to have an opinion about trees. For trees, adding an indentation per list layer (including length 0 and 1) seem reasonable. That or commit to one level of bullets for the left to right visit order of the leaves.
One way we could make String() being opinionated less risky is to have a clear alternative if you want a different format. Would wrapping in a custom error type if you want an alternative format be easy enough?

Musing...one downside to the multi-line w/ bullets formatting is that it doesn't nest well (without magic).
Consider errors.Join(errors.Join(errors.New("A"), errors.New("B")), errors.Join(errors.New("C"), errors.New("D"))). How should this format using e.g. "newlines+asterisk"? IIUC, it'd naively format as:
* * A
* B
* * C
* D

If it did have magic it would be easily defeatable by wrapping the inner list before adding it to the outer list.

Sampling of existing packages handling formatting of nested multierrs:
https://go.dev/play/p/7L2Ydp4-JdZ

I think Uber's behavior is because it doesn't plumb the %+v down into contained errors, so everything under the top level formats as ;-separated on a single line.

Looking at that dog's breakfast of outputs makes me think that the original Join proposal is the best of the lot. But I really don't feel strongly.

Several thoughts:

We should not expose the ability to specify the delimiter to Join.

We should choose something reasonable, whether it be ; or \n or even switching between the two based on whether the error is formatted with %v or %+v.
Allowing users to choose is just going to lead to more mess. One package uses ;, another uses \n, yet another ,. When I compose all of those errors together, the result is a big mess.

A potential use-case for decomposing an multi-error is with non-fatal JSON (or protobuf) deserialization.

In such an application there could be a number of non-fatal errors where the user wants to have as much of the unmarshal process to proceed, but to remember every non-fatal error (e.g., mismatching types, invalid UTF-8, etc.). Afterwards, the caller inspects the set of errors to do additional work.
This doesn't need to be solved using Split, but we definitely need a way to iterate through the errors in a multi-error. That JSON package could very well document that it is guaranteed to return a flattened list of errors such that a single call to errors.Split would return everything.

A gotcha with multi-errors is that is that errors.Is is ill-defined as whether it means exactly is or contains. The former checks that the multi-error has length==1 and that the element is the target error. The latter checks whether any element in the multi-error is the target error. It's a subtle difference, but has quite significant impact.

There used to be a multi-error package in google.golang.org/protobuf to hold non-fatal errors (e.g., invalid UTF-8, unpopulated required fields, etc.). However, we removed it because we found that it was easy to misuse.

Suppose someone wanted to ignore invalid UTF-8 errors, it would be tempting do something like:
switch err := proto.Unmarshal(b, &m); {
case errors.Is(err, proto.ErrInvalidUTF8):
    // ignore invalid UTF-8
case err != nil:
    return err
}
... // use m

the intent of the user is to ignore only invalid UTF-8, but to still reject other errors.

However, the seemingly innocent logic above is buggy if the error returned by proto.Unmarshal was errors.Join(proto.ErrInvalidUTF8, proto.ErrRequiredNotSet) as it would subtly ignore the presence of the proto.ErrRequiredNotSet error.

Regarding this issue, I don't have any good solutions. There are times when I would want errors.Is to mean "exactly is" and other times that I want it to mean "contains". Either semantic we choose, it's going to be footgun.

Regarding this issue, I don't have any good solutions. There are times when I would want errors.Is to mean "exactly is" and other times that I want it to mean "contains". Either semantic we choose, it's going to be footgun.

Perhaps we need a new errors.Has or errors.Contains to allow for the contains version and then specify that errors.Is is the exact error.  More choice of methods may be the solution.

Looking at that dog's breakfast of outputs makes me think that the original Join proposal is the best of the lot

I think the evidence here is that a bulleted list is not the right formatting option for the Error method. None of the implementations surveyed do a good job at all of formatting nested multierrs. (Uber comes the closest, by virtue of only applying the bulleted-list formatting to the outermost error.)
That leaves a user-provided delimiter (the original Join proposal) or a fixed delimiter.
How about "\n"? Semicolon-separated errors get unreadable quickly, and placing each error on a separate line gets most of the benefits of a bulleted list without the problems caused by nested indenting. Tree structure of nested errors gets lost, but
// Join returns an error that wraps the given errors.
// Any nil error values are discarded.
// The error formats as the text of the given errors, separated by newlines.
// Join returns nil if errs contains no non-nil values.

func Join(errs ...error) error

@josharian's last two test cases of nested errors using newlines as a separator:
https://go.dev/play/p/a7gHGrNst9-
https://go.dev/play/p/c1Y7GYwEAyj

How about "\n\

The issue with \n is programs needing to parse the log output being able to associate the lines together.

Programs parsing raw line-oriented log output are already going to have a bad time on any number of fronts. And there are proper fixes (structured output) and cheap hacks (a passthrough io.Writer that rewrites non-trailing \n to \n\t, or just using a standard logging prefix) to handle that.
Ironically, given that many people choose to log multi-errors individually, plain \n might make some systems easier.

3. A gotcha with multi-errors is that is that errors.Is is ill-defined as whether it means exactly is or contains.

That is an interesting point that didn't occur to me until now, but it also brings to mind what the semantics of errors.Is when the target is a multi-error.
isErr := errors.Is(errors.Join(err1, err2), errors.Join(err2, err3)) // ???

I realize this may not come up much in most code since the target is often a sentinel error value. I can imagine it possibly coming up in test code checking if returned errors are consistent across an API perhaps.
I suspect this isn't a big concern, but wanted to mention it in case anyone else has thoughts or concerns about it.

Updated proposal, incorporating the following changes:

Dropped Split.
Dropped the separator parameter from Join. Join uses "\n" as the separator.
If the slice of errors passed to Join contains exactly one non-nil error, Join returns that error.
Fixed specification of tree traversal performed by As to inorder, not preorder.

Proposal
An error wraps multiple errors if its type has the method
Unwrap() []error

Reusing the name Unwrap avoids ambiguity with the existing singular Unwrap method. Returning a 0-length list from Unwrap means the error doesn't wrap anything. Callers must not modify the list returned by Unwrap. The list returned by Unwrap must not contain any nil errors.
We replace the term "error chain" with "error tree".
The errors.Is and errors.As functions are updated to unwrap multiple errors. Is reports a match if any error in the tree matches. As finds the first matching error in an inorder traversal of the tree.
The errors.Join function provides a simple implementation of a multierr. It does not flatten errors.
// Join returns an error that wraps the given errors.
// Any nil error values are discarded.
// The error formats as the text of the given errors, separated by newlines.
// Join returns nil if errs contains no non-nil values.
// If errs contains exactly one non-nil error, Join returns that error.
func Join(errs ...error) error

The fmt.Errorf function permits multiple instances of the %w formatting verb.
The errors.Unwrap function is unaffected: It returns nil when called on an error with an Unwrap() []error method.
Questions
Prior proposals have been declined on the grounds that this functionality can be implemented outside the standard library, and there was no good single answer to several important questions.
Why should this be in the standard library?
This proposal adds something which cannot be provided outside the standard library: Direct support for error trees in errors.Is and errors.As. Existing combining errors operate by providing Is and As methods which inspect the contained errors, requiring each implementation to duplicate this logic, possibly in incompatible ways. This is best handled in errors.Is and errors.As, for the same reason those functions handle singular unwrapping.
In addition, this proposal provides a common method for the ecosystem to use to represent combined errors, permitting interoperation between third-party implementations.
How are multiple errors formatted?
The errors.Join function separates the text of the joined errors with newlines. The fmt.Errorf wraps multiple errors in a user-defined layout. If users have other formatting requirements, they can still create their own error implementations.
How do Is and As interact with combined errors?
Every major multierror package that I looked at (see "Prior art" below) implements the same behavior for Is and As: Is reports true if any error in the combined error matches, and As returns the first matching error. This proposal follows common practice.
Does creating a combined error flatten combined errors in the input?
The errors.Join function does not flatten errors. This is simple and comprehensible. Third-party packages can easily provide flattening if desired.
Why is there no function to unwrap a multiply-wrapped error?
While existing multierror implementations generally provide a mechanism for extracting the individual errors from a combined error, this functionality seems to be used infrequently in practice.
A package which wishes to provide a list of errors for the caller to iterate through should either return an explicit []error (which the caller may Join into a single error if needed), or a concrete type that wraps the contained errors. For example:
type ValidationErrors struct {
  Errs []error
}

func (e *ValidationErrors) Unwrap() []error { return e.Errs }
func (e *ValidationErrors) Error() string   { return errors.Join(e.Errs).Error() }

var ve *ValidationErrors
if errors.As(err, &ve) {
  for _, e :-= range ve.Errs { /* ... */ }
}

Returning a concrete type like ValidationErrors has the advantage of permitting iteration over the individual errors even if the multiply-wrapped error has been itself wrapped.

errors.Is doesn't unwrap the target today. That wouldn't change. This is important to keep the complexity of Is reasonably bounded.
So
errors.Is(errors.Join(err1, err2), errors.Join(err2, err3))

is false, because the target doesn't match either err1 or err2.

Fair enough. Exploring this a bit more, what about:
errj := errors.Join(err2, err3)
errors.Is(errors.Join(err1, errj), errj)

errj := errors.Join(err2, err3)
errors.Is(errors.Join(err1, errj), errj)

This case turns on whether errj == errj. If it does, then Is reports true.
My unwritten assumption has been that a joined error is equal to itself, and that the underlying type of the error returned by Join is something like *struct { errs []error }.

Why the change to an in-order traversal for As, and what does an in-order traversal mean here? It seems to me that since our error tree is not a binary tree a pre- or post-order traversal would be the more sensible way; either an error node or its children should have precedence over the other as there's no meaningful "left" or "right" child to have precedence. (I can see arguments for either pre-order or post-order; I'd lean towards pre-order as the toplevel error is closest to the caller and thus most likely to be meaningful.)

Does anyone have any objections to the most recent statement of the proposal in https://github.com/golang/go/issues/53435#issuecomment-1191752789?
I do tend to agree with @benjaminjkraft that I don't know what in-order means for, say, a node with 3 children. It seems like it should be either pre-order or post-order. @neild, thoughts?

Callers must not modify the list returned by Unwrap.

I think that should be in the contract, but also probably the standard implementation should make a defensive copy.

I do tend to agree with @benjaminjkraft that I don't know what in-order means for, say, a node with 3 children. It seems like it should be either pre-order or post-order. @neild, thoughts?

Yes, this should be pre-order. I was confused.

Programs parsing raw line-oriented log output are already going to have a bad time on any number of fronts. And there are proper fixes (structured output) and cheap hacks (a passthrough io.Writer that rewrites non-trailing \n to \n\t, or just using a standard logging prefix) to handle that.
Ironically, given that many people choose to log multi-errors individually, plain \n might make some systems easier.

Yes, they have problems. \n in output increases the problems, and structured logs and pass-through's don't always help. I've had programs before where parts of the program out of my control log out raw data that just dumps out information with \n, so parsing then required checking the line starts to try to associate the lines. It'd be best just to avoid it to start and push anything ending in a \n into a separate log entry or remove the \n. It's better to not create issues.

Adding this section into the latest version of the proposal:

How should existing multierror types adopt the new interface?
A goal is for existing multierror implementations to implement the common multiple-unwrap interface.
Most existing multierr implementations include Is and As methods on their error type which descend into each wrapped error. If such an implementation simply adds an Unwrap() []error method with no other changes, errors.Is and errors.As will examine the wrapped errors twice: Once when the custom Is or As method is called, and a second time when descending into the wrapped errors returned by Unwrap() []error.
To avoid this double-examination, multierr implementations which add support for Unwrap() error should use build constraints to define Is and As methods when built with older versions of Go, and an Unwrap() error method when built with newer ones.

Let's wait a little while for any comments to arrive via the pings on uber-go/multierr#64 and hashicorp/go-multierror#63, but things seem pretty positive about this.
@neild:

To avoid this double-examination, multierr implementations which add support for Unwrap() error should use build constraints to define Is and As methods when built with older versions of Go, and an Unwrap() error method when built with newer ones.

Do you mean Unwrap() []error in this sentence?

Do you mean Unwrap() []error in this sentence?

Yes.

Hello, thanks for the proposal, and thanks for the ping on https://github.com/uber-go/multierr/issues/64.
We support the Unwrap() []error method, and will include an implementation of it for whichever Go version this targets. We also really like the idea of multiple %ws supported in fmt.Errorf.
Our collective eyebrows are raised at the newline delimiter for errors.Join, but we don't see that as a major issue. That's probably what most users want at the presentation layer, and other implementations are still free to use something else.
Thanks!

I haven't red all the thread, only skimmed through the conversation. I would like to see this proposal being integrated into the standard library for various reasons. The most obvious one is that concatenating the errors with the "%w" fmt directive using errors.New() would solve the multi errors to string conversion problem, but the main issue I'm facing with the current approach is that when calling a function in a loop which should return an error or nil, in case of using this approach is quite tedious to return a nil error when there is no error. So the ideal solution would be to return a concatenated error string in case of multiple errors or nil in case there is no error. With errors.New() as far I know is not really possible.

// If errs contains exactly one non-nil error, Join returns that error.

I've been thinking about this case, and I now think it's a mistake. Join should consistently return an error with an Unwrap() []error method.

Returning different types based on the number of wrapped errors makes it more likely that one case goes untested.
There's a meaningful semantic difference between "err" and "a list of errors containing only err".
The efficiency win from avoiding an allocation in this path is small.

I've been thinking about this case, and I now think it's a mistake. Join should consistently return an error with an Unwrap() []error method.

Returning different types based on the number of wrapped errors makes it more likely that one case goes untested.
There's a meaningful semantic difference between "err" and "a list of errors containing only err".
The efficiency win from avoiding an allocation in this path is small.

Are we sure that we need the guarantee that the returned error must implement Unwrap() []error?
errors.Join already states that the returned value may be nil, so there's already an expectation to check the result.
Is it too much of a stretch from that to say that the returned error may implement Unwrap() []error, but you have to check?
That aligns with how other upcasting-based API contracts work—there's never a guarantee.
Users that want to access the individual errors will likely want a function like the following that operates on any error, not just those returned by errors.Join, so they'll have to account for the possibility that it does not implement the method.
func unwrapErrors(err error) []error {
  if merr, ok := err.(interface{ Unwrap() []error }); ok {
    return slices.Copy(merr.Unwrap())
  }
  return []error{err}
}

Are we sure that we need the guarantee that the returned error must implement Unwrap() []error?
errors.Join already states that the returned value may be nil, so there's already an expectation to check the result.
Is it too much of a stretch from that to say that the returned error may implement Unwrap() []error, but you have to check?
That aligns with how other upcasting-based API contracts work—there's never a guarantee.

for a standard library type why should we impose the extra burden of checking the interface? The Error interface should be fully implemented; this should especially be the case for Error types.

for a standard library type why should we impose the extra burden of checking the interface? The Error interface should be fully implemented; this should especially be the case for Error types.

I'm sorry, @BenjamenMeyer , I may be misunderstanding this comment. Could you clarify what you mean by the interface being fully implemented?
I also want to state that my last comment is only about the return value of errors.Join.
My suggestion is that the returned error by errors.Join may implement the Unwrap() []error method but does not have to—depending on how many non-nil errors were provided to it.
This is similar to how the error returned by fmt.Errorf may implement Unwrap() error, Unwrap() []error, or neither depending on how many %ws were present in the template string.
fmt.Errorf("foo: %w", err)                 // implements Unwrap() error
fmt.Errorf("foo: %w, bar: %w", err1, err2) // implements Unwrap() []error
fmt.Errorf("foo: %v", err)                 // implements neither

errors.Join(nil)        // == nil, implements nothing
errors.Join(err)        // == err
errors.Join(err1, err2) // implements Unwrap() []error

I'm suggesting that because the advantage of changing that is not clear to me from the discussion above.
@neild suggested three reasons:

Returning different types based on the number of wrapped errors makes it more likely that one case goes untested.
There's a meaningful semantic difference between "err" and "a list of errors containing only err".
The efficiency win from avoiding an allocation in this path is small.

(The third one is less a reason to do this, and more a reason why we can do this, so I'll skip that.)
For the first one, I don't think we actually get additional safety from making this change.
The change will not enable, say, unchecked type casts of returned errors because of how the errors are intended to be used.
Functions will normally return joined errors to their callers, with some code paths returning plain errors.
So callers still need to match on the interface if they want to access individual errors directly.
E.g. given,
func foo(name string) (err error) {
  f, err := os.Open(name, ...)
  if err != nil {
    return err
  }
  defer func() {
    err = errors.Join(err, f.Close())
  }()

  // Errors returned from this point onwards are wrapped in errors.Join.
  ...
}

Callers of foo() cannot assume that the returned error implements Unwrap() []error because if os.Open failed, it's a plain error.
@neild, maybe there's something more to this point you made. Would you mind elaborating on this?

There's a meaningful semantic difference between "err" and "a list of errors containing only err".

for a standard library type why should we impose the extra burden of checking the interface? The Error interface should be fully implemented; this should especially be the case for Error types.

I'm sorry, @BenjamenMeyer , I may be misunderstanding this comment. Could you clarify what you mean by the interface being fully implemented?

If the interface of Error includes Unwrap() []error then anything returning error should be returning something that complies with the Error interface. We shouldn't be guessing what is provided and what isn't especially for standard library defined types.
Now if someone is implementing a new error type, f.e MyNewErrorType, that should implement the standard library Error interface and anything they want to add so that it is still compliant with error.
Now if it returns nil then that's still valid - it's a non-object.  Honestly, fmt.Errorf() should also only return error values that fully define the Error interface.

Various discussion here over the last two weeks, but I don't see any objections to accepting this proposal. Do I have that right? Does anyone object to the proposal?

What is the final version of the proposal though?
@neild said

// If errs contains exactly one non-nil error, Join returns that error.

I've been thinking about this case, and I now think it's a mistake. Join should consistently return an error with an Unwrap() []error method.

But the proposal still states the "maybe mistake" as the chosen path.
Separately, @neild would you consider capturing all the weird cases like errj := errors.Join(err2, err3); errors.Is(errors.Join(err1, errj), errj)==? discussed throughout in the comments as part of the proposal itself? It might make it easier to grok from a single place.

Updated proposal (https://github.com/golang/go/issues/53435#issuecomment-1191752789) to restore the original behavior of Join, dropping the line "If errs contains exactly one non-nil error, Join returns that error".
I'm not certain what weird cases need further explanation; we could explicitly state that the error returned by Join is equal to itself, but that seems like a sine qua non to me.

Here is a possible objection: if someone writes a library that returns a type with Unwrap() []error and then a user on an old version of Go imports the library, it will just silently fail errors.Is/As checks instead of failing loudly. Maybe a check should be back ported to the prior version when this comes out.

@carlmjohnson Some thoughts. The program would fail to compile with old Go versions if errors.{Join,Split}  is used.  So adding var _ error = errors.Join("") in the package declaring Unwrap() []error would guard against this. Seems like kinda bad advice though. We might be able to add a vet check to look for Unwrap() []error methods declared in a package with a go.mod go directive with a version that is too old.

Updated proposal (#53435 (comment))

Thanks for updating, @neild.
No objections from uber-go/multierr on this version of the proposal.

Re @carlmjohnson it's unclear what we can do except caution people about rollout. Tim's var _ = errors.Join (no need to call it and cause runtime overhead) would be fine for people who want to be extra cautious. I don't see how to do a vet check with sufficient precision, since it won't bother the majority of people, and a go.mod in a dependency is allowed to be newer than the toolchain. (Also the older toolchain won't have the vet check.)
It doesn't sound like there are any other objections, so moving this to likely accept.

The number of multierror libraries is smaller than the number of multierror users, so telling libraries to include _ = errors.Join if they aren't backwards compatible seems fine.

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

The errors.Unwrap function is unaffected: It returns nil when called on an error with an Unwrap() []error method.

Can errors.Unwrap be changed to return the next error in the chain, which when called with errors.Unwrap again returns the next error in the chain (and so on and so forth)? I'm not comfortable with how there are two Unwrap interfaces to implement but errors.Unwrap only respects one.
interface{ Unwrap() error }   // <-- errors.Unwrap returns the wrapped error.
interface{ Unwrap() []error } // <-- errors.Unwrap returns nil, potentially confusing.

Instead, errors.Unwrap could flatten an error tree into a chain and return each error in order as errors.Unwrap repeatedly gets called on it. That way it could serve as the iterator API as well.

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

I was sort of surprised looking at the errors.Join documentation that it is not mentioned that the returned error implements the Unwrap() []error method. In the absence of the errors.Split function, this method has significantly reduced discoverability. Making it more discoverable would ease the issue of how to format multiple errors — at least in this case — for different use cases because it would become obvious to users that there was an easy path from the returned value of errors.Join to a []error that they could format as they wish.
The addition would not need to be more than "A non-nil error returned by Join implements the Unwrap() []error method.".

https://github.com/goware/superr might be interesting to some

Multiple error wrapping will be in 1.20.

it's really sad, I have no understanding why you need it.
just will complicate the apps a lot and make people use it in a weird way because we are not smart in general.

I probably missed it simply, but is errors.Join concurrency-safe?

I probably missed it simply, but is errors.Join concurrency-safe?

Yes, see https://go-review.googlesource.com/c/go/+/432898/11/src/errors/join.go

Looks great and can't wait to apply it to engineering!

Referring to bokwoon95 https://github.com/golang/go/issues/53435#issuecomment-1250206592

interface{ Unwrap() []error } // <-- errors.Unwrap returns nil, potentially confusing.

and kortschak https://github.com/golang/go/issues/53435#issuecomment-1287964610

I was sort of surprised looking at the errors.Join documentation that it is not mentioned that the returned error implements the Unwrap() []error method. In the absence of the errors.Split function, this method has significantly reduced discoverability.

This muliterror feature is incomplete, because I am required to make err.(interface{ Unwrap() []error }) checks myself to call Unwrap() []error explicitly to get and handle multiple errors. Split(error) []error func, that return a slice of errors for both regular single error and multierror cases would help here.

@dimandzhi This issue is closed. I created #65428 as a new issue for follow up. You can propose new ideas there.

@ChristoWolf

I probably missed it simply, but is errors.Join concurrency-safe?

I'm late to the party, but see https://tip.golang.org/doc/comment#func:

By default, programmers can assume that a top-level function is safe to call from multiple goroutines; this fact need not be stated explicitly.


I installed the windows version by cnapy-installer.exe but the CNApy icon wasn't created

Hello,
someone could help me? I can't use the app on windows cause the CNApy icon wasn't created after installation process.
(I'm not from computer science and my coding skills are bad, sorry if this issue was ridiculous)
Help the newbie :)
thanks

Hello! That's not a ridiculous issue, actually, creating a bug-free Windows .exe installer is one of our main problems xD and every message about problems with it helps us :-) Regarding your issue, I just tried the installer on my computer and it worked fine :3, so that answering the following questions would greatly help us in investigating the problem:

Did you see the message that CNApy was successfully installed at the end of the installation process?
Did you give the installer elevated (administrator-like) rights at the beginning? In other works, did you click on "Yes" when WIndows asked if you are ok with "severe" hard drive writing rights?
Can you search, in the folder where you installed CNApy (usually a subfolder called "CNApy" at your selected location), for a "cnapy.exe"? If it exists, you should be able to start CNApy by double-clicking on it.

Hello, thank for replying !
So, lets me see:

Yes, I saw the message 'CNApy was successfully installed" and the follow steps.
I tried it too.. But unfortunately the same issue occur.
So, it's the key point for my issue. The CNAPy.exe wasn't created. When I look inside of the CNApy folder I see only:

cnapy-uninstaller.exe
miniconda folder

I have been trying to install in different folders on my pc but every time the same issue occurs. The .exe doens't exist.
check my gif for the installation process.

thank you for your attention

Hello again and thank you for your extensive and helpful answer! Regarding point number 3, could you check whether maybe a "cnapy.exe" or at least a "cnapy" subfolder is inside of the "miniconda" folder (just by searching it with the file explorer)? Then I could deduce whether or not the conda package itself may have a problem :3

Hello
I tried to find CNAPY.exe in miniconda folder (and subfolders) but didn't work. The cnapy.exe doesn't exist in any folder.
Here the print of miniconda folder.

Hello again! Your answer helps me a lot at it looks like, strangely, Miniconda wasn't installed correctly on your device (there are some missing folders and files such as the important "condabin" subfolder). To investigate this problem, and if you have time, I would ask you to install Miniconda and cnapy "by hand". You can do it as follows:

Download the latest Miniconda from https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe
Run it and follow the installation instructions while remembering where you installed it. If you've already installed Python on your system and you want to avoid confusion with it, just deactivate all settings which state that Miniconda would added to the system's PATH.

Additionally, to install cnapy easily, I created a small .bat (Windows console) script which tries to install the cnapy conda package directly using your new Miniconda installation. It is added as an attachment to this message in a zipped form. To run it, do the follwing:

Download the zip zInstallCnapy.zip by clicking here
Unzip the zip file
Copy the resulting unzipped "zInstallCnapy.bat" file into the "condabin" subfolder of your new Miniconda installation
Double-click on "zInstallCnapy.bat"
Hopefully, you don't see any error messages (if this happens, please post them here) and CNApy should be successfully installed

Hello Paulo,
I did all steps and happily everything worked!
Now I can invest my time learning how to use it in metabolic engineering/FBA etcs.
I saw that your team developed the StrainDesign package and I think the next step is to learn how I can integrate these two.
I'm so grateful with your help.
Thanks a lot.
best regards

Hello!
I'm glad that the installation protocol worked successfully. Maybe we'll abolish the current installer and just provide this alternative assisted installation route :3
Regarding StrainDesign, its GUI can be found in the "Analysis" menu entry under "Computational Strain Design"->"Compute Strain Designs...". StrainDesign's documentation is available here, although it is currently written only in its Python package form. However, you can translate and save nearly all examples using the assistance of the StrainDesign GUI in CNApy.
Since your installation worked well, I'll close this issue but if you have any further issues or questions you are of course free to do any of writing an issue, using our Gitter chat room or using the CNApy GitHub discussions :-) And have fun in the world of constraint-based metabolic engineering :D


Fancy Zones Calibration

Microsoft PowerToys version
0.81.1
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
FancyZones Editor
Steps to reproduce
In the zone editor when setting the space around the zones to 0 pixels
✔ Expected Behavior
There should not be any pixels around the windows when using another window. The window should cover all the available space
❌ Actual Behavior
Since you are not using the window, there is a line of a single pixel wide around it.
Other Software
No response

/dup https://github.com/microsoft/PowerToys/issues/25220


interop / move dom related collections into separate repo?

Regarding this file: https://github.com/styled-components/styled-components/blob/master/src/utils/domElements.js
And perhaps others. This stuff creeps up plenty depending on which libs are bundled in. For instance it's almost the same in react-spring: https://github.com/drcmda/react-spring/blob/master/src/animated/targets/react-dom.js and here's some of it in animated: https://github.com/animatedjs/animated/blob/master/src/targets/react-dom.js
There's also normalize-css-color, https://github.com/react-community/normalize-css-color/blob/master/index.js Not sure if styled-components has a use for it.
But anyway, would it make sense to have one sensible, modular repo for this stuff so that knowledge, spec-updates, etc. could be shared while also relieving bundles a bit?

So we're actually working on a few strategies to drop those various lists in the next major version.

dom element list will be droppable once https://github.com/styled-components/babel-plugin-styled-components/issues/125 is in
the attribute whitelist will be droppable once this is in: https://github.com/styled-components/styled-components/pull/1682

normalize-css-color looks cool, but I don't think we have a need for it, at least on the web side. Maybe for native @kitten?


row-class function is triggered every time after closing the modal

@ratiw I met a problem.
I have a vue table on the main screen, then if click the action button,a modal will be shown.
Every time I close the modal, the row-class function is triggered. I am wondering that because the data haven't been changed the vuetable should not be re-rendered. Am I right? Or Am I missing something?

You're right. This has nothing to do with the modal at all (eventhough I have no idea what kind of modal you've implemented). It sounds more like the reactivity issue. Did you reference anything inside the row-class function?

@ratiw Yes. I referenced the row data and return different classes. But even though I comment out all the source code in this function, it still was called. I need to check whether somewhere is changing the data in my source code. I will keep you posted.


Documentation is sometimes inconsistent

Hi,
Trying to setup configuration client via consul discovery. Found out the service id tag should be spring.cloud.config.discovery.service-id and not spring.cloud.config.discovery.serviceId as written under: http://cloud.spring.io/spring-cloud-static/spring-cloud.html#discovery-first-bootstrap.

Would be nice to get a correction!
Regards,
Kelassar

They both should work


Refine keyring api

This is work to specify a desired API related to issue #302
So far, I just have a first draft in https://github.com/iov-one/iov-core/blob/refine-keyring-api/packages/iov-keycontrol/src/proposal.ts
Please add comments, or make another PR if there are large changes, to better demonstrate with code.

I like most of "Represent bip44 as wrapper over bip32 functionality".
One thing I noticed: if our "bip32" implementation supports curves other than secp256k1 it should be called "slip10", which is a superset of bip32.
Separation would be even better if the bip44 code is only responsible to create paths to be used, e.g.
const path = bip44path(hardened(1), hardened(2), 0, 4); // user input
const identity = entry.createSlip10Identity(path);
const nextPath = bip44IncrementAddress(identity.path);
// nextPath is now 44', 1', 2', 0, 5
const nextIdentity = entry.createSlip10Identity(nextPath);

This is made obsolete from all the other refactoring in the 0.7.0 release


📦 Workbox > v4.3.1

Hey @liyasthomas,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 3ca67210-7fda-11e9-a8ca-1f101d92bd96

Hey @liyasthomas,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 48dafce0-7fda-11e9-a8ca-1f101d92bd96


Which code formatters do you use?

Which code formatters do you use?
I am so sorry, but I can't find this information from this repository.

ESLint style rules.

So it's a linter, not a formatter.

Yes.

ESLint style rules.

Yes.

So it's a linter, not a formatter.

Yes.

Physically, how do you edit files? What's under the hood?

VS Code's fix all on save infrastructure.

VS Code's fix all on save infrastructure.

That is, it does the plugin format eslint rules into the rules of the regular vscode formatter? And Vscod has own formatter?


How the lidar detected trajectory is generated?

Hi,
Are bounding box detector part and lidar trajectory generation part included in this repo? I want to have a look at it for reference. it would be very grateful if you could upload them.
Thank you!!

box detector has been added. Trajectory generation with tracking is documented in the paper.


Support for Screenplay-style explicit and fluent wait

Hi,
I Loved the concept of Screenplay pattern. I would love to learn this. Concept is clear.
But I'm new to Automation with Javascript. Used serenity in the past with Java. I'm wondering if there is a boilerplate available for javascript/serenityjs(Screenplay pattern)/protractor combination.
Waiting to see a boilerplate using javascript :)
Thanks in Advance
Regards
Srini

Kindly let me if this is not a relevant area for this query as this is not a real issue. I can close this if required

Hey @srinivasbudh and thank you for your kind words and your interest in Serenity/JS :-)
The best way to get started with Serenity/JS is to go through the tutorials.
If you want to just have a look at a finished implementation of some example projects, you can head to  the serenity-js-getting-started, which is the project you'd be working on as part of the tutorial, and check out the branch called 2-reports.
There's also an example implementation located in the examples folder of this repository, which you might find useful.
Does this answer your question?
Best,
Jan

Hey @jan-molak,
Thanks for your response. Yes I have gone through the implementation using your tutorials. In fact I have implemented 2-reports branch using your tutorials.
I was looking for a project which would use .js files rather than .ts files for step definition. Is this possible for implementation??
Reason I am asking this is Few of the protractor commands I tried executing are not compilable in .ts files.
Example: browser.waitForCondition(.....)
Thanks
Srini

Ah, I see. TypeScript is a superset of JavaScript, so technically speaking, any code that's valid JavaScript should work when defined in a .ts file.
What I guess might be happening in your case might not necessarily be due to JavaScript/TypeScript problem. What it feels like is that browser.waitForCondition(.....) does not get synchronised correctly with the rest of the flow due to how webdriver-js handles promises using what they call the ControlFlow, which although interesting, is a webdriver-specific, non-standard way of handling asynchronous operations.
In order to resolve this problem Serenity/JS needs to provide a Task centred around waiting for things to happen, effectively wrapping the browser.waitForCondition(.....) and converting it to a standard JS Promise, so that it can be chained with other tasks.
Is that's what you think might help?
Would you mind giving me an example of what is that you'd like the test scenario to wait for in your case (I might just prioritise it over other "waits" I need to implement ;-) ).

That's good to see a response, so quick.
In my case I am using Protractor with a non-angular application my UI is designed in reactJS. So I can't use waitForAngular for the page to load.
When I navigate in between pages (example: gmail) It's easy to land on login page, However After login it might take few seconds(1-10 depending on the speed of internet) for the inbox to be displayed. In this case I want to make my code to wait till it find the compose button(may be with a time limit of 10 seconds).
I assume this wait can be handled using Explicit wait, which is throwing compilation error on this files.

Hey @srinivasbudh,
The latest version of Serenity/JS should support your use case.
Please have a look at the spec/cookbook/waiting.recipe.ts
There are two ways you can wait for things to happen:

Using PassiveWait (an equivalent of browser.sleep() in Protractor):

actor.attemptsTo(
  Wait.for(Duration.ofMillis(500)),        // *assumes* that the button will show up during 500ms
  Click.on(InboxNavigation.Compose_Button)
)

Using ActiveWait (waiting up to some timeout, polling the page repeatedly to check if the condition is met):

actor.attemptsTo(
  Wait.until(InboxNavigation.Compose_Button, Is.clickable()),
  Click.on(InboxNavigation.Compose_Button)
)

You can also specify the maximum timeout:
actor.attemptsTo(
  Wait.upTo(Duration.seconds(10)).until(InboxNavigation.Compose_Button, Is.clickable()),
  Click.on(InboxNavigation.Compose_Button)
)

I hope that this helps you solve your problem! Please let me know how you're getting on with this new feature :-)
Best,
Jan

Hi,
This Looks great I was looking for a similar solution, However this is not working when I tried Implementing it. Duration.seconds(10) gives me a error sating  second is not a parameter. Tried using Duration.ofSeconds(60), Which is not throwing any error but Not Waiting for the element to be displayed and not throwing an error when locator is not available.
Wait.upTo(Duration.ofSeconds(10)).until(InboxNavigation.Compose_Button, Is.clickable())

Sorry to hear that, would you be able to come up with a minimal test case to reproduce the issue?

Not had a look into the latest serenity recipes yet, but isn't the protractor 'way' to use expected conditions?
I've had success in the past with:
browser.wait(protractor.ExpectedConditions.and(
protractor.ExpectedConditions.visibilityOf(element()),
protractor.ExpectedConditions.elementToBeClickable(element())
)

@jan-molak : This is working fine as expected Using it in my current project,I assume initially something went wrong with npm install. Now I'm able to use both active and passive waits.
Thanks a ton for your help.

@nbarrett : Yes, Protractor can handle this, I was also using something similar to handle this.
However we cant call below function inside performAs of any task as this not a user task. so this solution will help
export function WaitForElementToBeDisplayed(webElement, browser) {
    return browser.wait(function () {
        return browser.isElementPresent(webElement);
    }, 55000).then(isElementStable(webElement,browser));
}

function isElementStable(webElement,browser){
    var isStable = false;
    var count = 0;
    var elementLocation=webElement.getLocation();
    var initTop= elementLocation.y;
    var initLeft=elementLocation.x;
        while (!isStable) {
            if (initTop == webElement.getLocation().y
                && initLeft == webElement.getLocation().x) {
                count++;
            } else {
                count = 0;
                 initTop= elementLocation.y;
                 initLeft=elementLocation.x;

            }

            if (count == 10) {
                console.log('This Element is stable');
                isStable = true;
            }

            try {
                // sleep for 100ms to give page a little time
                browser.sleep(15);
            } catch (err) {
            }
        }

}

@nbarrett : isElementStable() method will avoid stale element exception

Hmm, I'd always avoid browser.sleep() as it's a generally recipe for unreliability. I've also never had to resort to verifying an element's stability by reference to it's x/y location as there are probably  more conventional ways to overcome StaleElementReferenceException as discussed here


Longest Common Substring length in C++

I have made the required changes, and added longest common substring length in C


Standard Hashtags in Template

I use
[ap_hashtags]
 and like to add some standard hashtags for Mastodon in that template. I tried with
[ap_hashtags]#dnd #pnpde
 but the manually added tags rendered as hashtags in Mastodon (not linked, not found via search). Here's a working example using that template: https://mastodon.pnpde.social/<EMAIL_ADDRESS>Not sure if it's a bug or a feature request.
Here's my full template:

[ap_title]

[ap_content]

[ap_permalink]

[ap_hashtags] #dnd #pnpde

FYI: https://github.com/Automattic/wordpress-activitypub/issues/283


Source Control fails to launch - "The window is not responding"

Issue Type: Bug
Clicking on the source control icon does not enable access to my git repository.

Has been working for months w/o issue until now
Git works from command line per normal
Functions as normal with other projects/repositories
Otherwise, everything appears to work as normal

VS Code version: Code 1.66.2 (Universal) (dfd34e8260c270da74b5c2d86d61aee4b6d56977, 2022-04-11T07:49:20.994Z)
OS version: Darwin x64 21.4.0
Restricted Mode: No
Remote OS version: Linux x64 4.14.232-176.381.amzn2.x86_64
Connection to 'SSH: dev4-aws-teleport' could not be established  Canceled
Remote OS version: Linux x64 4.14.232-176.381.amzn2.x86_64

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
4, 3, 2

Memory (System)
16.00GB (1.65GB free)

Process Argv
--crash-reporter-id 2e91b11f-3a6a-410b-b2b9-dcfd2e9d0347

Screen Reader
no

VM
0%

Item
Value

Remote
SSH: dev4-aws-teleport

OS
Linux x64 4.14.232-176.381.amzn2.x86_64

CPUs
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (8 x 1293)

Memory (System)
30.96GB (0.80GB free)

VM
0%

Connection to 'SSH: dev4-aws-teleport' could not be established  Canceled

Item
Value

Remote
SSH: dev4-aws-teleport

OS
Linux x64 4.14.232-176.381.amzn2.x86_64

CPUs
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (8 x 1293)

Memory (System)
30.96GB (0.80GB free)

VM
0%

Extensions (26)

Extension
Author (truncated)
Version

Bookmarks
ale
13.2.4

remote-containers
ms-
0.231.6

remote-ssh
ms-
0.78.0

remote-ssh-edit
ms-
0.80.0

remote-wsl
ms-
0.66.0

vscode-remote-extensionpack
ms-
0.21.0

material-icon-theme
PKi
4.16.0

vue-vscode-snippets
sdr
3.1.1

thoroughbred-basic
Kev
0.0.1

bootstrap4-vscode
the
6.1.0

vscode-icons
vsc
11.11.0

JavaScriptSnippets
xab
1.8.0

npm-intellisense
chr
1.4.1

vscode-eslint
dba
2.2.3

githistory
don
0.6.19

xml
Dot
2.5.1

gitlens
eam
12.0.6

prettier-vscode
esb
9.5.0

php-intellisense
fel
2.3.14

git-graph
mhu
1.30.0

vsliveshare
ms-
1.0.5527

printcode
nob
3.0.0

markdown-preview-enhanced
shd
0.6.2

tbred-basic-help
und
0.0.1

vscode-jumpy
wma
0.3.1

markdown-all-in-one
yzh
3.4.2

(1 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebug:30475216
vscaat:30438848

Same problem here, has anyone found a workaround?

In case you are still able to reproduce the issue, could you please follow the steps from the wiki to collect the necessary telemetry. Thank you very much in advance!

@lszomoru This is not a Performance Issue.  It is a VS-Code-goes-completely-unresponsive-on-startup issue.  All extensions are disabled so nothing at your Performance Issues wiki page seems achievable (as the particular VS Code window has already gone unresponsive when this happens) or seemingly relevant.

@deepak1556, is there anything that we can collect to track down the root cause of the problem? Thanks!

It help us debug this issue further, please follow the steps from https://github.com/microsoft/vscode/issues/157752#issuecomment-1240725164 and attach the generated profile in this issue. Thanks!

Ahhh.  I was more patient this time and indeed, after a period of unresponsiveness after selecting the source-control plugin, during which time the dialog does pop up, if I actually do click Keep Waiting, and do wait a while, Code returns from the freeze.  Let me see if I can reproduce this with the steps from https://github.com/microsoft/vscode/issues/157752#issuecomment-1240725164 and attach the profile.

Hey @deepak1556 @lszomoru, this issue might need further attention.
@MontyMunro, you can help us out by closing this issue if the problem no longer exists, or adding more information.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


fix bug 471: fixture does not compile under java7

Currently master does not build under java7.

Seems there were more problems then just the test fixture compilation. Will investigate.

https://github.com/mirah/mirah/pull/430 have to be merged prior this. Done


Consul systemd.service typo

In https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/consul.nix it says:
181         serviceConfig = {
182           ExecStart =<EMAIL_ADDRESS>consul agent -config-di    r /etc/consul.d"

note the extra consul in the command
This is in both master and release-19.09.
I will post a PR for master in a minute, don't know you guys do backports to release(s).
Maintainer information:
# a list of nixos modules affected by the problem
module: consul

INVALID, please ignore


Use highp precision in the gles2 fragment shader if available

This fixes #28199.
The problem was, that the custom shader code (uniforms starting with m_; added via ShaderCompilerGLES2) did not have explicit precision types set, so the default ones for the fragmant shader (mediump) were used while the vertex used highp.
The specs say, that uniforms should have the same precision.
See the specs (4.5.3 Default Precision Qualifiers):
https://www.khronos.org/registry/OpenGL/specs/es/2.0/GLSL_ES_Specification_1.00.pdf
This fix uses highp for the fragment shader by default (if available).
Another possiblity which also works whould be to set the default precision in the vertex shader to mediump for ints and floats.

We discussed this on IRC, and reduz is concerned about the performance impact on mobile if we default to high precision always. The issue with this fix is that all calculations in fragment shaders are going to use highp by default. Most users don't specify precision for each variable, so everyone's projects will take a big performance hit (on mobile the speed difference between highp and mediump can be huge).
While this does correctly fix the bug, I think a better fix can be found. We need to make it so that all uniforms are specified highp by default, but all others are not (they would use default value). This will likely take some tinkering in https://github.com/godotengine/godot/blob/master/drivers/gles2/shader_gles2.cpp
Reduz on IRC:

When you write a shader, on desktop, everything should be high precision by default, both on GLES2 and GLES3. On mobile, vertex program should be high precision by default and fragment program should be mediump, because performance on mobile is limited and because many devices don't even support highp properly

Let me know if you have any questions/need any help!

Yes, that was what i was worried about as well. We could explicitly set appropriate uniforms to highp (if not already set by the user) and leave the shaders unchanged.
I'm gonna have a look at this over the weekend. Thanks for the feedback!

@clayjohn
Now, only uniforms have a default precision of highp. Users can still change it though if they expliclity set precision values for uniforms.

Yes, i tested it on android emulators with API levels 18, 25 and 28. All of them were affected by the issue and they work now.

Thanks!

Note to release maintainers: if/when cherrpicking this PR, #30331 should be included too.

Cherry-picked for 3.1.2.


use null prototype instead of additional check

Followup on https://github.com/luin/ioredis/pull/1416, this is a more efficient way of fixing the issue by creating a object that does not inherit anything.

Stricly speaking this is an incompatible change as null objects behave slightly different then "regular" objects in some regards, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create#custom_and_null_objects.


Replaced FutureLearn pre-calculus with Khan Academy

To be more consistent with our Khan Academy recommendation elsewhere in the curriculum
also some students expressed confusion with the FutureLearn course
also added link to interactive exercises of Kurose-Ross textbook website for Intro to Networking, because many people have been asking

(we might want to use these as the default assignments and remove the other 4 maybe? They have Wireshark Labs here and they are in the process of adding lecture videos for a Fall 2020 course here, hopefully it will turn into a full fledged online course because Lagunita is gone)

It would be great to see a full course!
Assignment 4 in the OSSU curriculum is the TCP Wireshark lab from Kurose-Ross.

@waciumawanjohi I don't really support this idea of replacing the Future learn's course with Khan Academy. I believe the reasoning for this change was that FutureLearn charges for certificates and exams. Whilst this is true, Khan academy has neither i.e. neither an exam nor a certificate.  In fact, apart from the videos, there is no testing of the concepts learned whatsoever.
Is this change effected only on comparisons of technical & pedagogical merits of the two courses?


Data corrupt when submit form

I'm have simple entity:
public class PostModel
{
    [Key]
    public int Id { get; set; }

    public string Caption { get; set; }

    public string Body { get; set; }

    [DatabaseGenerated(DatabaseGeneratedOption.Computed)]
    public DateTime? CreateDate { get; set; }

    public ICollection<TagModel> Tags { get; set; }
}

... and controller
[Authorize]
public class PostController : Controller
{
    private readonly SiteDbContext db;
    public PostController(SiteDbContext context)
    {
        db = context;
    }

    // GET: /<controller>/
    public IActionResult Index()
    {
        return View();
    }

    // GET: /Post/Edit/1
    [HttpGet]
    public IActionResult Edit(int PostId)
    {
        var post = db.Posts.Any(p => p.Id == PostId) ? db.Posts.First(p => p.Id == PostId) : new PostModel();

        return View(post);
    }

    // POST: /Post/Edit/1
    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Edit(PostModel model)
    {
        if (ModelState.IsValid)
        {
            db.Entry(model).State = Microsoft.Data.Entity.EntityState.Modified;

            await db.SaveChangesAsync();

            return RedirectToAction("Edit", new { PostId = model.Id });
        }

        return View(model);
    }

}

When I request a page by route /post/edit?postid=5, the correct form is generated.
When I confirm the form field Id receives an incorrect value (model.Id == 2)
But if I modify action to
public async Task Edit([FromForm]PostModel model)
all work fine

please add details of your configured template routes and the view.  in addition, is model.Id == 2 at a breakpoint in the action (versus when displayed in the view, which would imply the ModelState contains unexpected values)?
separately we've fixed a few bugs in model binding lately.  which exact version of MVC are you using  i.e. which DNX feed is configured and what does your project.json contain?

project.json
"dependencies": {
"Microsoft.AspNet.Server.IIS": "1.0.0-beta5-",
"Microsoft.AspNet.Hosting": "1.0.0-beta5-",
"Microsoft.AspNet.Mvc": "6.0.0-beta5-",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta5-",
"Microsoft.AspNet.Diagnostics": "1.0.0-beta5-",
"Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta5-",
"Microsoft.AspNet.Identity": "3.0.0-beta5-",
"Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta5-",
"Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta5-",
"Microsoft.AspNet.Session": "1.0.0-beta5-",
"Microsoft.AspNet.StaticFiles": "1.0.0-beta5-",
"EntityFramework.SqlServer": "7.0.0-beta5-",
"EntityFramework.Commands": "7.0.0-beta5-",
"Microsoft.Framework.ConfigurationModel.Json": "1.0.0-beta5-",
"Microsoft.Framework.OptionsModel": "1.0.0-beta5-",
"Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta5-",
"Microsoft.Framework.Cache.Distributed": "1.0.0-beta4-",
"Microsoft.Framework.Logging.Console": "1.0.0-beta5-"
}
Microsoft.AspNet.Mvc version 6.0.0-beta5-13474
dnx-clr-win-x<IP_ADDRESS>-beta5-11427
VS2015 CTP6, Windows 10 Pro 10049, Chrome 41.0.2272.118.
Routes:
.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller}/{action}/{id?}",
defaults: new { controller = "Page", action = "Index", id = 2 },
constraints: new { id = @"\d+" }
);
               routes.MapRoute(
                     name: "defaultWithoutAction",
                     template: "{controller}/{id?}",
                     defaults: new { action = "Index" },
                     constraints: new { id = @"\d+" }
                   );
           });

The value of id is available in both the request body and the route named default (the default value for id there is 2)...in this case looks like the one on the route is being used.
In case of FromForm you are explicitly asking to only bound data from the request body form and hence you are seeing the desired behavior.

Now understood . thank a lot!


refactor brsa_keypair_generate() to fail early if sk or pk are NULL

This PR refactors brsa_keypair_generate() to return 0 earlier if sk or pk are NULL as they are assumed to be not null in the assignments on L156-158
    sk->evp_pkey = NULL;
    pk->evp_pkey = NULL;
    pk->mont_ctx = NULL;

The null check on L184 is then removed to avoid deadcode.

The intent is to make pk optional, as the public key can be recovered later if needed.
sk, on the other hand, cannot be NULL, as declared in the function prototype.
e891bfb should fix it.
Thanks for noticing this!


Fix unstable dependency on swift-checkit.

Hey there!
In your swift package, you have what SwiftPM classifies as an "unstable version" on the swift-checkit dependency. SwiftPM is exceptionally strict on versioning requirements of packages that hold dependencies of packages that have "unstable versions".
The main issue with this, is that it disallows any Swift package which includes your dependency from being able to tag a release version on their own packages, with a SwiftPM error in the form of:
error: Dependencies could not be resolved because root depends on 'consumer-of-tomlkit'
'consumer-of-tomlkit' cannot be used because package 'consumer-of-tomlkit' is required using a stable-version but 'consumer-of-tomlkit' depends on an unstable-version package 'tomlkit'

I have provided the simple fix to tag the 0.0.2 release of swift-checkit, which is even with the master branch of swift-checkit at the time of writing.
Thank you!

Thank you! Can you please update<EMAIL_ADDRESS>as well?

Should be all set! 🤘🏻


Update yandex.json according to actual rules

This rules based on actual yandex's csscomb-file from bem-components https://github.com/bem/bem-components/blob/v5/.csscomb.json

Okay. Let's use csscomb's version. Thank you for PR @palegrow .


Allow optional semrev 'v' prefix in fabric-ca reported version

Allows the version reported by fabric CA to include an optional leading semrev 'v' character.
Signed-off-by: Josh Kneubuhl<EMAIL_ADDRESS>

@Mergifyio backport release-2.2


Integrate Jasonette (or extend) to mix with Swift 3 and/or 4

I'm working with an existing pure Swift 3 iOS app (moving to Swift 4 in the next 6 months or less), and would love to be able to use Jasonette with my existing app.  I'd ideally like to be able to create views in Jasonette, that have custom forms served to the app from a web server, and be used offline.
Where I'm getting stuck is:

I need my Swift code to have access to the data that's captured in forms I setup in Jasonette views. As an example, a 10 question form in a Jasonette view, and then pass the answer data to the Swift app to mix with already collected data that is written out to a file.
I need to be able to segue from a Jasonette view, to a native Swift UIView that's already created, and then back again to the calling Jasonette view (which is part of the larger Swift app).

I'm not sure how to proceed at this point to integrate and/or extend Jasonette with my Swift app. I'm NOT an Objective-C coder (I've tried, and just get lost). I've followed through the Extending Jasonette or integrating with with Objective-C, but with no luck for my app yet. I've also tried going through guides like the Apple page on integrating Objective-C with Swift apps.
Any suggestions or examples of how to do this with Swift 3 or 4 would be greatly appreciated.
As a side note, I love the concept and implementation of Jasonette. It truly is an amazingly quick way to get a native iOS app going.

Hey thanks for sharing. Theoretically this should be simple, I am curious which part you're getting stuck at. Can you share more details?
Would be helpful to know which part you tried in http://docs.jasonette.com/advanced/#integration and specifically where you got stuck. It would be cool to get it working with swift.

Sorry, I wasn't at all clear about how I'm trying to integrate Jasonette from the start.
While the Setup script creates a nice Xcode project ready to go, and you can choose to "Continue working on the existing app". I didn't see clear instructions on how to migrate or import Jasonette into my existing Xcode Swift 3 project.
So here's what I did.

First, in my existing Xcode Swift project that we will call my_app for now, I did an Add files to "my_app" from the Right Click menu in the Project Navigator (the folder view for the project in Xcode).
From the file browser popup I selected the Jasonette folder that was created from the Setup script in the downloaded Jasonette project. This imported the Jasonette folder into my existing project.
I then created a Bridging Header file (my_app-Briding-Header.h) in my project.
I then added the JasonViewController.h to the my_app-Briding-Header.h file like so.

//  my_app-Bridging-Header.h

#ifndef my_app_Bridging_Header_h
#define my_app_Bridging_Header_h

#import "Jasonette/JasonViewController.h"

#endif /* my_app_Bridging_Header_h */

I then created a storyboard with two views in it. The first one controlled by my existing Swift based view controller code. This view has a button on it that navigates to a second storyboard view that I want Jasonette to control. I setup the second storyboard view to use this view controller code.

//  JasonetteVC.swift
//  my_app
//

import JasonetteVC

class SecondView: JasonetteVC {

    override func viewDidLoad() {
        super.viewDidLoad()

        self.url = "https://jasonbase.com/things/jYJ.json"
    }
}

I then tried to build and run my_app.
At this point I got the error 'SDWebImage/UIImageView+WebCache.h' file not found.
After some snooping around in the original Jasonette Xcode project I realized that CocoaPods are being used (a lot of them).

I then imported all the Pods that were found in the project created by the Jasonette Setup script and manually linked them into my app through the my_app-Bridging-Header.h

I then tried to build and run my_app again.

After all this, things seem to build. I can see the first view (based on my Swift code), but I never get anything when I try to transition to the Jasonette view.
No errors, so I'm not sure how to integrate with Jasonette at this point.
Should I be calling the JasonetteVC as I did in step 5 above, or do I need to try a different approach from the start?
Thanks!

If you look at viewDidLoad this is where all the magic happens, which means you need to have self.url set BEFORE calling super.viewDidLoad(). Could you try changing the order in your viewDidLoad() overload?

I am facing problem using swift file class in Jasonette, I need to extend JasonAction Class with my swift class as project Jasonette is in ObjC we can achieve creating swift class with the help of bridging header. As I try to import "JasonAction.h" in bridging header it gives me an error.
looking for some help
Thanks

Integrated Swift in Jasonette with following steps:

Created a bridging header
Since pods were integrated, did a fresh pod install, and for few pods changed their scope to project.
And we modified the pod library import statements from ex:  "UIImageView+WebCache.h" to <SDWebImage/UIImageView+WebCache.h>
Imported JasonAction.h in bridging header and successfully subclassed it for custom action.

Integrated Swift in Jasonette with following steps:

Created a bridging header
Since pods were integrated, did a fresh pod install, and for few pods changed their scope to project.
And we modified the pod library import statements from ex:  "UIImageView+WebCache.h" to <SDWebImage/UIImageView+WebCache.h>
Imported JasonAction.h in bridging header and successfully subclassed it for custom action.

Thanks @riddhi8  solution worked for me

@gliechtenstein  , @ARVRHI & @zachstegall  ...Did you guys manage to work with jasonette in your swift project ?
if yes ,then please describe how you guys integrated jasonette in swift project ?
And can we use jasonette with json received from api response ?

Hey @gliechtenstein . Sorry for this late reply. I discovered your comment on the new GitHub iOS app.
No, we didn’t end up using jasonette.

hey @zachstegall  what did you use instead of jasonette? did you come across any other library?

hey @zachstegall  what did you use instead of jasonette? did you come across any other library?

Ended up using HubFramework. You could define JSON schemas to map to component properties with that framework. But it has been deprecated. We needed to be quite a bit more dynamic than pre-defined schemas, so we ended up writing our own modeling engine and leveraging HubFramework for rendering.
An interesting future direction we are exploring is SwiftUI, which could work well for our case.


Bug fix duplicate names

Bug reported - The user was able to create duplicate names for the calendar
Now the user will not be able to, and will be alerted when attempting to do so.

Closes #90