Re: [go-nuts] [ANN] Edit - Acme command language

Thanks for suggesting the Reader(q0, q1 int64) io.RuneReader. I accidentally replied off list. I wasn't aware of up to four horsemen being involved. The man pages didn't prepare me for this. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: Go channels overused and hyped?

Author did a range over channel without select, making cancellation impossible without closing the channel or the process. However, author challenges user to solve cancellation problems with no selection, even saying he awaits for the user to accomplish this. So author will stop waiting when no

[go-nuts] [ANN] Edit - Acme command language

I'm sure this has been done already, but I thought I'd share my implementation of this here for anyone interested in using structural regular expressions in Go. It doesn't cover 100% of what Edit does in Acme, but its close enough that I can use the example program

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

Threads are the structural and functional loci of execution on some operating systems, data stored in a box accessible to each thread makes sense when you obey the constraint that the things in that box are to be used for that thread exclusively. Goroutines are different, they function like th

[go-nuts] [Blog] Context should go away for Go 2

I also dont want to see context everywhere. At the same time, I don't want it to be obfuscated in a confusing way. ctx is an unfortunate initialism and context.Context package stuttering doesn't help. I suppose you could stuff a pointer on the stack pointing to a potential context and then p

[go-nuts] Re: Generics are overrated.

I'm hesitant to accept generics due to the fear of *overloaded operators *being the next big deal*. *C# even has *properties (user-defined methods dispatched upon an assignment operation)*. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To un

[go-nuts] Re: gitcreepy – get GitHub users' previous email addresses from all their historical commits!

This information is actually stored in the git commits themselves. There is a zlib'd field that contains the author's name and email address for each commit in the repo. A complete transcript for every commit can be reconstructed from a git repo in this manner. On Saturday, July 15, 2017 at 5:5

[go-nuts] Re: Is x/exp/shiny dead?

It's not ready for general use, but it certainly isn't dead. I think a lack of examples for some of the more-complex widgets is probably where it needs the most help, but considering that only one person is working on it the result is a very impressive addition to the Go ecosystem. I've not used

[go-nuts] Re: Disadvantage of Go

To sacrifice simplicity of readability for simpler writing is to have never been tasked with reading a 25kloc C# project and having to open 10 windows just for the object-oriented pyramid of generic abstract partial template class factories On Thursday, January 12, 2017 at 11:44:10 PM UTC-8,

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

I haven't seen this either, the solution depends on what platform you're trying to support. I have a package that does this, for Win32. If you're using Windows, you use the the Rect() or ClientAbs() in my package to get the position of the window (or the client area). https://godoc.org/github

[go-nuts] Deleting the /r/golang subreddit

I don't use the site, nor understand how any immediate conflicts of interest can manifest based on the CEO's actions that justify removing the subreddit or locking it down. Why not add a community to the official golang.org site and let the subreddit die of natural causes? It would be a favorab

Re: [go-nuts] Small complete examples which show the power of Go?

