proposal: anonymous struct literals

Currently it is not possible to write a struct literal without mentioning its type (with the exception of struct literals in map and slice composite literals). This can make it extraordinarily hard to write literals for some types. As an extreme example, consider writing a literal initializer for the sarama.Config type. All the unnamed struct types need to be written out explicitly, leading to a highly redundant expression 100s of lines long, and also fragile because any fields that are added will cause breakage.
I propose that Go adds a way of writing an anonymous struct literal - a struct literal that has no explicit type - by using the blank identifier (_) as a type name in a composite literal.
For example:
_{
	Name: "Bob",
	Age: 12,
}

Unlike other composite literals, it would require all members to be qualified with field names (no non-keyed elements).
Any field values in the literal that are const will remain const. If all fields in the literal are const, the entire literal is also considered considered const too, forming a struct constant.
For example:
const Bob = _{
	Name: "Bob",
	Age: 12,
}
const BobAge = Bob.Age

Like other constants, an untyped struct constant has a default type, which is the anonymous struct type with all fields converted to their default type.
So, for example, the default type of _{} is struct{}; the default type of _{Name: "Bob", Age: 12} is struct{Name string, Age int}.
An anonymous struct literal can be assigned to any struct type that contains a superset of the fields in the literal. Any const fields are treated with the usual const assignment rules. Fields that are not mentioned will be zero.
So, for example:
type Person struct {
	Name string
	Age uint32
}
var alice Person = _{
	Name: "Alice",
	Age: 32,
}

Unlike other struct literals, it would not be possible to use the & operator, so:
&_{Name: "Bob"}

would be invalid. There might be an argument for allowing assignment of an anonymous struct literal to a pointer type, so:
var P *Person = _{Name: "Bob"}

would be the same as:
var P *Person
var P1 Person = _{Name: "Bob"}
P = &P1

This would fit with the way that literal elements in map and slice literals work.

Discussion
Related proposals
Issue #12854 proposes type-inference for composite literals, but it's more general (including support for maps and slices) and doesn't propose allowing const structs.
That proposal is also somewhat more restrictive - it doesn't allow the untyped composite literals to be used in places where the type being assigned to isn't clear.
By contract, this proposal always allows such a literal to be formed, and applies the same kind of rules for other Go values and constants.
In #12854, the fact that the type is inferred from the destination can make the resulting code hard to read. If I see a statement like:
foo({x: y})

I can only tell if x is a field name or an expression by looking at the type of foo. In foo(_{x: y}) in this proposal, x is always a field name and never an expression.
Issue #9859 is also relevant. If we allow direct reference to embedded fields in struct literals, perhaps we should make assignment from untyped struct literals work for that too, allowing this, for example:
type T struct {
	X int
}
type S struct {
	T
	Y int
}
var s S
s = _{X: 10, Y: 20}

Zero value
All types in Go other than struct types and arrays have short representations for their zero value. Pointers, maps, slices and channels have nil, strings have "" and numbers have 0. This proposal implies a universal form for structs too: _{}.
This makes it less verbose to return from struct-returning functions:
func Foo() (somepkg.SomeStructType, error) {
	if err := doSomething(); err != nil {
		return _{}, err
	}
	return somepkg.SomeStructType{
		// etc
	}, nil
}

It also makes it slightly less verbose to form an empty struct{} literal:
m := make(map[string]struct{})
m["a"] = _{}

Struct constants
There are places where it would be nice to be able to have struct constants. For example, image.ZP is a variable, and deprecated mostly, I believe, because using it is inefficient (the compiler is unable to prove that it doesn't change).
const ZP = Point{}

wouldn't have those disadvantages.
Struct parameters
It's common for functions to accept a struct parameter argument containing an extensible set of parameters. Often, this is defined as a pointer type because it's inconvenient to write the struct literal, where it would be more natural to pass it by value.
With anonymous struct literals, this idiom becomes less weighty. Instead of:
x, err := foo.New(foo.Params{})

you'd be able to write:
x, err := foo.New(_{})

Anonymous map/slice literals
This proposal makes a deliberate choice that an anonymous composite literal represents a struct literal, not a map, slice or array literal. The main reason for doing this is that it means that the parser can know that the keys are field names, not arbitrary expressions. Allowing an anonymous composite literal to represent other kinds of types would significantly complicate the spec.
Compatibility
The syntax is compatible with existing Go parsers, so current gofmt formatting wouldn't need to change. As _ is always an error to use as a type name in a literal, there shouldn't be any problem with breaking existing code.
Updates would be needed to the go/types packages and other associated tooling.

Apologies if it's a bikeshed, but maybe struct{_} {...}?

Apologies if it's a bikeshed, but maybe struct{_} {...}?

That has the advantage of being more obviously a struct literal, but it's more verbose - the syntactic light weight of the original proposal seems to me to be a significant point in its favour.

If (and that is a big IF) I understand it correctly, this proposal is not so much about anonymous structs, but more of a const structs - at least all examples are const
(below is Thinking Out Loud, and breaking old visual conformity)
if so... why don't we entertain the idea to use word const instead of "_" ?
This way you know

you cannot use it as r-value (using C++'s terms), but only as a left side.
you cannot take a direct address of it. So if you do, it will introduce a copy and then address
you don't exactly have a type until you assign it to something, sort of like const works on a simple consts

t := const { Name: "Bob", Age: 12 }

would need to be made illegal, since t would have no type that can be derived. Or... (to go with anonymous types), it would become a
var t struct {Name string, Age int}
t = const { Name: "Bob", Age: 12 }

automatically. (Might not that be that bad actually)
Retyping all the examples above to see how it "feels"
const Bob = const {
	Name: "Bob",
	Age: 12,
}
const BobAge = Bob.Age

type Person struct {
	Name string
	Age uint32
}
var alice Person = const {
	Name: "Alice",
	Age: 32,
}

(although, in this example, I would drop the const altogether, more of what https://github.com/golang/go/issues/12854 does. Different meaning though with and without const - one is type elided, another is copied of const struct into new Person.)
Last one is a bit of a gotcha
var P *Person = const {Name: "Bob"}

would be the same as:
var P *Person
var P1 Person = const {Name: "Bob"}
P = &P1

but... feels breaking the rule of const having no address. But then again, existing example would be an initializing array of pointers with just (const) structs.

On Fri, 1 Nov 2019, 20:09 tandr<EMAIL_ADDRESS>wrote:

If (and that is a big IF) I understand it correctly, this proposal is not
so much about anonymous structs, but more of a const structs - at
least all examples are const

That's actually my mistake, sorry: I am not proposing that they should all
be const any more than I'm proposing that all expressions should be const.
I'll try to fix the wording to make this clearer.
An anonymous struct literal would be a set of expressions just like the
expressions in a call to a function. To pass arguments to a function, we
write positional, comma-separated expressions. In this proposal, the _{}
syntax is very similar but works for struct types instead of function
arguments.
This would be valid code, for example:
func main () {
    Configure(_{Reader: os.Stdin})
}

type Params struct {
     Reader io.Reader
 }

func Configure(p Params) error { ... }

Hope that makes it a bit clearer.
(below is Thinking Out Loud, and breaking old visual conformity)

if so... why don't we entertain the idea to use word const instead of
"_" ?
This way you know

you cannot use it as r-value (using C++'s terms), but only as a
left side.
you cannot take a direct address of it. So if you do, it will
introduce a copy and then address
you don't exactly have a type until you assign it to something,
sort of like const works on a simple consts

t := const { Name: "Bob", Age: 12 }
would need to be made illegal, since t would have no type that can be
derived. Or... (to go with anonymous types), it would become a
var t struct {Name string, Age int}
t = const { Name: "Bob", Age: 12 }
automatically. (Might not that be that bad actually)
Retyping all the examples above to see how it "feels"
const Bob = const {
Name: "Bob",
Age: 12,
}
const BobAge = Bob.Age
type Person struct {
Name string
Age uint32
}
var alice Person = const {
Name: "Alice",
Age: 32,
}
(although, in this example, I would drop the const altogether, more of
what #12854 https://github.com/golang/go/issues/12854 does. Different
meaning though with and without const - one is type elided, another is
copied of const struct into new Person.)
Last one is a bit of a gotcha
var P *Person = const {Name: "Bob"}
would be the same as:
var P *Person
var P1 Person = const {Name: "Bob"}
P = &P1
but... feels breaking the rule of const having no address. But then again,
existing example would be an initializing array of pointers with just
(const) structs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/35304?email_source=notifications&email_token=AAAQHOZADZUIZ4AQW2VINDDQRSEIFA5CNFSM4JHZFQ2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4AXRI#issuecomment-548932549,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAQHOZXC3QRMOA7TEVTOOTQRSEIFANCNFSM4JHZFQ2A
.

The problem is that currently you can write something like this
var foo = map[string]struct{
   Foo int
}{
    "1": {Foo: 1},
    "2": {Foo: 2},
}

which is why #12854 wants to extend the places where that is allowed.
Whereas this would introduce a slightly different syntax, which leads to the following problem:
Either change the valid syntax mentioned above to be in the form of _{Foo: 1}, or have 2 different syntaxes for the same thing, used in different places.

Either change the valid syntax mentioned above to be in the form of _{Foo: 1}, or have 2 different syntaxes for the same thing, used in different places.

In this proposal, this would be valid too, because the _{...} form is valid whereever a struct-valued expression is valid:
var foo = map[string]struct{
   Foo int
}{
    "1": _{Foo: 1},
    "2": _{Foo: 2},
}

The {...} form without the _ qualifier would only be allowed where it is now - it is more general than the _ literal (it allows positional members as well as keyed members, and map and slice literals too) and if it's allowed in any expression, it introduces some syntactic ambiguity too (does a { at the start of a statement mean the start of a composite literal or of a braced block?)
To recap: the _{...} form is allowed in any expression, but always implies a struct literal. The {...} form may only be used inside composite literals but may be used for slices, maps and non-keyed struct literals too.

Not sure if that's better or not. You'd have 2 different syntaxes for the same thing now. In some places, both can be used, but in others, only 1 can be used. And the users are either gonna have to know the spec pretty good, or suffer through the learning curve of whether to use which syntax.
IMHO, i would prefer if #12854 is implemented wherever its unambiguous. I'm also wondering whether

I can only tell if x is a field name or an expression by looking at the type of foo. In foo(_{x: y}) in this proposal, x is always a field name and never an expression.

is really a big problem. My guess would be that structs are a lot more prevalent as argument types than maps, so if you really care about the type, a guess that its a struct would more than likely be correct. For a casual reader, would it really matter if the argument was a struct or a map anyway? And finally, for a writer, you'd need to know the type beforehand, otherwise can you really say you know what you're writing?

Not sure if that's better or not. You'd have 2 different syntaxes for the same thing now. In some places, both can be used, but in others, only 1 can be used. And the users are either gonna have to know the spec pretty good, or suffer through the learning curve of whether to use which syntax.

I think it would probably be fine if gofmt -s (or maybe even just gofmt) removed any redundant _ prefixes inside struct literals. That might be enough.

My guess would be that structs are a lot more prevalent as argument types than maps, so if you really care about the type, a guess that its a struct would more than likely be correct. For a casual reader, would it really matter if the argument was a struct or a map anyway?

I think it does matter. There's a big difference between {name: "hello"} when name is an expression (you'll need to know what it's referring to) and when it's a field (it's really just a field name with no extra cognitive overhead).

And finally, for a writer, you'd need to know the type beforehand, otherwise can you really say you know what you're writing?

That's a good question. In a sense, the struct literals are somewhat analogous to method definitions in that respect. If you write a method definition, there are many possible interfaces it could satisfy, so can you really know what you're writing? With this proposal, it's possible to write a struct constant like this:
const One = {N: 1}

which is assignable to any struct type that has a numeric field named N. I'm not sure how useful this is in practice, but it falls out naturally from giving untyped literals a first class place in the language alongside other kinds of untyped expression. Personally, I think this is preferable to restricting the contexts in which this kind of literal can be used as #12854 does, something which itself has quite a learning curve and goes against the way that most of the type system works.

This is two proposals. One is an adjustment to composite literals to permit replacing the name of a struct type with _. The other introduces "struct constants". These two changes are orthogonal--we could have either without the other--and can be considered separately.
Constant structs is a subset of #6386. I don't have anything to add to the discussion on that issue, so the rest of my comments focus on the proposed composite literal syntax change.

Currently it is not possible to write a struct literal without mentioning its type.

This isn't actually true--the type of a composite literal (struct or otherwise) may often be elided when nested within another composite literal.
type T struct{ V int }

var _ = map[T]T{{V: 0}: {V: 1}} // type T elided in map key and value
var _ = []T{{V: 0}}             // type T elided in slice
var _ = []T{{V: 0}}             // type T elided in slice
var _ = [...]T{{V: 0}}          // type T elided in array

The only time the type of a nested composite literal may not be elided is when the containing type is a struct. Permitting elision in this case as well is proposal #21496, and would address the example of sarama.Config. I think we should do this. I find it odd that elision is permitted in the cases above, but not this one:
var _ = struct{K T}{K: {V: 0}} // error: missing type in composite literal

Issue #12854 proposes type-inference for composite literals, but it's more general (including support for maps and slices) and doesn't propose allowing const structs.

It's not quite accurate to say that #12854 proposes type-inference for composite literals. We already permit eliding the type of composite literals in many circumstances; #12854 essentially proposes extending those circumstances. It does this by suggesting that a composite literal without an explicitly specified type be assignable to a compatible variable. The type is taken from the variable, not inferred.

This proposal makes a deliberate choice that an anonymous composite literal represents a struct literal, not a map, slice or array literal. The main reason for doing this is that it means that the parser can know that the keys are field names, not arbitrary expressions.

The parser already needs to deal with cases where whether a key is a field name or an expression is only knowable after type resolution.
var key = "key"
var _ = T{key: "value"} // Is `key` a field name, or an expression?

The interpretation of key depends on the type of T, which may of course be defined in a different file or package:
type T map[string]string

type T struct{key string}

Limiting this proposal to structs doesn't simplify the parser's job at all.

This is two proposals. One is an adjustment to composite literals to permit replacing the name of a struct type with _. The other introduces "struct constants". These two changes are orthogonal--we could have either without the other--and can be considered separately.

That's a reasonable characterisation, except that we're not just talking about constants - it proposes untyped struct literals, which are a different thing. An untyped struct literal is not necessarily constant, although it can be - it's constant iff all its fields are constant.

Currently it is not possible to write a struct literal without mentioning its type.
This isn't actually true--the type of a composite literal (struct or otherwise) may often be elided when nested within another composite literal.

Yup, that's true, thanks. I've adjusted the proposal text accordingly.

I find it odd that elision is permitted in the cases above, but not this one:
var _ = struct{K T}{K: {V: 0}} // error: missing type in composite literal

Personally, I don't find it that odd, because in a large struct, there can be significant cognitive overhead in understanding complex composite literals, particularly when literals omit keys.
For example, in the statement below, there's no clue as to whether the K value is a slice or a struct. When the
var _ = foo.Bar{K: {0, 1, 2}}

I think it's instructive to go through the CLs from the time we actually did this inside the Go source tree.
ISTM that most of the "unreadable" review comments came from situations where the literals were slice literals or struct literals with positional arguments.

The parser already needs to deal with cases where whether a key is a field name or an expression is only knowable after type resolution.

Yes, that's true; I've adjusted the text to say "compiler" there. If you don't know if it's map or a slice or a struct literal, you can't really have the concept of an untyped literal in the same way because the meaning of the key syntax can vary according to how it's used. So the language can't (for example) support assignment of an untyped struct literal to an interface type, something that I suspect might turn out to be quite useful; for example:
someTemplate.Execute(os.Stdout, _{
	Name: "hello",
	Age: 123,
})

Personally, I don't find it that odd, because in a large struct, there can be significant cognitive overhead in understanding complex composite literals, particularly when literals omit keys.

To make sure we're talking about the same thing: Right now, you're allowed to elide the type from a nested composite literal when the containing type is a map, slice, or array. You aren't allowed to elide the type when the containing type is a struct. I think this is an odd inconsistency.
I don't find arguments about cognitive overhead or readability convincing. You can write utterly unreadable composite literals right now. To use your own example, this is perfectly valid Go code right now:
var _ = foo.Bar{K: {0, 1, 2}}

You can always write unreadable code. The standard to judge language syntax on is whether it can be used to write readable code, and whether it encourages unreadable code. To go back to your example of samsara.Config, this does not seem unreadable to me:
conf := samsara.Config{
  Net: {
    MaxOpenRequests: 10,
  }
}

Yes, that's true; I've adjusted the text to say "compiler" there.

Parser or compiler, the current implementation already needs to deal with the fact that an identifier appearing as a key in a composite literal can only be determined to be a field name or an expression after type resolution has been performed. Limiting the _{ ... } composite literal syntax to structs doesn't simplify the compiler because it still needs to handle the existing cases. I do not believe the assertion that "allowing an anonymous composite literal to represent other kinds of types would significantly complicate the spec" is correct; the complexity is already there today.

To use your own example, this is perfectly valid Go code right now:
var _ = foo.Bar{K: {0, 1, 2}}

Yes, and that example is just about OK because, firstly it's clear that foo.Bar must be a slice or a map, and you look at its definition and find out its key and element type, and thence what K and {0, 1, 2} signify. When you get to multiple levels and struct fields with heterogeneous types, that quickly adds a lot of cognitive overhead, which is why I don't support #12854.

To go back to your example of samsara.Config, this does not seem unreadable to me:
conf := samsara.Config{
  Net: {
   MaxOpenRequests: 10,
 }
}

I agree, which is why this proposal would allow that (assuming a _ prefix in front of the Net value).

Limiting the _{ ... } composite literal syntax to structs doesn't simplify the compiler because it still needs to handle the existing cases.

I actually said that it would simplify the spec, not necessarily the compiler. I was talking about a spec allows untyped composite literals, not just type-elided ones, as this proposal does.
If an untyped composite literal can represent a map or a struct, what does it mean if I assign one to an interface{}?

When you get to multiple levels and struct fields with heterogeneous types, that quickly adds a lot of cognitive overhead, which is why I don't support #12854.

I'm confused by which cases you see as involving cognitive overhead, and which ones as not doing so. The presence or absence of an additional _ prefix doesn't seem to me to have a great deal of influence on the comprehensibility of the samsara.Config example.
Do you see #21496 as introducing too much cognitive overhead? That proposal seems to address your motivating example for this proposal (the difficulty of writing initializers for some types) with a very small spec change.

If an untyped composite literal can represent a map or a struct, what does it mean if I assign one to an interface{}?

You can't, same as you can't assign an untyped nil to an interface{}. An untyped composite literal does not have a default type.

Do you see #21496 as introducing too much cognitive overhead?

Yes I do. I think that allowing elision of type specifiers for all kinds of type of field is going a bit too far. I'm hoping that my proposal here is a reasonable half way house in this respect: you can always make a keyed struct literal without specifying the type, but not other types.

An untyped composite literal does not have a default type

It does in this proposal :-)

In terms of cognitive overhead, i really don't see how adding an extra _ is that much better, tbh. Lets take the following examples:
foo := Config{
    Bar: {
      Baz: {"alpha", "beta"},
   },
}

foo = Config{
   Bar: _{
      Baz: {"alpha", "beta"},
   },
}

Now, it is in fact clear that the value of Bar is a struct. However, that in itself isn't all that useful information. Just knowing that something is a struct, is like knowing that something is a box. You still don't know what's inside of it. And given that most of the time, maps just aren't used in such structs, the reader can just go ahead and assume that this is a struct and not a map.
Adding a _ is an optimization, however its one that I don't think is necessary due in part to the proliferation of structs over maps.

Now, it is in fact clear that the value of Bar is a struct.

It might be in this small piece of code, but I don't think that's always true when exploring large foreign code bases. I've been bitten by this assumption before.
What about the value of Baz ? Is that a struct or not?
What about code like this (from a real example from when this was tried in the stdlib)?
stmt := &Stmt{
    css:   {{ci, si}},
}

Adding a _ is an optimization, however its one that I don't think is necessary due in part to the proliferation of structs over maps.

It's not really an optimisation as such. It's disambiguating syntax, both for the user (I do believe that knowing it's always a struct type is helpful) and for tools - it means that current Go parsers can parse the new syntax, even if they can't understand the new semantics.

Just for disambiguation, wouldn't it be better to use _{} for maps/slices as opposed to structs, since they are less likely to occur in the wild, while keeping structs representations as {}?

Just for disambiguation, wouldn't it be better to use _{} for maps/slices as opposed to structs, since they are less likely to occur in the wild

Firstly, one main reason for using _{} is to keep the syntax backwardly compatible and unambiguous, which wouldn't be the case if {} is used.
Secondly, I'm not sure that an untyped map/slice literal is as useful - as you say, they're less likely to occur in the wild, and also it's much less common to have significant numbers of large map/slice types that aren't easy to type. If you've just got a few such types, it's easy to define your own alias:
type m = map[something]somethingElse
var foo = m{"a": "b"}

It's not really an optimisation as such. It's disambiguating syntax, both for the user (I do believe that knowing it's always a struct type is helpful) and for tools - it means that current Go parsers can parse the new syntax, even if they can't understand the new semantics.

When you say disambiguating syntax, what are the specific ambiguities you're thinking of?
I think it would also be useful to be very clear about when considerations apply to a non-nested _{} literal and one occurring inside some other composite literal. The motivating example introducing this proposal (it is "extraordinarily hard to write literals for some types") is entirely concerned with nested composite literals; writing the top-level type is not generally a problem.

To continue the recent theme of proposing new uses for ...:
    v := struct{...}{Name: "Bob", Age: 21}

I don't really like the idea that _{} implies an anonymous struct.  @bradfitz 's suggestion of struct{...} is longer but clearer.  It also roughly corresponds to the [...]int{} array syntax.

This would help out with text/template & html/template usage. Grepping for Execute.*struct I find code like:
        err := notifyTmpl.Execute(&msg, struct {
                Builder  string
                LogHash  string
                Hostname string
        }{builder, logHash, domain})

and
func emailBody(page, diff string) (string, error) {
        var buf bytes.Buffer
        if err := htmlTmpl.Execute(&buf, struct {
                PageURL, Diff string
        }{
                Diff:    diff,
                PageURL: fmt.Sprintf("https://golang.org/wiki/%s", page),
        }); err != nil {

Presumably one could write:
var s struct{x int; y float32} = struct{...}{1, 2}

and the 2 in the struct literal would become a float32 in the assignment?

I think the constant part of this proposal is basically the same as #6386.  We can probably consider that separately.

@griesemer I would personally expect your example to be a compile time error. I'd expect that the literal must be keyed and that the usual rules would apply for default types so that it would need to be written
var s struct{x int; y float32} = struct{...}{x: 1, y: float32(2)}

Even then I'm not sure how I feel about that since the order of the keys would matter. struct{...}{a: 1, b: 2} would have type struct { a, b int } but struct{...}{b: 1, a: 2} would have type struct { b, a int }.
Something like #12854 seems a better fit for this particular example, where the below would suffice
var s struct{x int; y float32} = {1, 2}

@griesemer wrote:

Presumably one could write:
var s struct{x int; y float32} = struct{...}{1, 2}

and the 2 in the struct literal would become a float32 in the assignment?

Yes, that's my main reason for including const structs as part of this proposal.
The value on the right hand side is a constant struct value, and can be assigned
as described in this rule (from the proposal description):

An anonymous struct literal can be assigned to any struct type that contains a superset of the fields in the literal. Any const fields are treated with the usual const assignment rules. Fields that are not mentioned will be zero.

@ianlancetaylor wrote:

I think the constant part of this proposal is basically the same as #6386. We can probably consider that separately.

That proposal also includes constant arrays and slices, which aren't be considered here and are perhaps of more marginal use.

Perhaps, rather than allowing a const struct to be assigned to a superset struct, only allow assignment to a comparable one.
For supersets, we could propose "yet another usage of ...", and allow destructing assignment of any struct to another one, as is currently allowed for slices and varargs:
r := struct{x: int, z: string}{42, "foo"} s := struct{x: int, y: float32, z: string}{r..., y: 0.5}
This doesn't fall within the boundaries of this particular proposal, though it might be worthwhile to keep in mind lest we end up with potentially multiple ways of doing a very similar thing.

@rogpeppe Any thoughts on struct{...} suggested in https://github.com/golang/go/issues/35304#issuecomment-555749438 ?
I see your earlier comment that this is more verbose.  Yes, it is.  But it seems more clear than _, which in other contexts implies discarding a value.

I take your point about _ usually implying a discarded value. But, at 11 characters, struct{...} does seem to me to be more verbose than I'd like for this feature.
Two other possibilities:

we could define builtin type name for this... but I haven't managed to think of a good name.
I think it might be viable to use ... itself. For example:

v := ...{Name: "Bob", Age: 12}

To me, ...{} looks like you'd somehow be defining a slice of these structs

Proposed syntax struct{...}{Foo: "bar"} by Brad plays quite well with [...]int{1, 2, 3} and looks natural in Go.
We do not reuse _ in a different context (original context is about skipping variables, right?), optimising 1 vs 11 characters is an overkill (we won more by dropping {Foo string, Bar int} in a struct declaration).
(basically what Ian mentioned https://github.com/golang/go/issues/35304#issuecomment-555750151)

Although I prefer struct{...} to the other suggestions made so far, I agree with @rogpeppe that it is rather long.
Another possibility would be to stick with the struct keyword but use parentheses rather than braces:
v := struct(Name: "Bob", Age: 12)

// or if type inference is to be allowed

var v struct{name string; age int} = struct("Bob", 12)

As struct is a keyword, this couldn't be mistaken for a function call.
If a new built-in type were to be used instead, then tuple would be a good name for it as that, in effect, is what it is:
v := tuple{Name: "Bob", Age: 12}

// or in type inferred form

var v struct{name string; age int} = tuple{"Bob", 12}

Although introducing a new built-in type name may seem like an expensive way of dealing with this particular problem, it might find wider usage as a kind of generic struct. For example as a function parameter or return type to which compatible structs could be assigned.
Also, if const structs were introduced where all the field types were themselves const types, then tuple could serve as an 'untyped' form of such constants.

Is ... too verbose to type, or to see/read? I think in Go we're generally okay with needing a few extra characters to gain some clarity.

Another possibility would be to stick with the struct keyword but use parentheses rather than braces:

Disagree. That will make struct a context dependent word, which Go generally try to avoid.

If a new built-in type were to be used instead, then tuple would be a good name for it as that

That would actually introduce a new metatype since tuple(int, float) != tuple(float, int). Also there is a different issue about the type inference.

@mvdan

Is ... too verbose to type, or to see/read?

Well, the extra typing would actually be {...} rather than just ....
As I said earlier I certainly prefer this to those suggestions which just use a symbol (these look more like Perl than Go to me), but the fact remains that it is verbose and hence my alternative suggestions.

Is ... too verbose to type, or to see/read? I think in Go we're generally okay with needing a few extra characters to gain some clarity.

For the record, I was comparing the suggested struct{...} with the originally proposed _ (11 characters vs 1).

@DmitriyMV

That will make struct a context dependent word, which Go generally try to avoid.

If you mean that struct (which is a 'full' keyword, not a 'contextual' one) could now be followed by either a ( or  a { then, of course, I agree with you though I don't think this is necessarily a fatal objection.

That would actually introduce a new metatype since tuple(int, float) != tuple(float, int).

Agreed again. As far as type inference is concerned,  if something like this were allowed:
const c = tuple {12, 12.0}

then c would only be compatible with struct {int; float64}, not struct {float64; int) since, in the absence of other info,  the default types of 12 and 12.0 would need to be used to infer the types of the fields.

perhaps add a typed Tuple which is implicitly a const? The syntax directly parallels that of the arguments to a function call / return specification
        t := ( "hello", "world", 123 ) // Define a const tuple of type  (string, string, int )
        // Or explicitly ( "hello", "world" string, 123 int )
	t[0] == "hello"
	t[2] == 123
	t[0] = "update" // Compile time error

this could open up a number of paths. Firstly collecting generic args and passing them in a compile time typed way, this is not possible today and you have to shift to ...interface{}.
        // Using tuples this could work
        func f( args ...tuple )  {
             g( args... )
        }
        func g( a string, b int ) { }
        func main() {
             f( "hello", 123 )
        }

collecting return args, if multiple return types are implemented as tuples you end up being able to do something like
     func f() ( string, int, int ) { return "hello", 1, 2 }
     arg1, ...args := f() // where args is tuple ( int, int)

enabling tuple operations
    a, _, b  := ( "hello", 1.23, "world" )
    a == "hello"
    b == "world"

Finally a move towards the anonymous typed struct by supporting a named tuple syntax.
	n := ( f1  : "hello", f2 : 123)
	// n := ( f1 string : "hello", f2 int : 123)

        n[0] == n.f1 == "hello"
	n[1] == n.f2 == 123
	n.f2 = 345 // Compile time error

t[0] = "hello"

That's going to be very easy to confuse with array access, sorry.
Maybe
t.0 == "hello"
or
t.[0] == "hello"
would make it more readable?

Why isn't &_{Name: "Bob"} allowed? Sounds like a nice way to express an anonymous struct without typing out all of its types.
I think this should be allowed:
data := _{X: x, Y: y}

Or like this perhaps
data := struct _ {X: x, Y: y}

I with it was possible to use _ in place of an empty struct literal, like this:
m := make(map[int]struct{})
m[0] = _

or even this:
m := make(map[int]_)
m[0] = _

Is there a proposal for that?

@opennota I don't know of an open proposal for that.  It's been proposed at least at https://groups.google.com/g/golang-nuts/c/kBOnfs3a2tU/m/YxTuqMLhYckJ and https://groups.google.com/g/golang-dev/c/iAysKGpniLw/m/qSbtBUx4-sMJ .  There is also https://go.dev/issue/35966.


librealm-ios file is using 48 mb

Hi, i just install realm using cocoa pods, (the swift version) and there's a librealm-ios.a file adding 48 mb to my app, there is any way solve this problem, my final ipa is too big

You wrote you're using the Swift version, so I'm assuming you mean the RealmSwift.podspec, is that right? Because then you can only integrate with use_frameworks! in your Podfile with CocoaPods, which wouldn't produce any static library artifacts as librealm-ios.a. Do you have perhaps embedded Realm's prebuilt binaries before using CocoaPods and the static library is left from that? Beside that my final question would be, how is your final ipa too big? Is it iTunes Connect / Xcode complaining when you're trying to upload the binary. Since introduction of bitcode the size of binaries have definitively increased, but that is only the size, you ship to the app store. The actual app download will be much smaller.

this is my podfile, xcode is giving me a size warning, the actual download is still to big, but without realm is just 16 mb
i haven't do anything weird with the instalation only added the pod 'RealmSwift' and run pod install
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '8.0'
use_frameworks!

target 'gasmov' do
pod 'Alamofire'
pod 'SWXMLHash'
pod "SwiftPages"
pod 'ImageLoader'
pod "MaterialKit", :git => "https://github.com/reesemclean/MaterialKit", :branch => "swift_2"
pod "SwiftyJSON", :git => "https://github.com/SwiftyJSON/SwiftyJSON.git"
pod 'CocoaLumberjack/Swift'
pod 'AEXML'
pod 'RealmSwift'
pod 'Popover'
pod 'ActionSheetPicker-3.0'
pod "GMStepper"
end

How did you found about librealm-ios.a? That is not part of your built app bundle, right? It is expected to be located in your Pods directory, but it is compiled into Realm.framework. Could you please make a full clean, archive again and report after that the size of Realm.framework and RealmSwift.framework from your build directory?

just did a full clean, still no luck, i'm going to try with the new version 0.98

Did integrating 0.98 help @jplazcano87?

the problem was fixed by deleting derived data, for some reason it has duplicates build info.
thanks for your help!

Hi.
My librealm-ios.a is 51,8 MB large! Using 'RealmSwift' as a dependency in my project. Already removed derived data, removed the hold Pods folder and installed pods from scratch.
Installing Realm (1.0.1) Installing RealmSwift (1.0.1)

this is not a problem, you only should be worried if your final ipa file size is too big, so i recommend uploading this to testflight and check if you see anything unsual.
also you should ignore your pod folder in your .gitignore file to avoid this heavy file
sorry about the english, i'm from chile

Not having the Pods folder in git is part of a separate discussion and not necessarily good advice. It depends on how your dev team handles Cocoapods projects. If you check in the folder builds on the build server will be faster and not all developers need Cocoapods installed.


Handle multiple captions

do a laion-like dataset but with multiple caption per sample : dedup per url+caption not by url ; then group by url at the end

This may also help to select the best caption for a given image


Add public ViewManagerModel.viewSelectionObserver

For use by apps to mask components during view select/rebuild.

Hoist P/R Checklist
Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

[x] Caught up with develop branch as of last change.
[x] Added CHANGELOG entry, or determined not required.
[x] Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
[x] Updated doc comments / prop-types, or determined not required.
[x] Reviewed and tested on Mobile, or determined not required.
[x] Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

Testing out our new stuff in an actual app that manages a fair amount of state via viewManager - on switch there's a noticeable lag/pause while the components are all given their new state.  Exposing this task observer allowed me to put a mask in place, which I think works well to let the user know what's happening.


Find rust web framework.

Sub task of #16 and #17
Find a framework is:

Async
Support web socket.
Static and dynamic hosting.
Rest apis

[ ] Find a candidate.
[ ] Setup static hosting.
[ ] Hello world dynamic content.
[ ] Hello world web socket.

Closed for archive.

Closed for archive.


Installing not the latest Node 18.13

Description:
I have in my yaml
      - uses: actions/setup-node@v3
        with:
          node-version: 18

and expect it installs always the latest 18 version, but In the CI I have v18.12.1 the latest one is 18.13.0
Action version:
Specify the action version
Platform:

[X] Ubuntu
[ ] macOS
[ ] Windows

Runner type:

[X] Hosted
[ ] Self-hosted

Tools version:
  node: v18.12.1
  npm: 8.19.2
  yarn: 1.22.19

Repro steps:
https://github.com/shopware/platform/actions/runs/3873523857/jobs/6603640318#step:9:1544
Expected behavior:
The latest Node 18 version
Actual behavior:
Got v18.12.1

Hello @shyim. Thank you for your report. It's an expected behaviour because initially action tries to set up the version from the hosted toolcache directory. Could you please try to set check-latest: true to get the latest version.
    - uses: actions/setup-node@v3
      with:
        node-version: 18
        check-latest: true

For now I'm going to close the issue.

Hi @dmitry-shibanov I got same error, the latest one is 18.14.0 now, however even I add check-latest: true, it still does not work. I opened a new ticket at https://github.com/actions/setup-node/issues/689 Thanks! 😃


Add README to pyproject metadata

https://pypi.org/project/control/0.9.3.post1/ shows an empty page.
Compare https://test.pypi.org/project/control/0.9.3.post2/ with the PR applied.

Coverage: 94.856%. Remained the same when pulling 308be1d9b446735138fa5ac65c31fc610afaaf33 on bnavigator:add-readme-metadata into 18975c5162e8d6b3cd43730f8734c935b340161c on python-control:main.


Local file support

User story
Currently, files can be loaded from remote resources but cannot be loaded from local files.
Preferred solution
I can imagine a few ways to solve this:

Add support for file:// URLs.
Add a new field on the fileType configuration object for filePath.
Add a new filed on the fileType configuration object for file that could be set to a File object.

Context
I am working on a project that uses the React component in an Electron window. I would like to allow users to load files from their local machine and not have to stand up server. I would be happy to attempt to implement this if you approve of the feature.

Sounds good! I will toss this on my list of things to do.

First pass: dont worry about config sharing or page reloading, it is fine if local files are only supported in same session in which the user drag-and-dropped/selected local files
Future exploration:

Wrap in electron/lightweight equivalent app for more access to local files (outside of initial session of drag-and-drop/selection)?
Ensure FileReader automatically launches user into folder(s) containing previously-selected files?
Copy file contents into browser local storage on first file load to support reloading?
Provide easy options for user to easily upload their selected local files to a remote location (e.g., provide AWS credentials and upload file contents via JS requests)?

I need some links to where in the codebase we handle reading data out of files -- I couldn't find it myself

CSV: https://github.com/vitessce/vitessce/blob/e6114769cd6cf973b082fc31144773fb306ca7ef/packages/file-types/csv/src/CsvSource.js#L13
Zarr: https://github.com/vitessce/vitessce/blob/e6114769cd6cf973b082fc31144773fb306ca7ef/packages/file-types/zarr/src/ZarrDataSource.js#L12C22-L12C31
OME-TIFF: https://github.com/vitessce/vitessce/blob/e6114769cd6cf973b082fc31144773fb306ca7ef/packages/file-types/ome-tiff/src/OmeTiffLoader.js#L28
JSON: https://github.com/vitessce/vitessce/blob/e6114769cd6cf973b082fc31144773fb306ca7ef/packages/file-types/json/src/JsonSource.js#L12

New idea from discussions today with @manzt: can we abstract this to map from URLs to Zarr store objects (as opposed to FileSystem API objects)? In addition to local file support, this could enable cool jupyter widget functionalities such as mapping a Python store to a JS Store for binary data passing between the Python kernel and the widget.
<Vitessce
  config={{ datasets: [ { files: [{ url: 'file://Users/mkeller/cells.zarr', ...}], ...}], ...}}
  stores={{
    'file://Users/mkeller/cells.zarr': new FileSystemAccessStore(/* FileSystemDirectoryHandle object here */),
  }}
/>

See https://github.com/placemark/flat-drop-files and example from @manzt


snowflake-connector-python fails into install from source for Homebrew formula

A workaround (see https://github.com/fishtown-analytics/dbt-release/pull/4) was put in place to install snowflake-connector-python for in the dbt Homebrew formula without build-system dependencies (--no-pep-517). I think we will still have to give snowflake-connector-python special treatment, but it might be worth not trying to install snowflake-connector-python from source. This issue will serve as additional investigation and possible permanent solution for packaging snowflake-connector-python as part of the dbt Homebrew release.

@kwigley Do you want to keep this one open for further investigation, or should we close it now that we've managed to release v0.19.0 (including Homebrew)?

We'll be revisiting this issue (or a version of it) every time we release dbt :) closing for now

https://github.com/fishtown-analytics/dbt-release/pull/14 will force us to revisit this every release


Default gateway lost on CARP master after failback on HA cluster setup with single public IP

Hi everybody!
This problem still occurs in version 21.1.5 (again).
Original issue in https://github.com/opnsense/core/issues/3128

Logs, screenshots, anything? HA works in general so it's an individual problem and needs proper description.

My colleague has a suggestion what the reason for this behaviour might be. We can't test before Tuesday next week.
I'll keep you informed. Please don't close this issue before.

@bbtaeuber could you share that suggestion ... I might be able to test!
@mimugmail the failover works  but the transition from MASTER to BACKUP takes away the default gateway with it (on the now backup).
Also, may be not the place to discuss here (it needs a an issue on it's own), in my setup the backup would still want to use the wan floating ip to communicate with the exterior world, need  to toggle carp on/off (temporarily disable CARP -> enter persistent CARP Maintenance mode -> Leave Maintenance mode -> Enable CARP)   to make it use it's own ip, and that again takes down the default gateway on the backup.

Please open a thread in forums and we discuss it there


changes required to build on MacOS.

Hi, I'm on MacOS and wanted to give this a try.
I'm running MacOS 12.6.1 and I have the standard command line tools installed (sudo xcode-select --install ).
(base) charlie@charlieMBP build % clang --version
Apple clang version 14.0.0 (clang-14<IP_ADDRESS>)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I used homebrew to install cmake (brew install cmake).
(base) charlie@charlieMBP build % brew --version
Homebrew 3.6.7
Homebrew/homebrew-core (git revision c0c3fa66dbb; last commit 2022-10-24)
Homebrew/homebrew-cask (git revision 10ad9a07c8; last commit 2022-10-24)
(base) charlie@charlieMBP build % cmake --version
cmake version 3.24.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

I had to make a few very minor mods to three files to get steganography to compile. This is my first pull request on git...hopefully I didn't f it up too badly...

Nice! Thanks for your work!


Issue with mouse utilities

Microsoft PowerToys version
0.57.2
Running as admin

[ ] Yes

Area(s) with issue?
Mouse Utilities
Steps to reproduce
Hello!
Thank you so much for all these utilities in this beautiful app!
Just one issue, if I open start or open the search, run the mouse utility to find my mouse, the mouse doesn't have that highlighter around it that time.
Just attaching the screenshots for the same!

✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

This is likely caused by us being unable to draw on top of the start menu on Windows.
Not sure if we can fix this at all.

Ah alright! Thanks for the response :)

Can’t fix as start menu is above everything


Update test dependencies

Summary
This PR upgrades packages used only by tests

Hmmm… that happened locally, it's missing an assembly from the output directory (even though it's marked as Copy Local). I had thought maybe it was an environment thing and we wouldn't see it in a clean CI build, but I guess not… It's only that one Config console tests project. I didn't see an obvious difference.

@david-poindexter removing the reference to the assembly it needed resolved the issue 🤷🏻♂


Upload code coverage

Need more investigation to understand as codecov fails to upload:
(node:5741) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'startsWith' of undefined
    at Object.getAgent (/home/runner/work/js-waku/js-waku/node_modules/teeny-request/build/src/agents.js:30:22)
    at requestToFetchOptions (/home/runner/work/js-waku/js-waku/node_modules/teeny-request/build/src/index.js:86:30)
    at teenyRequest (/home/runner/work/js-waku/js-waku/node_modules/teeny-request/build/src/index.js:143:14)
    at /home/runner/work/js-waku/js-waku/node_modules/codecov/lib/codecov.js:213:9
    at /home/runner/work/js-waku/js-waku/node_modules/teeny-request/build/src/index.js:233:13
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:5741) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:5741) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.


Canvas is taking full height and width of screen

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

Use custom painter
Give it Size of 300 X 400
Then fill canvas with color to fill color use drawPaint method you will see it's also painting color outside .

Expected results
The canvas should occupy only 300 x 400 space.
Actual results
The canvas is occupying 300 x 400 space. But still painting color outside of the canvas.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});
  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: MyHomePage(),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key});

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      appBar: AppBar(),
      body: Center(
        child: Container(
          color: Colors.green,
          child: CustomPaint(
            painter: CanvasTest(),
            size: const Size(300, 400),
          ),
        ),
      ),
    );
  }
}

class CanvasTest extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    Paint paint = Paint()
      ..strokeWidth = 2
      ..color = Colors.black
      ..style = PaintingStyle.fill;
    canvas.drawPaint(paint);
  }

  @override
  bool shouldRepaint(CanvasTest oldDelegate) {
    return true;
  }
}

Screenshots or Video

Logs
No response
Flutter Doctor output
[✓] Flutter (Channel stable, 3.13.5, on macOS 13.4.1 22F770820d darwin-arm64, locale en-IN)
    • Flutter version 3.13.5 on channel stable at /Users/creator/Development/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 12fccda598 (6 days ago), 2023-09-19 13:56:11 -0700
    • Engine revision bd986c5ed2
    • Dart version 3.1.2
    • DevTools version 2.25.0

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    • Android SDK at /Users/creator/Library/Android/sdk
    • Platform android-33, build-tools 33.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E300c
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] VS Code (version 1.81.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.70.0

[✓] Connected device (3 available)
    • iPhone 14 (mobile) • 4AD8F2F6-D566-4F65-B3C0-23146BB6013D • ios            • com.apple.CoreSimulator.SimRuntime.iOS-17-0
      (simulator)
    • macOS (desktop)    • macos                                • darwin-arm64   • macOS 13.4.1 22F770820d darwin-arm64
    • Chrome (web)       • chrome                               • web-javascript • Google Chrome 116.0.5845.187

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Thanks for the report. I do see the same behavior as reported, although I tried to use Container and provide height and width but it didn't make any difference by wrapping it with CustomPaint class.

 stable, master flutter doctor -v
[!] Flutter (Channel stable, 3.13.5, on macOS 12.2.1 21D62 darwin-x64, locale
    en-GB)
    • Flutter version 3.13.5 on channel stable at
      /Users/dhs/documents/fluttersdk/flutter
    ! Warning: `flutter` on your path resolves to
      /Users/dhs/Documents/Fluttersdk/flutter/bin/flutter, which is not inside
      your current Flutter SDK checkout at
      /Users/dhs/documents/fluttersdk/flutter. Consider adding
      /Users/dhs/documents/fluttersdk/flutter/bin to the front of your path.
    ! Warning: `dart` on your path resolves to
      /Users/dhs/Documents/Fluttersdk/flutter/bin/dart, which is not inside your
      current Flutter SDK checkout at /Users/dhs/documents/fluttersdk/flutter.
      Consider adding /Users/dhs/documents/fluttersdk/flutter/bin to the front
      of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 12fccda598 (32 hours ago), 2023-09-19 13:56:11 -0700
    • Engine revision bd986c5ed2
    • Dart version 3.1.2
    • DevTools version 2.25.0
    • If those were intentional, you can disregard the above warnings; however
      it is recommended to use "git" directly to perform update checks and
      upgrades.

[!] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    ! Flutter recommends a minimum Xcode version of 13.
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] VS Code (version 1.62.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.21.0

[✓] Connected device (5 available)
    • SM G975F (mobile)       • RZ8M802WY0X • android-arm64   • Android 11 (API 30)
    • Darshan's iphone (mobile)  • 21150b119064aecc249dfcfe05e259197461ce23 •
      ios            • iOS 14.4.1 18D61
    • iPhone 12 Pro Max (mobile) • A5473606-0213-4FD8-BA16-553433949729     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-3 (simulator)
    • macOS (desktop)            • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)               • chrome                                   •
      web-javascript • Google Chrome 98.0.4758.80

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

