Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

On Sun, Jan 26, 2020 at 9:16 AM Eric Raymond wrote: > And that's the insight that led be to the extension I proposed. I asked > myself what the most natural way to pass out a soft close might be. If you're proposing combining generators and exceptions, be aware of how complicated the exact

Re: [go-nuts] Bound checks elimination hint.

On 2/22/20, Bruno Albuquerque wrote: > https://play.golang.org/p/P2JPI42YJa8 > > ... > > So, in this simplified case, if the step divides the length evenly, then > there are no bound checks. If it does not, then bound checks are inserted. > > This seems to be an unnecessary check If the step

Re: [go-nuts] Bound checks elimination hint.

On 2/22/20, Bruno Albuquerque wrote: > https://play.golang.org/p/Y7ICg7t4_nd > > ... > > Unfortunately, I could not find an incantation that would remove the bound > checks. The code from that play.golang.org link is: func NRGBA(rgbData []byte) []byte { nrgbaData := make([]byte,

Re: [go-nuts] Bound checks elimination hint.

On 2/23/20, Bruno Albuquerque wrote: > Would adding an explicit len() check before the loop help the > compiler in any way (can not test right now)? I don't know. Sorry. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

Re: [go-nuts] Image Resize and Crop

On Mon, May 11, 2020 at 4:28 AM robert engels wrote: > All of the code to do scaling and cropping in the ‘image’ package in the > stdlib. Cropping is in the stdlib but scaling is not. Various scaling algorithms (e.g. nearest neighbor, Catmull-Rom) are in the golang.org/x/image/draw package

Re: [go-nuts] Re: [Feature Request] x/mobile: support for gamepad/joystick/controller events

On Fri, Sep 18, 2020 at 6:02 AM Ben Lubar wrote: > I'd appreciate feedback on the potential future existence of gamepad input > support in x/mobile x/mobile is not a very active project. Sorry. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group.

Re: [go-nuts] [generics] () instead of (type T)

On Sun, Jun 21, 2020 at 3:45 AM David Anderson wrote: > It's covered in the generics design doc, and by about a dozen threads on > golang-nuts at this point. I think that the suggestion was for F(), not F. If so, that suggestion isn't covered by the generics design doc or the other golang-nuts

Re: [go-nuts] Generics: More on parens

Heh, I also run GMail+Chrome, but I see rectangles instead of blank spaces (see attachment), which only reinforces your point. On Fri, Jun 19, 2020 at 8:28 AM David Anderson wrote: > Here's one reason to not do that (screenshot from gmail, in a chrome with > a ton of unicode-ready fonts,

Re: [go-nuts] Graphics/Image example programs

On Sun, Jun 27, 2021 at 8:44 AM Tharaneedharan Vilwanathan < vdhar...@gmail.com> wrote: > But I need something that displays images and accepts mouse input, etc but > not vector graphics (say, in OpenGL) for now. Can you please provide some > pointers? >

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

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 either double the memory (give or take), or a filename/io.Reader > handle to keep around. > Two []byte

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