It's shorter, but it's harder for me to grasp what it does as easily as the first example. On Wednesday, August 10, 2016 at 2:09:58 AM UTC-7, Anmol Sethi wrote: > > You can shorten that by 6 lines > > package main > > import "net/http" > > func main() { > http.ListenAndServe(":8080",

[go-nuts] Re: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

This is just a guess based on the origins of the language, but the design decision probably stems from a dim view of symbolic links. They are seen as ugly hacks that carry persistent state on the filesystem instead of a higher control plane such as a per-process namespace. The path variable app

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

> > I wish I could be pointed to such discussion. > It was briefly discussed in *The Go Programming Language *book by Donovan & Kernighan (p 132) *:* > An analogous “shallow” equality test for slices could be useful, and it > would solve the problem with maps, but the inconsistent treatment o

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

I was being facetious. You have the right to opine, but elevating opinions to that of proofs doesn't give the discussion any utility. I think you should consider the underlying assumptions in some of your points: 1. A slice is a descriptor of an aggregate 2. A struct can resemble a descriptor o

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Hardcoded proofs should be assigned well-named identifiers. If you ever have to alter them, you don't want to be rummaging around your lemmas and corollaries. On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote: > > Ok. That "haha" was merely to show that no animosity was borne. And also >

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Relaxing unformalized behavior makes little sense to me. Explaining why equality is inconsistent between slices and arrays is not something I want to do either. On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: > > Rob and Robert actually wrote that this area of the spec needs more work.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Go does not have reference types. As far as I know, the word was purposefully removed from the spec to remove the ambiguity surrounding the word. https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA -- You received this message because you are subscribed to the Google Groups "golan

[go-nuts] Re: How to decrypt data with AES in golang

An IV is not a key, it just changes the state of the block chain and must the same size as the block. The key can be a different size than the block, the IV can not in this case. Your program complains because you are reusing the key as an IV, and this key-IV happens to be a different size than

Re: [go-nuts] redirect already running processes stdout

Most systems don't support this functionality without a kernel patch or debugger trick. You can manipulate the file descriptor before the process is born, everything afterwards is luck or system specific. In Go, you have a lot more power: os.Stdout, os. Stderr = os.Stderr, os.Stdout fmt.Prin

Re: [go-nuts] How to be safe in Go?

I wasn't referring to concurrency within package scope, but data crossing package boundaries (the earlier post says libraries' are responsible to ensure data passed *to* them is safe). The map type reveals an implementation detail by documenting that it isn't safe for parallel use. On Friday,

Re: [go-nuts] How to be safe in Go?

I mostly agree, but there are times when abstraction leads to complex code and more reasonable approach involves documented constraints. The map type is not safe either, but it enjoys widespread use. If it were abstracted to handle all possible use-cases, it would be unnecessarily slow for most

Re: [go-nuts] Fedora and crypto/elliptic.P224

Security has little to do with this. It's a "legal" problem: Unfortunately, this code has to be removed due to legal concerns. We > apologize for any inconvenience this causes you. https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/RDAHDK4RKN477G2ZDSX4DZT5ED

Re: [go-nuts] Fedora and crypto/elliptic.P224

Go should not encourage distribution builder shenanigans. The effective way to solve this problem is by submitting it as an issue to the appropriate community it affects. A high search rank will accumulate based on the popularity of this issue, and the feedback (blame) will flow to the right

Re: [go-nuts] Fedora and crypto/elliptic.P224

If the distribution builders can take it out, what is preventing them from adding their own documentation? On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote: > > Yep, that's exactly what I'm saying. > > > https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.

Re: [go-nuts] [ANN] Mirror of Go SSA

That's because you are mirroring the compiler's internal ssa package. Sharing it as compile/ssa would probably remove this unintuitive name clash. On Thursday, June 16, 2016 at 1:52:31 AM UTC-7, JW Bell wrote: > > I've used golang.org/x/tools/go/ssa, it doesn't have everything this does. > On J

Re: [go-nuts] [ANN] Mirror of Go SSA

Have you tried to *go get golang.org/x/tools/go/ssa *? On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote: > > >>I have to say that I don't see a big benefit to mirroring a github > repo on github itself. > There isn't another way to use the ssa package. > > On Tuesday, June 14, 201

[go-nuts] Re: Problem with `go run *.go` in windows CMD - winapi error #123

How exactly do you propose this be fixed? Windows has a crippled shell that thinks programs should process and interpret their own asterisk characters. This turns into a major inconsistency across windows CLI tools. I dont think Go should tailor itself to badly designed plumbing. -- You recei

[go-nuts] Re: Save to store encryption key in Go executable?

You're right, even if you aren't planning to share the program, it's still a good idea to separate the key from the executable. For one, the executable is bigger and harder to keep secret than a few bytes of data. It's generally frowned upon to bundle the two since the secrecy should rely solel

Re: [go-nuts] Re: Better sum types for go

Thanks! On Monday, June 13, 2016 at 3:27:51 AM UTC-7, Jesper Louis Andersen wrote: > > > On Mon, Jun 13, 2016 at 1:58 AM, > wrote: > >> What research or other literature can you recommend on the topic of type >> theory? > > > Benjamin C. Pierce's "Types and Programming Languages", often abbreviat

[go-nuts] Re: Save to store encryption key in Go executable?

This is a key distribution problem, if you store the key in the executable you should assume everyone already has access to the key. This is a different problem than "can someone get the key out of running memory". If you store the key in the executable, then an existential compromise of this k