[!] Flutter (Channel master, 3.15.0-7.0.pre.5, on macOS 12.2.1 21D62 darwin-x64,
    locale en-GB)
    • Flutter version 3.15.0-7.0.pre.5 on channel master at
      /Users/dhs/documents/fluttersdk/flutter
    ! Warning: `flutter` on your path resolves to
      /Users/dhs/Documents/Fluttersdk/flutter/bin/flutter, which is not inside
      your current Flutter SDK checkout at
      /Users/dhs/documents/fluttersdk/flutter. Consider adding
      /Users/dhs/documents/fluttersdk/flutter/bin to the front of your path.
    ! Warning: `dart` on your path resolves to
      /Users/dhs/Documents/Fluttersdk/flutter/bin/dart, which is not inside your
      current Flutter SDK checkout at /Users/dhs/documents/fluttersdk/flutter.
      Consider adding /Users/dhs/documents/fluttersdk/flutter/bin to the front
      of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision be085a9229 (45 minutes ago), 2023-09-25 00:37:04 -0400
    • Engine revision 3ea1174ecf
    • Dart version 3.2.0 (build 3.2.0-191.0.dev)
    • DevTools version 2.28.0-dev.12
    • If those were intentional, you can disregard the above warnings; however
      it is recommended to use "git" directly to perform update checks and
      upgrades.

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/dhs/Library/Android/sdk
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for
      more details.

