Re: [go-nuts] Possible Go 2 proposal for built-in Remove method for Slices.

Dnia 2021-02-04, o godz. 00:30:57 Selahaddin Harmankaya napisał(a): > There are obviously more things to consider Slice is not an array, it is a _view_into_ an array. Many such views into the same array may exist simultaneously. A "remove element from _slice_" operation always must make a new

Re: [go-nuts] x/image/font: Font serialization

If you don’t write the font “exactly” you might run into copyright/TOS problems. In most cases though, you are better off using standard fonts and using the correct name in the pdf - and let the viewer find/replace the font - you will not have a problem in that case. > On Feb 5, 2021, at

Re: [go-nuts] x/image/font: Font serialization

On Sat, Feb 6, 2021 at 9:18 AM Nigel Tao wrote: > It doesn't have any in-memory representation of the not-frequently-used > parts, including the actual glyph vectors. > Correction: it doesn't have not-frequently-used or too-big-to-cache parts, and glyph vectors are the latter. Avoiding "takes

Re: [go-nuts] x/image/font: Font serialization

On Fri, Feb 5, 2021 at 8:56 PM Sebastien Binet wrote: > ‐‐‐ Original Message ‐‐‐ > On Friday, February 5th, 2021 at 2:10 AM, Nigel Tao > wrote: > > Two []byte values aren't double the memory if the slices share the same > backing array. > > sure, I was thinking more of the memory taken

Re: [go-nuts] reflect and generic type or func?

It's impossible to tell, as that code is invalid. You didn't define `a`, so we don't know what its type should be. If you intended to add a `var a String[int]`, for example, I would assume it should print something like "String[int]". On Fri, Feb 5, 2021 at 4:05 PM xie cui wrote: > type String

Re: [go-nuts] Code coverage in error cases when compared to other languages

On Thu, Feb 4, 2021 at 4:35 PM Charles Hathaway wrote: > Hey all, > > Thomas, I agree that the code you provide would benefit from unit tests, > but I would like to focus my question on the very common case which simply > throws the error without additional edge cases, such as the example given

[go-nuts] reflect and generic type or func?

type String [T any] struct { str T } fmt.Println(reflect.TypeOf(a).Name()) in generic code, what is the output of relfect type name of generic type? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

it may be useful to avoid repetition, for example if implementing stacks, you have to create the "pop(), push(), top()" before starting to code what you want. Maybe there's place for this utility functions under the "container/" package (like "container/slice"), where you could do things like:

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

On Fri, Feb 5, 2021 at 3:46 PM Fernando Meyer wrote: > I understand the pragmatism behind having or not features in the language and > its standard library. But, almost all the golang projects I've worked with > implement their own utility function to remove elements from a slice, > sometimes

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

On Fri, Feb 5, 2021 at 6:46 AM Fernando Meyer wrote: > I understand the pragmatism behind having or not features in the language > and its standard library. But, almost all the golang projects I've worked > with implement their own utility function to remove elements from a slice, > sometimes

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

I understand the pragmatism behind having or not features in the language and its standard library. But, almost all the golang projects I've worked with implement their own utility function to remove elements from a slice, sometimes with order in place, others not. Mostly always these

Re: [go-nuts] prevent unnecessary escape to heap

On Thu, Feb 4, 2021 at 10:32 PM Steve Roth wrote: > > How can I implement a writeByte function, against an unknown io.Writer > implementation, that doesn't allocate heap memory? > The only way I'm aware of achieving this is proving to the compiler that buf is safe to be kept by w by moving buf

[go-nuts] Re: Cookies in http package

Forgot to add, Double-quotes are being dropped with log message. as per RFC6265 a cookie-value can be enclosed in double-quotes. Multiple issues were mentioned in github regarding this behavior but either closed or stalled, Why isn't this

[go-nuts] Cookies in http package

func main() { c := { Name: "cookie", Value: "\"hello\"", } fmt.Println(c) } 1. Why too much work being done while printing , shouldn't this be done only once? 2.

Re: [go-nuts] Failed to install golang.org/x/tools

On Mon, Feb 1, 2021 at 11:36 PM eric...@arm.com wrote: > > Os: ubuntu 18.04 > Arch: arm64 linux > go version: go1.15.7 > What did I do: > $ go get -u golang.org/x/tools/... > package mvdan.cc/gofumpt/format: unrecognized import path > "mvdan.cc/gofumpt/format": reading

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

See also this graphical cheat sheet: https://ueokande.github.io/go-slice-tricks/ On Fri, Feb 5, 2021 at 2:09 AM Brian Candler wrote: > See: https://github.com/golang/go/wiki/SliceTricks#delete > (and lots of other neat tricks there). > > There's no need to add new syntax or functions when the

Re: [go-nuts] x/image/font: Font serialization

‐‐‐ Original Message ‐‐‐ On Friday, February 5th, 2021 at 2:10 AM, Nigel Tao wrote: > On Fri, Feb 5, 2021 at 7:00 AM Sebastien Binet wrote: > > > but as I wrote in the OP, it's not completely satisfying. > > one needs to keep track of the association font.Face/[]byte. > > so that's

[go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

See: https://github.com/golang/go/wiki/SliceTricks#delete (and lots of other neat tricks there). There's no need to add new syntax or functions when the existing ones do the job. On Thursday, 4 February 2021 at 23:55:36 UTC selahad...@gmail.com wrote: > Hi, > I wonder if there are any