profile
viewpoint

google/go-cloud 7375

The Go Cloud Development Kit (Go CDK): A library and tools for open cloud development in Go.

google/wire 4550

Compile-time Dependency Injection for Go

google/codesearch 2449

Fast, indexed regexp search over large file trees

rsc/2fa 1138

Two-factor authentication on the command line

rsc/c2go 482

C to Go translation tool supporting Go toolchain migration

google/licensecheck 237

The licensecheck package classifies license files and heuristically determines how well they correspond to known open source licenses.

rsc/corpus 187

Corpus of interesting Go code

rsc/benchstat 123

Benchstat computes and compares statistics about benchmarks.

rsc/dbstore 46

Data structure interface to database/sql

rsc/binaryregexp 36

Go regexp for binary/latin-1 data

issue closedgolang/go

proposal: context: add Context.IsCanceled method

please add function like that to the context type: func (c Context) IsCanceled() { select { case <- c.Done(): return true default: return false } } or something like that to simplify context cancelation checking in channelless situations by something like that: if ctx.IsCanceled() { return ctx.Err() }

closed time in an hour

ilyapashuk

issue commentgolang/go

proposal: context: add Context.IsCanceled method

Forgot to close in July.

ilyapashuk

comment created time in an hour

issue closedgolang/go

proposal: regexp: add Regexp.ProgramSize method similar to C++ RE2::ProgramSize

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

go version go1.14.1 linux/amd64

Does this issue reproduce with the latest release?

Yes, checked https://pkg.go.dev/regexp?tab=doc

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> amd64</summary><br><pre> $ go env

</pre></details>

What did you do?

Checked https://pkg.go.dev/regexp?tab=doc for ProgramSize() function

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

What did you see instead?

Have not function of ProgramSize()

closed time in an hour

liangyuanpeng

issue commentgolang/go

proposal: regexp: add Regexp.ProgramSize method similar to C++ RE2::ProgramSize

Forgot to close in July, sorry.

liangyuanpeng

comment created time in an hour

issue commentgolang/go

proposal: reflect: add func (Value) UnsafePointer() unsafe.Pointer

#26070 was retracted. As I remember it, we were picky about importing "unsafe" to get an unsafe.Pointer (and not providing ways to get one otherwise) for two reasons:

  1. It's good practice to call out the unsafe parts of the code clearly, and the import does that.
  2. App Engine needed to be kept from using unsafe.

(2) is no longer a concern, and (1) seems well enough handled by the name v.UnsafePointer, which seems just as clearly "unsafe" as import "unsafe".

So overall this seems like a fine change. It might be worth thinking about for Go 1.17 along with the other unsafe/pointer cleanup.

mdempsky

comment created time in an hour

issue commentgolang/go

proposal: reflect: add Value.CanCall method

(Forgot to close this back in July, sorry.)

sgrodriguez

comment created time in an hour

issue closedgolang/go

proposal: reflect: add Value.CanCall method

Introduction

If you want to call a method with a slice of Value's as input of the method the inner function of call runs diferents checks if one of them fails ie reflect: Call with too few input arguments it panic.

Why not have a method like:

func (v Value) CanCall(in []Value) bool {
  
}

So we avoid panic as we have with CanInteface, CanAddr.

This is the actual checks that call make:

