Re: [go-nuts] Re: Forking/transfering a repository and import paths

Relative import paths was a feature in old versions of Go and explicitly removed *because* of Go modules: https://github.com/golang/go/issues/26645 https://github.com/golang/go/issues/27224 On Wed, Dec 12, 2018 at 1:52 PM Sotirios Mantziaris wrote: > > I was under the impression that go modules

Re: [go-nuts] Re: go language sensitive editor?

But sam is a pretty solid improvement over ed. On Tue, Nov 20, 2018 at 6:04 PM Rob Pike wrote: > > Ed is the standard text editor. > > -rob > > > On Wed, Nov 21, 2018 at 8:15 AM wrote: >> >> >> Another vote for VS Code. I'm a hobbyist and have tried lots of editors. >> >> On Tuesday, November

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tue, Oct 16, 2018 at 4:14 PM Eric Raymond wrote: > If the alternative is requiring programmers to remember pre-cooked > relationships between different operators that may or may not be appropriate > for what he or she is trying to model, then I embrace this "problem". > > It's up to the

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Why is the implements keyword a better solution than magic names? Magic names feel more Go-ish to me in the sense that interface implementations already eschew the implements keyword (unlike most other languages) and don't require any syntactic changes to the language. Would there be any rules

Re: [go-nuts] Go += Package Versioning

I really like this, except for the claim that it the blog post that it will eliminate vendoring and deprecate GOPATH and the problems that will cause for backwards compatibility for things that are currently using them. If this is going to result in removing language features (ie. vendoring),

Re: [go-nuts] shiny driver.Main not returning

> case paint.Event: > w.Upload(image.Point{}, b, b.Bounds()) > w.Publish() > case size.Event: > if b != nil { > b.Release() > } > b, err = s.NewBuffer(e.Size()) > if err != nil { > log.Fatal(err) > } > case error: > log.Print(e) > } > } > }) > fmt.Println

Re: [go-nuts] shiny driver.Main not returning

What are you trying to do? I don't see the point in a shiny program that doesn't even create a window. There's likely a loop internally in the driver that's handling processing of events from the OS and since you're never creating a window, it's never exiting (this is just a guess, I haven't

Re: [go-nuts] File organization in a github-ed Go project

If someone wanted to fork your library for one of their programs, they could also vendor the package with their changes until it's changed significantly enough that they think it's worth updating to its own namespace (and at that point, it really should be a different import path..) On Mon, Feb

Re: [go-nuts] correct/working 9p2000 library in Go?

On Sun, Feb 19, 2017 at 5:39 PM, Jason E. Aten wrote: > I'd like to play with the 9p protocol (plan9's "everything is a filesystem" > IPC protocol; I guess the updated 9p2000 version is the one everyone > actually uses) ... > > ...but the implementations I can find in Go seem

Re: [go-nuts] 9fans.net/go

> if len(a) == 0 { > fid.Close() > return nil, errors.New("short read from acme/new/ctl") > } > id, err := strconv.Atoi(a[0]) > if err != nil { > fid.Close() > return nil, errors.New("invalid window id in acme/new/ctl: " + a[0]) > } > return Ope

Re: [go-nuts] 9fans.net/go

since 2015), so I'm wondering if there's any other packages that deal with the plumbing ports (because otherwise I think my only option is to fork it and maintain it myself..) On Sat, Feb 18, 2017 at 10:57 PM, Bakul Shah <ba...@bitblocks.com> wrote: > On Sat, 18 Feb 2017 21:42:05 GMT Da

[go-nuts] 9fans.net/go

Are there any cross-platform alternatives to 9fans.net/go for interacting with the Plan9/p9p plumber? It doesn't seem to be maintained (I've had to vendor a bug fix for a while to use it to receive plumbing messages) and I just discovered while trying to use my de text editor on Plan 9 that,

Re: [go-nuts] Cross compile GOOS

"BSD" isn't a valid OS. It's a family of OSes.. but why don't you just set the environment variable while running the command? Such as: GOOS=dragonfly go build prog On Thu, Jan 26, 2017 at 1:10 PM, wrote: > Is there any way to cross compile without setting GOOS

Re: [go-nuts] shiny: get mouse position relative to window

That doesn't sound right to me. I just added a 'fmt.Printf("X: %v Y: %v\n", e.X, e.Y)' to the switch case handling mouse.Event in one of my shiny programs, and the mouse coordinates are reported relative to the top-left corner of the window. On Sat, Jan 14, 2017 at 5:59 AM,

Re: [go-nuts] Re: Shiny

On Tue, Aug 16, 2016 at 12:56 PM, wrote: > No buttons (though they aren't hard to implement from a label), no radio > boxes, no built-in scrollbars that I could find, no actual text editors, no > lookups/drop-downs/choosers, no listboxes. And certainly nothing akin to a >

Re: [go-nuts] Bitmasks on signed types

; > > > On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com> wrote: > >> > >> All binary operators, except shifts, require identical left and right > >> types. Untyped values will be coerced to the type of the other side, if > >> repr

[go-nuts] Bitmasks on signed types

Is this supposed to be legal in Go: var x int32 = 3 fmt.Printf("%d", x & 0x)? The language spec just says the bitwise operator "applies to integers only" and "yields a result of the same type as the first operand" that I can see, but it's giving me a compiler error: ./main.go:10: