[go-nuts] TMTP messaging protocol

[Liam Breck]

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 browser tab, rendered by Vue.js. Feedback &
contributions welcome!

[1] https://github.com/networkimprov/mnm/blob/master/Protocol.md
[2] https://github.com/networkimprov/mnm-hammer
[3] https://github.com/networkimprov/mnm

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgTW%3DPnEwg6F3tXVZEFa0pG%2BtmEAdmW-HaOWXiQMgfLpcA%40mail.gmail.com.

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

[Liam Breck]

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 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 server are written in Go. The client UI runs in a
> localhost browser tab, rendered by Vue.js. The client has had nine preview
> releases since Spring 2019.
>
> Contributors welcome!
>
> [1] https://github.com/networkimprov/mnm-hammer
> [2] https://github.com/networkimprov/mnm
> [3] https://github.com/networkimprov/mnm/blob/master/Protocol.md
>
> PS: Ambitious? Yes and no. Establishing a new protocol is a process, but
> email as we know it is headed for extinction, because phishing has made it
> a trivial cybercrime portal.
>
>

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgQDtMM%3Df8_ETVrZXpdqWm1_tkkaA1cAaGXucC7Rom5rVA%40mail.gmail.com.

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

[Liam Breck]

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 property of extensible
> > interpreters of being friendly to "hang things" onto just like ornaments
> on
> > trees. By linking with C/C++-libraries and adding glue/shim code,
> anything
> > can be used from Python. This facility and interpretive execution (as
> Eric
> > Johnson observed above) makes it a natural for discovery and trying of
> > things.
> >
> > These virtues may seem less so in eventual deployments, at scale, and in
> > other cases.
>
> True, and connects directly to my recent experience report.
>
> Python was the best language to prototype reposurgeon in,
> but scale pressure forced the move to Go.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
>
>

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgRSCF5MQW4CTew5kD4KKNkdt4X7c0X1gqDq6Bxyz98ssQ%40mail.gmail.com.

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

[Liam Breck]

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:
> >>
> >> 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?
> >
> > Two locks and a bool?
> >
> > var door=sync.Mutex{}
> > var x=sync.Mutex{}
> > var b bool
> >
> > func trylock() bool {
> > x.Lock()
> > if b {
> >  x.Unlock()
> >  return false
> > }
> > b=true
> > door.Lock()
> > x.Unlock()
> > return true
> > }
> >
> > unlock:
> >
> > x.Lock()
> > b=false
> > door.Unlock()
> > x.Unlock()
> >
> >
> >
> >
> >>
> >> --
> >> 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 this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKvHMgTO%3DxfFQ_u7aO9UE-1vHHEKmdhr47sro2mnp6DkEb6mPA%40mail.gmail.com
> .
> >
> > --
> > 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 this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrDeBNhkeswg%2BhdCf1kSzMEJduota%3D6UrNq4z2PQRtzEQ%40mail.gmail.com
> .
>
>

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgQROw%3DoxSP%2BT3m_woZXX4ke3gP02BpXiFMv-1Nb9cs-tA%40mail.gmail.com.

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

[Liam Breck]

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 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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgTO%3DxfFQ_u7aO9UE-1vHHEKmdhr47sro2mnp6DkEb6mPA%40mail.gmail.com.

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

[Liam Breck]

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 does Response.Body.Close() before io.EOF not release unread
> buffers or otherwise prepare it for persistence?
>
> The connection can’t be reused for another request before all the data
> from the first request is read. The server is sending those bytes over the
> wire, and they need to go somewhere before another response can be read. So
> there were two options for how to implement Close when the whole body
> hasn’t been read:
>
> 1. Copy the rest of the body to /dev/null (or equivalent), and reuse the
> connection like normal.
> 2. Close the connection, thus communicating to the server that we don’t
> need that data after all.
>
> Option 1 would generally be preferable for short responses, and option 2
> for long ones. For consistency, and because we don’t always know the
> response length in advance (e.g. if it is chunked), it always does option 2.
>

So after read-to-EOF, Close() behaves differently, i.e. it does reset for
next request?

In the event of early Close(), should I discard that Client instance? Or
will it work for subsequent requests?

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgRH6K5WBdAoMVnq6KsHi7Hnqqhm39ZcUHX%3DWBCbfKsiwg%40mail.gmail.com.

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