[✓] Xcode - develop for iOS and macOS (Xcode 13.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 13C100
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] IntelliJ IDEA Ultimate Edition (version 2021.3.2)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin version 65.1.4
    • Dart plugin version 213.7228

[✓] VS Code (version 1.62.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.29.0

[✓] Connected device (3 available)
    • Darshan's iphone (mobile) • 21150b119064aecc249dfcfe05e259197461ce23 • ios
      • iOS 15.3.1 19D52
    • macOS (desktop)           • macos                                    •
      darwin-x64     • macOS 12.2.1 21D62 darwin-x64
    • Chrome (web)              • chrome                                   •
      web-javascript • Google Chrome 109.0.5414.119

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

[!] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    ! Flutter recommends a minimum Xcode version of 13.
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] VS Code (version 1.62.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.21.0

[✓] Connected device (5 available)
    • SM G975F (mobile)       • RZ8M802WY0X • android-arm64   • Android 11 (API 30)
    • Darshan's iphone (mobile)  • 21150b119064aecc249dfcfe05e259197461ce23 •
      ios            • iOS 14.4.1 18D61
    • iPhone 12 Pro Max (mobile) • A5473606-0213-4FD8-BA16-553433949729     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-3 (simulator)
    • macOS (desktop)            • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)               • chrome                                   •
      web-javascript • Google Chrome 98.0.4758.80

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

This issue is also present in older versions.

This is expected, by default the Canvas clip region is infinite, you can start painting with a call to Canvas.clipRect(Offset.zero & size);.

Closing this as working as intended.


DOH Client stops responding after internet access disruption

Greetings
I am not sure if this is a problem.
My network uses the DOH client along with a pihole for DNS. Client machines use port 53 udp/tcp for DNS from the pihole. The pihole uses the DOH client for DNS requests. The DOH client then uses Google DOH servers. The DOH client runs in a container on docker on a macvlan with it's own unique network IP. As does the pihole.
The network has a pfsense router/firewall. I did an OS update for the pfsense which, in turn, stopped internet access for about 2 minutes. After internet access was restored I noticed DNS problems. When I tried dig using the DOH client as source, I got a "no response from server". I restarted the DOH client and dig returned a normal and successful result.
I applied a second update to the pfsense a day later, again blocking internet access for about 2 minutes. I had the same issue with the DOH client. A simple docker container restart solved the problem.
To be fair I did not wait more than a couple of minutes after internet access was restored before restarting the DOH client container. It is possible that normal function would have resumed at some point but I did not want to wait and find out.
So I am not sure if this is a problem or expected behaviour. My expectation was that the DOH client would resume connectivity with the Google DOH servers without container restart. But perhaps I did not wait long enough. In any case, I thought I would let you know.
best regards

Yes, this is a known problem.
The issue mainly lies on the connection reusing in Go’s HTTP2 library. Go does not know the old connection is already unusable, and still tries to reuse it to send requests.
I have tried very hard to workaround this issue in various ways, for example, creating a new connection pool whenever a timeout is detected. I could only get it a little bit better, not completely perfect.
I also added a NetworkManager trigger script to automatically restart doh-client whenever there is a network change. However, this only works if the system is using NetworkManager, and the disconnection is at the NIC level.
Currently, I can’t think of a better solution… I will appreciate it if you can provide any.

Thank you for the prompt and very informative response. I will take a look and see if I can contribute - not really a go programmer per se. I will close and potentially submit a PR.


Add Mine's blog Citizen Statistician

Thanks @Athanasiamo!

Thank you for adding your blog to the list and for making free and open R content 😊 🥳 🎉


