[go-nuts] TMTP messaging protocol

TMTP is a protocol [1] to let Internet sites message customers/members directly, instead of unreliable, insecure email or costly custom apps. https://mnmnotmail.org https://twitter.com/mnmnotmail The open source client [2] and server [3] are written in Go. The client UI runs in a localhost

[go-nuts] Re: an open source project to replace SMTP/email

I've just posted an online demo of the mnm client. Feedback welcome! https://mnmnotmail.org/demo.html Follow mnm: https://twitter.com/mnmnotmail The mnm project is building a legitimate email replacement: a client[1], a > server[2], and a simple protocol[3] between them. (Legitimate, i.e. >

Re: [go-nuts] an open source project to replace SMTP/email

be to enable Discussions on the project's github page. > This is a relatively new feature in Github, but it's being used by some > projects e.g. Netbox > <https://github.com/netbox-community/netbox/discussions>. > > On Wednesday, 13 January 2021 at 20:45:34 UTC Liam wrote:

Re: [go-nuts] an open source project to replace SMTP/email

Here's the backstory to mnm, in a draft article not yet published. I'd love any feedback... https://mnmnotmail.org/volunteered.html On Tue, Jan 5, 2021 at 1:31 PM Liam wrote: > > The mnm project is building a legitimate email replacement: a client[1], a > server[2], and a simple p

[go-nuts] an open source project to replace SMTP/email

The mnm project is building a legitimate email replacement: a client[1], a server[2], and a simple protocol[3] between them. (Legitimate, i.e. n-identity, decentralized, store-and-forward, open protocol, open source.) https://mnmnotmail.org https://twitter.com/mnmnotmail Both client and

[go-nuts] os.Readdir() & FileInfo proposal by Go team

A discussion of changes to os.Readdir() & os.FileInfo and alternatives is underway in https://github.com/golang/go/issues/41188 -- 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,

[go-nuts] Proposal: env variable defaults

Some users have requested a way to turn off async preemption without having to set an environment variable at runtime. If you'd benefit from building defaults for GODEBUG and other environment variables into Go programs, please comment here: https://github.com/golang/go/issues/40870 -- You

[go-nuts] Fuzzing design doc from Go team

The Go team has released a design doc for a Fuzzing API. https://golang.org/s/draft-fuzzing-design The original proposal is https://github.com/golang/go/issues/19109 Discussion is on Reddit, which I don't wish to use for technical feedback or debate. I haven't seen an announcement; I

[go-nuts] No http.ServeStream() ?

Wondering why there's no http.ServeStream() API to do chunked transfer-encoding (or the http2 equivalent), in addition to the nice features of ServeContent()... Has it been considered? Does it merit a proposal? If not, some example code in the docs would be helpful... -- You received this

[go-nuts] url.QueryEscape unexpectedly slow

I would expect this to complete pretty quickly, but after 40 minutes (on 1.13, linux/amd64), it hasn't printed a thing. I'm following up a report of panic in QueryEscape: https://github.com/golang/go/issues/38643 package main import ( "net/url" "fmt" ) func main() { for a :=

[go-nuts] Re: dial TLS error in Windows 10

This was due to Norton Firewall. On Saturday, May 2, 2020 at 12:02:25 PM UTC-7, Liam wrote: > > On Windows 10, in a Go app started by a command prompt which has > Administrator privs, I see this error when attempting a TLS connection: > > dial tcp [host:port]: connectex: An a

[go-nuts] dial TLS error in Windows 10

On Windows 10, in a Go app started by a command prompt which has Administrator privs, I see this error when attempting a TLS connection: dial tcp [host:port]: connectex: An attempt was made to access a socket in a way forbidden by its access permissions. Do I need an outbound TCP firewall