[Liam Breck]

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 rebuild and reinstall
> pkg/tool/.../link ?
>
> I think there are two options:
>
> - Learn how to make the distro's package from sources.
> - Install Go from sources: https://golang.org/doc/install/source.
>

Hoping it's easier, as it has a full src directory installed, with
src/cmd/link/*

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgSHe1WD303aYF20xCpELp_O%3Dj1qxTjUkiKRz%3DsmGgT6Rw%40mail.gmail.com.

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

[Liam Breck]

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
> Unix-like
> > behavior in Go 1.14:
> > https://github.com/golang/go/issues/32088
> >
> > I believe this will change early in pre-release 1.14.
>
> May I inquire as to why you believe that?
> Reading the issue itself, nothing points to a favorable opinion to your
> change request.
> At least not from the comments there.
>
> Most of the members / contributors either speak clearly against it, or are
> very
> cautious.
>
> The only thing is the go1.4 milestone, but milestones tend to be shifted
> around quite often.
>
> Can you please point to the discussion where this was decided?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/aRvSo3iKvJY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20190804091533.o2lz7s7gpyqotaz2%40feather.localdomain
> .
>

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgTu2EO4OFrvPo%3DVoxeFLaVxM2nWScuoxbfrzNXcrJRd0g%40mail.gmail.com.

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

[Liam Breck]

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 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 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 function
>> on err, continue  // retry in a loop
>>
>> on err, goto label// labeled handler invocation
>> on err, hname // named handler invocation
>>
>>
>>
>> And offers these possible extensions:
>>
>> on err, os.IsNotExist(err):  
>> on err, err == io.EOF:   
>> on err, err.(*os.PathError): // doesn't panic if not a match
>>
>> on err, : 
>> on err:   // this pair provides if/else in 2 lines
>>
>> on err := f(),  // for assignment with single lvalue
>>
>>
>>
>> Other punctuation is possible, e.g. on (err) 
>>
>> Now if we could just convince the Go gods to prototype this along with
>> try() in 1.14 :-)
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/4Djft8snCjM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/1b7ab9bd-0c1b-4658-8ee2-a36544b58f20%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/1b7ab9bd-0c1b-4658-8ee2-a36544b58f20%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgQpFe-tOuDyYfVE%3DzfLUjZgk5nq%3D5Hdh8wXE_v3cmq75Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Liam Breck]

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 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 function
> on err, continue  // retry in a loop
>
> on err, goto label// labeled handler invocation
> on err, hname // named handler invocation
>
>
>
> And offers these possible extensions:
>
> on err, os.IsNotExist(err):  
> on err, err == io.EOF:   
> on err, err.(*os.PathError): // doesn't panic if not a match
>
> on err, : 
> on err:   // this pair provides if/else in 2 lines
>
> on err := f(),  // for assignment with single lvalue
>
>
>
> Other punctuation is possible, e.g. on (err) 
>
> Now if we could just convince the Go gods to prototype this along with
> try() in 1.14 :-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/4Djft8snCjM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1b7ab9bd-0c1b-4658-8ee2-a36544b58f20%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgTYHEx5o%2Bxn8TSL6a46utuf%3DJn%2Boko-Dess6LbWBBWZnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Liam Breck]

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 placement would make it somehow impossible (or at least I
> cannot see it right now) to use with someExpression?.someMember
> If I am not mistaken, yours is close to the currently proposed "try", just
> replacing it with ?, am I right on that ?
>
> A.
>
> On Monday, July 1, 2019 at 2:49:09 AM UTC-6, Liam wrote:
>>
>> 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 will(always(work()?)?)?
>>
>> On Saturday, June 29, 2019 at 4:05:44 PM UTC-7, Michael Jones wrote:
>>>
>>> My personal thought, though it may seem strange, is that the best
>>> argument for it lies in the single word sentence at the bottom of your
>>> email. You write "Thoughts?" -- and that is very expressive in English in
>>> just the way that you mean above in your examples. I don't know enough
>>> other languages to really know if the parallels are universal, but it's
>>> pretty clear to me what it means why "file?.close()" and
>>> "os.Open(filename)?" are "punctuated" as they are -- where the question is.
>>> I feel like you're asking this compiler, "is there anything about this
>>> value that you need to tell me?" I like that.
>>>
>>> The long (crazy long!) discussion of error handling has among its many
>>> branches an analysis from the Go team about '?' and this kind of postfix
>>> interrogation. I'm watching it all with a bit of wonder, but I wanted to
>>> speak up and say how your human-language phrasing matches your idea of
>>> computer-language phrasing. That seems a powerful kind of naturalness to
>>> take advantage of in this issue and future ones.
>>>
>>> On Sat, Jun 29, 2019 at 2:56 PM Andrey Tcherepanov <
>>> xnow4f...@sneakemail.com> wrote:
>>>
 Hello mighty fighters of errors!

 Here comes my half-thought idea of another way to express error
 handling:

 *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND
 an error for nil. *

 (Denis have shred it to pieces already in
 https://github.com/golang/go/issues/32852. Thank you Denis.)

 I am not good with expressing my inner talk, so there are couple
 examples

 original , Go 1 function

 func stat(filename string) (os.FileInfo, error) {

 var info os.FileInfo
 {
 var a1 *os.File
 if a1, err := os.Open(filename); err != nil || a1 == nil {
 return _, err
 }
 var a2 os.FileInfo
 if a2, err := a1.Stat(); err != nil || a2 == nil {
 return _, err
 }
 info = a2
 }
 return info, nil
 }


 And with "?", trying to avoid original try() proposal handle leak

 // would return _, err, but since there is no err in signature, will 
 return default value in case of error
 // uses ? on func call that returns (value, error)
 func stat2(filename string) (os.FileInfo) {
  file := os.Open(filename)?
  defer file.Close()
  return file.Stat()?
 }
 // would return error too, uses ? as "not nil" on a variable too
 func stat3(filename string) (_ os.FileInfo, err error) {
  var file *os.File
  defer file?.Close()
  file := os.Open(filename)?
  return file.Stat()
 }


 Thoughts?

 --
 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 golan...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>> --
>>>
>>> *Michael T. jonesmichae...@gmail.com*
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/-lmobOi3p5s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/93987580-3f1d-4ab8-b796-2e095d49a3b4%40googlegroups.com
> 

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

[Liam Breck]

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, path_b)// or os.Remove(path)
if err != nil { ... }  // sharing violation
fd.Close()


Do you know of Windows apps that expect this error, which is undocumented
in package "os" ?

Microsoft has suggested that Go on Windows should switch to Unix-like
behavior:
https://github.com/golang/go/issues/32088

-- 
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 this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKvHMgSWehzEATg5L_w6mCngnm1q1LkVyQ8PpE1T1R9%3D5QQ-gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Liam Breck]

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 https://groups.google.com/d/optout.

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

[Liam Breck]

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 email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Project install for go mod

[Liam Breck]

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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Liam Breck]

Maybe fmt.Errorf encourages
  fmt.Errorf("%v %v", false, 42)

Or worse
  fmt.Errorf("error %v %v", false, 42)

:-)

On Sun, Dec 30, 2018, 1:07 AM Jakob Borg  I would suggest that an error should start with a descriptive string. The
> existing methods encourage this. A fmt.Error 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, see docs for fmt.Print(...interface{})
>>
>
> Ah true. I forgot about the whitespace formatting versions. I stand
> corrected that a fmt.Error would actually perform formatting and would be
> consistent with Sprint and Print. My only guess now is that it *could* have
> been in the errors package if the errors package had been created at the
> same time as the fmt package, but it was added later after fmt.Errorf
> already existed.
>
>
>>
>> On Sun, Dec 30, 2018, 12:15 AM Justin Israel > wrote:
>>
>>>
>>>
>>> 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 this function to accept a variable number of
>>> arguments when there is no formatting or printing implied by the name of
>>> the function?
>>>
>>>
>>>> Given that other fmt functions come in that variety?
>>>>
>>>
>>> The other functions in the fmt package do some kind of formatting with
>>> the arguments (newlines, format string)
>>>
>>>
>>>> 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?
>>>>
>>>
>>> I have a feeling it wouldn't be accepted since it would just duplicate
>>> the functionality of errors.New() and it doesn't provide any extra
>>> formatting functionality.
>>>
>>>
>>>> Happy New Year to all :-)
>>>>
>>>> --
>>>> 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 https://groups.google.com/d/optout.
>>>>
>>> --
> 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 https://groups.google.com/d/optout.
>
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

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 this function to accept a variable number of
> arguments when there is no formatting or printing implied by the name of
> the function?
>
>
>> Given that other fmt functions come in that variety?
>>
>
> The other functions in the fmt package do some kind of formatting with the
> arguments (newlines, format string)
>
>
>> 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?
>>
>
> I have a feeling it wouldn't be accepted since it would just duplicate the
> functionality of errors.New() and it doesn't provide any extra formatting
> functionality.
>
>
>> Happy New Year to all :-)
>>
>> --
>> 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 https://groups.google.com/d/optout.
>>
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

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 :-)

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Generic function aliases

[Liam Breck]

I meant this should work

https://play.golang.org/p/w6MBzP9RNdH

On Tue, Dec 4, 2018, 11:21 AM messju mohr  Erm, function names may be const, but functions are first class citizen
> types and can of course be assigned to variables and be passed around.
>
> just my 2c
>
> On Tue, Dec 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 can use
> >  var Gi = g.G(int)
> >  or you can use
> >  func Gi(i int) error { return g.G(i) }
> >  for the same effect. Which is pretty much the reason why
> >  alias-declarations 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 <[2]
> l...@networkimprov.net>
> >  wrote:
> >
> >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 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 [3]golang-nuts+unsubscr...@googlegroups.com.
> >For more options, visit [4]https://groups.google.com/d/optout.
> >
> >--
> >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 [5]golang-nuts+unsubscr...@googlegroups.com.
> >For more options, visit [6]https://groups.google.com/d/optout.
> >
> > References
> >
> >Visible links
> >1. mailto:axel.wagner...@googlemail.com
> >2. mailto:l...@networkimprov.net
> >3. mailto:golang-nuts+unsubscr...@googlegroups.com
> >4. https://groups.google.com/d/optout
> >5. mailto:golang-nuts+unsubscr...@googlegroups.com
> >6. https://groups.google.com/d/optout
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Generic function aliases

[Liam Breck]

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  You can use
> var Gi = g.G(int)
> or you can use
> func Gi(i int) error { return g.G(i) }
> for the same effect. Which is pretty much the reason why
> alias-declarations 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 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 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 https://groups.google.com/d/optout.
>>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Generic function aliases

[Liam Breck]

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 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 https://groups.google.com/d/optout.

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

[Liam Breck]

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
> >
> > Recently I was asked about support for a test harness in functions that
> contain error handlers; my document doesn't address this. My first guess is
> that the tooling could generate a function to mirror the one being tested,
> which takes a slice argument with a handler input (or function to call) for
> each handler invocation site in the function:
> >
> > func f(i int) {  // function to test
> >op hname = x(i)
> >handle hname T { ... }
> > }
> > func f_errors(i int, e [1]interface{}) { // generated for go-test
> >op hname = e[0].(T)   // or e[0].(func(int)T)(i)
> >handle hname T { ... }
> > }
> >
> >
> > I'd love to hear other ideas about triggering error handlers from a test
> harness.
>
> You don't need the new handler syntax to do this, although the 'check'
> keyword would make things much easier. You can parse a function,
> identify all error returning calls, and replace them with a call to a
> func() passed in as an argument.
>

Parse & replace, yes above I suggested the compiler could do that in a
testing pass, generating f_errors()

But something like this would be very hard to maintain, I think. When
> you reorganize the function, you need to reorder that []interface
> argument to match.
>

Need to reorder the argument, yes but that only adds burden for functions
whose effect is unchanged by reordering.

I once did something like this, in a Java project, by manually
> instrumenting the code to put named breakpoints, so I can intercept
> the execution. I think in something like this the key is to be able to
> invoke handlers by name, not by sequence. So if you already rewrote
> the function, why not pass in a map[string]func(), keyed by handler
> name?
>

f_errors(..., e map[string]interface{}) is a useful alternative. The
compiler could generate that or f_errors(..., e []interface{}), depending
on the type passed by the caller.

Thanks for the feedback!

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

Hi Sameer,

Glad to hear someone's reading my posts re Go 2 error handling! Debate on
generics simmers in multiple threads, but discussion of error handling,
which impacts many more gophers and lines of code, has been almost
non-existent.

Reading the feedback wiki, one might surmise that the draft design fell
wide of the mark. That begs the question, Where lies the mark?

In quest thereof, I've added a Requirements section to the wiki, with links
to @ianlancetaylor's original criteria list, and my own comprehensive list
of possible requirements for a Go 2 error idiom.

https://github.com/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.
>
> On Thu, Sep 13, 2018 at 2:46 PM Liam Breck 
> wrote:
>
>> 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 handle my checks!"
>>> A Critique of the Go check/handle Error Proposal
>>>
>>>
>>> https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my-checks-d5485f991289
>>>
>>>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

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 handle my checks!"
> A Critique of the Go check/handle Error Proposal
>
>
> https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my-checks-d5485f991289
>
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

Posted your link to the feedback wiki, and to my design-revision draft,
which will land on the issue tracker this week.

https://golang.org/wiki/Go2ErrorHandlingFeedback

https://gist.github.com/networkimprov/c6cb3e2dff18d31840f2ef22e79d4a1e


On Sun, Sep 2, 2018, 4:49 PM Vlad Didenko  wrote:

> 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 was then, this is now...
>>
>> I'll just note that 10 of 30 feedback posts on the error handling draft
>> feedback wiki have asked for named handlers. Can I add your link there?
>>
>>
>> On Sun, Sep 2, 2018, 4:33 PM Vlad Didenko  wrote:
>>
>>> Some time ago, after going through a very similar design (really, even
>>> had the catch clause in there), I have arrived at a more generalized
>>> version of it. That contemplation (still available at
>>> https://didenko.github.io/grab/grab_worth_it_0.1.1.html ) was very much
>>> unaccepted here.
>>>
>>> Well, I actually do not remember if it was posted 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 posted this feedback

 https://gist.github.com/networkimprov/c6cb3e2dff18d31840f2ef22e79d4a1e

 Which contains an alternate handler concept. Please let me know if you
 think this merits its own github.com/golang issue.

 A *flag identifier *indicates errors of various types. This also allows 
 chaining of handlers with the same flag name. There are options for the 
 #flag syntax, e.g. flag!, $flag, @flag, etc.

 func f() {
v, #ret := returnIfError()   // #ret can be any type; any non-zero 
 value for it triggers its catch
v, #fat := fatalIfError()// #ret, etc are (probably) not local 
 variables
v, #wrt := writeOnError()
if v != nice { // new scope
   #fat = MyError{msg:"!nice", ...}
   catch fat error { debug.PrintStack() }  // no return/exit; 
 chained with next catch fat
}
#packageFlag = anotherError() // invokes package-level handler

catch ret error { return ret } // if type is error, 
 type name could be optional
catch fat error { log.Fatal(fat) }
catch wrt error { con.Write(...); return nil } // return/exit required 
 in last handler on chain
 }

 catch packageFlag error { ... } // package-level handler; packageFlag is 
 not a package variable

 --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/tW97ZxsCvdQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/tW97ZxsCvdQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

Well, that was then, this is now...

I'll just note that 10 of 30 feedback posts on the error handling draft
feedback wiki have asked for named handlers. Can I add your link there?


On Sun, Sep 2, 2018, 4:33 PM Vlad Didenko  wrote:

> Some time ago, after going through a very similar design (really, even had
> the catch clause in there), I have arrived at a more generalized version of
> it. That contemplation (still available at
> https://didenko.github.io/grab/grab_worth_it_0.1.1.html ) was very much
> unaccepted here.
>
> Well, I actually do not remember if it was posted 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 posted this feedback
>>   https://gist.github.com/networkimprov/c6cb3e2dff18d31840f2ef22e79d4a1e
>>
>> Which contains an alternate handler concept. Please let me know if you
>> think this merits its own github.com/golang issue.
>>
>> A *flag identifier *indicates errors of various types. This also allows 
>> chaining of handlers with the same flag name. There are options for the 
>> #flag syntax, e.g. flag!, $flag, @flag, etc.
>>
>> func f() {
>>v, #ret := returnIfError()   // #ret can be any type; any non-zero value 
>> for it triggers its catch
>>v, #fat := fatalIfError()// #ret, etc are (probably) not local 
>> variables
>>v, #wrt := writeOnError()
>>if v != nice { // new scope
>>   #fat = MyError{msg:"!nice", ...}
>>   catch fat error { debug.PrintStack() }  // no return/exit; chained 
>> with next catch fat
>>}
>>#packageFlag = anotherError() // invokes package-level handler
>>
>>catch ret error { return ret } // if type is error, type 
>> name could be optional
>>catch fat error { log.Fatal(fat) }
>>catch wrt error { con.Write(...); return nil } // return/exit required in 
>> last handler on chain
>> }
>>
>> catch packageFlag error { ... } // package-level handler; packageFlag is not 
>> a package variable
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/tW97ZxsCvdQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

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:
>>
>> var foo FooBar
>> if someCond {
>> foo.Field = blah
>> } else {
>> foo.Field = bar
>> }
>> return foo
>>
>
>  ...I hardly consider that to be idiomatic Go.  A more go-like approach
> would be to follow the guideline to "return early" and write it more like
> this:
>
>  if someCond {
>   return FooBar{Field: blah}
> }
>
> return FooBar{Field: bar}
>
>
> ...which (IMHO) is markedly more readable than a ternary expression.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/MrpkS4epn_E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

People have a wide range of perceptive and cognitive abilities. People also
have difficulty imagining the very different abilities that others possess.

I find constant vertical scanning and scrolling to be distracting and thus
inefficient. So I won't use a tool that adds line breaks to my code, and
I'd benefit from a one-line switch.

This is a good compromise, less cryptic than ?:

v = if t a; else b // else can be on next line
v = if (t) a; else b // parens isolate the test if required

And maybe that implies

v = switch t; case 1 a; case 2 b

Note that go fmt allows this clumsy construct

if err = pkg.ActionItem(); err != nil { // which op is tested?
   return err
}

While exploding this clear one

err = pkg.ActionItem()
if err != nil { return err }


On Thu, Aug 16, 2018, 9:08 PM 'Kean Ho Chew' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Friday, August 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
>> one-concept-per-line.
>>
>> The thing is, what is cost with the current if else expression that worth
> more to introduce another possible complications? Like my previous email
> and other developers had implied, LOC doesn't matter. In the end, the
> compiler knows what to do.
>
> It's okay to do vertical eye scanning (we're doing it anyway while we're
> coding/reviewing). When ternary logic is abused, we need to do vertical +
> horizontal scrolling.
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

Ah, very nice! Tho I can't tell from scanning the readme which features are
different than go fmt.

On Fri, Aug 17, 2018, 1:17 AM Matthias B.  wrote:

> On Thu, 16 Aug 2018 16:54:35 -0700
> Liam Breck  wrote:
>
> > Indeed, the problem is largely go fmt, I already raised this, but no
> > one picked up on it:
> >
> > I use this one-liner:
> >
> > v := a; if t { v = b }
> >
> > This is not compatible with go fmt, but that tool's effects are
> > undocumented (see issue 18790
> > <https://github.com/golang/go/issues/18790> which was declined), and
> > it has no switches to disable/enable features.
>
> Now THAT is something I can help you with:
>
> https://github.com/mbenkmann/goformat
>
> has the option "inlineblocks=keep" which should give you what you want.
> And if it doesn't, you're welcome to contribute more switches.
>
> MSB
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

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
one-concept-per-line.

go fmt aspires to produce an odd sort of poetry, which I find inefficient.
It's especially bad in GitHub commits.

Providing a small menu of recommended project-wide formats, and allowing
maintainers to tailor one for their needs would be most helpful. As is, I
eschew it.

On Thu, Aug 16, 2018, 5:18 PM Christopher Nielsen 
wrote:

> How is a ternary more readable? I've found that they make code more
> complex and unreadable, in both C and the proposed go, and the one-liner
> you provide is equally or more unreadable than the more verbose if
> statement.
>
> On Thu, Aug 16, 2018, 16:55 Liam Breck  wrote:
>
>> Indeed, the problem is largely go fmt, I already raised this, but no one
>> picked up on it:
>>
>> I use this one-liner:
>>
>> v := a; if t { v = b }
>>
>> This is not compatible with go fmt, but that tool's effects are
>> undocumented (see issue 18790 <https://github.com/golang/go/issues/18790> 
>> which
>> was declined), and it has no switches to disable/enable features. A
>> syntax-aware sed is a good idea, but sadly go fmt destroys useful
>> constructs. Other examples:
>>
>> err := fn()
>> if err != nil { return err }
>>
>> switch v {
>> case 1: pkg.one()
>> case 2: pkg.two()
>> case 3: pkg.thrice()
>> }
>>
>> On Thu, Aug 16, 2018, 3:30 PM Matthias B.  wrote:
>>
>>> On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
>>> Hoo Luu  wrote:
>>>
>>> > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
>>> >
>>> > > var color = temperature > 100 ? “red” : “blue”
>>> >
>>> >
>>> > Although this feature will not be accepted, we could just talk about
>>> > it. I prefer 'if-expression'  to ternary.
>>> >
>>> > var color = if temperature > 100 { "red" } else { "blue" }
>>> >
>>> > vs. current if statement syntax:
>>> >
>>> > var color
>>> > if temperature > 100 {
>>> > color = "red"
>>> > } else {
>>> > color = "blue"
>>> > }
>>> >
>>>
>>> I get the impression that the real issue here is that gofmt will break
>>>
>>> if temperature > 100 { color = "red" } else { color = "blue" }
>>>
>>> over multiple lines and that what the people asking for a ternary
>>> operator really want is a one-liner. So ask yourselves, if gofmt were
>>> to format your ternary operator (or the above suggested if-expression)
>>> identical to the if statement, i.e. across the same number of lines,
>>> would you still want it?
>>>
>>> var color =
>>> if temperature > 100 {
>>>  "red"
>>> } else {
>>>  "blue"
>>> }
>>>
>>>
>>> var color =
>>> temperature > 100 ?
>>>   "red"
>>> :
>>>   "blue"
>>>
>>>
>>> If you would NOT use these, your real issue is with gofmt, not the Go
>>> language.
>>>
>>>
>>> MSB
>>>
>>>
>>> --
>> 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 https://groups.google.com/d/optout.
>>
>

-- 
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 https://groups.google.com/d/optout.

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

[Liam Breck]

Indeed, the problem is largely go fmt, I already raised this, but no one
picked up on it:

I use this one-liner:

v := a; if t { v = b }

This is not compatible with go fmt, but that tool's effects are
undocumented (see issue 18790  which
was declined), and it has no switches to disable/enable features. A
syntax-aware sed is a good idea, but sadly go fmt destroys useful
constructs. Other examples:

err := fn()
if err != nil { return err }

switch v {
case 1: pkg.one()
case 2: pkg.two()
case 3: pkg.thrice()
}

On Thu, Aug 16, 2018, 3:30 PM Matthias B.  wrote:

> On Wed, 15 Aug 2018 07:46:51 -0700 (PDT)
> Hoo Luu  wrote:
>
> > 在 2018年8月15日星期三 UTC+8上午12:43:37，Mark Volkmann写道:
> >
> > > var color = temperature > 100 ? “red” : “blue”
> >
> >
> > Although this feature will not be accepted, we could just talk about
> > it. I prefer 'if-expression'  to ternary.
> >
> > var color = if temperature > 100 { "red" } else { "blue" }
> >
> > vs. current if statement syntax:
> >
> > var color
> > if temperature > 100 {
> > color = "red"
> > } else {
> > color = "blue"
> > }
> >
>
> I get the impression that the real issue here is that gofmt will break
>
> if temperature > 100 { color = "red" } else { color = "blue" }
>
> over multiple lines and that what the people asking for a ternary
> operator really want is a one-liner. So ask yourselves, if gofmt were
> to format your ternary operator (or the above suggested if-expression)
> identical to the if statement, i.e. across the same number of lines,
> would you still want it?
>
> var color =
> if temperature > 100 {
>  "red"
> } else {
>  "blue"
> }
>
>
> var color =
> temperature > 100 ?
>   "red"
> :
>   "blue"
>
>
> If you would NOT use these, your real issue is with gofmt, not the Go
> language.
>
>
> MSB
>
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] go mod: x/net,etc repos need version tags

[Liam Breck]

Retry under clarified subject...

I could not find a version number for x/net or x/net/ipv4. If none exists,
> could the maintainers start committing version tags for each submodule in
> golang.org/x -- i.e. x/*/* (or x/* if no submodules)?
>
> This will benefit the imminent rush of *go mod* users :-)
>
> I did not find an issue filed for this; shall I add one?
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: cross-compile with cgo 'permission denied'

[Liam Breck]

On Oct 25, 2016 3:49 PM, "Ian Lance Taylor"  wrote:
>
> On Tue, Oct 25, 2016 at 2:23 PM, Liam  wrote:
> > What I wanted was the magic incantation (documented nowhere) for
linux_arm
> > installation:
> >
> >GOOS=linux GOARCH=arm CGO_ENABLED=1 CC=arm-linux-gnueabihf-gcc go
install
> > -v -a std
> >GOOS=linux GOARCH=arm CGO_ENABLED=1 CC=arm-linux-gnueabihf-gcc go
install
> > -v -a cmd
> >
> > where CC varies for the toolchain installed.
> >
> > Would the maintainers mind if I filed an issue for this under the docs
tag?
>
> Even better than an issue would be a change (see
> https://golang.org/doc/contribute.html).  But an issue is still OK,
> but please tell us where it should be documented.

Filed issue here
https://github.com/golang/go/issues/17620

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam Breck]

On Oct 16, 2016 6:03 PM, "Liam Breck" <networkimp...@gmail.com> wrote:
>
>
>
> On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Sun, Oct 16, 2016 at 5:25 PM, Liam <networkimp...@gmail.com> wrote:
>> >
>> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor
wrote:
>> >>
>> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam <networ...@gmail.com> wrote:
>> >> >
>> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor
wrote:
>> >> >
>> >> >> To argue that this should go into the standard library, look at
some
>> >> >> corpus of Go code and find out how often it occurs.  If it occurs
>> >> >> fairly often, you've got a good case.
>> >> >
>> >> >
>> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it
>> >> > passes
>> >> > that test.
>> >>
>> >> This is something that can actually be measured.
>> >
>> >
>> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
>> > Neither of these will be accurate.
>> >
>> > Part of my point is that Insert operations are semantically obscured.
>>
>> Understood.  But my guess is that insertion operations are fairly
>> rare--much less common than Replace or Trim.  People obviously append
>> to slices all the time, but I suspect that they tend to write their
>> slice operations to not require inserting a single element in the
>> middle of the slice, because insertion is by definition O(N) rather
>> than O(1).  I could certainly be wrong, but that guess leads me to
>> suspect that adding a function for something that can easily be
>> written in a single expression is overkill.  Since I am only guessing,
>> and since it seems to me that you are also guessing, I think we should
>> measure rather than guess.
>
>
> You characterize optimization as a widespread habit. Most code isn't
optimized, as it doesn't need to be. Most coders follow the first advice
found, which in my case was Insert() on [1]. If you wish the most optimal
solution to be widespread, stdlib would be a good vehicle :-)
>
> I would attempt to provide data confirming my guess, but I can't see how
to do that without spending a lot of time hunting for semantically
invisible operations. Since there are two authoritative suggestions for
this op, it's a reasonable guess that it's widely done.
>
> BTW, we are having this discussion because fmt does not support thousands
grouping, which also seems like a common need.
>
> [1] https://blog.golang.org/slices

As an alternative to bytes.Insert/Delete how about

bytes.Replace(s []byte, pos int, len uint, new []byte)

A zero len is insert, and empty new is delete.

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Why no bytes.InsertByte(s []byte, p int, b byte) []byte ?

[Liam Breck]

On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor  wrote:

> On Sun, Oct 16, 2016 at 5:25 PM, Liam  wrote:
> >
> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote:
> >>
> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam  wrote:
> >> >
> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor
> wrote:
> >> >
> >> >> To argue that this should go into the standard library, look at some
> >> >> corpus of Go code and find out how often it occurs.  If it occurs
> >> >> fairly often, you've got a good case.
> >> >
> >> >
> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it
> >> > passes
> >> > that test.
> >>
> >> This is something that can actually be measured.
> >
> >
> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ?
> > Neither of these will be accurate.
> >
> > Part of my point is that Insert operations are semantically obscured.
>
> Understood.  But my guess is that insertion operations are fairly
> rare--much less common than Replace or Trim.  People obviously append
> to slices all the time, but I suspect that they tend to write their
> slice operations to not require inserting a single element in the
> middle of the slice, because insertion is by definition O(N) rather
> than O(1).  I could certainly be wrong, but that guess leads me to
> suspect that adding a function for something that can easily be
> written in a single expression is overkill.  Since I am only guessing,
> and since it seems to me that you are also guessing, I think we should
> measure rather than guess.
>

You characterize optimization as a widespread habit. Most code isn't
optimized, as it doesn't need to be. Most coders follow the first advice
found, which in my case was Insert() on [1]. If you wish the most optimal
solution to be widespread, stdlib would be a good vehicle :-)

I would attempt to provide data confirming my guess, but I can't see how to
do that without spending a lot of time hunting for semantically invisible
operations. Since there are two authoritative suggestions for this op, it's
a reasonable guess that it's widely done.

BTW, we are having this discussion because fmt does not support thousands
grouping, which also seems like a common need.

[1] https://blog.golang.org/slices

-- 
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 https://groups.google.com/d/optout.