On Mon, Feb 8, 2021 at 8:40 PM Sebastien Binet wrote: > SGTM, and make Source implement io.Reader or io.WriterTo. > > or directly return an io.Reader (either from the underlying []byte, or as > an io.SectionReader - wrapping the io.ReaderAt+size) ? On further thought, since a Source (and its

Re: [go-nuts] Error handling

If you're proposing exceptions, be aware of how complicated the control flow for correct handling can be. Look for what follows `The statement "RESULT = yield from EXPR" is semantically equivalent to...` in https://www.python.org/dev/peps/pep-0380/ -- You received this message because you are

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

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. Avoidi

Re: [go-nuts] Implementation of image.NRGBA64

On Tue, Sep 28, 2021 at 3:53 AM Scott Pakin wrote: > I'm curious: Why does image.NRGBA64 define Pix as a []uint8 and > perpetually pack pairs of uint8 values into a uint16? Wouldn't it have > been easier and faster to define Pix as a []uint16 and Stride to be a > stride in uint16s rather than

Re: [go-nuts] Re: When will the official encoding/json package support parsing json5？

On Mon, Mar 21, 2022 at 6:00 AM jan.f...@gmail.com wrote: > Just googled for "json5 golang" and there seem to be several 3rd party > implementations available. > Can you not use one of those? See also HuJSON, also known as "JSON With Commas and Comments": https://github.com/tailscale/hujson

Re: [go-nuts] shiny, windows, and goroutines

On Wed, Oct 18, 2023 at 9:55 PM SuperTXT Team wrote: > I'm experimenting with shiny, trying to develop a wire protocol for > it. I have some questions about the interfaces. > > It seems from some of the examples in the documentation and some > tutorials that everything except perhaps sending

[go-nuts] Why is foo in my go.sum file?

The go.sum file in the golang.org/x/image repo has a line that is not another golang.org.x/* module: github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= https://github.com/golang/image/blob/2b687b56714d59d061135c735913a64fe2b70778/go.sum#L1 That line was

Re: [go-nuts] Nil could be the zero value for type variables

On Tue, May 31, 2022 at 1:39 AM Will Faught wrote: > Why not allow nil to be used as the zero value for type variables, to fill > this gap? > > return nil // == V(nil) > See also: https://github.com/golang/go/issues/35966 https://github.com/golang/go/issues/19642 -- You received this message

[go-nuts] Go Fonts v2.010

The Go Fonts were originally released in 2016 and version 2.008 came out in 2017. It's taken longer that we'd have liked, but we have just released version 2.010 as of commit 41969df7

Re: [go-nuts] Go Fonts v2.010

On Sat, Jun 18, 2022 at 6:24 PM Shulhan wrote: > Do you know any public CDN for gofont/ttfs? I don't know of any public CDN for gofont/ttfs. Sorry. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] Should io.WriterTo "seek to the end"?

The io.WriterTo interface has come up in a code review discussion. ``` // WriterTo is the interface that wraps the WriteTo method. // // WriteTo writes data to w until there's no more data to write or // when an error occurs. The return value n is the number of bytes // written. Any error

Re: [go-nuts] How to cast *interface{} into *T ?

Possibly relevant: https://go.dev/doc/faq#pointer_to_interface -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view

Re: [go-nuts] overriding image.Decode image type detection

On Sun, Feb 26, 2023 at 12:43 PM 'Dan Kortschak' via golang-nuts wrote: > The alternative is to > replicate the image.Decode functionality, including registration which > seems ugly. It may seem ugly but that is what I'd recommend. https://go.dev/src/image/format.go is only 110 lines of code.

Re: [go-nuts] Interesting "select" examples

On Tue, Apr 4, 2023 at 8:06 AM Ian Lance Taylor wrote: > Some of the select statements in net/http/transport.go are non-trivial. Yeah, net/http (and its transport.go) is probably equally good an example of selects as golang.org/x/net/http2 (and its transport.go). But that's not really

Re: [go-nuts] Interesting "select" examples

On Mon, Apr 3, 2023 at 3:40 PM Konstantin Kulikov wrote: > select { > case <-ctx.Done(): > case linksCh <- links: > } On Tue, Apr 4, 2023 at 1:15 AM burak serdar wrote: > select { > case <-pause: > case <-done: > return > } Thanks, but I think both

Re: [go-nuts] Interesting "select" examples

On Mon, Apr 3, 2023 at 8:14 PM Rob Pike wrote: > select { > case <-ticker.C: > case <-pauseC: > <-pauseC > } This one is more interesting. You can't combine the ticker.C and the pauseC into a single heterogenous channel because you want to wait for the

Re: [go-nuts] Interesting "select" examples

On Tue, Apr 4, 2023 at 7:56 AM Skip Tavakkolian wrote: > mux9p, Fazlul Shahriar's port of Russ' 9pserve (plan9port) > https://github.com/fhs/mux9p/search?q=clientIO > > ... > > select { > case v, ok := <- counts: > // collect samples > case reporting <- Stats{ stats }: >

[go-nuts] Interesting "select" examples

I'm working on a multi-threaded C++ project. We have the equivalent of Go's channels, and are considering whether we also need to implement the equivalent of Go's select. Does anyone have interesting, non-trivial examples of a Go select statement in real code? By non-trivial, I mean that a lot

[go-nuts] io.Reader can return (n, err), both non-zero

The ubiquitous io.Reader interface's Read method returns a (int, error). Surprisingly (for programmers coming from other languages with a built-in or idiomatic Result type), it's possible for both return values to be non-zero. There's (often overlooked??) commentary in https://pkg.go.dev/io#Reader

Re: [go-nuts] io.Reader can return (n, err), both non-zero

On Wed, Mar 20, 2024 at 2:13 PM Ian Lance Taylor wrote: > Some earlier discussions: > > https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/jq8lAQhenaoJ > https://groups.google.com/g/golang-nuts/c/WGYJx3ICCW4/m/1L0WcN8eqmkJ > > See in particular this message from Russ: >

<    1   2