Firestore crashes after Firebase Signoff - Missing a feature to stop listening?

Hi,
When i run the code below, it all works fine, until i sign off. The Widget containing the StreamBuilder is unloaded by setting _currentUser = null.
I am not sure what the issue is, on one side i expect the listener to halt when the authstate is changed. As the listener is not halted the security error is logical but should in my opinion have been picked up by  if (snapshot.hasError).
On the other hand, i would also find it logical if it were my responsibility to close the listener before signing the user out. A method i have not been able to locate.
Snippet of code which runs:
    return new StreamBuilder<QuerySnapshot>(
        stream: Firestore.instance
            .collection('expenses')
            .where("owner", isEqualTo: _currentUser.uid)
            .where("status", isEqualTo: choice.statusCode)
            .where("expenseDate", isGreaterThanOrEqualTo: _cutOffDate)
            .orderBy("expenseDate", descending: true)
            .snapshots,
        builder: (BuildContext context, AsyncSnapshot<QuerySnapshot> snapshot) {
          if (snapshot.hasError)
            return new Center(
              child: new Column(
                children: <Widget>[
                  new Icon(Icons.cloud_off),
                  new Text('An error has occured'),
                ],
              ),
            );

Works Ok throughout the app. Until the users sign's off:
Future<Null> _handleSignOut() async {
    print("_handleSignOut");
    try {
      setState(() {
        _currentUser = null;
      });

      await _googleSignIn.signOut();
      await _auth.signOut();

      print("_handleSignOut Completed");
    } catch (error) {
      print(error);
    }
  }

Logs
I/flutter (19097): _handleSignOut Completed
I/System.out(19097): com.google.firebase.firestore.FirebaseFirestoreException: PERMISSION_DENIED: Missing or insufficient permissions.
D/AndroidRuntime(19097): Shutting down VM
E/AndroidRuntime(19097): FATAL EXCEPTION: main
E/AndroidRuntime(19097): Process: com.qlouder.expenses, PID: 19097
E/AndroidRuntime(19097): java.lang.NullPointerException: Attempt to invoke virtual method 'java.util.List com.google.firebase.firestore.QuerySnapshot.getDocuments()' on a null object reference
E/AndroidRuntime(19097): 	at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$EventObserver.onEvent(CloudFirestorePlugin.java:137)
E/AndroidRuntime(19097): 	at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$EventObserver.onEvent(CloudFirestorePlugin.java:119)
E/AndroidRuntime(19097): 	at com.google.firebase.firestore.zzi.onEvent(Unknown Source)
E/AndroidRuntime(19097): 	at com.google.android.gms.internal.zzevc.zza(Unknown Source)
E/AndroidRuntime(19097): 	at com.google.android.gms.internal.zzevd.run(Unknown Source)
E/AndroidRuntime(19097): 	at android.os.Handler.handleCallback(Handler.java:751)
E/AndroidRuntime(19097): 	at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime(19097): 	at android.os.Looper.loop(Looper.java:154)
E/AndroidRuntime(19097): 	at android.app.ActivityThread.main(ActivityThread.java:6077)
E/AndroidRuntime(19097): 	at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(19097): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
E/AndroidRuntime(19097): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:756)

Flutter Analyze
flutter analyze
Analyzing /Users/arno/AndroidStudioProjects/...
No issues found!
Ran in 6.6s

Flutter Doctor
[✓] Flutter (on Mac OS X 10.13.2 17C88, locale en-NL, channel alpha)
    • Flutter at /Users/arno/flutter
    • Framework revision 8f65fec5f5 (3 weeks ago), 2017-12-12 09:50:14 -0800
    • Engine revision edaecdc8b8
    • Tools Dart version 1.25.0-dev.11.0
    • Engine Dart version 2.0.0-edge.d8ae797298c3a6cf8dc9f4558707bd2672224d3e

[✓] Android toolchain - develop for Android devices (Android SDK 27.0.1)
    • Android SDK at /Users/arno/Library/Android/sdk
    • Android NDK at /Users/arno/Library/Android/sdk/ndk-bundle
    • Platform android-27, build-tools 27.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] iOS toolchain - develop for iOS devices (Xcode 9.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.2, Build version 9C40b
    • ios-deploy 1.9.2
    • CocoaPods version 1.4.0.beta.2

[✓] Android Studio (version 3.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] Connected devices
    • Android SDK built for x86 • emulator-5554                        • android-x86 • Android 7.0 (API 24) (emulator)
    • iPhone X                  • F0BB54B0-B069-490B-A231-200E104E3FDF • ios         • iOS 11.2 (simulator)

This issue is specific to the Firebase Authentication plugin. I'm gettng the same logs without using any other plugins.
Is there any update on this?

I'm also experiencing this.
Are there any developments on this issue?

I believe that the issue probably no longer happens because CloudFirestorePlugin.java has been rewritten to include this null check
    if (querySnapshot == null) return new HashMap<>();

If I am mistaken please provide a test case app and I'd be happy to look into it further.

@Arno-Z
This issue has been moved to https://github.com/FirebaseExtended/flutterfire/issues/920. Any further collaboration will be done there.


Add Saikrishna0422 as contributor

Pull Request Template
What have you Changed(must)
I added palindrome program in java. Can you please check it out once...?
Issue no.(must) -
Pr will be close and marked as spam. If issue number not found or issue was assigned to someone else.
Marking as spam can block your account from HacktoberFest.
Self Check(Tick After Making pull Request)

[ ] This issue was assigned to me if not it will be marked as spam.
[ ] My file is in the proper folder
[ ] I am following clean code and Documentation.
[ ] I have added the title and what program will do first in the file
[ ] I have named the file as (Problem #). (Problem Title(in Camel Case)).(extension)
palindrome in java

README - How to Contribute

@SaiKrishna0422 you have to mention the issue number in the PR Body. Please go through the contribution guidelines.


[GLUTEN-1864][VL] feat: Support bucketed read

What changes were proposed in this pull request?
Support bucketed read
(Fixes: #1864)
How was this patch tested?

@PHILO-HE @rui-mo Can you please help review this?  BTW, not sure why the CI fails

Hi @WangGuangxin, there is a compilation error reported from ClickHouse CI:
clickhouse/src/main/scala/io/glutenproject/backendsapi/clickhouse/CHTransformerApi.scala:38: error:
class CHTransformerApi needs to be abstract, since method genInputPartitionSeq in trait TransformerApi of type

@WangGuangxin can you please do a rebase? There's a minor conflict in FileScanExec
-yuan

@WangGuangxin can you please do a rebase? There's a minor conflict in FileScanExec
-yuan

rebased

please rebase


[SmartPeakCLI] Error when provided mzML directory as a symbolic link on Linux

Describe the bug
SmartPeakCLI expects its input files and data files to be contained in the same execution directory. However, the bioinformatics pipeline in my organization is structured so that mzML data files are contained in a directory separate from the SmartPeak execution directory. To get around this, I created a symbolic link within the SmartPeak execution directory that points to the actual mzML data directory on the computing cluster.
However, SmartPeakCLI does not detect the symlink'd directory named "mzML" at all, and attempts to create the mzML input directory. This causes a filesystem conflict since there is already a symbolic link named "mzML," the execution halts due to this error.
To Reproduce
Steps to reproduce the behavior:

Collate all SmartPeak input files into the SmartPeak execution directory, except the mzML files folder
Create a symbolic link ln -s /path/to/mzML /smartpeak/mzML from the directory containing mzML files and deposit the link named "mzML" into the SmartPeak execution directory
Run SmartPeakCLI
See error

Expected behavior
SmartPeak accepts the symbolic link to the mzML directory invisibly as if it were a "real" directory, and executes the workflow normally.
logs

Linux
smartpeak_log_2021-09-20_10-17-20.csv

Version information

OS: CentOS Linux 7 (Core)
SmartPeak Version 1.12.0

Additional context
This would also be solved by https://github.com/AutoFlowResearch/SmartPeak/issues/417, providing a separate CLI option for the mzML input directory.

Thanks for for submitting the issue, in order to use symlinks for any files or folders used by the SmartPeakCLI please make sure you provide the full path for both the target and the link_name like so
ln -s /common/.../path/to/mzML  /common/.../path/to/symlink/mzML
It is also recommended to provide the full path to the sequence.csv file should you opt for using symlinks in your datasets like so
./SmartPeakCLI -l /common/.../dataset/sequence.csv
Relative paths has proven to be unreliable when the issue was reproduced locally while providing full paths works as expected, however let us know if this doesn't workout either.


decode method for batch_converter

Hi
I have been working with some of the models from the hugging face library and their tokenizers have a .decode() method associated with them. it seems that 'batch_converter' is the esm equivelent of huggingfaces 'tokenizer', but I can't find a similar method to map back from ids to strings. Is there one?
Thanks

Hi @wjs20: Yes, you can do this with ESM. Given an alphabet: Alphabet and a list of token ids token_ids: List[int], you can recover the corresponding string with ''.join(alphabet.get_tok(i) for i in token_ids).
Hope this helps!


First NumPad+Enter does not produce new line when switching from diff to normal editor

I have this issue since a couple of months and only now realized how to reproduce. So I do not think it is related to the keybinding service context change we did:

open a diff from the git viewlet and copy a line from the right hand side
use quick open to jump back to another editor that is not a diff
press Enter
=> you do not get a new line

I updated the title, I think this only happens for me when I use the Enter on the numpad keyboard. I hope this is not some weirdness with my Mac keyboard and Mac OS, maybe you try to reproduce on Windows?

hmm, I cannot reproduce:

@alexandrudima let's debug on my Mac tomorrow, might be very specific to the OS and keyboard.

@bpasero Adding to November so we don't forget about this.

I am fine closing this given the work we did in this area.


Conda

Create a bioconda recipe using the nextclade recipe as a template.

Bioconda recipes pull request: https://github.com/bioconda/bioconda-recipes/pull/44625


feat: Initialize Jupyter Book

The following additions are made:

Added jupyter book configuration and intro markdown.
Added readthedocs yaml configuration
Added requirements text file to list dependencies
Added dependabot
Added logo

Ref: #14

Self-merging this... seems to work.


BIGTREETECH PITFT support?

Love this project!
Any way you could add support for the BIGTREETECH PITFT screens? Either the 4.3", 5", or 7" (but 5" or 7" preferred).
https://www.biqu.equipment/collections/lcd/products/bigtreetech-pi-tft43-v2-0-screen-board?variant=39840251936866.
Not sure if you'd keep the PI mounted to the screen, or keep it in the tray (probably tray? though that'd require a longer DSI cable, which should be fine.)

Steve's original project has a set of 5" files that are easily adaptable and set the TFT on the lid above the display. I don't have access to a PITFT myself, but if you're willing to fit test, I'm willing to make the adjustments for you.
I'll also take a look at the 7" and see what I can do with that. Bear in mind the case is 7" wide, so it may look slightly awkward.

I've got CAD files for the display and Steve's mounts as reference. It looks like both the 5" and 7" will mount fine. The longer DSI cable is going to be necessary, btw.
I should have something for you to test before end of week. Which display are you getting, or do you have one already?

Do what's best for you, dude. If you want the 7", someone else will come along to test the 5". 🙂

Haha, I definitely get what you're saying, just a hard decision for me. Ok, I'm going to go with the 5".

Heya, Majawat. Hope you're well. I'm almost done with some bugfixes and such to get 0.9.7 out the door. Getting your Pi TFT going is next on my design list.
The simplest approach is to attach a hollow pillar to the Raspberry Pi screw holes in the back of the TFT. The ribbon cable can run through a hole into the center. I'm planning to make this pillar part of a half-length case lid that will sit up front.
I want to ask a few questions before I get too far, though.

What mounting hardware does the TFT come with? The Amazon page shows brass standoffs and mentions M2.5 screws but doesn't list what hardware comes it ships with.
Will the screen look okay without an outer protective panel?

Thanks!

Lovely! I got the 5" last week and attached it just to get KlipperScreen working to play with.

No other hardware. Just the standoffs, screws, screen, and short cable.
I think so! There's a small bezel around the screen otherwise no features.

(Forgive the mess)

There is a small potential clearance issue with the display cable on the left. Or the brightness dial on the top right.
Let me know if you need any other info

Thanks a ton for the pics! Unexpected and super helpful!
Can you tell me how long those standoffs and screws are? I'm probably going to hijack them to help mount the screen, rather than using the outer screw holes.

PiTFT Test 1.zip
This is a test for fit file. If it works, the rest of the mount should work and I'll send you a full STL for the lid/stand combo.
Steps:

Add the standoffs to the TFT in the Raspberry Pi holes;
The standoffs should fall in to the holes in the tray;
You should be able to use the stock 2.5mm screws to then tighten it.

If anything doesn't go as planned, lemme know! I guessed at the size of the holes for the standoffs. Right now they're 6.5mm, which should be loose enough. If they could be tighter or don't fit at all, likewise let me know.
Thanks again for testing this!

Seems pretty perfect.

I looked at the standoff holes, they're slightly big, but it's stable without needing to be tighter.

Lid - PITFT.zip
Awesome! Here's the TFT mount, then. This is a half lid so that you can customize the back half still. I haven't uploaded that template yet but will soon.
I hope I got the slot for the flat ribbon cable in the right orientation.

I think I'm a bit confused. Where is this supposed to go on the box? Up top like this?

I was thinking it would have gone in the front, like here instead:

Also, it would probably be better if the cable came in through the side instead of the top if possible.

I think I'm a bit confused. Where is this supposed to go on the box? Up top like this?

Yes indeed. This is the format for the Pi TFT that Steve's case uses, and I admit I took the placement from him. The normal printer display goes below so that they appear stacked at an angle with the Pi TFT above.
Quick render:

I was thinking it would have gone in the front, like here instead:

The 12864 or other LCD screen usually goes there. Are you planning to do entirely without? I can adapt the Pi TFT stand for the front easily enough, though I do still need to get the top version finished.

Also, it would probably be better if the cable came in through the side instead of the top if possible.

Gotcha. I'll add a side cutout for the wire. Do you ever use the top cable port or any wiring on the other sides? Any issues with cable reach?

0.9.7 is almost packed up for release. When it's done today I'm going to create the 0.9.8 branch to add this and the MOSFET mount.
FYI, I also have a half-size lid to add that will go behind the Pi TFT screen and cover the back half of your case (with a handle, too).

The 12864 or other LCD screen usually goes there. Are you planning to do entirely without?

Yep! I'm running Klipper on my RPI for an Ender 5 Plus. None of which supports the original screen without heavy software modifications (a different Klipper fork). So I'll only be using the PITFT.
I see no issues with the top print, so I'd call that one good!
(Sorry for the close/reopening, my finger slipped as I typed)

Awesome! I'll go ahead and commit the Pi TFT lid, but I'll leave this issue open. It shouldn't take too much time to attach the modify a display template now that the fit work is done. I'll plan to have that to you (sometime =) this week.

Howdy Majawat. Hopefully this works and is what you were looking for.


[Umbrella] Release 0.7.0

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

Describe the proposal
Release Apache Uniffle 0.7.0
Task list

[x] Bump master to 0.8.0-SNAPSHOT.
[x] Checkout branch-0.7.
[ ] Tag and release 0.7.0-rc1.

[ ] Backport necessary fixes from master to branch-0.7.
[ ] Bump project version to 0.7.0 in branch-0.7.
[ ] (GitHub) Tag 0.7.0-rc1.
[ ] (SVN) Upload tarball, checksum and signature to .../0.7.0-rc1/.
[ ] Update release note on Uniffle website.
[ ] Vote on<EMAIL_ADDRESS>[ ] Vote on<EMAIL_ADDRESS>

[ ] Tag and release 0.7.0-rc2 (optional).

[ ] Cancel the 0.7.0-rc1 vote on corresponding mailing lists.
[ ] (Same process as above).

[ ] Tag and release 0.7.0.

[ ] (SVN) Move the artifacts under 0.7.0-rc? to 0.7.0.
[ ] (GitHub) Tag 0.7.0 to 0.7.0-rc? and upload the artifacts.
[ ] Update download link on Uniffle website.
[ ] Bump project version to 0.7.1-SNAPSHOT in branch-0.7
[ ] Post an announcement on<EMAIL_ADDRESS>

Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

I don't know why the step of Bump master to 0.8.0-SNAPSHOT is the final step ? It looks unrelated with the tag creating

I don't know why the step of Bump master to 0.8.0-SNAPSHOT is the final step ? It looks unrelated with the tag creating

Make sense, updated.

Do we have a release guide? like https://linkis.apache.org/zh-CN/community/how-to-release/
I'm not familiar with Apache release.

Do we have a release guide? like https://linkis.apache.org/zh-CN/community/how-to-release/

I don't think there is one yet. You can reference this link, and ask any questions in the current thread.
Cc @jerqi

How to deploy my gpg key to uniffle svn? Here: https://dist.apache.org/repos/dist/dev/incubator/uniffle/KEYS @kaijchen .

How to deploy my gpg key to uniffle svn? Here: https://dist.apache.org/repos/dist/dev/incubator/uniffle/KEYS

Need help from PPMC, Cc @jerqi.

Need help from PPMC, Cc @jerqi.

OK
Besides, need I do the mvn deploy operation? Or @jerqi

Besides, need I do the mvn deploy operation?

AFAIK, no need for now.

@zuston I've updated the checklist in the issue description.

Hi, what's the status of 0.7.0 release?

I'm working on this.

I have drafted the release. could you help check this? https://github.com/apache/incubator-uniffle/releases/tag/untagged-e126c5971ca7ac9e1d6d @advancedxy @kaijchen @jerqi

https://github.com/apache/incubator-uniffle/pull/322
https://github.com/apache/incubator-uniffle/pull/307
https://github.com/apache/incubator-uniffle/pull/249
The three prs should be highlighted, too.

I have drafted the release. could you help check this? https://github.com/apache/incubator-uniffle/releases/tag/untagged-e126c5971ca7ac9e1d6d @advancedxy @kaijchen @jerqi

Please bump version in branch-0.7 to 0.7.0.
Also, it's recommended to push a tag manually.
git checkout branch-0.7
git tag v0.7.0
git push origin v0.7.0

I have drafted the release. could you help check this? https://github.com/apache/incubator-uniffle/releases/tag/untagged-e126c5971ca7ac9e1d6d @advancedxy @kaijchen @jerqi

Please bump version in branch-0.7 to 0.7.0. Also, it's recommended to push a tag manually.
git checkout branch-0.7
git tag v0.7.0
git push origin v0.7.0

OK. Do we need to set a rc version? @kaijchen

Besides, does the source tarballs need to upload to apache svn before voting this release?

OK. Do we need to set a rc version?

No, because if everything goes well, 0.7.0-rc1 will become 0.7.0.

Besides, does the source tarballs need to upload to apache svn before voting this release?

Yes, the tarball should be named apache-uniffle-0.7.0-rc1-incubating-src.tar.gz.

Yes, the tarball should be named apache-uniffle-0.7.0-rc1-incubating-src.tar.gz.

OK. Could you tell me the steps or commands to build this tarball?

Yes, the tarball should be named apache-uniffle-0.7.0-rc1-incubating-src.tar.gz.

Sorry, no rc1 in tarball name, see https://dist.apache.org/repos/dist/dev/incubator/uniffle/0.6.1-rc2/

Yes, the tarball should be named apache-uniffle-0.7.0-rc1-incubating-src.tar.gz.

OK. Could you tell me the steps or commands to build this tarball?

And how to upload this?

I heard from @jerqi that we just need to do source release.

OK. Could you tell me the steps or commands to build this tarball?

Since we are making source release only, you can use git-archive to create the tarball.

And how to upload this?

Put the tarball, checksum and signature in SVN, and upload it.
See: https://linkis.apache.org/zh-CN/community/how-to-release/#3-发布apache-svn仓库

You can also refer to https://kvrocks.apache.org/community/create-a-release

Yes, the tarball should be named apache-uniffle-0.7.0-rc1-incubating-src.tar.gz.
Edit:apache-uniffle-0.7.0-incubating-src.tar.gz under 0.7.0-rc1 directory.

Done https://dist.apache.org/repos/dist/dev/incubator/uniffle/

Done https://dist.apache.org/repos/dist/dev/incubator/uniffle/

Artifacts looks good, but version should be changed to 0.7.0.

git checkout branch-0.7
git tag v0.7.0
git push origin v0.7.0

Tag should be v0.7.0-rc1 in this case.

You don't change the pom.xml 's version t0 0.7.0.

You don't change the pom.xml 's version t0 0.7.0.

Got it.

You don't change the pom.xml 's version t0 0.7.0.

Got it.

Updated

I have drafted the release. could you help check this? https://github.com/apache/incubator-uniffle/releases/tag/untagged-e126c5971ca7ac9e1d6d @advancedxy @kaijchen @jerqi

#322 #307 #249 The three prs should be highlighted, too.

Updated. https://github.com/apache/incubator-uniffle/releases/tag/untagged-b70804300bb45088ec43

@zuston please refer to the task list in https://github.com/apache/incubator-uniffle/issues/611#issue-1587121237

@zuston please refer to the task list in #611 (comment)

Thanks. I will do remaining tasks tomorrow

I have sent the vote email to<EMAIL_ADDRESS>cc @kaijchen

I have sent the vote email to<EMAIL_ADDRESS>
Thanks.

Comparing to 0.6.1, a bug fix of memory leak is included:

Minor versions are not like patch versions, the changes may be too many to describe in a sentence.
Maybe you can include the link to the (proposed) release note instead when voting in the incubator mailing list.

Minor versions are not like patch versions, the changes may be too many to describe in a sentence.
Maybe you can include the link to the (proposed) release note instead when voting in the incubator mailing list.

It's my fault, I forget changing this.

I forgot deleting the pom.xml.versionBackup files, so do I need to cancel this vote and revote the rc-2 version after fixing? @kaijchen

I forgot deleting the pom.xml.versionBackup files, so do I need to cancel this vote and revote the rc-2 version after fixing? @kaijchen

Yes, but no need to be hurry. You can give one or two days to let people check for other problems, and fix them together in rc2.

@zuston I think it's a good time to fix the problems and release the RC2.

Done. The vote mail has been sent

@zuston Do we need rc3?

@zuston Do we need rc3?

Let's make rc2 as release version directly? WDYT?

@zuston Do we need rc3?

Let's make rc2 as release version directly? WDYT?

We should release rc3, we don't get enough votes because of flaky tests.

We should release rc3, we don't get enough votes because of flaky tests.

OK.

I have checked the branch-0.7 latest commits, it looks all flaky test fixes are all cherry picked. I want to release 0.7-rc3

Let's release 0.7-rc3.

I have checked the branch-0.7 latest commits, it looks all flaky test fixes are all cherry picked. I want to release 0.7-rc3

Let's release 0.7-rc3.

Done

Is it time to release 0.7.0 ?

Is it time to release 0.7.0 ?

We need to vote on<EMAIL_ADDRESS>

Is it time to release 0.7.0 ?

@zuston Remind, we should start to vote in the incubator.

All done.

@zuston You forget bump version to 0.7.1-SNAPSHOT in branch-0.7.

@zuston You forget bump version to 0.7.1-SNAPSHOT in branch-0.7.

Done.


[VEV-03C] Non-Uniform Mapping Declaration Style

VEV-03C: Non-Uniform Mapping Declaration Style

Type
Severity
Location

Code Style

VotingEscrowVesting.sol:L43

Description:
The referenced mapping utilizes a named value type, however, all other declarations do not do so across the codebase.
Example:
mapping(address owner => uint256[]) private _depositedTokens;
mapping(uint256 tokenId => uint256) private _depositedTokensIndex;

mapping(uint256 tokenId => VestingSchedule) vestingSchedules;
mapping(uint256 tokenId => address owner) depositors;

Recommendation:
We advise the named declaration to be omitted, ensuring a uniform mapping declaration style across the code.

Acknowledged, but won't change at this point as it would change the auto-generated external function's return signature, possibly affecting FE implementations.


s/checkedRead/checkedWrite/ in tutorial (typo fix).

Also replaces the more ambiguous "for" with "with".

thanks


[pubsub][test] Add region name to PubSubBrokerWrapper

[pubsub][test] Add region name to PubSubBrokerWrapper
This commit introduces the region name property to the PubSubBrokerWrapper class.
Other changes in this commit include:

Relocating Kafka producer-specific constants to the ApacheKafkaProducerConfig class for better organization.
Dynamically creating the producer based on the pubsub broker in use, replacing the previous hardcoded approach.

How was this PR tested?

Does this PR introduce any user-facing changes?

[x] No. You can skip the rest of this section.
[ ] Yes. Make sure to explain your proposed changes and call out the behavior change.

Thank you, @haoxu07 for the quick reviews! Appreciate it.


Add comctl32 support

I added support for comctl32

In https://github.com/skdltmxn/winapi-rs/blob/comctl32/src/commctrl.rs#L149 you have extra parentheses that aren't needed. I'd comment on the diff, but the diff was too big for github to display it. :disappointed:

I removed parentheses and _PROPSHEETPAGEA since there is typedef below.

Could you rebase this PR, and your other PRs, against master?

Ok, it's rebased

Your msvc tests appear to be testing functions that don't exist at runtime on appveyor. Could you figure out which symbols they are and disable them from testing?

hmm it's strange, I can't find any failure from msvc test logs but only a message saying "Build execution time has reached the maximum allowed time for your plan (40 minutes)."

The issue is that if a program links to a symbol which doesn't actually exist in the DLL, then at runtime the process will error. How the error manifests depends on the environment it is run in, and apparently in the appveyor environment it pops up a dialog saying there is a missing symbol. Since it is automated CI and there is nobody to click that dialog it just hangs until it times out.

Resolved!


LinkedIn Auth Not working: JWT error ''throw new Error('Not enough or too many segments')"

I am able to pass the data to my server and when i debug it, my app shows the correct first and last name.  However when it hits this line of code ..
361: var payload = jwt.decode(token, config.TOKEN_SECRET);
which fails on in jwt.js line 60 -
var segments = token.split('.');
if (segments.length !== 3) {
throw new Error('Not enough or too many segments');
}
the token it gets has no periods and fails saying 'Not enough or too many segments'.  Ive done nothing to the server side.  Im thinking that LinkedIn has changed the way their tokens are formatted and is causing this application to break.

Actually its happening with Google Authentication also.  I suspect Facebook will have the same problem...

@leonaburime Can you open the Dev Tools and see the value of the token in Console? Type localStorage and you should see something like satellizer_token there.

Hi Sahat,
Thank you for responding so quickly.  This is actually on the server-side node.js code. I had to use the node debugger to see it.  This is my token minus the last couple characters im receiving from
225: var token = req.headers.authorization.split(' ')[1];
which is...
CAAXJfDxwfXQBAPZCZCyDlgnhEfcGViqJHWidxBpLLq2CpD5g200oXsiGOYVVnSTKMCFOtPuahElbB3ri1R087TxuM8D79qhcIVpGkVI5ZBnK72UPQCa28mBK0eZAlJfZBzUv8IEFaGvfUfAvAySUqwqYbAJ6IGHRzW9gRmT2pLNftULYKGsqcqTtiPtD3
As you can see there are no periods and this is why the jwt.decode is failing.

Hmmm.. I tried it for Google and Linkedin and the tokens appear identical...

@leonaburime do localStorage.clear() in the browser. That is not a JWT token. Here is what it looks like:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI1N…UwMn0.z7RWMtcKTmQlayQAqkUOGgJEKZgq1nOYLVuSaam4_bo

This was it exactly.  I must have retained bad values in there from when I was testing earlier.  Now though nothing saves to my database.  What code on the server side in the node/server.js file actually saves it to mongodb using mongoose?  I cant find it...

It's this code here:
        // Step 3b. Create a new user account or return an existing one.
        User.findOne({ linkedin: profile.id }, function(err, existingUser) {
          if (existingUser) {
            return res.send({ token: createJWT(existingUser) });
          }
          var user = new User();
          user.linkedin = profile.id;
          user.picture = profile.pictureUrl;
          user.displayName = profile.firstName + ' ' + profile.lastName;
          user.save(function() {
            var token = createJWT(user);
            res.send({ token: token });
          });
        });

Just add a few console.log inside each if-statement and trace it to where the problem is occuring. Also note that I am not handling any error handling there, so be sure to do if (err) console.log(err); as well.


Docker hub push

Ref: #48

#49  👈
main

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

Join @tazarov and the rest of your teammates on  Graphite


Update azure-pipelines.yml for Azure Pipelines

Signed-off-by: Subba Reddy Veeramreddy<EMAIL_ADDRESS>Description:  Added docker and redhat publish steps to azure pipeline
Changes Proposed in PR:

Added triggers for tags
New service connection is needed for scan redhat repo
podman pull and push needs special authfile argument

Fixes: #Github issue id
General Checklist

[x] Updated Added functionality/ bug fix in release notes
[x] Added examples for new feature
[x] Updated the documentation

CRD Checklist

[x] Updated required CR schema

/azp run

/AzurePipelines run

/azp run


Iterate on pull request template.

Summary of the changes included in this PR

Moves the "front matter" to a Markdown comment so you don't necessarily have to delete it.

Reduces a little bit of boilerplate (this is a bit subjective).

Tweaks some formatting (also subjective).

Describe what happens when you use "Fixes [...]".

Tweak the release note block so it should be easier to parse out automatically (using the same syntax as Kubernetes).

Issue(s) addressed by this PR
N/A
Things to consider while reviewing this PR
Suggested release note for the first release which contains this PR
N/A

Merging after discussion w/@ankeesler and @cfryanr.


Make boolean argument explicit in peerInfo.ban(banStatus) readme

The docs seemed to imply that just calling the function would ban the peer but when I looked at the function itself it just sets this.banned = !!val. So the function actually requires a boolean to be passed which is the case in tests. Currently the default is actually to unban the peer if no argument is passed. Perhaps it should default to true?
Finally I noticed that peerInfo.ban() was called after a firewall check but wasn't passed true, so I fixed that as well.

Nice catch! Probably should be this.banned = val !== false

Ah except it can be considered a breaking change so it's wise as you did

Yeah. I can see an argument either way. If we're worried about breaking existing code, they may have assumed that it defaults to true as the docs implied. Even hyperswarm's own codebase makes this assumption. If we decide to default to true, the only code that will have a breaking change is code that intentionally relied on it defaulting to unbanning instead of banning. Which I would assume is a rare case, but I assume people at holepunch might know more about how the library's ecosystem looks like.

Thanks, in 4.5.0