Re: [go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

The Linux kernel has TLS; one reason is to allow sendfile(2) with TLS. But I guess Go doesn't enable that yet? https://www.kernel.org/doc/html/latest/networking/tls.html On Tuesday, April 28, 2020 at 12:39:04 PM UTC-7, Robert Engels wrote: > > Depends on how the file descriptor is implemented.

Re: [go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

On Tuesday, April 28, 2020 at 1:42:15 AM UTC-7, Liam wrote: > > > > On Tuesday, April 28, 2020 at 12:05:00 AM UTC-7, Liam wrote: >> >> >> >> On Monday, April 27, 2020 at 10:00:52 PM UTC-7, Ian Lance Taylor wrote: >>> >>> On Mon, Apr 27, 2020

Re: [go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

On Tuesday, April 28, 2020 at 12:05:00 AM UTC-7, Liam wrote: > > > > On Monday, April 27, 2020 at 10:00:52 PM UTC-7, Ian Lance Taylor wrote: >> >> On Mon, Apr 27, 2020 at 6:59 PM Liam wrote: >> > >> > On Monday, April 27, 2020 at 5:56:52 PM UTC-7, Ia

Re: [go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

On Monday, April 27, 2020 at 10:00:52 PM UTC-7, Ian Lance Taylor wrote: > > On Mon, Apr 27, 2020 at 6:59 PM Liam > > wrote: > > > > On Monday, April 27, 2020 at 5:56:52 PM UTC-7, Ian Lance Taylor wrote: > >> > >> On Mon, Apr 27, 2020 at 5:10 PM Lia

Re: [go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

On Monday, April 27, 2020 at 5:56:52 PM UTC-7, Ian Lance Taylor wrote: > > On Mon, Apr 27, 2020 at 5:10 PM Liam > > wrote: > > > > On Monday, April 27, 2020 at 4:22:41 PM UTC-7, Ian Lance Taylor wrote: > >> > >> On Sun, Apr 26, 2020 at 4:55 PM Liam

Re: [go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

On Monday, April 27, 2020 at 4:22:41 PM UTC-7, Ian Lance Taylor wrote: > > On Sun, Apr 26, 2020 at 4:55 PM Liam > > wrote: > > > > During an io.Copy() where the Writer is a TCPConn and the Reader is a > 200K disk file, my code may concurrently Write() on the sa

[go-nuts] Concurrent io.Copy(tcpConn, file) and tcpConn.Write(...)

During an io.Copy() where the Writer is a TCPConn and the Reader is a 200K disk file, my code may concurrently Write() on the same TCPConn. I see the result of the Write() inserted into the result of the io.Copy(). I had the impression that was impossible, but I must be mistaken, as the

[go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions

https://github.com/golang/go/issues/36281 https://github.com/pebbe/zmq4/issues/17 On Wednesday, February 26, 2020 at 3:33:05 AM UTC-8, Peter Kleiweg wrote: > > With Go version 1.14 I get a lot of errors when I run: > > go test -v github.com/pebbe/zmq4 > > I didn't see this with Go 1.13.8 or

[go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

The archlinuxarm.org project has great support for a variety of arm64 boards. On Tuesday, February 11, 2020 at 7:33:04 PM UTC-8, kortschak wrote: > > I have been wanting an arm64 builder to do local testing for Gonum > recently. Unfortunately, though RPi 3 and 4 have 64 bit cores, Raspbian >

[go-nuts] Re: Go-1.14 irreproducibly fails with mlock failure

You were bitten by a kernel bug; update your kernel. https://github.com/golang/go/issues/35777 On Sunday, February 9, 2020 at 10:48:29 AM UTC-8, Juliusz Chroboczek wrote: > > The first time I ran go-1.14rc1 on a stock Debian system, I got: > > runtime: mlock of signal stack failed: 12 >

Re: [go-nuts] Seeking new custodian for godoc.org

od faith on the part of the Go team in its efforts and communications; please do the same for mine. Most sincerely, Liam *# Why does pkg.go.dev <http://pkg.go.dev> require a detected license to show docs? * *Why doesn't godoc.org <http://godoc.org>?* The teams working on the proxy an

[go-nuts] Seeking new custodian for godoc.org

Legal advice will apparently force the Go team to close godoc.org [1] But the site could be taken over by a new custodian, for instance a non-profit funded by donations. A first step is to identify a place to host the site. Perhaps a well-known Go shop like Cloudflare? Then we'd apply to join

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

That was a great read, thank you. Re throw/catch, this is one of the few Go2 error handling proposals still open, tho it hasn't yet seen substantive feedback from the Go team: https://github.com/golang/go/issues/27519 I'd suggest re-posting this on golang-dev; I almost missed it as I rarely

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Go mindshare suffers if it's seen as worse for prototyping, and necessary only for scale. Especially as there are more efficient (albeit more complex) ways to achieve scale. On Mon, Jan 27, 2020, 10:55 AM Eric S. Raymond wrote: > Michael Jones : > > Python, to its credit, has the nice inclusive

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

gt; /^((Found|Teach|Hack)er|(Men|Jani)tor|C\w+O)$/ > r...@robs.io • skilstak.io > > > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, January 15, 2020 5:18 PM, Liam > wrote: > > My point is that Go should be rising, since Java & C# are falling. Python > has gained significant mindsh

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Open source is a rapidly growing movement across virtually all languages, but still a small minority of all software. So the Trends graph is more revealing than Github activity. Assembly language use on Github also increased by ~150% There's no question that Go use is growing rather quickly.

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

For example, if everyone that uses product Y can't figure out how feature > X works, and they search for it. Product Y will be showing growth... > > -----Original Message- > From: Liam > Sent: Jan 15, 2020 4:18 PM > To: golang-nuts > Subject: [go-nuts] Re: Go mindshare i

[go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

My point is that Go should be rising, since Java & C# are falling. Python has gained significant mindshare, and Go is way better. I think something's amiss with the public perception of Go, but it's hard to say what. On Wednesday, January 15, 2020 at 12:34:54 PM UTC-8, Liam wrote: > &

[go-nuts] Go mindshare is low & ~flat, per Google Trends

Google Trends graph showing past 5y of Java, Python, C#, Node.js, Go https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

> v = read() > if v !=0 { > cond.wait() > } > else { > if(cas(v,WRITER)) { // we are the writer > return > } else { > // loop and try again > } > } > } > > wunlock() { > set(v,0); >

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

r > wrote: > >>> > >>> On Tue, Dec 3, 2019 at 5:21 PM Liam Breck > wrote: > >>> > >>> I have a problem that is trivially solved via > >>> > >>> door sync.RWMutex > >>

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

the lock. > > On Dec 3, 2019, at 6:52 PM, Liam Breck > > wrote: > >  > Which looks like...? > > On Tue, Dec 3, 2019, 4:50 PM Robert Engels > wrote: > >> I would use an atomic and a lock instead of two locks. >> >> > On Dec 3, 2019, at 6:35 PM,

Re: [go-nuts] Workaround for missing RWMutex.Try*Lock()

Which looks like...? On Tue, Dec 3, 2019, 4:50 PM Robert Engels wrote: > I would use an atomic and a lock instead of two locks. > > > On Dec 3, 2019, at 6:35 PM, burak serdar wrote: > > > > On Tue, Dec 3, 2019 at 5:21 PM Liam Breck > wrote: > >> > >&

[go-nuts] Workaround for missing RWMutex.Try*Lock()

I have a problem that is trivially solved via door sync.RWMutex func Reader() T { if !door.TryRLock() { // missing in stdlib :-( return busy } defer door.RUnlock() ... } func Writer() { door.Lock() defer door.Unlock() ... } How does one achieve this in Go? -- You

Re: [go-nuts] atomic.Add*() doesn't produce unique values

;1< > j is n%8, so "n&(8-1)" > > if mask=1<<(n&(8-1)) then one can test if the bit is set with > > a[n>>3] & mask != 0 > > to set it is > > a[n>>3] |= mask > > the values 3 and 8 here are from 8 bits in a byte and 8

Re: [go-nuts] Where is the middle of Brazil?

"considered making a T-shirt saying "answers rhetorical questions" Thank you for the LOL :-) On Saturday, November 30, 2019 at 5:57:32 PM UTC-8, Michael Jones wrote: > > Sigh. I overlooked the riddle and took it as a straight question. Typical > for me all my life. (once considered making a

Re: [go-nuts] atomic.Add*() doesn't produce unique values

kker%27s_algorithm>). That it is now > just a number-of-fingers cycles is fantastic progress! > > On Sat, Nov 30, 2019 at 3:38 PM Michael Jones > wrote: > >> Liam, >> >> I just wrote a little stress test program for you. Maybe it will make you >> less stre

Re: [go-nuts] atomic.Add*() doesn't produce unique values

PM UTC-8, Kurtis Rader wrote: > > On Fri, Nov 29, 2019 at 6:21 PM Liam > > wrote: > >> Does atomic.AddInt32(, 1) always yield unique values for concurrent >> callers? >> >> I'm guessing not, because (I think) I'm seeing that two callers get x+2, >> n

[go-nuts] atomic.Add*() doesn't produce unique values

Does atomic.AddInt32(, 1) always yield unique values for concurrent callers? I'm guessing not, because (I think) I'm seeing that two callers get x+2, neither gets x+1. Is there a way to generate unique values with pkg atomic, or is a mutex required? -- You received this message because you

Re: [go-nuts] early close of http.Client's Response.Body

On Mon, Nov 25, 2019, 10:32 AM Andy Balholm wrote: > > > > On Nov 25, 2019, at 9:54 AM, Liam wrote: > > > > - does the read-to-EOF stipulation also apply to Client.Get/Post() ? > > Yes. Those methods are fairly simple wrappers around Do. > > > - why d

[go-nuts] early close of http.Client's Response.Body

Scenario: Sending a client request and only reading the whole Response.Body for certain .StatusCode values, and/or reading only the first N bytes. Docs for Client.Do() "If the Body is not both read to EOF and closed, the Client's underlying RoundTripper (typically Transport) may not be able to

Re: [go-nuts] rebuild & reinstall pkg/tool/.../link

On Wed, Oct 9, 2019, 3:17 AM Jan Mercl <0xj...@gmail.com> wrote: > On Wed, Oct 9, 2019 at 12:10 PM Liam wrote: > > > > I have the current 1.12 release from a Linux distro, installed in > /usr/lib/go. > > > > If I patch the linker source, how would I rebui

[go-nuts] rebuild & reinstall pkg/tool/.../link

I have the current 1.12 release from a Linux distro, installed in /usr/lib/go. If I patch the linker source, how would I rebuild and reinstall pkg/tool/.../link ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

[go-nuts] Go policy does not fully support previous release

I was startled to learn that regressions found in the previous release (currently 1.12.x) will not be fixed in that release. Regressions are only fixed in the most recent release. If you wait until 1.12.5 to upgrade a deployment from 1.11.x, and then discover a regression on the day 1.13 comes

[go-nuts] Go 1.13 will cause spurious deadline events in TCP servers

Go 1.13 enables TCP keepalive by default, and keepalive errors appear to be "deadline" events. This will impact working code that sets deadlines, perhaps breaking it in some cases. The fix is to disable TCP keepalives. This wasn't known when the listener keepalive-by-default change was

Re: [go-nuts] Re: Windows syscall.Open() change to fix os.Rename() & .Remove()

If you can point to an example that depends on the windows-specific error, could you post it in the issue? On Sun, Aug 4, 2019, 2:16 AM Reto wrote: > On Wed, Jul 31, 2019 at 07:00:46PM -0700, Liam wrote: > > In this issue, Microsoft suggested that Go on Windows switch to &g

[go-nuts] Re: Windows syscall.Open() change to fix os.Rename() & .Remove()

Microsoft recommends changing syscall.Open() for GOOS=windows to fix this. Pls reply if you know of existing apps that rely on it. This code fails with a "sharing violation" on Windows. That behavior is undocumented in package "os". path := "rename-after-open" fd, err := os.OpenFile(path,

[go-nuts] Windows syscall.Open() change to fix os.Rename() & .Remove()

Microsoft recommends changing syscall.Open() for GOOS=windows to fix this. Pls reply if you know of existing apps that rely on it. This code fails with a "sharing violation" on Windows. That behavior is undocumented in package "os". path := "rename-after-open" fd, err := os.OpenFile(path,

[go-nuts] Re: simplified error handling

See https://github.com/golang/go/issues/32500 On Tuesday, July 9, 2019 at 10:25:36 AM UTC-7, Robert Engels wrote: > > > There is probably a similar proposal out-there, but if there is it hasn't > surfaced, so I thought I would throw this out there. > > It only requires 2 simple changes and is

Re: [go-nuts] `on err` alternative to `try()` has traction...?

The controversy between try and explicit error checking is why I wrote this proposal, to provide a compromise that's both explicit and terse. On Fri, Jul 5, 2019, 11:08 PM Liam Breck wrote: > I've expanded the proposal to address feedback from the Go team. It now > offers a more special p

[go-nuts] Re: Go compiler backlog

Get, you may get more response on this by posting to golang-dev... On Sunday, July 7, 2019 at 3:06:55 PM UTC-7, Gert wrote: > > My intelligence is that of a ping pong ball but think it's time to clean > up de go compiler backlog so ping pong balls like me have a chance to > understand the

Re: [go-nuts] `on err` alternative to `try()` has traction...?

I've expanded the proposal to address feedback from the Go team. It now offers a more special purpose construct than the generic if-variant 'on'. See the Critiques section in https://github.com/golang/go/issues/32611 On Tue, Jul 2, 2019, 12:57 PM Liam wrote: > This proposal has attrac

Re: [go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

[Sorry to keep re-posting this; I'm keeping it visible for infrequent readers] Microsoft recommends changing syscall.Open() for GOOS=windows to fix this. Pls reply if you know of existing apps that rely on it. This code fails with a "sharing violation" on Windows. That behavior is

[go-nuts] `on err` alternative to `try()` has traction...?

This proposal has attracted modest attention from the Go team... https://github.com/golang/go/issues/32611 It suggests: err := f() on err, on err, return err// any type can be tested for non-zero on err, return fmt.Errorf(...) on err, fmt.Println(err) // doesn't stop the

Re: [go-nuts] YAEHI (Yet another error-handling idea)

Erm, what expression besides a function call would yield an error only sometimes? I suppose channel receive, but is that a useful case? It's all moot anyway. On Mon, Jul 1, 2019, 10:42 PM Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > Thanks Liam, > > your suggested

Re: [go-nuts] YAEHI (Yet another error-handling idea)

I've noted in several places that a 'try' expression (via keyword, built-in, or symbol) is suitable only when the function is expected to always succeed, and so would panic on error. Also the symbol, which I agree is preferable, works best this way will?(always?(work?())) vs

Re: [go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

Microsoft has suggested that Go change syscall.Open() to fix this. Please pipe up if that might break your app! Details quoted... On Tuesday, June 25, 2019 at 8:25:24 AM UTC-7, Liam wrote: > > Microsoft recommends changing this, so we need to know whether existing >

[go-nuts] Re: A counter proposal to the try proposal - catch

If you really care to "catch" errors, you want this: https://github.com/golang/go/issues/27519 If all you need is to allocate a line to check an error and take an action, you want this: https://github.com/golang/go/issues/32611 But it's all moot. the Go team has told us we must prove that try

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

I wrote a proposal with function-scope named handlers that uses a per-call try flag and offers most features of 'catch', but it hasn't received any attention... https://github.com/golang/go/issues/27519 On Saturday, June 29, 2019 at 12:45:37 PM UTC-7, Robert Engels wrote: > > If you don’t

Fwd: [go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

Microsoft recommends changing this, so we need to know whether existing apps rely on it: On Windows (but not elsewhere) this fails with a "sharing violation": path := "rename-after-open" fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600) if err != nil { ... } err = os.Rename(path_a,

[go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

On Windows (but not elsewhere) this fails with a "sharing violation": path := "rename-after-open" fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600) if err != nil { ... } err = os.Rename(path_a, path_b)// or os.Remove(path) if err != nil { ... } // sharing

Re: [go-nuts] Interesting public commentary on Go...

I filed an issue requesting that the Go team issue RFPs to both communicate directions they plan to go in, and solicit community input about them. It was declined. proposal: Go 2: establish RFP/RFC process for language feature proposals https://github.com/golang/go/issues/29860 Part of my

[go-nuts] Web access to golang-dev is down

But golang-nuts is still working... -- 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. For more options, visit

[go-nuts] rand.Rand.Seed() vs rand.NewSource()

Could anyone clarify the difference between these two? r := rand.New(rand.NewSource(...)) var r rand.Rand; r.Seed(...) -- 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

[go-nuts] Project install for go mod

What are the recommended from-scratch download/install directions for a project using go.mod (having 1+ main packages)? I don't see them in the wiki, 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] 1.12 coverage generation broken?

Doing the following yields no ./app.cov. Have I got it wrong, or should I file an issue? $ go test -c -covermode=count -coverpkg ./... $ ./app.test -apptest localhost:443 -test.coverprofile app.cov code coverage for v0.0.0 (unreleased) ... PASS coverage: 71.7% of statements in ./... $ ls

Re: [go-nuts] missing fmt.Error(...interface{})

rror as suggested would not, > instead implicitly encouraging things like fmt.Error(false, 42) which is > user unfriendly. > > //jb > > On 30 Dec 2018, at 09:53, Justin Israel wrote: > > > > On Sun, Dec 30, 2018 at 9:26 PM Liam Breck > wrote: > >> Justin

Re: [go-nuts] missing fmt.Error(...interface{})

Justin, see docs for fmt.Print(...interface{}) On Sun, Dec 30, 2018, 12:15 AM Justin Israel > > On Sun, Dec 30, 2018, 7:24 PM Liam Breck wrote: > >> What's the rationale for omission of: >> fmt.Error(a ...interface{}) error >> > > What does it mean for t

[go-nuts] missing fmt.Error(...interface{})

What's the rationale for omission of: fmt.Error(a ...interface{}) error Given that other fmt functions come in that variety? I realize it can be achieved like this, but so can fmt.Errorf errors.New(fmt.Sprint(...)) Would a proposal to add it be entertained? Happy New Year to all :-) --

Re: [go-nuts] Generic function aliases

04, 2018 at 10:27:19AM -0800, Liam Breck wrote: > >Ah yes, var works. But it should be const, since func names aren't > >variables. > >On Tue, Dec 4, 2018, 5:40 AM Axel Wagner <[1] > axel.wagner...@googlemail.com > >wrote: > > > > You c

Re: [go-nuts] Generic function aliases

larations ended up only be added for types - all other > declarations can already be emulated sufficiently well. :) > > > On Mon, Dec 3, 2018 at 11:39 PM Liam Breck wrote: > >> Type aliases appear in the contracts draft design. Has anyone suggested >> alias declarations

[go-nuts] Generic function aliases

Type aliases appear in the contracts draft design. Has anyone suggested alias declarations for generic functions? This would simplify syntax for callers... package g func G(type T)(i T) error { ... } --- package main import "g" func Gi g.G(int) // declare alias func f() { Gi(1) } -- You

[go-nuts] Re: [ANN] fixed point math library

This made the front page of Hacker News https://news.ycombinator.com/item?id=18559625 On Wednesday, November 28, 2018 at 10:47:37 PM UTC-8, robert engels wrote: > > For those interesting in financial apps, I have released ‘fixed' at > https://github.com/robaho/fixed a high performance

Re: [go-nuts] Important design missing from Errors overview

The wiki page for the Error Values Draft Design is actually here: https://golang.org/wiki/Go2ErrorValuesFeedback You could link the article on the wiki page, or better yet make a gist with a summary of how its insights apply to the Error Values proposal, and link your gist on the wiki page.

Re: [go-nuts] recommend that error and panic auto coverting

A predefined handler which produces a panic appears in item (L) of Requirements to Consider for Go 2 Error Handling ...which is a comprehensive survey of error-related issues, most of which aren't mentioned in the draft

Re: [go-nuts] Go 2 Error Handler Testing

On Tue, Oct 30, 2018, 4:08 PM Burak Serdar wrote: > On Tue, Oct 30, 2018 at 2:15 PM Liam wrote: > > > > I've compiled an outline of Requirements to Consider for Go 2 Error > Handling. > https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a > > >

[go-nuts] Re: Go 2 error handling non-proposal

Hi, could you link this thread on the Feedback wiki page (probably in the Against section)? https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback URL to this thread: https://groups.google.com/d/topic/golang-nuts/1McP4_-oOpo/discussion It seems clear that the Go team has resolved to add

[go-nuts] Go 2 Error Handler Testing

I've compiled an outline of Requirements to Consider for Go 2 Error Handling . Recently I was asked about support for a test harness in functions that contain error handlers; my document doesn't address this. My first

[go-nuts] Re: Go2 proposal: remove := operator (or remove variable shadowing)

Since most variable re-declaration is to support error variables, one likely outcome of the new error handling scheme is to end the need for it. v1, err := f1() // this v2, err := f2() v1 := check f1() // becomes this (proposed by Go team) v2 := check f2() v1, ?err := f1() // or this (invokes

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

I don't think we'll see check in the next draft. A LOT of the feedback[1] suggests various ways to invoke a named handler. But these are awkward: check(name) f(a) check(name, f(a)) f(a) check name I hope check will be supplanted[2] by *symbol handler_name*, e.g. ?name = f(a);

[go-nuts] Re: New keywords and backwards compatibility

I suggested a //go:lang directive to select non-backwards-compatible features on the issue below, but it was rejected. https://github.com/golang/go/issues/28221 Note also the semver suggestion that each new version which provides non-backwards-compatible features should get a new major

[go-nuts] Re: A suggestion for the error handling proposal

You might want to read the links on the feedback wiki, if you haven't already: https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback Quite a lot of them suggest named handlers. Feel free to add your gist link to the wiki! On Monday, October 22, 2018 at 7:33:38 AM UTC-7, Burak Serdar

Re: [go-nuts] Feedback from Stripe developers on Go 2 draft designs

I have linked the webpage for this thread on the error handling feedback wiki https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback Could someone link it on the other wikis? On Wednesday, October 17, 2018 at 4:46:13 PM UTC-7, Ian Lance Taylor wrote: > > Thanks for the feedback. > > Please

[go-nuts] Re: Feedback from Stripe developers on Go 2 draft designs

Hi, thanks for posting this! > *Is `defer check f.Close()` valid?* *No, because the defer stack would run after the final handle block.* *I describe handlers within the defer stack in Requirements to Consider for Go 2 Error Handling*

Re: [go-nuts] Go language should become an ANSI and ISO standard.

You may need to find a large organization with ISO-only policy to approach the Go team directly, and help staff a standardization effort. If there is already a member of the Go team doing outreach to government and enterprise IT managers, it would be interesting to hear from them re

Re: [go-nuts] Error Handling Best Practice (error wrapping)

The Go designers considered and discarded exceptions for common errors, then added panic/recover for truly exceptional circumstance. There are known problems with try/catch: https://en.wikipedia.org/wiki/Exception_handling#Criticism I've posted a comprehensive list of "possible requirements"

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Note that the check/handle proposal has largely prompted counter-proposals and critique... https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback So I'd guess that the final product will look rather different :-) On Monday, October 8, 2018 at 7:54:54 AM UTC-7, Chris Hopkins wrote: > >

Re: [go-nuts] Golang, how dare you handle my checks! (Critique of error proposal)

/golang/go/wiki/Go2ErrorHandlingFeedback#requirements I also opened a thread regarding requirements on golang-dev last week, but no discussion has yet ensued. Cheers! Liam On Fri, Sep 21, 2018, 3:37 PM Sameer Ajmani wrote: > That's quite an interesting wiki page, thanks for sharing. > &g

[go-nuts] Re: Golang, how dare you handle my checks! (Critique of error proposal)

See also this comprehensive list of possible Go 2 error handling requirements on golang-dev: https://groups.google.com/d/topic/golang-dev/4x7Fv_wIiZg/discussion On Monday, September 10, 2018 at 6:11:16 AM UTC-7, Liam wrote: > > > "Golang, how dare you handle my checks!" >

[go-nuts] Go 2 error-handling: choose requirements!

There are *thirty-something* counter-proposals on the feedback wiki ! It's a bit of a train wreck :-p What that means, I believe, is that many folks see different requirement sets for a new error-handling idiom, so the union of the

Re: [go-nuts] Golang, how dare you handle my checks! (Critique of error proposal)

The contents of the feedback wiki are interesting. The Go 2 error proposal hasn't seen much support, and there are lots of counter-proposals... https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback On Mon, Sep 10, 2018, 6:11 AM Liam wrote: > > "Golang, how dare you handl

[go-nuts] Golang, how dare you handle my checks! (Critique of error proposal)

"Golang, how dare you handle my checks!" A Critique of the Go check/handle Error Proposal https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my-checks-d5485f991289 Upvote it on Hacker News :-) https://news.ycombinator.com/item?id=17951511 -- You received this message because you are

[go-nuts] Re: A "not-so-alien" syntax for error check.

See the feedback wiki . I encourage you to read the links there, then post your own. On Saturday, September 8, 2018 at 10:44:00 PM UTC-7, nvcnvn wrote: > > With the current proposal >

Re: [go-nuts] Re: Go2 Error Handling - Alternate Handler Concept

: > Absolutely, go ahead, thank you! I can add more "why" reasoning about > "grab" design differences from "catch", but won't get to it until next > weekend :( > > On Sunday, September 2, 2018 at 6:46:08 PM UTC-5, Liam wrote: >> >> Well, that wa

Re: [go-nuts] Re: Go2 Error Handling - Alternate Handler Concept

ted here or in golang-dev. > > On Wednesday, August 29, 2018 at 5:16:42 PM UTC-5, Liam wrote: >> >> Re the Go2 Error Handling proposal >> >> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md >> >> I have

[go-nuts] Go2 Error Handling - Alternate Handler Concept

Re the Go2 Error Handling proposal https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md I have posted this feedback https://gist.github.com/networkimprov/c6cb3e2dff18d31840f2ef22e79d4a1e Which contains an alternate handler concept. Please let me know if you think

Re: [go-nuts] Re: Ternary ... again

Normally the FooBar is full of other fields, necessitating the single field patch. On Sat, Aug 18, 2018, 1:17 PM Tim Peoples wrote: > Regarding your issues with the following... > > >> I've lost count of the times I've had to change: >> >> return FooBar{ >> Field: blah, >> } >> >> To: >> >>

Re: [go-nuts] Re: Ternary ... again

17, 2018 at 8:53:15 AM UTC+8, Liam wrote: >> >> I find that one-concept-per-line, yielding more compact functions, is >> easier to focus on, as it reduces vertical eye scanning and scrolling. >> >> A single-line if stmnt and my switch example demonstrate >> o

  1   2   >