func (v Value) call(op string, in []Value) []Value {
	// Get function pointer, type.
	t := (*funcType)(unsafe.Pointer(v.typ))
	var (
		fn       unsafe.Pointer
		rcvr     Value
		rcvrtype *rtype
	)
	if v.flag&flagMethod != 0 {
		rcvr = v
		rcvrtype, t, fn = methodReceiver(op, v, int(v.flag)>>flagMethodShift)
	} else if v.flag&flagIndir != 0 {
		fn = *(*unsafe.Pointer)(v.ptr)
	} else {
		fn = v.ptr
	}

	if fn == nil {
		panic("reflect.Value.Call: call of nil function")
	}

	isSlice := op == "CallSlice"
	n := t.NumIn()
	if isSlice {
		if !t.IsVariadic() {
			panic("reflect: CallSlice of non-variadic function")
		}
		if len(in) < n {
			panic("reflect: CallSlice with too few input arguments")
		}
		if len(in) > n {
			panic("reflect: CallSlice with too many input arguments")
		}
	} else {
		if t.IsVariadic() {
			n--
		}
		if len(in) < n {
			panic("reflect: Call with too few input arguments")
		}
		if !t.IsVariadic() && len(in) > n {
			panic("reflect: Call with too many input arguments")
		}
	}
	for _, x := range in {
		if x.Kind() == Invalid {
			panic("reflect: " + op + " using zero Value argument")
		}
	}
	for i := 0; i < n; i++ {
		if xt, targ := in[i].Type(), t.In(i); !xt.AssignableTo(targ) {
			panic("reflect: " + op + " using " + xt.String() + " as type " + targ.String())
		}
	}

IMHO will refactor some checks in order to reuse in CanCall.

closed time in an hour

sgrodriguez

issue commentgolang/go

proposal: os: add ReadDir, ReadFile, WriteFile, CreateTemp, MkdirTemp & deprecate io/ioutil

Accepting this issue will obsolete #19660, which proposes renaming ioutil.

rsc

comment created time in an hour

issue closedgolang/go

proposal: gopherbot: add proposal process status box to each proposal issue

Many people filing issues that turn into proposals have no idea what that means. The proposal process is linked from the code contribution guidelines, but reading those is not necessary to file an issue. And because the issue template targets bug fixes, adding more to the issue template is not appropriate either. It would be nice for gopherbot to post a link to the proposal process when an issue becomes a proposal.

Separately, it would also be nice if there were a clear place for information about the status of a proposal. GitHub being what it is, with no pinned comments or anything like that, the only place you can put that information and be sure it will be displayed is in the issue description (the top-most comment box).

So probably what gopherbot should do instead of leaving a comment is to insert and then maintain a basic header at the top of the issue description that clearly states the status of the issue and where it is in the proposal process, along with a link to the proposal process description itself.

To start, it would be enough to insert the header with a link to the proposal process doc.

closed time in an hour

rsc

issue commentgolang/go

proposal: gopherbot: add proposal process status box to each proposal issue

When I wrote the post about this issue, someone reached out to suggest GitHub Projects instead. We've been using that for quite a while now, and it lets us show the status on the right side of the issue. I've also added a link to the proposal process to the description of both the Proposal label and the Proposals issue project. That seems to be working well enough that editing the top comment is not worth the trouble. Closing this issue - completed in another way.

rsc

comment created time in an hour

issue commentgolang/go

proposal: fmt: %p should accept uintptr

It sounds like %#x is fine. Printing uintptr(0) as nil would be pretty surprising. It's an integer, not a pointer.

seebs

comment created time in an hour

issue commentgolang/go

proposal: review meeting minutes

2020-10-28 / @rsc, @griesemer, @ianlancetaylor, @bradfitz, @andybons, @spf13

  • #34974 archive/zip: add File.OpenRaw, Writer.CreateRaw, Writer.Copy
    • no change in consensus; accepted 🎉
  • #40724 cmd/compile: switch to a register-based calling convention for Go functions
    • likely accept; last call for comments ⏳
  • #41583 cmd/go: add go test -skip to skip specific tests
    • likely accept; last call for comments ⏳
  • #41730 cmd/go: allow users to control VCS usage
    • no change in consensus; accepted 🎉
  • #41696 cmd/go: deprecate the -i flag
    • no change in consensus; accepted 🎉
  • #40405 cmd/go: detect proxy redirect loops
    • discussion ongoing
  • #40364 cmd/go: enable listing direct dependency updates
    • likely accept; last call for comments ⏳
  • #42040 container/list: add trimming APIs
    • no change in consensus; declined
  • #32406 crypto/tls: add (*tls.Conn).HandshakeContext and add context to ClientHelloInfo and CertificateRequestInfo
    • commented
  • #40521 crypto/tls: support TLS 1.3 post-handshake authentication
    • discussion ongoing
  • #41790 database/sql: close driver.Connector if it implements an io.Closer
    • commented
  • #40127 encoding/json: add Encoder.EncodeToken method
    • commented
  • #42009 encoding/json: add EvalJSONPointer function to support RFC 6901
    • discussion ongoing
  • #40128 encoding/json: garbage-free reading of tokens
    • commented
  • #41792 flag: validate the name of the flag
    • discussion ongoing
  • #40765 net/http: accept "x-gzip" content encoding value
    • likely decline; last call for comments ⏳
  • #41773 net/http: add Server.OptionsHandler to allow custom handling of OPTIONS *
    • likely accept; last call for comments ⏳
  • #42173 net/http: handle Seek error in range request by sending entire file
    • discussion ongoing
  • #41625 net/mail: allow AddressParser helper code to signal invalid character set
    • discussion ongoing
  • #41733 net/url: add URL.Clone method
    • commented
  • #42026 os: add ReadDir, ReadFile, WriteFile, CreateTemp, MkdirTemp & deprecate io/ioutil
    • discussion ongoing
  • #42201 path/filepath: add Resolve, replacing EvalSymlinks
    • moved from #37113
    • discussion ongoing
  • #42027 path/filepath: add WalkDir (Walk using DirEntry)
    • likely accept; last call for comments ⏳
  • #41896 reflect: add Type.IsEmptyInterface
    • likely decline; last call for comments ⏳
  • #42099 reflect: add Type.QualifiedString
    • likely decline; last call for comments ⏳
  • #42098 syscall: add SysProcAttr.NoInheritHandles on Windows
    • likely accept; last call for comments ⏳
  • #41980 testing: show diffs for incorrect output from Example tests
    • retitled
  • #42102 time: add Time.IsDST() bool method
    • commented
rsc

comment created time in an hour

issue closedgolang/go

proposal: reflect: allow multi-line struct tags

Overview

Go's struct tags has been wildly successful. It has been so successful, in fact, that many projects leverage the reflect.StructTag system to support code generation, struct value validation, storage and retrieval, UI presentation, and a number of other use cases. Tagging allows one structure to be used throughout the layers of the program resulting in having a central location to modify the attributes, yet also allowing customizations to be applied to each of the layers.

The following example is a use case where the struct is used to:

  • Generate a presentation layer (label, description)
  • Generate REST API docs (label, description, json, example, pattern)
  • Deserialize and validate data coming into a REST API (json, pattern)
  • Define how to persist the data in a SQL database (sql)
  • Serialize a response back to the client (json)

All of that meta information together could easily be as complicated as the following:

type Machine struct {
    ID string `json:"id" yaml:"id" description:"UUID auto-generated to identify the machine" pattern:"[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}" sql:"type:varchar(36);not null;unique;primary_key" label:"Machine Id" example="1328149e-15a1-11eb-adc1-0242ac120002"`

    Host string `json:"host,omitempty" yaml:"host,omitempty" pattern:"(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])" description:"Host name for the machine" label:"Host Name" example:"myserver.domain.com" sql:"type:varchar(255)"`

    IPv4 string `json:"ipv4,omitempty" yaml:"ipv4,omitempty" pattern:"(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}" description:"IPv4 address for the machine." label:"IPv4 Address" example:"127.0.0.1" sql:"type:varchar(15)"`
}

Proposal

To improve readability, reduce mistakes, and allow the meta information to continue to scale, a minor backwards compatible change could be applied to the struct tag spec: allow newlines and tabs to exist within the tag. This would enable the following struct definition:

type Machine struct {
    ID string `
        label:"Machine ID"
        description:"UUID auto-generated to identify the machine"
        json:"id"
        yaml:"id"
        pattern:"[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}"
        example="1328149e-15a1-11eb-adc1-0242ac120002"
        sql:"type:varchar(36);not null;unique;primary_key"
    `

    Host string `
        label:"Host Name"
        description:"Host name for the machine"
        json:"host,omitempty"
        yaml:"host,omitempty"
        pattern:"(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])"
        sql:"type:varchar(255)"
    `

    IPv4 string `
        label:"IPv4 Address"
        description:"IPv4 address for the machine"
        json:"ipv4,omitempty"
        yaml:"ipv4,omitempty"
        pattern:"(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}"
        sql:"type:varchar(15)"
    `
}

The resulting structure is much more readable and can help prevent mistakes (ironically, just converting the above example into the more readable format exposed my own mistake of missing an end quote). This allowance would still be backwards compatible with all previous tag definitions. In addition, denoting multi-line content with `` is already a well understood and widely used pattern in the Go community. This would be a natural fit that some probably already expect to work.

These new characters should only be allowed in the spaces between the key:"value" pairs. This would be consistent with the documentation on StructTag:

https://golang.org/src/reflect/type.go?s=30914:30935#L1101

// A StructTag is the tag string in a struct field. // // By convention, tag strings are a concatenation of // optionally space-separated key:"value" pairs. // Each key is a non-empty string consisting of non-control // characters other than space (U+0020 ' '), quote (U+0022 '"'), // and colon (U+003A ':'). Each value is quoted using U+0022 '"' // characters and Go string literal syntax.

Dependencies

  • The Go formatter would need to enforce a style for multi-line tags

Related:

  • Allow multiple keys in key:value pair -- https://github.com/golang/go/issues/40281
  • Go 2: Structured Tags -- https://github.com/golang/go/issues/23637

closed time in 7 hours

gtrevg

issue commentgolang/go

proposal: reflect: allow multi-line struct tags

Closing as duplicate of #38641. (That was only a few months ago, not much about Go has changed since then.)

gtrevg

comment created time in 7 hours

issue commentgolang/go

os/exec: LookPath implicitly searches current directory

The behavior we chose matched the behavior of the default Windows shell at the time. It seems unlikely we could change it now without breaking many Windows programs.

dholmesdell

comment created time in 7 hours

issue commentgolang/go

proposal: flag: validate the name of the flag

FWIW I grepped my Go corpus for flag.(Bool|Int|String...)\("" and turned up exactly one instance of this mistake, in my own code:

github.com/rsc/rsc@v0.0.0-20180427141835-fc6202590229/c2go/main.go:28:	strip   = flag.String("", "", "strip from input paths when writing in output directory")

Apparently I never used that flag!

KimMachineGun

comment created time in 7 hours

issue commentgolang/go

proposal: flag: validate the name of the flag

Another option is to make flag.Bool etc panic but not if you're using a custom FlagSet. That would catch essentially all the easy cases without affecting "advanced" uses.

KimMachineGun

comment created time in 7 hours

issue commentgolang/go

proposal: cmd/go: detect proxy redirect loops

I retitled this to be about adding some way to detect proxy redirect loops, but I admit I don't quite understand the connection to private repos. Did I miss another part of the proposal? Should it be two separate proposals? Thanks.

marwan-at-work

comment created time in 8 hours

issue commentgolang/go

proposal: encoding/json: add EvalJSONPointer function to support RFC 6901

encoding/json does support a generic JSON representation - map[string]interface{} - but it's not really the most efficient or preferred implementation most of the time. Would jsonpointer have to work on every possible struct that can be marshaled or unmarshaled with the json package?

Also, how commonly used is this? Why not keep using one of the choices outside the standard library?

baijum

comment created time in 8 hours

issue commentgolang/go

proposal: crypto/tls: support TLS 1.3 post-handshake authentication

Thoughts, @FiloSottile ?

skyfmmf

comment created time in 8 hours

issue commentgolang/go

proposal: mime should export a CharsetError to allow net/mail.AddressParser to catch errors associated with bad character sets instead of presently ignoring them since they can't be passed back

It doesn't seem like we should change anything for Go 1.16.

For the future, why does mime need to export the CharsetError? Why not net/mail?

tt

comment created time in 8 hours

issue commentgolang/go

proposal: encoding/json: add Encoder.EncodeToken method

EncodeToken seems like a nice analog of Decoder.Token.

I'm less convinced about ClosingToken. If the program doesn't know what syntax comes next, what business does it have encoding JSON token by token?

rogpeppe

comment created time in 8 hours

issue commentgolang/go

proposal: encoding/json: garbage-free reading of tokens

Brad points out that my memory is bad - Token was added after we started making more garbage in interface conversions.

rogpeppe

comment created time in 8 hours

issue commentgolang/go

proposal: encoding/json: garbage-free reading of tokens

It's certainly the case that when I designed this API, everything but string fit into an interface without allocating. TokenBytes seems like a reasonable way to establish a non-allocating tokenizer for those who want it.

rogpeppe

comment created time in 8 hours

issue commentgolang/go

proposal: crypto/tls: add (*tls.Conn).HandshakeContext and add context to ClientHelloInfo and CertificateRequestInfo

I'm not sure what exactly is the state of this proposal. It sounds like https://github.com/golang/go/issues/32406#issuecomment-712117269 is the most recent statement of the changes. Does anyone object to those?

johanbrandhorst

comment created time in 8 hours

issue commentgolang/go

proposal: flag: validate the name of the flag

@andybons says safehtml does this (takes a *flag.Value as a parameter), for what it's worth. Still seems weird.

KimMachineGun

comment created time in 8 hours

issue commentgolang/go

proposal: cmd/go: enable listing direct dependency updates

(If accepted, this would not be until Go 1.17. There's already a lot for Go 1.16.)

icholy

comment created time in 8 hours

issue commentgolang/go

proposal: cmd/go: enable listing direct dependency updates

Based on the discussion, this seems like a likely accept.

icholy

comment created time in 8 hours

issue commentgolang/go

proposal: cmd/go: add go test -skip to skip specific tests

Based on the discussion, this seems like a likely accept.

dprotaso

comment created time in 8 hours

issue commentgolang/go

proposal: net/http: add Server.OptionsHandler to allow custom handling of OPTIONS *

Based on the discussion, this seems like a likely accept.

simonmittag

comment created time in 8 hours

issue commentgolang/go

proposal: net/url: add URL.Clone method

Put another way, if we decide to add net.URL.Clone, what other types will we need to add Clone to? It kind of seems like we'd need to add it to almost any type in the standard library. Is there something special about URL that I am missing?

icholy

comment created time in 9 hours

issue commentgolang/go

proposal: reflect: add Type.QualifiedString

Since we rolled back that change, this seems like a likely decline.

dsnet

comment created time in 9 hours

issue commentgolang/go

proposal: time: add Time.IsDST() bool method

I misunderstood the proposal when I retitled it. It doesn't really make sense for the Location to be answering a question about a Time. The Time has its own Location built in. The method should be on the Time itself: t.IsDST, not t.Location().IsDST(t). I retitled it assuming the method would be on time.Time.

Otherwise, this seems fine (with the method on time.Time). Does anyone object to this?

jufemaiz

comment created time in 9 hours

issue commentgolang/go

proposal: database/sql: close driver.Connector if it implements an io.Closer

Does anyone object to adding this?

tie

comment created time in 9 hours

issue commentgolang/go

proposal: path/filepath: add WalkDir (Walk using DirEntry)

Based on the discussion above, this (including the extra callback for reporting directory read errors) seems like a likely accept.

rsc

comment created time in 9 hours

issue commentgolang/go

proposal: syscall: add SysProcAttr.NoInheritHandles on Windows

Based on the discussion above, this seems like a likely accept.

ianlancetaylor

comment created time in 9 hours

issue commentgolang/go

proposal: net/http: accept "x-gzip" content encoding value

Based on the discussion above, this seems like a likely decline.

melardev

comment created time in 9 hours

issue commentgolang/go

proposal: reflect: add Type.IsEmptyInterface

Since we rolled back that change, this seems like a likely decline.

cuonglm

comment created time in 9 hours

issue commentgolang/go

proposal: testing: show diffs for incorrect output from Example tests

Retitled for the suggestion I made last week, namely show diffs. Does anyone object to that?

komuw

comment created time in 9 hours

issue commentgolang/go

proposal: cmd/compile: switch to a register-based calling convention for Go functions

Based on the discussion above, this seems like a likely accept.

aclements

comment created time in 9 hours

issue commentgolang/go

proposal: archive/zip: add File.OpenRaw, Writer.CreateRaw, Writer.Copy

No change in consensus, so accepted.

saracen

comment created time in 9 hours

issue commentgolang/go

proposal: cmd/go: deprecate the -i flag

No change in consensus, so accepted.

jayconrod

comment created time in 9 hours

issue commentgolang/go

proposal: cmd/go: allow users to control VCS usage

No change in consensus, so accepted.

rsc

comment created time in 9 hours

issue closedgolang/go

proposal: container/list: add trimming APIs

Motivation LinkedLists are a good candidate for creating dynamic sliding windows over streams of data, and maintain some aggregated values for the data captured inside the window. They are suitable because they have O(1) Time complexity to push data to the back of the window, without performance issues of dynamic array/slice size. Also a pointer to the beginning of the window would be simply a pointer to an element in the list to allow O(1) access. But there is one downside to this application: as the stream continues to flow, the LinkedList inside which we are maintaing our window would keep growing in size and there is no way currently in the Go container/list implementation to cut the old data which are past the window off it. Ofcourse I am certain one could think of many more general use cases for the functionalities I am going to propose.

Proposal So I am proposing to add 2 APIs to the Go's LinkedList implementation to provide Left Trim and Right Trim functionality, which would simply let the user cut the list into smaller one which considering the LinkedList structure, could be accomplished by as easy as modifying the root and start/end elements pointers to their neighbours. As an addition a SubList API could also be provided which would allow for cutting both ends based on the provided elements at once.

How Well the how is very simple and I have already mentioned that in the Proposal section, but to be more specific, I have already applied my thoughts on a copy of the Go container/list, which could be used as an ultimate demonstation of my thoughts accompanied with tests. https://github.com/siaminator/linked-list/blob/7c49a02b37803a6ca379a4546b95f2145d433ad9/list.go#L242 https://github.com/siaminator/linked-list/blob/7c49a02b37803a6ca379a4546b95f2145d433ad9/list.go#L259

There is one caveat to this functionality on LinkedList, which is to maintain the correct length of the list after trimming. there is no way other than iterating through the cut part elements to be able to calculate the new lenght of the resulting array. I have took advantage of this iteration to unlink cut elements from each other to faciliate grabage collection.

closed time in 9 hours

siaminator

issue commentgolang/go

proposal: container/list: add trimming APIs

No change in consensus, so declined.

siaminator

comment created time in 9 hours

issue commentgolang/go

proposal: cmd/go: notify about newer major versions

@seh, it really shouldn't be orange or red or blink. The point that we've made repeatedly in this discussion is that the mere existence of v2 does not mean that everyone using v1 needs to be coerced into updating.

Now, if the module was flagged as deprecated (#40357), then that would be appropriate to make orange or red or blink.

That's the fundamental difference between that issue and this one. This issue takes as a given the proposition that if an author has published v2, v1 is deprecated and should no longer be used. That's just not always true, and we should not act as though it is true in the absence of a clearer signal from the module author. #40357 provides that clearer signal.

zachgersh

comment created time in 9 hours

issue commentgolang/go

embed, cmd/go: add support for embedded files

@benitogf Embedding lets you put a file from disk into a []byte in your program conveniently, nothing more. If you have a way to use a dynamic C library that is already in your program in the form of a []byte, then embedding will help you get a disk file there. Otherwise, no.

rsc

comment created time in 10 hours

issue commentgolang/go

proposal: net/url: add URL.Clone method

I still don't understand what exactly is worth calling out in URL's documentation. It is a general property of data that if you want to make a copy before mutating you can do u2 := *u; mutate u2.

And I still don't understand how often this operation is needed on URLs. @ainar-g has seen it, but that establishes existence not frequency.

icholy

comment created time in 10 hours

issue commentgolang/go

proposal: flag: validate the name of the flag

@ianthehat I don't have much sympathy for a program that creates a flag named "". But I also can't tell what your opinion is: the two halves of this line seem to say opposite things:

I don't think this would be an okay breaking change, I would be happy with a panic added to Parse.

KimMachineGun

comment created time in 10 hours

issue commentgolang/go

proposal: path/filepath: add WalkDir (Walk using DirEntry)

@mpx, I hear you, but as I noted above, I disagree. io/fs should be as capable as the existing library routines. If we have filepath.WalkDir, we can have fs.WalkDir too.

rsc

comment created time in 10 hours

issue comment9fans/plan9port

how acme display chinese font

Is the document UTF-8? What font are you using?

ivoidi

comment created time in 10 hours

issue openedgolang/go

proposal: net/http: handle Seek error in range request by sending entire file

In the io/fs proposal, I made the comment that if an fs.File did not support Seek then net/http couldn't serve it when presented by a range request. Many people pointed out that strictly speaking that statement is incorrect: it is always allowed for an HTTP server to respond to a request with a Range header by sending the entire content (the response headers clearly indicate whether ranges or the entire content are being sent).

That said, the net/http server behavior on Seek failure has been here for a long time, long before io/fs. While we could handle a Seek failure by responding with full content, it is less clear to me whether we should. Hence this issue, to make sure the question is properly evaluated.

There are two cases where a Seek failure can happen:

  1. A single range has been requested. The Seek to that range fails. In this case, if we assume the Seek left the file offset at the start of the file, then we can send the whole thing.

  2. Multiple ranges have been requested. The first Seek succeeds but a later Seek fails. In this case, we cannot take back the partial chunks that have already been sent. It seems clear that we must report an error. A complicating factor here is that a File with a “best-effort” Seek might succeed only for “seek to where the file already is,” and if the first range is 0-N, then that first Seek might succeed even though the next one will fail. If we want to try to detect Seek failures before sending any ranges, so that full content can be sent instead, we could try Seeking to the second range, then to the first range, before sending the first range. One of those two should be a non-no-op Seek.

Clearly in both these cases (with the complication in the second), we could detect a Seek failure and send the whole file.

On the other hand, I have vague memories of a browser-based PDF reader being exceedingly slow against Go servers because it was making range requests and getting the full content back and discarding all but the ranges it had requested. (Maybe this was before we supported Range at all, or maybe our Range implementation was sending full content; I don't remember.) So the browser was downloading the same, entire large file over and over and over. Yes, the bug was on the client side, but even a correct implementation in that case (notice the full response and save it) would still just appear to be very slow (but not exceedingly slow) when it downloads an entire (say) 100 MB PDF to display just the first page. It may be that any reasonable server should support range on files being served, and that sending the entire file as a pedantically correct response, instead of giving a clear error that would cause the server author to add Seek support, causes more problems than it avoids.

I honestly don't know what's right here. What we can do is different from what we should do. What does nginx or Apache do if a seek fails while serving a range request? What do other servers do?

/cc @bradfitz

created time in 5 days

issue commentgolang/oauth2

Cannot import the package

For what it's worth, this is the fetch that would have been failing if it was a web issue:

% curl 'https://sum.golang.org/lookup/golang.org/x/exp@v0.0.0-20191227195350-da58074b4299'
565615
golang.org/x/exp v0.0.0-20191227195350-da58074b4299 h1:zQpM52jfKHG6II1ISZY1ZcpygvuSFZpLwfluuF89XOg=
golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4=

go.sum database tree
1746116
+EOpGhQBrMVEcZqC8Dd0+zh6FGUQhufW8pwJZDl//XM=

— sum.golang.org Az3grn6arXlgu9br11PaPzSvFmUgfwILARu8Ea5HI+2kYYb9NigDa6fO/otFxXyj9DMcdE05kd2mgIkGEUqlkTR/CQc=
% 

Most truncations or corruptions would get a syntax error parsing the record.

The only way to get the message you were seeing from a truncation would be if it were truncated after the first line but before the first blank line. That is, to get through to the error being reported, the response to this fetch would need to start with a decimal integer on a line by itself (and not too big or else it would index out of the checksum tree) and not contain any blank lines. The blank line introduces a signed tree root, which the go command would attempt to parse and merge into the local state. There's zero chance of that succeeding without being real and complete.

An in-flight corruption in the first three lines would also produce the error you were seeing, provided that it (1) kept the first line containing only a small decimal integer, (2) did not introduce a new blank line, and (3) left the blank line and everything after it alone.

rakyll

comment created time in 6 days

issue commentgolang/go

embed, cmd/go: add support for embedded files

@burik666, see https://golang.org/s/draft-embed-design for details, but no, you cannot embed a symlink.

rsc

comment created time in 6 days

issue commentgolang/go

embed, cmd/go: add support for embedded files

@Merovius, embed.FS uses value receivers. embed.FS is a one-word struct containing a single pointer, so there's no actual overhead to doing so, but it means you can assign them around and use them without worrying about *s and &s everywhere.

@chabad360, yes, you can embed directories.

rsc

comment created time in 6 days

issue commentgolang/go

proposal: path/filepath: add WalkDir (Walk using DirEntry)

@mpx, I think io/fs needs a walk API at the start, and if filepath.WalkDir exists, then fs.WalkDir should too. That doesn't preclude adding another one later, but it does make it unlikely without a really compelling case. Most importantly, the combination of ReadDir and io/fs mean that some other general walker can be implemented without being required to have OS-specific code in it for efficiency, so having more sophisticated APIs in third-party packages is not as big a problem as it is today.

rsc

comment created time in 6 days

issue commentgolang/go

embed, cmd/go: add support for embedded files

One detail that came up in the implementation review is that "Files" as a singular noun is pretty awkward ("A Files holds ...").

The choice of embed.Files for the name predated both the io/fs proposal and also the support for string and []byte. Given both of those developments, one seemingly sensible way to resolve the "A Files holds" problem is to call it an FS instead of a Files.

Then the three ways to embed & print data are:

import "embed"

//go:embed hello.txt
var s string
print(s)

//go:embed hello.txt
var b []byte
print(string(b))

//go:embed hello.txt
var f embed.FS
data, _ := f.ReadFile("hello.txt")
print(string(data))

That seems clearer about what you get: a string, a []byte, or an FS. That is, most of the functionality of the embed.F* comes from it being an fs.FS, and calling it FS makes that clearer than calling it Files.

I've made that change in my latest draft of the CL implementing package embed, but I wanted to circle back here and see if there are any objections to the name change.

(A more radical change would be to do var f fs.FS instead of var f embed.FS, but that would preclude ever having any method on f other than Open. For example, above, having ReadFile is convenient and would not be possible. And in general we've learned that using a concrete type for something that might want to add methods later is good future-proofing compared to using an interface type directly.)

rsc

comment created time in 6 days

issue commentgolang/oauth2

Cannot import the package

I can't reproduce this.

It means that somehow the record for that go.mod is not matching the checksum in the database. It could be corrupted or it could simply be truncated. The record is loaded from the web but is also cached on disk. A record loaded from the web is not written to the disk cache until after it has been authenticated, though. So if the command is using the on-disk copy, it means the corruption happened after the correct one was written. Or it may be that you didn't have this record cached and were trying to load from the web, and somehow the web result was being truncated or corrupted in transit. Most corruptions or truncations would result in the record not parsing, though, which would produce a different error message.

Anyway, lots of thoughts, no obvious answers. Can you share a bit more about go version, how many machines you see this on, whether it is still happening?

rakyll

comment created time in 6 days

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

I'm OK with '-' because the string means "before Go 1.16" not "after Go 1.16". But I don't want to claim any interest in closing the semver gap. :-)

mvdan

comment created time in 6 days

created tagrsc/grepdiff

tagv1.0.0

grep for diffs

created time in 6 days

push eventrsc/grepdiff

Russ Cox

commit sha 39902dfc2223f2757bb32eff9d8c113a23826d48

grepdiff: add example, go.mod

view details

push time in 6 days

issue commentgolang/go

proposal: review meeting minutes

2020-10-21 / @rsc, @griesemer, @ianlancetaylor, @bradfitz, @andybons, @spf13

  • #40827 annotate which error values should never be wrapped
    • no change in consensus; declined
  • #34974 archive/zip: add File.OpenRaw, Writer.CreateRaw, Writer.Copy
    • likely accept; last call for comments ⏳
  • #42100 build: add ios/amd64 as a GOOS/GOARCH
    • no change in consensus; accepted 🎉
  • #40724 cmd/compile: switch to a register-based calling convention for Go functions
    • commented
  • #40189 cmd/go: add a sub command to manage authentication
    • discussion ongoing
  • #41583 cmd/go: add go test -skip to skip specific tests
    • discussion ongoing
  • #41730 cmd/go: allow users to control VCS usage
    • likely accept; last call for comments ⏳
  • #41696 cmd/go: deprecate the -i flag
    • likely accept; last call for comments ⏳
  • #27628 cmd/go: do not cache tool output if tools print to stdout/stderr
    • no change in consensus; accepted 🎉
  • #40364 cmd/go: enable listing direct dependency updates
    • commented
  • #42040 container/list: add trimming APIs
    • likely decline; last call for comments ⏳
  • #32406 crypto/tls: add (*tls.Conn).HandshakeContext and add context to ClientHelloInfo and CertificateRequestInfo
    • discussion ongoing
  • #41790 database/sql: close driver.Connector if it implements an io.Closer
    • discussion ongoing
  • #41757 flag: Introduce functions for defining rune flag
    • proposal retracted by author; declined
  • #41792 flag: validate the name of the flag
    • discussion ongoing
  • #41974 io/fs, filepath: add more efficient Walk alternative
    • proposal retracted by author; declined
  • #39057 log: add func Default() *Logger
    • no change in consensus; accepted 🎉
  • #40765 net/http: accept "x-gzip" content encoding value
    • commented
  • #41773 net/http: add Server.OptionsHandler to allow custom handling of OPTIONS *
    • commented
  • #41046 net/http: add support for the upcoming "Structured Field Values for HTTP" RFC
    • put on hold
  • #41733 net/url: add URL.Clone method
    • commented
  • #37113 path/filepath: add Resolve, replacing EvalSymlinks
    • discussion ongoing
  • #42027 path/filepath: add WalkDir (Walk using DirEntry)
    • discussion ongoing
  • #42027 path/filepath: add WalkDir (Walk using DirEntry)
    • discussion ongoing
  • #41563 reflect: add StructField.IsExported and Method.IsExported
    • no change in consensus; accepted 🎉
  • #41896 reflect: add Type.IsEmptyInterface
    • commented
  • #42099 reflect: add Type.QualifiedString
    • commented
  • #42098 syscall: add SysProcAttr.NoInheritHandles on Windows
    • commented
  • #41980 testing: Provide ability to inspect output of Example tests
    • commented
  • #42102 time: add Time.IsDST() bool method
    • discussion ongoing
rsc

comment created time in 7 days

issue commentgolang/go

proposal: reflect: add Type.IsEmptyInterface

It's certainly easy to go overboard on helpers. We've come a long way without this one, and NumMethod() == 0 is both clear and correct.

cuonglm

comment created time in 7 days

issue closedgolang/go

proposal: annotate which error values should never be wrapped

Following up on #39155, I propose there be a consistent method to annotate which error values can never be wrapped, such as io.EOF. This would be the first step towards being able to automate detection when illegal wrapping occurs, e.g. causing fmt.Errorf("some message: %w", io.EOF) to panic, or go vet to emit a warning.

A naive way to determine this would likely be to grep for err == in the standard library. (Per the above-linked issue, the use of == instead of errors.Is() is a feature, not a bug.) This list should be linked from the errors package documentation, and there should be an indication that an error is "not wrappable" in the error value (e.g. io.EOF) and function (e.g. io.Reader.Read) documentation.

The aim is to detect and prevent incorrect (but reasonable-looking) code such as:

func (r *MyReader) Read(b []byte) (int, error) {
    n, err := r.underlying.Read(b)
    if err != nil {
        err = fmt.Errorf("reading %q: %w", r.Filename, err)
    }
    return n, err
}

closed time in 7 days

dpifke

issue commentgolang/go

cmd/go: consider including Go's own version in 'go env'

We shouldn't have two different variables. One should be enough, it should be GOVERSION, which should record the output of go version (with the 'go version' prefix and the goos/goarch suffix removed I assume).

There is a separate issue, which is that you can't tell from go version what the base version of Go is. Changing the output to do that seems fine to me. I think I would suggest changing the git hash to "go1.Version+Hash", as in:

go version devel go1.16+a8a337f1f4 Tue Oct 20 16:43:37 2020 -0400 darwin/amd64
mvdan

comment created time in 7 days

issue commentgolang/go

proposal: net/http: accept "x-gzip" content encoding value

We are not trying to support HTTP/0.9 - we removed support for it. Nor are we trying to support hypothetical uses. If there's no actual x-gzip use in the wild, let's not add the complexity here. Do you know of any important need for x-gzip in real-world use cases?

melardev

comment created time in 7 days

issue commentgolang/go

proposal: switch to a register-based calling convention for Go functions

It sounds like everyone involved is on board for doing this in Go 1.17. Adding to proposal minutes for wider visiblity, but seems headed for likely accept.

aclements

comment created time in 7 days

issue commentgolang/go

proposal: testing: Provide ability to inspect output of Example tests

There is a trap here, namely adding infinite new API to package testing as individual needs come up. We need testing to do a limited amount of things. It's already getting hard to remember everything.

Looking at https://play.golang.org/p/969hijP9sMx, the issue I see is not that testing needs new API but instead that the example test output needs to do a better job highlighting the differences, such as by showing a diff. Maybe we should do that instead?

komuw

comment created time in 7 days

issue commentgolang/go

proposal: reflect: add NewAtPtr, ValueAt

The only difference between this API and the existing API is which type gets passed in. NewAt(typ, p) == NewAtPtr(PtrTo(typ), p). And the issue is that PtrTo sometimes requires a map lookup. But that map lookup is only needed for types that are not themselves already in the binary. If type T gets reflect information in the binary, then we also write out *T in the binary. You'd only see this if you constructed T itself at runtime, or if you were using **T or something like that. What is the context in which this occurs?

If T is constructed at runtime, the data is writable, so we could fill in the *T link once and reuse it instead of using the map. (That's not true for a *T built into the binary - there we can't write the link to **T.)

So it seems like in whatever important case we have, we could make PtrTo faster instead of adding new API here.

But would that address the case where you are seeing this? (That is, again, what is the context in which this occurs?)

yazver

comment created time in 7 days

issue commentgolang/go

unsafe: add Add function

I hadn't remembered this but yeah they probably should all go out together as part of a coherent update to unsafe. Thanks for implementing, and let's save for Go 1.17.

rsc

comment created time in 7 days

issue commentgolang/go

proposal: container/list: add trimming APIs

When generics happens, we are likely to deprecate list entirely in favor of new, properly typed APIs. This API was an interesting demo but is essentially deprecated already, certainly frozen.

This seems like a likely decline because we are not modifying this API anymore (ever).

But feel free to use the code as the base of an implementation that does exactly what you want.

siaminator

comment created time in 7 days

issue commentgolang/go

proposal: syscall: add SysProcAttr.NoInheritHandles on Windows

Does anyone object to this change?

ianlancetaylor

comment created time in 7 days

issue commentgolang/go

proposal: syscall: add SysProcAttr.DontInheritHandles on Windows

We don't have any fields beginning with Dont, which is a bit difficult because of the missing apostrophe, among other things. But we do have a bunch of fields and other names that begin with the word "No". So maybe NoInheritHandles would be better. (It can't be InheritHandles because we want inherit to be the default, but the default will be the zero value for this struct field.)

With NoInheritHandles, this seems fine to me.

ianlancetaylor

comment created time in 7 days

issue commentgolang/go

proposal: archive/zip: add File.OpenRaw, Writer.CreateRaw, Writer.Copy

Based on the discussion above, this seems like a likely accept. This is subtle, though, so it would make sense to put off until Go 1.17 at this point.

saracen

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: enable listing direct dependency updates

It sounds like people are saying:

  • In go list direct, direct expands to a list of all the packages directly imported by the current module.
  • In go list -m direct, direct expands to a list of all the modules providing those packages.

That is, direct becomes a pseudo-name like std and cmd and all that expands to this meaning in all commands, not just go list. But like with go list -m all, the meaning of direct changes for go list -m (as it must, since -m is about modules, not packages).

Do I have that right? Does anyone object to that?

icholy

comment created time in 7 days

issue commentgolang/go

proposal: net/http: add support for the upcoming "Structured Field Values for HTTP" RFC

It seems like we should put this on hold for now. We are probably going to have to rethink a bit for HTTP/3, and since there are not many uses of structured field values yet, it might make sense to wait until that work is going on too, to try to deal with potential API changes all at the same time.

For now, we've already seen that nothing prevents using a third-party package for this functionality.

dunglas

comment created time in 7 days

issue commentgolang/go

proposal: flag: validate the name of the flag

The empty string seems unlikely, but I could see someone unfamiliar with how the flag package works trying to use flag.Bool("-b") to add a -b flag. A panic with a clear message would be better than silently installing an inaccessible flag.

Does anyone object to adding this panic (like duplicate registrations currently panic)?

KimMachineGun

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: deprecate the -i flag

Based on the discussion above, this seems like a likely accept. To be clear, Go 1.16 would warn that the flag should not be used (but still complete successfully), and Go 1.17 would remove the flag.

jayconrod

comment created time in 7 days

issue commentgolang/go

proposal: flag: Introduce functions for defining rune flag

(Retracted by author.)

ghost

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: allow users to control VCS usage

Based on the discussion above, this seems like a likely accept.

rsc

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: add go test -skip to skip specific tests

-list already applies to everything - tests, benchmarks, examples - so I think it's probably OK to have -skip do the same (apply to benchmarks; tests and examples were already covered since they are controlled by -run).

Does anyone object to doing this?

dprotaso

comment created time in 7 days

issue commentgolang/go

proposal: net/http: add Server.OptionsHandler to allow custom handling of OPTIONS *

This is a pretty niche thing but seems small enough. Does anyone object to adding this?

simonmittag

comment created time in 7 days

issue commentgolang/go

proposal: net/url: add URL.Clone method

It seems like there are two concerns with this proposal:

  1. How often is this really needed? If not much, then we shouldn't add new API.
  2. When it is needed, why isn't doing a u2 := *u, modify u2 the answer that people should reach for? Why is a new method warranted? (Are there uses other than preparing to modify a URL?)
icholy

comment created time in 7 days

issue commentgolang/go

proposal: reflect: add StructField.IsExported and Method.IsExported

No change in consensus, so accepted.

dsnet

comment created time in 7 days

issue commentgolang/go

proposal: reflect: add StructField.IsExported and Method.IsExported

That's likely to be rolled back.

dsnet

comment created time in 7 days

issue commentgolang/go

proposal: path/filepath: add Resolve, replacing EvalSymlinks

There's clearly new, substantive discussion here. Moving back to Active.

bk2204

comment created time in 7 days

issue commentgolang/go

proposal: log: add func Default() *Logger

No change in consensus, so accepted.

carnott-snap

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: do not cache tool output if tools print to stdout/stderr

No change in consensus, so accepted.

cherrymui

comment created time in 7 days

issue commentgolang/go

proposal: database/sql: close driver.Connector if it implements an io.Closer

Adding to minutes.

tie

comment created time in 7 days

issue commentgolang/go

proposal: database/sql: close driver.Connector if it implements an io.Closer

@kardianos, we'll take care of updating the proposal project status. It needs to go through some discussion before moving to likely accept. Thanks.

tie

comment created time in 7 days

issue commentgolang/go

proposal: annotate which error values should never be wrapped

No change in consensus, so declined.

dpifke

comment created time in 7 days

issue commentgolang/go

proposal: reflect: add Type.IsEmptyInterface

We are probably going to roll back that change - see #42123 - so it looks like we don't need this.

cuonglm

comment created time in 7 days

issue commentgolang/go

proposal: add ios/amd64 as a GOOS/GOARCH

Accepted.

aclements

comment created time in 7 days

issue commentgolang/go

proposal: add ios/amd64 as a GOOS/GOARCH

Sorry, I missed that amd64 is the important bit here, not ios. This is a clear yes.

aclements

comment created time in 7 days

issue commentgolang/go

proposal: reflect: add Type.QualifiedString

We are probably going to roll back that change - see #42123 - so it looks like we don't need this.

dsnet

comment created time in 7 days

issue commentgolang/go

reflect: NumMethod includes non-exported methods for interface types

Filed #42123 to roll this back. It looks like it breaks too much.

mdempsky

comment created time in 7 days

issue openedgolang/go

reflect: roll back NumMethod change for interfaces

The NumMethod change for interfaces (#22075) broke code in the standard library that assumed for interfaces that NumMethod() == 0 if and only if it is an empty interface. There is also a lot of code testing NumMethod() against 0 in the wild. See attached nummethod.txt. There are dups in that file but still, there's a bunch.

All that code will break with the change. We should probably roll it back and live with the difference between NumMethod on interfaces and NumMethod on non-interfaces.

nummethod.txt

created time in 7 days

issue commentgolang/go

proposal: add ios/amd64 as a GOOS/GOARCH

For android, what we do is GOOS=android but "linux" is implied as a build tag. Is the suggestion to do the same here? GOOS=ios but "darwin" is implied as a build tag?

aclements

comment created time in 7 days

issue commentgolang/go

proposal: path/filepath: add WalkDir (Walk using DirEntry)

There is one detail that still bothers me that might be worth changing.

Suppose you want to do a walk but ignore all testdata directories. In the WalkFunc you write:

if filepath.Base(path) == "testdata" {
    return filepath.SkipDir
}

That works fine. But behind the scenes, filepath.Walk already did a full directory read from testdata before calling the WalkFunc. Because the dir ended up being skipped, that ReadDir was entirely wasted effort. Often one reason to skip a directory is that it's big (like a cache). Doing a ReadDir on a big directory that you are going to skip is unfortunate. (It's nice that it's a ReadDir and not a Readdir, so you didn't spend tons of time calling Stat on every entry on Unix systems, but still, it's wasted effort.)

One of the complications of #41974 was defining that both entry and exit from a directory appeared in the iteration; the equivalent here would be calling the WalkFunc twice for a directory: both before and after. We clearly do not want to do that.

But I wonder if instead we should define that a directory read error (only) can result in a second call to the WalkFunc with the same path, to report the error. That is, to walk a directory, WalkDir does basically:

err := walkFn(path, d, nil)
if err != nil && err != SkipDir {
    return err // usual early out
}
if err != SkipDir {
    all, err := ReadDir(path)
    for _, child := range all {
        ... recursively handle path+/+child.Name() ...
    }
    if err != nil {
        walkFn(path, d, err)
    }
}

In addition to avoiding an expensive ReadDir that is not needed, this has the benefit of presenting the early children of a directory even if the directory read fails later in the directory. The current filepath.Walk throws away any children that were found when a read error also occurs. That's clearly a mistake, which would be good to fix in a new API but may be too subtle to fix in the existing API. And then the error is reported after the children that are available.

The one downside of course is that the WalkFunc is called twice for a directory with a read error: once for the existence of the directory itself, which is error-free, and then again when the directory read fails. This seems like a clearer separation of concerns, but at the cost of two calls with the same path.

Over on https://github.com/golang/go/issues/41974#issuecomment-708597849, @ianlancetaylor wrote:

As far as I can tell the Exiting method exists only to clearly report an error from ReadDir on a directory. Since errors are rare, I agree that this seems like an undesirable API complication. Personally I think it would be OK for the error case to return the directory a second name--same Name, same IsDir--but with a non-nil Err.

The "extra callback only for directory read error" I'm suggesting here is the equivalent to what Ian suggested, but for the callback API. It seems like a reasonable solution to me.

What do other people think about doing this?

rsc

comment created time in 7 days

issue commentgolang/go

proposal: path/filepath: add WalkDir (Walk using DirEntry)

I've retracted #41974. Let's focus on this (WalkDir) as the replacement for Walk. What I like most about this API is that updating existing code requires almost no effort at all: change Walk to WalkDir, change FileInfo to DirEntry, maybe rename info to d, and in 90% of cases you're done and have a more efficient file system traversal that does the same thing as the original code.

rsc

comment created time in 7 days

more