from:"Michael"

Thanks, Axel & Robert.  As I said in the first post, the package already 
works well for my purposes (and apparently for the few others who use it).  
It allows defining web content more concisely than raw HTML and makes the 
full power of Go available for composing repetitive page structures.

I was mostly just curious about the possibility of detecting bad content at 
compile time instead of at run time. In practice, that's turned out not to 
be a significant problem so I'm ok with learning generics don't support a 
fix.

On Monday, December 20, 2021 at 2:31:32 PM UTC-5 axel.wa...@googlemail.com 
wrote:

> Oh, forgot the footnote:
>
> [1] Note that even that doesn't *actually* work, as `*HtmlNode` would 
> become a parametric type, so it would have to be instantiated to be used in 
> the constraint - you'd have to write `type HtmlNode[T string | 
> *HtmlNode[Something]]`. And the fact that there is no actual answer to what 
> "Something" would be should be a strong indicator for how much generics are 
> not what you want for this.
>
> On Mon, Dec 20, 2021 at 8:29 PM Axel Wagner  
> wrote:
>
>>
>>
>> On Mon, Dec 20, 2021 at 7:07 PM Michael Ellis  
>> wrote:
>>
>>> >Just to be clear, the way I understood you is that you want HtmlTree.C 
>>> to be a slice which has elements which can each either be a string or an 
>>> *HtmlTree - i.e. you want these to be mixed in a single slice. Correct?
>>>
>>> Actually, no.  An HtmlTree instance whose content is a string is a 
>>> terminal node.  The recursion in the Render() func looks like:
>>>
>>>   for _, c := range h.C {
>>> switch c := c.(type) {
>>> case string:
>>> b.WriteString(c)
>>> case *HtmlTree:
>>> err = Render(c, b, rindent)
>>> if err != nil {
>>> return fmt.Errorf("%s : %v", h.T, err)
>>> }
>>> default:
>>> return fmt.Errorf("Bad content %v. Can't render 
>>> type %T! ", h.C, c)
>>> }
>>> }
>>>
>>
>> That's pretty much what I meant, yes. You want a sum type (and in lieu of 
>> sum types, an interface), not generics. 
>> The "union" aspect of Go generics (the `a | b` syntax) only applies to 
>> using interfaces as *constraints*, not as *types* - you want to do the 
>> latter. You want to have a field which is either a string or an *HtmlNode - 
>> but Go only gives you a convenient way to write the two distinct types 
>> `type HtmlNodeString struct { /*…*/ C string }` and `type HtmlNodeNode 
>> struct { /* … */ C *HtmlNode }` into one¹ type declaration and write 
>> function which can work on either. It's just not what you want.
>>
>> The best option for you is (as Robert mentions) to use an interface, 
>> which is an "open sum" - meaning you can't have the guarantee that its 
>> dynamic type is of a limited set of options, but you *can* have a value 
>> whose actual type is dynamic. You can look at e.g. ast.Node 
>> <https://pkg.go.dev/go/ast#Node>, which is de-facto the same thing - 
>> it's supposed to be a limited set of options, but in lieu of sum types, 
>> it's an interface.
>>
>> Go might, at some point, allow the union-elements of constraint 
>> interfaces to be used as actual types, which *would* be a form of sum 
>> types. But probably not for a while - it's more complicated than it may 
>> seem.
>>
>>
>>>
>>> I suppose it's still a problem, though, since the compiler doesn't have 
>>> any way of knowing that's how trees of HtmlTree meant to be constructed. I 
>>> should have expressed the intended constraint on HtmlTree.C as `string | 
>>> []*HtmlTree`.  Does that make a difference?
>>> On Monday, December 20, 2021 at 10:25:26 AM UTC-5 
>>> axel.wa...@googlemail.com wrote:
>>>
>>>> Just to be clear, the way I understood you is that you want HtmlTree.C 
>>>> to be a slice which has elements which can each either be a string or an 
>>>> *HtmlTree - i.e. you wan these to be mixed in a single slice. Correct?
>>>> Because that is not a use case for generics, it's a use case for sum 
>>>> types (which Go does not have).
>>>>
>>>> On Mon, Dec 20, 2021 at 4:11 PM Michael Ellis  
>>>> wrote:
>>>>
>>>>> > They can't, sorry.
>>>&

Re: [go-nuts] Generic member of recursive struct

On Monday, December 20, 2021 at 1:33:49 PM UTC-5 ren...@ix.netcom.com wrote:

> You should use interfaces and a “node” type.
>

Hmm, I tried 

type Node interface {
string | []*HtmlTree
}

type HtmlTree struct {
T string // html tagname, e.g. 'head'
A string // zero or more html attributes, e.g 'id=1 class="foo"'
C Node   // a slice of content whose elements may be strings or 
*HtmlTree
empty bool   // set to true for empty tags like 
}

and the compiler said: 
./prog.go:21:8: interface contains type constraints.

(line 21 is the declaration of HtmlTree.C as type Node)

What's the syntax you have in mind?

-- 
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/c619d54d-5a69-4828-b10b-771722f8f646n%40googlegroups.com.

Re: [go-nuts] Generic member of recursive struct

>Just to be clear, the way I understood you is that you want HtmlTree.C to 
be a slice which has elements which can each either be a string or an 
*HtmlTree - i.e. you want these to be mixed in a single slice. Correct?

Actually, no.  An HtmlTree instance whose content is a string is a terminal 
node.  The recursion in the Render() func looks like:

  for _, c := range h.C {
switch c := c.(type) {
case string:
b.WriteString(c)
case *HtmlTree:
err = Render(c, b, rindent)
if err != nil {
return fmt.Errorf("%s : %v", h.T, err)
}
default:
return fmt.Errorf("Bad content %v. Can't render 
type %T! ", h.C, c)
}
}

I suppose it's still a problem, though, since the compiler doesn't have any 
way of knowing that's how trees of HtmlTree meant to be constructed. I 
should have expressed the intended constraint on HtmlTree.C as `string | 
[]*HtmlTree`.  Does that make a difference?
On Monday, December 20, 2021 at 10:25:26 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> Just to be clear, the way I understood you is that you want HtmlTree.C to 
> be a slice which has elements which can each either be a string or an 
> *HtmlTree - i.e. you wan these to be mixed in a single slice. Correct?
> Because that is not a use case for generics, it's a use case for sum types 
> (which Go does not have).
>
> On Mon, Dec 20, 2021 at 4:11 PM Michael Ellis  
> wrote:
>
>> > They can't, sorry.
>> Ok. Thanks, Axel. 
>> Saves me wasting more time.  In the past 3 years of using Go, this is the 
>> only use case where I've  really wanted generics (other cases I've 
>> encountered so far are easily handled with code generation). 
>>
>> -- 
>>
> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ac75dc32-733d-4a73-9735-619c33cb4cd4n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/ac75dc32-733d-4a73-9735-619c33cb4cd4n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/2de22684-0263-465c-8ac0-ff288c535fb7n%40googlegroups.com.

Re: [go-nuts] Generic member of recursive struct

> They can't, sorry.
Ok. Thanks, Axel. 
Saves me wasting more time.  In the past 3 years of using Go, this is the 
only use case where I've  really wanted generics (other cases I've 
encountered so far are easily handled with code generation). 

-- 
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/ac75dc32-733d-4a73-9735-619c33cb4cd4n%40googlegroups.com.

[go-nuts] Generic member of recursive struct

I've got a package, github.com/Michael-F-Ellis/goht, that supports creating 
HTML docs in Go.  It works well, for my purposes at least, but I've always 
been bothered by having to use []interface{} to define the struct member, 
C, that supports recursion.

type HtmlTree struct {
T string// html tagname, e.g. 'head'
A string// zero or more html attributes, e.g 'id=1 
class="foo"'
C []interface{} // a slice of content whose elements may be 
strings or *HtmlTree
empty bool  // set to true for empty tags like 
}

I've created a minimal extract of the package on the playground at 
https://go.dev/play/p/-_7JKRZYLC_J?v=gotip.  Assuming the new generics can 
support constraining HtmlTree.C to be a slice of string | *HtmlTree, what 
is the right syntax for doing so?

Thanks!


-- 
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/a8817b41-85dd-4fd1-a946-00764713c008n%40googlegroups.com.

[go-nuts] Re: Do you have a minimal runnable go code that contain all key words in go?

2021-12-06 Thread Michael Ellis

Nice! Noticed it didn't have "new" so I changed the counter initializer in 
main() from

var c = counter

to 

p := new(counter)
var c = *p

https://go.dev/play/p/2vw4w44qSWm


On Sunday, December 5, 2021 at 4:10:54 PM UTC-5 ben...@gmail.com wrote:

> Not strictly "minimal" -- it uses some keywords twice, and I'm sure it's 
> longer than it needs to be, but here you go: 
> https://go.dev/play/p/XPoqfI8RmyH
>
> On Monday, December 6, 2021 at 4:54:04 AM UTC+13 cuiw...@gmail.com wrote:
>
>> show me you code
>
>

-- 
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/851b403a-dc73-487f-b10e-e1608cb8cda2n%40googlegroups.com.

[go-nuts] Go 1.17.4 and Go 1.16.11 are released

2021-12-02 Thread Michael Knyszek

Hello gophers,

We have just released Go versions 1.17.4 and 1.16.11, minor point releases.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.17.minor

You can download binary and source distributions from the Go web site:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.17.4" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Michael, Heschi, Dmitri, and Carlos for the Go team

-- 
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/CAN%3D%2BcNrpFGMQwHQW-yVt3htHfahHzCe8NNDr9aR282UrJ8c9YQ%40mail.gmail.com.

Re: [go-nuts] Which error handling pattern do you prefer?

2021-11-12 Thread Michael Ellis

FWIW (which may not be much) I've settled on explicitly naming my return 
values in the function declaration.  If the function returns include an 
error, I name always name it err. The general pattern is

func foo() (v someType, err error) {
  err = doSomething()
  if err != nil {
err = fmt.Errorf("some context: %v", err)
return
}
  err = doNextThing()
  if err != nil {
 err = fmt.Errorf("some context: %v", err)
 return
  }
// etc
return
}

Naming the error solves the initial := problem.  As for shadowing, I make 
it a point never to do a := assignment involving err. For example, if I 
need to call os.Open, I do

var f *os.File
f, err = os.Open(...)

I tend to use other names for errors only when it's something I can fix 
within the local scope.

At first I tried hard to avoid the verbosity.  Now I use a few helpful 
snippets to reduce keystrokes and an editor plugin the partially fades any 
block that starts with "if err != nil".  The latter works amazingly well 
(for me at least) to reduce visual clutter.  I like it much better than one 
I tried that auto-folds error blocks.  It made me waste time unfolding them 
to see what was inside :-)

YMMV, of course.

On Friday, November 12, 2021 at 11:15:21 AM UTC-5 david@gmail.com wrote:

> On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo <
> ntr...@gmail.com> wrote:
>
>> I tend to use errX (X is adapted according to context) for function 
>> scoped errors, and err for block scoped errors
>>
>> func MyFunc() error {
>>>   v, errDS := doSomething()
>>>   ...
>>>   errDA := doAnotherthing()
>>> }
>>>
>>
>> if err := doAnotherthing(); err != nil {
>>> return err
>>> }
>>>
>>
>> That way you don't shadow errors.
>>
>
>
> I can't +1 this enough.
>
> I've caught *so* many bugs from shadowed errors (and re-used error 
> variables). I consider it a rather bad anti-pattern to have a single err 
> variable 
> that's reused throughout a scope.
> If you have unique error variable names and you forget to do something 
> with an error that you've assigned a name you automatically get unused 
> variable compile-errors. (just this is enough to be worthwhile)
>
>
> With that said, constraining the scope using the initializer statement on 
> an if (or switch) statement suffices when you don't need any other return 
> values, at which point I may use the err variable-name (although I often 
> make those unique for clarity anyway).
>
>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%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/6b493efc-79ad-43f7-8730-91abd9b6c9cfn%40googlegroups.com.

Re: [go-nuts] initialization loop ?

2021-10-23 Thread Michael Ellis

> The rules for when an initialization loop occurs are part of the language 
spec: https://golang.org/ref/spec#Package_initialization.

Thanks for the link.  It helps with questions I've had recently about 
package initialization.  Can you confirm that the statement

"If a package has imports, the imported packages are initialized before 
initializing the package itself. If multiple packages import a package, the 
imported package will be initialized only once"

means that if 
 - package x imports y and z (in that order), and
 - package y imports a
 - package a imports b
 - package z imports b

then b will be initialized during the initialization of y ( and not 
initialized again during the import of z)?

-- 
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/59051b16-7717-4035-9a9e-765dc894cda9n%40googlegroups.com.

[go-nuts] [security] Go 1.17.2 and Go 1.16.9 are released

2021-10-07 Thread Michael Knyszek

Hello gophers,

We have just released Go versions 1.17.2 and 1.16.9, minor point releases.

These minor releases include a security fix according to the new security
policy (#44918 <https://golang.org/issue/44918>).

When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
passing very large arguments can cause portions of the module to be
overwritten with data from the arguments.

If using wasm_exec.js to execute WASM modules, users will need to replace
their copy (as described in
https://golang.org/wiki/WebAssembly#getting-started) after rebuilding any
modules.

This is issue #48797 <https://github.com/golang/go/issues/48797> and
CVE-2021-38297. Thanks to Ben Lubar for reporting this issue.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.17.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.17.2" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Michael and Heschi for the Go team

--
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/CAN%3D%2BcNobSW%3DrQF_5LhX%2BnrU4XooL6QbUpvA77qf5R8ybWmGOiQ%40mail.gmail.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

2021-10-07 Thread Michael Ellis

Kamil,
Have you read https://go.dev/blog/errors-are-values by Rob Pike?  Wrapping 
my head around the concept that an error is simply a value returned from a 
function was tremendously helpful when I had questions along the same lines 
as yours.

-- 
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/724b763c-cd5d-4c9c-83f2-8c08cb739887n%40googlegroups.com.

Re: [go-nuts] Question on handling Data Race

2021-09-11 Thread Michael Dwyer

Kurtis,

I realized this question would arise.
Presently working with an existing code base.
The code presented in the example is a close approximation to what actually 
exists, the only thing changed were the names.
Additionally, I checked the package and the call order is SomeFunc() -> 
Refresh().
So there will be goroutines that will be calling SomFunc(), which will then 
call Refresh().
Looking at the code I can confirm that Refresh() is not called directly 
from this package.

The problem I face is working with the existing code base, identify 
problems, viz., Data Race, look at the code figure out what the best 
solution to fix the proximate problem.

I do agree with your assessment as to why code would be written in the 
manner, in which it now exists.
I do not, at this time, have an answer to this question.

Working with the authors is difficult at best.
Basically, working alone, with assistance, when really needed, from this 
group.

Presently, taking the existing code, and provide the best solution for 
problems without changing present structure.
Which is why I reached out, because the way the code is presently 
structured, trying to figure out if my proposed solution is workable.

I realize this is not ideal code, could be, should be written cleaner.

My question then is this, using the template of the hypothetical code 
presented, knowing that there are going to be several goroutines calling 
this code,
will my proposed solution address the Data Race problem sufficiently?
Have I missed any potential edge cases, that I have not thought through?

I look forward to your reply.

Thank you for your time and patience ...

THANX(MKD).

On Saturday, September 11, 2021 at 8:42:36 PM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 11, 2021 at 5:01 PM Michael Dwyer  
> wrote:
>
>> Presently working on a Data Race and have some questions on how to 
>> proceed.
>> The code example is a hypothetical mock up of the actual code under 
>> review, but is a fair representation.
>>
>> The struct used by both functions is named Foo.
>> In the hypothetical, SomeFunc() reads variable from foo.bar, checking for 
>> nil,
>> if nil SomeFunc() calls a Foo method Refresh().
>> Foo method Refresh() calls function DoSomeCalc() assigned to foo.bar and 
>> returned back to method SomeFunc()
>>
>> The race detector flags the read of foo.bar in method SomeFunc() in the 
>> if statement,
>> and flags the write of foo.bar in method Refresh().
>>
>> The problem I see is that in method SomeFunc() the if statement does a 
>> read,
>> but it too also does an assignment to foo.bar.
>>
>> My initial thought is to add a sync.Lock() at the beginning of method 
>> SomeFunc(),
>> followed by a defer sync.UnLock(),
>> that will be held until method SomeFunc() exists.
>> I state this because method SomeFunc() also does an assignment to 
>> variable foo.bar.
>> So, a sync.RLock() would be insufficient to protect variable foo.bar
>>
>> My only concern is the call to method Refresh(), which also writes to 
>> foo.bar.
>>
>> If my understanding is correct, this should work, because the lock is 
>> initiated in method SomeFunc(), held to the exit of the method.
>> With the call to method Refresh() occurring within method SomeFunc() the 
>> lock should protect variable foo.bar from other goroutines trying to update 
>> this variable.
>>
>> Asking this question to confirm my thought process is correct.
>> If there is an edge case I missed, please advise.
>>
>> func (foo *Foo) SomeFunc() fields.SomeVariable {
>> if foo.bar == nil { <=== Race detector flags this 
>> read
>> foo.bar = foo.ReFresh()
>> }
>> return foo.bar
>> }
>>
>> func (foo *Foo) ReFresh() fields.SomeVariable {
>> foo.bar = DoSomeCalc(foo)   <=== Race detector flags this 
>> write
>> return foo.bar
>> }
>>
>
> I know this is psuedo-code meant to illustrate the relevant aspect of your 
> real code but I don't understand why you're assigning to foo.bar in the 
> ReFresh() method as well as where you invoke this method in SomeFunc(). If 
> that isn't a mistake introduced while writing the simplified example it 
> suggests there are other problems beyond the data race. It also seems like 
> you've omitted some important details about the real program since the race 
> implies that ReFresh() is called from a goroutine other than the one 
> executing SomeFunc().
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/26024074-973b-4ef8-935c-3568147c46bcn%40googlegroups.com.

[go-nuts] Question on handling Data Race

2021-09-11 Thread Michael Dwyer

Presently working on a Data Race and have some questions on how to proceed.
The code example is a hypothetical mock up of the actual code under review, 
but is a fair representation.

The struct used by both functions is named Foo.
In the hypothetical, SomeFunc() reads variable from foo.bar, checking for 
nil,
if nil SomeFunc() calls a Foo method Refresh().
Foo method Refresh() calls function DoSomeCalc() assigned to foo.bar and 
returned back to method SomeFunc()

The race detector flags the read of foo.bar in method SomeFunc() in the if 
statement,
and flags the write of foo.bar in method Refresh().

The problem I see is that in method SomeFunc() the if statement does a read,
but it too also does an assignment to foo.bar.

My initial thought is to add a sync.Lock() at the beginning of method 
SomeFunc(),
followed by a defer sync.UnLock(),
that will be held until method SomeFunc() exists.
I state this because method SomeFunc() also does an assignment to variable 
foo.bar.
So, a sync.RLock() would be insufficient to protect variable foo.bar

My only concern is the call to method Refresh(), which also writes to 
foo.bar.

If my understanding is correct, this should work, because the lock is 
initiated in method SomeFunc(), held to the exit of the method.
With the call to method Refresh() occurring within method SomeFunc() the 
lock should protect variable foo.bar from other goroutines trying to update 
this variable.

Asking this question to confirm my thought process is correct.
If there is an edge case I missed, please advise.

func (foo *Foo) SomeFunc() fields.SomeVariable {
if foo.bar == nil { <=== Race detector flags this 
read
foo.bar = foo.ReFresh()
}
return foo.bar
}

func (foo *Foo) ReFresh() fields.SomeVariable {
foo.bar = DoSomeCalc(foo)   <=== Race detector flags this 
write
return foo.bar
}


THANX(MKD).

-- 
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/7226a9db-1215-411d-b769-56a9f97d34fdn%40googlegroups.com.

Re: [go-nuts] Two consecutive reads from a buffered channel results in deadlock

2021-09-04 Thread Michael Dwyer

Kurtis, thank you for your explanation and for the links, providing more 
detailed information on the subject matter.
This was what I was looking for, a reasoned explanation and documentation 
that would explain why this condition occurred.

Always good when there are those willing to provide helpful hints and 
documentation, so others can learn.

Greatly appreciate your time an assistance.


THANX(MKD).

On Saturday, September 4, 2021 at 9:31:32 PM UTC-4 Kurtis Rader wrote:

> On Sat, Sep 4, 2021 at 5:55 PM Michael Dwyer  wrote:
>
>> I encountered a deadlock when reading from a buffered channel.
>> The deadlock occurs when an attempt is made to read from the channel 
>> twice, without an intermediate write to the channel.
>>
>
> That is not a deadlock. Reading from a buffered channel blocks when the 
> channel is empty. From https://golang.org/ref/spec#Channel_types:
>  
>
> Otherwise, the channel is buffered and communication succeeds without 
> blocking if the buffer is not full (sends) or not empty (receives). A nil 
> channel 
> is never ready for communication.
> You can use the "select" operator (
> https://golang.org/ref/spec#Select_statements) to detect if the channel 
> is empty.
>  
>
>> The problematic code is as follows:
>>
>> func main() {
>> myInt  := 432
>>
>> readerChan := make(chan int, 3)
>>
>> for forI := 0; forI <= 1; forI++ {
>> readerChan <- myInt
>> fmt.Printf("%d:", <- readerChan)
>> fmt.Printf("%d:", <- readerChan)
>> }
>>
>> close(readerChan)
>> }
>>
>> The first read from variable readerChan succeeds.
>> The second read from variable readerChan results in a deadlock.
>>
>> I have two links to playground.
>> The first link is the problematic code.
>> The second link is for similar code that has an intervening write to the 
>> channel.
>>
>> I understand that a buffered channel allows a queue of results to be 
>> stored from other Go routines writing to the channel.
>> But, the code is attempting multiple read operations.
>>
>> Looking for a technical explanation to help me better understand this 
>> particular case.
>> Thanks in advance ...
>>
>>
>> The problematic playground link : https://play.golang.org/p/veo7phAZzMv
>> The working playground link : https://play.golang.org/p/qvYZNN9keqN
>>
>>
>> THANX(MKD).
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/44057a7a-b0aa-4ea1-9fb3-39836cd5713dn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/44057a7a-b0aa-4ea1-9fb3-39836cd5713dn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/7b41546f-f4cd-4c73-90bc-ee86775431fan%40googlegroups.com.

[go-nuts] Two consecutive reads from a buffered channel results in deadlock

2021-09-04 Thread Michael Dwyer

I encountered a deadlock when reading from a buffered channel.
The deadlock occurs when an attempt is made to read from the channel twice, 
without an intermediate write to the channel.

The problematic code is as follows:

func main() {
myInt  := 432

readerChan := make(chan int, 3)

for forI := 0; forI <= 1; forI++ {
readerChan <- myInt
fmt.Printf("%d:", <- readerChan)
fmt.Printf("%d:", <- readerChan)
}

close(readerChan)
}

The first read from variable readerChan succeeds.
The second read from variable readerChan results in a deadlock.

I have two links to playground.
The first link is the problematic code.
The second link is for similar code that has an intervening write to the 
channel.

I understand that a buffered channel allows a queue of results to be stored 
from other Go routines writing to the channel.
But, the code is attempting multiple read operations.

Looking for a technical explanation to help me better understand this 
particular case.
Thanks in advance ...


The problematic playground link : https://play.golang.org/p/veo7phAZzMv
The working playground link : https://play.golang.org/p/qvYZNN9keqN


THANX(MKD).

-- 
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/44057a7a-b0aa-4ea1-9fb3-39836cd5713dn%40googlegroups.com.

[go-nuts] Re: Printing a slice of structs recursively

2021-09-02 Thread Michael Ellis

Here's one way. https://goplay.space/#5KzrUc0171N

On Thursday, September 2, 2021 at 1:03:48 AM UTC-4 seank...@gmail.com wrote:

> Try doing it recursively, passing in both the current parent id and 
> indentation level
>
> On Thursday, September 2, 2021 at 3:55:01 AM UTC+2 n.erde...@gmail.com 
> wrote:
>
>> i need some help with printing a slice of structs which there is a child 
>> - parent relation in the struct.
>> *type* Emp *struct* {
>> id   int
>> name string
>> parentID int
>> }
>> probably the best way to do it recursively but i couldnt manage to do
>> https://play.golang.org/p/jHcbu3uBgOD
>
>

-- 
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/ae9b334a-67ab-4e5a-a1a6-a4e2a996a3ebn%40googlegroups.com.

Re: [go-nuts] Makefiles for Go Programs

2021-08-23 Thread Michael Ellis

Three cheers for mage .  It's more verbose than make 
but it's pure Go. I use it to build and test projects that include 
generated html/css/js supported by a Web Assembly clients communicating 
with a server.

On Monday, August 23, 2021 at 7:33:10 PM UTC-4 Connor Kuehl wrote:

>
>
> > On Aug 22, 2021, at 10:11 PM, jlfo...@berkeley.edu  
> wrote:
> > 
> > 
> > I've noticed that few, if any, Go programs use Makefiles. Is that 
> because the overhead of using make is greater than the overhead of just 
> always compiling and linking everything?
> > One piece of evidence for this is that the Go compiler leaves no 
> artifacts, like object files, so as is make wouldn't fit into the current 
> build method.
> > 
>
> I started using a Makefile for my Go project so that I could inject a 
> version string at build time without having to remember what to pass to go 
> binaries.
>
> I made a Discord bot to use in a server with my friends, and since I have 
> some automation in place to automatically deploy the tip of my main branch, 
> I thought it’d be convenient to be able to ask the bot what build it’s 
> running so we can see which commits are “live."
>
> So while it’s not a “traditional” use of make, it certainly is convenient.
>
> Connor
>
> P.S., here’s the Makefile. The important bits are the lines that mention 
> “LD_FLAGS"
>
> VERSION := v2.2.0+dev
> BUILD := $(shell git describe --tags 2>/dev/null || echo "$(VERSION)")
>
> LD_FLAGS := "-X 'main.Version=$(BUILD)'"
>
> SOURCES := $(shell find . -type f -name '*.go')
> SOURCES += go.mod go.sum
>
> .PHONY: build clean test
>
> all: popple
>
> popple: build
>
> build: $(SOURCES)
> @go build -v -ldflags=$(LD_FLAGS) ./...
>
> test: popple
> @go test -v -ldflags=$(LD_FLAGS) ./...
>
> clean:
> @rm -rf popple

-- 
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/6b2116b0-b6e1-4d60-bd88-ee71f011035en%40googlegroups.com.

[go-nuts] Go 1.17 is released

2021-08-16 Thread Michael Knyszek

Hello gophers,

We just released Go 1.17

To find out what has changed in Go 1.17, read the release notes:
https://golang.org/doc/go1.17

You can download binary and source distributions from our download page:
https://golang.org/dl/

If you have Go installed already, an easy way to try go1.17
is by using the go command:
$ go get golang.org/dl/go1.17
$ go1.17 download

To compile from source using a Git clone, update to the release with
"git checkout go1.17" and build as usual.

Thanks to everyone who contributed to the release!

Cheers,
Michael and Dmitri for the Go Team

-- 
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/CAN%3D%2BcNqFSAm8Er%3D09Yn825eKB4rgg24ZMvGSp5467ffj1z5Pdw%40mail.gmail.com.

[go-nuts] GOOS=js/GOARCH=wasm

2021-07-27 Thread W. Michael Petullo

I have been building applications using the GOOS=js/GOARCH=wasm for around 
two years. I really like being able to write both client and server code in 
Go. I have four questions that I have not yet found a clear answer for:

(1) The syscall/js package is marked EXPERIMENTAL. Is there any consensus 
as to when this package might become stable?

(2) The rules surrounding Go routines are different from the expectations 
of Go itself. There is a comment in src/syscall/js/func.go concerning this:

// As a consequence, if one wrapped function blocks, JavaScript's event loop 
// is blocked until that function returns. Hence, calling any async 
JavaScript 
// API, which requires the event loop, like fetch (http.Client), will cause 
an 
// immediate deadlock. Therefore a blocking function should explicitly 
start a 
// new goroutine. 

Is this the expected behavior in the long term? I often get caught up in 
the rules here.

(3) I have not yet found a clean way to read a file from the browser (i.e., 
in response to a file HTML input). I presently use a JavaScript function 
that uses a FileReader to read the file into a global variable data before 
setting another global Boolean done to true. On the Go side, I poll the 
global Boolean done, waiting for it to become true before pulling the file 
out of the global data. Does anyone have an example of a better way to do 
this?

(4) I have a Wasm Go routine that updates a progress bar as it executes. 
However, the progress bar does not update until the Go routine completes. I 
suspect this is related to (2). Is there a pattern for getting this to work?

--
Mike

:wq

-- 
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/e568cb0c-c9a9-4155-ae30-ea29fb7f2ea9n%40googlegroups.com.

Re: [go-nuts] Go and GPUs

2021-06-25 Thread Michael Poole

On Fri, Jun 25, 2021 at 11:52 AM Nikolay Dubina wrote:
>
> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last 
> weekend. To my great surprise, CUDA and pretty much all high performance 
> software/hardware from NVIDIA is proprietary close-source C/C++ code. 
> Meaning, you can't write native Go driver even if you wanted to. Forget Go, 
> people are trying to reverse engineer it in C/C++ with limited success. From 
> what I heard OpenCV is not a priority for NVIDIA either. Then I looked up 
> what Apple is doing with their Neural Engine in latest chips. It too is 
> closed-source Objective-C, Swift. I suspect situation with other powerful 
> hardware is the same. Moore's law seem to be about GPU lately, and everyone 
> is locking it in. Kind of not in the spirit open-source and Linux. That's 
> quite bad state of affairs for Go and computing in general. Yikes!
>
> Just want to see what others are thinking.

That would be a very nice thing to have.  I see four basic areas where
this becomes tricky or requires a lot of work.

1) Getting memory management right for sharing with the accelerator
device.  Shared memory buffers need to stay locked for longer than
just the call to a library or to the OS kernel, but in the worse case
could use something like Manish Rai Jain of Dgraph described at
https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
.  A lot of Nvidia's recent CUDA programmer-productivity improvements
have focused around transparent data movement, and Go's garbage
collector probably breaks the assumptions for those.

2) "Friendly" source development (like CUDA C) integrates the host and
target code into a single code base, with some kind of markup or
compiler hint about which functions should be compiled for the
accelerator, and which function calls need to be treated specially.
Those "special" function calls must be translated to dispatch the call
(usually with additional arguments like the grid/NDRange parameters)
to the accelerator rather than as a normal function call.  This is a
compiler front-end problem, which is almost certainly a lot easier
with Go than with C or C++, but still requires attention and perhaps
considerable effort because it requires multiple back-ends to run for
some functions.  In the worst case, do like OpenCL and require the
programmer to provide or build strings containing program text, along
with verbose code to set up calls to the accelerator.

3) Generating code for the accelerator.  SPIR-V is an obvious
candidate for portable uses; it integrates reasonably with current
OpenCL as well as Vulkan.  Nvidia makes a reasonable compromise for
this with their PTX assembly pseudo-language: They have good
documentation about which PTX instructions are only supported on some
GPU generations, they document when the translation to actual machine
code varies in major ways, and they even have a decent API for
compiling application-provided PTX code.  This is a compiler back-end
problem, conditional on not accepting the "worst case" in #2 above.

4) Integrating target libraries with the rest of an application.  A
large part of the value proposition for CUDA is that it has a lot of
highly optimized libraries available out of the box: cuFFT,
cuBLAS/NVBLAS, and more.  These are a hybrid between GPU elements and
host elements, and a lot of the host elements end up being black boxes
with respect to other languages.  The most general fix is to call out
to C, which is not satisfying for portability.

If I were going to spend the time on this, I would probably target
SPIR-V with Vulkan or OpenCL for portability rather than Nvidia's PTX
or Apple's Metal.  AMD, Nvidia and Google (Android) all have good
support for SPIR-V through their Vulkan stacks, and there are
third-party Vulkan layers that run on MacOS.

- Michael Poole

-- 
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/CAOU-OAK3dUn0hDAvEt3ayhQO4Ryg2-bMpaKZTCxW086%2BYFFnpQ%40mail.gmail.com.

Re: [go-nuts] How to cast a multi-value?

2021-05-18 Thread 'Marc Michael' via golang-nuts

'Keith Randall' via golang-nuts  schrieb am
Di., 18. Mai 2021, 18:25:

> You can use a function call to do the cast:
>
> func byteErr2stringErr(b []byte, e error) (string, error) {
> return string(b), e
> }
> content, err := byteErr2stringErr(os.ReadFile(path))
>
> It's still using additional variables, but they are hidden inside the
> helper function.
> On Sunday, May 16, 2021 at 8:07:24 PM UTC-7 Kurtis Rader wrote:
>
>> On Sun, May 16, 2021 at 7:49 PM 'Marc Michael' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> as Go provides multi values I would expect that's possible to cast such
>>> a multi value. Do I see it correctly, that Go does not provide it?
>>>
>>> Example:
>>>
>>> os.ReadFile returns []byte, error.
>>> I want to cast the []byte to a string.
>>>
>>> content, err := os.ReadFile(path)
>>>
>>> Is it possible to cast the []byte directly to a string without using a
>>> second variable?
>>>
>>
>> No, it is not possible to transform the type of one return value in a 
>> multi-valued
>> expression such as a function call. Such syntactic sugar would have limited
>> usefulness and, in my opinion, is likely to decrease readability and thus
>> be a source of bugs. If you find yourself needing to perform such
>> conversions so often that such a feature is useful that suggests the APIs
>> you're using need to be changed.
>>
>
Hello,

thanks for the clarification. I have thought that I had something overseen.

I have thought about introducing a second variable of type string, but this
would lead to doubling of the memory usage, especaly as I don't now really
how much data there is. With the additional function I think this would not
a real problem, as the []byte would go away if the additional function
finishes.

Thanks all for your help. :-)

Kindly regards

>

-- 
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/CAEOc3dUsahY7W3o_6j%3DM6ycRMnpv6XXnHOr0tyXxperzZ%3DB9kg%40mail.gmail.com.

[go-nuts] How to cast a multi-value?

2021-05-16 Thread 'Marc Michael' via golang-nuts

Hello,

as Go provides multi values I would expect that's possible to cast such a
multi value. Do I see it correctly, that Go does not provide it?

Example:

os.ReadFile returns []byte, error.
I want to cast the []byte to a string.

content, err := os.ReadFile(path)

Is it possible to cast the []byte directly to a string without using a
second variable?

Kindly regards

-- 
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/CAEOc3dWn%3Dn%3DFNaQVhnu56yu9yaoVeJRin_m%2B7DNh8hvqV7Ck%2Bw%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

2021-05-14 Thread 'Michael Pratt' via golang-nuts

Go has a non-moving GC [1], so that is not an issue. That said,
unsafe.Pointer states "the referenced allocated object, if any, is retained
and not moved until the call completes". It doesn't say that this
recursively applies to objects referenced by the converted object, though I
perhaps it should.

[1] Except for stacks, but taking the address of a byte slice and putting
it in Iovec.Base will force it to escape anyways.

On Fri, May 14, 2021 at 9:44 AM Shaun Crampton  wrote:

> > You can use a *byte for the buffer. For instance, unix.Iovec does this
>
> Are you sure that's not a bug?  What's to stop the *Byte from being
> moved by the GC?
>
> On Fri, May 14, 2021 at 2:27 PM Michael Pratt  wrote:
> >
> > You can use a *byte for the buffer. For instance, unix.Iovec does this:
> https://pkg.go.dev/golang.org/x/sys/unix#Iovec
> >
> > Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall
> without any special handling of the *byte field.
> >
> > On Fri, May 14, 2021, 09:01 sh...@tigera.io  wrote:
> >>
> >> Now, is it technically legal to convert a uintptr to some location that
> was manually allocated and then cast it to an unsafe.Pointer?  When I look
> at the docs for unsafe.Pointer, I can't match that to any of the cases but
> it seems very likely to be safe by analogy with the GCO rules for handling
> "C" pointers and "Go" pointers.
> >>
> >> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
> >>>
> >>> Thanks for the pointer to that package; looking at our go.mod, looks
> like we've already got it as a transitive dependency so it looks ideal for
> my use case.
> >>>
> >>> On Friday, May 14, 2021 at 12:10:45 PM UTC+1 Jan Mercl wrote:
> >>>>
> >>>> On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io 
> wrote:
> >>>>
> >>>> > One way I could see to solve this would be to do some manual memory
> management with MMap or BRK to allocate the buffer but I wondered if there
> was an easier way?
> >>>>
> >>>> IMO using manual memory management _is_ the easy way in this case. I'm
> >>>> using https://pkg.go.dev/modernc.org/memory for this.
> >>
> >> --
> >> 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/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.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/CALoThU8Qe8p1XyycwcoHnAcXG46DXYKWvDhLSUakAKN7fYmwHA%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

2021-05-14 Thread 'Michael Pratt' via golang-nuts

You can use a *byte for the buffer. For instance, unix.Iovec does this:
https://pkg.go.dev/golang.org/x/sys/unix#Iovec

Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall without
any special handling of the *byte field.

On Fri, May 14, 2021, 09:01 sh...@tigera.io  wrote:

> Now, is it technically legal to convert a uintptr to some location that
> was manually allocated and then cast it to an unsafe.Pointer?  When I look
> at the docs for unsafe.Pointer, I can't match that to any of the cases but
> it seems very likely to be safe by analogy with the GCO rules for handling
> "C" pointers and "Go" pointers.
>
> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
>
>> Thanks for the pointer to that package; looking at our go.mod, looks like
>> we've already got it as a transitive dependency so it looks ideal for my
>> use case.
>>
>> On Friday, May 14, 2021 at 12:10:45 PM UTC+1 Jan Mercl wrote:
>>
>>> On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io 
>>> wrote:
>>>
>>> > One way I could see to solve this would be to do some manual memory
>>> management with MMap or BRK to allocate the buffer but I wondered if there
>>> was an easier way?
>>>
>>> IMO using manual memory management _is_ the easy way in this case. I'm
>>> using https://pkg.go.dev/modernc.org/memory for this.
>>>
>> --
> 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/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.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/CALoThU-Ph1vE%3DgAPLGtD76aBHU6bgxxuquf_3E7c__9dm0UH1A%40mail.gmail.com.

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

2021-04-29 Thread 'Michael Knyszek' via golang-nuts

Hi Marco, https://go-review.googlesource.com/c/go/+/312431 just landed and
should resolve the issue for Go 1.17.

On Tue, Apr 20, 2021 at 3:28 PM Michael Knyszek  wrote:

> Oh, actually, you can compute Mallocs and Frees from allocs-by-size and
> frees-by-size (summing the total # of samples). You can only estimate
> TotalAlloc though, which is genuinely missing.
>
> On Tue, Apr 20, 2021 at 3:14 PM Michael Knyszek 
> wrote:
>
>> Oh gosh, I think TotalAlloc, Mallocs, and Frees are actually an oversight
>> on my part. Sorry about that. They're very easy to add and I can probably
>> even add them for this release.
>>
>> Please do use the new runtime/metrics package!
>>
>> Most of the other metrics should be there in some form (e.g. the
>> divisions are a little different; they're meant to be more orthogonal to
>> each other... GC pause latencies are now in a histogram) and new ones are
>> going to be added in the next release and in the future. Also: today, it
>> does not have the same stop-the-world penalty that ReadMemStats has, so I
>> recommend it on that basis.
>>
>> On Tue, Apr 20, 2021 at 3:08 PM Ian Lance Taylor  wrote:
>>
>>> [ + mknyszek ]
>>>
>>> On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > I was considering using the new stable metrics interface with go 1.16 (
>>> https://golang.org/pkg/runtime/metrics/) for our program and I was also
>>> wondering why things like TotalAlloc (
>>> https://golang.org/pkg/runtime/#MemStats) had been dropped in the
>>> available metrics.
>>> >
>>> > Any particular reasoning behind this?
>>> >
>>> > --
>>> > 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.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/CAFza%2Bu_SZRSpeEBHJ904jChgs%3D_Fu_ws8EGG8Zwh2jd174BmLg%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

2021-04-27 Thread 'Michael Pratt' via golang-nuts

Oops, I should say the syscall package could do this. x/sys/unix has the
extra complexity of not being tied to a Go release.

On Tue, Apr 27, 2021, 12:53 Michael Pratt  wrote:

> I'm not sure if calling through the VDSO is the best solution to this
> specific issue, though it does sound like a case that would certainly
> benefit.
>
> Regardless, one fairly clean way we could support this would be to make
> x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
> than performing the syscall. That is always a valid operation (the VDSO
> will make the syscall if it doesn't support the specific options passed),
> and I think would solve this problem without even changing the API. It
> seems we don't do that already for simplicity of implementation and prior
> lack of need.
>
> On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:
>
>> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
>> wrote:
>>
>>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
>>> scritto:
>>>
>>>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
>>>> wrote:
>>>> >
>>>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
>>>> scritto:
>>>> >>
>>>> >> So I really want to know what is the right way to do vdso call
>>>> outside runtime?
>>>> >>
>>>> > What about using a different function instead of time.Now, and using
>>>> RawSyscall?
>>>>
>>>> That wouldn't be a VDSO call. VDSO calls are in general faster than
>>>> system calls. There is more background at
>>>> https://man7.org/linux/man-pages/man7/vdso.7.html.
>>>
>>> Ian
>>>
>>>
>>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo
>>> , maybe RawSyscall will be more efficient?
>>>
>>
>> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it
>> is possible that RawSyscall of clock_gettime with a coarse clock would be
>> faster than time.Now, but I would be surprised.
>>
>> Ian
>>
>>> --
>> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CALoThU9C6uQHtHKFE7v38J-z5Ek5QgnUgHigQYOS6ZBp%3DRkY6Q%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

2021-04-27 Thread 'Michael Pratt' via golang-nuts

I'm not sure if calling through the VDSO is the best solution to this
specific issue, though it does sound like a case that would certainly
benefit.

Regardless, one fairly clean way we could support this would be to make
x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
than performing the syscall. That is always a valid operation (the VDSO
will make the syscall if it doesn't support the specific options passed),
and I think would solve this problem without even changing the API. It
seems we don't do that already for simplicity of implementation and prior
lack of need.

On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:

> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
> wrote:
>
>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
>> scritto:
>>
>>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
>>> wrote:
>>> >
>>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
>>> scritto:
>>> >>
>>> >> So I really want to know what is the right way to do vdso call
>>> outside runtime?
>>> >>
>>> > What about using a different function instead of time.Now, and using
>>> RawSyscall?
>>>
>>> That wouldn't be a VDSO call. VDSO calls are in general faster than
>>> system calls. There is more background at
>>> https://man7.org/linux/man-pages/man7/vdso.7.html.
>>
>> Ian
>>
>>
>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo ,
>> maybe RawSyscall will be more efficient?
>>
>
> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it
> is possible that RawSyscall of clock_gettime with a coarse clock would be
> faster than time.Now, but I would be surprised.
>
> Ian
>
>> --
> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/CALoThU-sH_HvNbZz-NSR-OOa3tZNybw2YNYK43YqWsYkmT-XsA%40mail.gmail.com.

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

2021-04-20 Thread 'Michael Knyszek' via golang-nuts

Oh, actually, you can compute Mallocs and Frees from allocs-by-size and
frees-by-size (summing the total # of samples). You can only estimate
TotalAlloc though, which is genuinely missing.

On Tue, Apr 20, 2021 at 3:14 PM Michael Knyszek  wrote:

> Oh gosh, I think TotalAlloc, Mallocs, and Frees are actually an oversight
> on my part. Sorry about that. They're very easy to add and I can probably
> even add them for this release.
>
> Please do use the new runtime/metrics package!
>
> Most of the other metrics should be there in some form (e.g. the divisions
> are a little different; they're meant to be more orthogonal to each
> other... GC pause latencies are now in a histogram) and new ones are going
> to be added in the next release and in the future. Also: today, it does not
> have the same stop-the-world penalty that ReadMemStats has, so I recommend
> it on that basis.
>
> On Tue, Apr 20, 2021 at 3:08 PM Ian Lance Taylor  wrote:
>
>> [ + mknyszek ]
>>
>> On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
>> >
>> > Hi everyone,
>> >
>> > I was considering using the new stable metrics interface with go 1.16 (
>> https://golang.org/pkg/runtime/metrics/) for our program and I was also
>> wondering why things like TotalAlloc (
>> https://golang.org/pkg/runtime/#MemStats) had been dropped in the
>> available metrics.
>> >
>> > Any particular reasoning behind this?
>> >
>> > --
>> > 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.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/CAFza%2Bu-E8yBaxOkvMrSLpPUcSzLjJedB_LcKhTQTxqhJuTMqgQ%40mail.gmail.com.

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

2021-04-20 Thread 'Michael Knyszek' via golang-nuts

Oh gosh, I think TotalAlloc, Mallocs, and Frees are actually an oversight
on my part. Sorry about that. They're very easy to add and I can probably
even add them for this release.

Please do use the new runtime/metrics package!

Most of the other metrics should be there in some form (e.g. the divisions
are a little different; they're meant to be more orthogonal to each
other... GC pause latencies are now in a histogram) and new ones are going
to be added in the next release and in the future. Also: today, it does not
have the same stop-the-world penalty that ReadMemStats has, so I recommend
it on that basis.

On Tue, Apr 20, 2021 at 3:08 PM Ian Lance Taylor  wrote:

> [ + mknyszek ]
>
> On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
> >
> > Hi everyone,
> >
> > I was considering using the new stable metrics interface with go 1.16 (
> https://golang.org/pkg/runtime/metrics/) for our program and I was also
> wondering why things like TotalAlloc (
> https://golang.org/pkg/runtime/#MemStats) had been dropped in the
> available metrics.
> >
> > Any particular reasoning behind this?
> >
> > --
> > 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.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/CAFza%2Bu954NiVW63%3DwGQD-97jXdats6UAB9p%2BrpiZHrLYP4EbRA%40mail.gmail.com.

Re: [go-nuts] Why does Go ignore HTTP_PROXY and HTTPS_PROXY if the proxy address is localhost

2021-04-14 Thread Michael Baker


On 14/04/2021 20:25, Jeff Peck wrote:


Just a complete shot in the dark. Have you verified that the 
environment variables you set are indeed getting picked up inside of 
your application? Try checking the output of os.GetEnv("HTTP_PROXY"), 
os.GetEnv("HTTPS_PROXY"), and os.GetEnv("NO_PROXY"). Make sure that if 
NO_PROXY is set that it isn't overriding your local proxy.



You could also try setting the lowercase versions of these env vars:

https://github.com/golang/net/blob/master/http/httpproxy/proxy.go

func FromEnvironment() *Config {
    return {
        HTTPProxy:  getEnvAny("HTTP_PROXY", "http_proxy"),
        HTTPSProxy: getEnvAny("HTTPS_PROXY", "https_proxy"),
        NoProxy:    getEnvAny("NO_PROXY", "no_proxy"),
        CGI:    os.Getenv("REQUEST_METHOD") != "",
    }
}

Thanks for the ideas Jeff. I already found out what the issue was though 
- see my other reply.






--
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/3b6c84a4-fed3-0bed-3c17-b595a3239066%40gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

2021-04-09 Thread Michael Ellis

FWIW, I completely agree with the sentiment that confusing documentation 
has created pain and unnecessary difficulty for solo developers.  I try to 
keep in mind that Go was developed for use by large teams working on 
million line programs and that I'm lucky to be able to piggyback on the 
efforts of top-notch talent. 

That being said, here is a recipe that seems to work -- for my purposes at 
least.  It's really just a restatement of what others have said in this and 
related threads:

1. Create a directory that will hold your local projects.  I think it best 
not to use ~/go/src.  My directory is ~/localgo,  I'll use that name in in 
what follows, though there's nothing special about it.
2. Undefine GOPATH, e.g. unset GOPATH
3.  Initialize a module named for the directory, i.e. cd ~/localgo; go mod 
init localgo
4. Move your package and cmd project underneath ~/localgo. 
5. When importing local package named "somepkg" use import localgo/somepkg
6. If a package in your local directory is something you've published, you 
have three choices when importing it:

   - Import it from your published repository,
   - Import from your published repository and use "replace" to force the 
   import to use the localgo copy,
   - Import directly from localgo (as in item 5).

To make this a little more concrete here's a portion of my localgo tree 
with two packages and two command projects.  Notice that mypkg and myprog 
do not have go.mod files yet myprog is able to import mypkg and build 
without error.  Package tbchrom, on the other hand, is already (privately) 
published and versioned on GitHub.  It's still under development. Having it 
cloned under localgo allows me to reference it from command tbflash which 
is not yet published.  I'm using the replace statement in tbflash's go.mod 
file, i.e.,  replace github.com/Michael-F-Ellis/tbchrom v1.0.0 => 
/Users/mellis/localgo/tbchrom

localgo
├── go.mod
├── mypkg
│   └── pkg.go
├── myprog
│   └── main.go
├── tbchrom
│   ├── .git
│   ├── .gitignore
│   ├── .vscode
│   ├── go.mod
│   ├── go.sum
│   ├── parser.go
│   ├── parser_test.go
│   ├── rhythm.go
│   ├── rhythm_test.go
│   ├── smf.go
│   └── smf_test.go
└── tbflash
├── go.mod
├── go.sum
├── main.go
├── main_test.go
└── tbflash.json

I like this solution because it's consistent and flexible. It's consistent 
in that all the go toolchain commands,  vet, build, ... etc., work the same 
regardless of whether a package or command if version controlled or has a 
go.mod file.  It's flexible, in large part, because it's consistent. I can 
start a project with bare Go code and add module support and version 
control as needed.

Hope someone finds it useful.  If you know of any awful pitfalls, please 
let me know.

On Friday, April 9, 2021 at 5:34:37 PM UTC-4 ohir wrote:

> Dnia 2021-04-07, o godz. 14:31:07
> Slawomir Pryczek  napisał(a):
>
> > Anyone has an idea for a reasonable solution which will allow easy 
> > refactoring and code organization in packages, in this new model?
>
> Idea is here: https://github.com/golang/go/issues/44347
>
> Whether is it reasonable or not — objectively — I can not tell as I am an 
> author.
> Though I'd like to see other's opinion whether proposed solution would 
> work for them.
>
> TC.
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/34e47688-3644-4005-a226-262fc2c480bfn%40googlegroups.com.

Re: [go-nuts] Re: [golang-dev] Go 1.16.3 and Go 1.15.11 are released

2021-04-02 Thread 'Michael Pratt' via golang-nuts

mgcsweepbuf.go was deleted in 1.16, so it seems you still have files from
1.15 sitting around in /usr/local/go/.

On Fri, Apr 2, 2021 at 4:13 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Apr 1, 2021 at 11:52 PM Dmitri Shuralyov 
> wrote:
>
> > We have just released Go versions 1.16.3 and 1.15.11, minor point
> releases.
>
> Cleared everything ($ go clean -cache -modcache -testcache ; rm -rf ~/pkg
> ~/.cache/go-build) and upgraded from 1.15.10 to 1.16.3. Now I am seeing
> while hacking some current project:
>
> jnml@3900x:~/src/modernc.org/qbe$ go test
> # runtime
> /usr/local/go/src/runtime/mgcsweepbuf.go:87:80: memstats.gc_sys undefined
> (type mstats has no field or method gc_sys)
> /usr/local/go/src/runtime/mgcsweepbuf.go:106:102: memstats.gc_sys
> undefined (type mstats has no field or method gc_sys)
> FAIL modernc.org/qbe [build failed]
> jnml@3900x:~/src/modernc.org/qbe$ go version
> go version go1.16.3 linux/amd64
> jnml@3900x:~/src/modernc.org/qbe$ go env
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/jnml/.cache/go-build"
> GOENV="/home/jnml/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GOMODCACHE="/home/jnml/pkg/mod"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/home/jnml"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct;
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GOVCS=""
> GOVERSION="go1.16.3"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/home/jnml/src/modernc.org/qbe/go.mod"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build1728759906=/tmp/go-build
> -gno-record-gcc-switches"
> jnml@3900x:~/src/modernc.org/qbe$
>
> Any ideas what's wrong? Thanks in advance.
>
> --
> 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/CAA40n-XUw%3D_SBa-dTVNFVuKKWdDreBjScwMxpHk4DGR7MyK-YQ%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/CALoThU86odpTdo8oFatbpyc%3Dc-o%3Di6%3DHToxrDuTF03zEeafm_A%40mail.gmail.com.

Re: [go-nuts] string matching

2021-04-01 Thread Michael Poole

You were on a good start with strings.Index().  The key is to move
past the pattern you searched for, assuming it was found.

Something like this should work, if `bigString` is what you are
searching over, and depending on whether "Core Count:" might be on the
first line or not:

pattern := "\nCore Count: "
if start := strings.Index(bigString, pattern); start >= 0 {
var nCores int
_, err := fmt.Sscanf(bigString[start+len(pattern):], "%d", )
if err == nil {
fmt.Println("Number of cores:", nCores)
}
}

As you can see, the regular expression-based solution suggested by
others leads to less code.  This input string is so short that CPU
usage will be negligible for most purposes, outweighed by graceful
error handling and code maintenance concerns.

Best regards,
Michael


On Thu, Apr 1, 2021 at 2:28 PM Sharan Guhan  wrote:
>
> Hi Experts,
>
> New to Golang and finding it non trivial to achieve the below efficiently :-) 
> Any pointers will help..
>
> I have a huge string as below  .. Now from this I want to extract the number 
> "18" after "Core count".. I was thinking of walking through each string with 
> Spilt("\n"), but that will make it slower. I also tried strings.Index with 
> "Core count", but unable to see how to pull the 18 from this..
>
> Sharan
>
>
> "Version: Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
> Voltage: 1.6 V
> External Clock: 100 MHz
> Max Speed: 4000 MHz
> Current Speed: 2300 MHz
> Status: Populated, Enabled
> Upgrade: Socket LGA3647-1
> L1 Cache Handle: 0x004D
> L2 Cache Handle: 0x004E
> L3 Cache Handle: 0x004F
> Serial Number: Not Specified
> Asset Tag: UNKNOWN
> Part Number: Not Specified
> Core Count: 18"
>
> --
> 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/CAGOT8aq8btVfAYWCpGz69cvPG_OQomNGyUjBg7oa85%2BAKqp7yQ%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/CAOU-OAL3_OQyVz_Zu9wntCLoKTiMeD-QazaOnZ_287_JdyQvrg%40mail.gmail.com.

Re: [go-nuts] Finding error type for `errors.As` and `errors.Is`

2021-04-01 Thread 'Michael Schaller' via golang-nuts

Roger, I think you slightly misunderstood me. ;-)

It is true that `As` and `Is` methods can be used to allow `errors.As` and 
`errors.Is` to handle error types that aren't actually in the error chain.

However my question was if an `errors.Chain` function which returns details 
about the error types and values in the error chain would be a worthwhile 
addition to Go's `errors` package.

On Wednesday, March 31, 2021 at 7:33:32 PM UTC+2 rog wrote:

> On Wed, 31 Mar 2021 at 18:05, 'Michael Schaller' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Hi everyone,
>>
>> I often encounter deep error chains where errors are wrapped across 
>> several Go packages and that makes it often hard to find a usable error 
>> type to use with `errors.As` or `errors.Is`.
>>
>> Could it make sense to add an `errors.Chain` function to Go that returns 
>> a slice with tuples of error type (reflect.Type) and the respective error?
>>
>
> Unfortunately that's not possible in general because errors in the change 
> can implement their own `As` and `Is` methods, so an error can appear
> to have some type T in the chain (i.e. errors.As(new(T)) returns true) 
> without *actually *having that type in the chain.
>
> For example: https://play.golang.org/p/-IAKMrD8FlG
>
> It's a shame in my view, but that's what we've got.
>
>   cheers,
> rog.
>
>
>> Quick example:
>> https://play.golang.org/p/hDW0_6P7O2Y
>>
>> Best,
>>
>> Michael
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/acab291d-21bc-4c84-a19a-7f9901cc8035n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/acab291d-21bc-4c84-a19a-7f9901cc8035n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/9aed0787-8a5f-4b1b-ab18-ee654418340an%40googlegroups.com.

[go-nuts] golang/mobile: Could we add GitHub Actions for PRs?

2021-03-22 Thread Michael Chong

GitHub Actions  has been introduced 
for a while.

For PRs of go-mobile , only *google-cla 
*is running on GitHub Actions.
I wonder whether we can add support like automatic testing?


-- 
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/e6194e76-bd34-40d0-995e-dff5110b98afn%40googlegroups.com.

[go-nuts] Re: encoding/html package to generate html markup programmatically

2021-03-15 Thread Michael Ellis

goht <https://github.com/Michael-F-Ellis/goht> might be what you're looking 
for.

On Sunday, March 14, 2021 at 7:36:52 PM UTC-4 atd...@gmail.com wrote:

> Hi,
>
> I am currently thinking about implementing SSR for a Go client-side 
> framework.
> Not only that but I would like to be able to create static html from the 
> same code I use to create dynamic  wasm-based webapps.
>
> I was trying to find a package that would enable me to generate an html 
> document but seems like none exists.
>
> Do you think it is possible to use encoding/xml to create an xhtml 
> document?
>
>
> That would allow me to create something like MarkupPy that would replace 
> js DOM created element by html element.
>
>

-- 
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/33063788-a96e-40f3-820a-78a34b7725f1n%40googlegroups.com.

Re: [go-nuts] Modules and internal packages

Just to close the loop, I've got a solution that's working well enough for 
my personal use.  

It takes advantage of GitHub's Template repo feature and the gh CLI tool to 
simplify the process of creating a new repository with a clone of the 
skeleton and a local copy thereof.  Using Axel's suggestion (thx!), I added 
an Init section to the magefile to walk the project tree changing any 
import references to match the new repo before building the app for the 
first time.

Thanks again for the help and explanations.
On Thursday, March 4, 2021 at 11:46:49 AM UTC-5 Michael Ellis wrote:

> On Thursday, March 4, 2021 at 11:01:06 AM UTC-5 axel.wa...@googlemail.com 
> wrote:
>
>> On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis  
>> wrote:
>>
>>> My bad. I should have tested before writing that.  Thanks for checking.  
>>> Good to know the tools are enforcing the distinction.  Still, the import 
>>> path requirement does get in the way of being able to create a new 
>>> application by cloning and revising an existing one without doing a 
>>> recursive sed (or equivalent thereof).
>>>
>>
>> I agree :) And as I said, we could probably make relative imports work. 
>> But currently, the mapping from import paths to packages in a single go 
>> binary is 1-1. If we would allow you to use relative imports *as well,* 
>> that would be lost. Or we would have to force you to do one *or* the 
>> other per module. Either way, it seems like a non-trivial and potentially 
>> confusing transition. At which point we get back to "your usecase seems 
>> fairly special". Not "using internal packages", but the entire "cloning an 
>> existing project/skeleton and expect to have that just work as the 
>> jumping-off point for a new one". Note that *some* search/replace like 
>> stuff is still going to be needed anyway - at the very least, `go.mod` 
>> needs to contain a user-chosen module path.
>>
>> That's why I really don't think it's worth changing. Overall, your 
>> use-case seems much better addressed by writing a tool that generates your 
>> skeleton, replacing paths as needed, instead of expecting `git clone` to 
>> serve that purpose.
>>
>  
> Ok. Thanks for coherent explanation of why it may be hard to support 
> relative imports.  The skeleton code already has a fair amount of code 
> generation at build time, so it's not unreasonable to add an "Init" target 
> to the magefile that modifies go.mod.  I'll look into ways (build tags?) to 
> avoid using internal if possible.
>
> I disagree that cloning and modifying existing projects is special.  Good 
> lord! I (along with about a million other engineers) have been doing that 
> for decades:-) My clients really don't want and shouldn't have to pay me to 
> start from scratch every time.
>
>

-- 
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/f29b9eaa-a8cc-49aa-9291-db77e81c06b0n%40googlegroups.com.

Re: [go-nuts] Modules and internal packages



On Thursday, March 4, 2021 at 11:01:06 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis  wrote:
>
>> My bad. I should have tested before writing that.  Thanks for checking.  
>> Good to know the tools are enforcing the distinction.  Still, the import 
>> path requirement does get in the way of being able to create a new 
>> application by cloning and revising an existing one without doing a 
>> recursive sed (or equivalent thereof).
>>
>
> I agree :) And as I said, we could probably make relative imports work. 
> But currently, the mapping from import paths to packages in a single go 
> binary is 1-1. If we would allow you to use relative imports *as well,* 
> that would be lost. Or we would have to force you to do one *or* the 
> other per module. Either way, it seems like a non-trivial and potentially 
> confusing transition. At which point we get back to "your usecase seems 
> fairly special". Not "using internal packages", but the entire "cloning an 
> existing project/skeleton and expect to have that just work as the 
> jumping-off point for a new one". Note that *some* search/replace like 
> stuff is still going to be needed anyway - at the very least, `go.mod` 
> needs to contain a user-chosen module path.
>
> That's why I really don't think it's worth changing. Overall, your 
> use-case seems much better addressed by writing a tool that generates your 
> skeleton, replacing paths as needed, instead of expecting `git clone` to 
> serve that purpose.
>
 
Ok. Thanks for coherent explanation of why it may be hard to support 
relative imports.  The skeleton code already has a fair amount of code 
generation at build time, so it's not unreasonable to add an "Init" target 
to the magefile that modifies go.mod.  I'll look into ways (build tags?) to 
avoid using internal if possible.

I disagree that cloning and modifying existing projects is special.  Good 
lord! I (along with about a million other engineers) have been doing that 
for decades:-) My clients really don't want and shouldn't have to pay me to 
start from scratch every time.

-- 
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/8f73006c-f3b2-42ee-a754-29d13bc5fa89n%40googlegroups.com.

Re: [go-nuts] Modules and internal packages



On Thursday, March 4, 2021 at 10:06:01 AM UTC-5 Bryan C. Mills wrote:

>
> I would argue that the “hack” in this case is the approach of defining the 
> API in terms of copying in an entire tree of packages, rather than having 
> users of the API make function calls into a specific set of (unmodified, 
> un-relocated) packages with stable import paths.
>
> If the API is defined in terms or reflection over a set of types, why 
> substitute a package rather than (say) having the caller pass in a set of 
> instances of `reflect.Type` or similar?
>

I'm not trying to create an API.  My initial goal is to provide a working 
skeleton app for my own use that incorporates:

   - a server,
   - a wasm client,
   - a web page that loads the client,
   - a common struct that represents information to be displayed in the 
   page, changed by controls therein, and propagated back to the server 
   through the wasm client.
   - magefiles and templates that generate code in the server, client and 
   web page such that changes in the common struct are updated in all of the 
   above at build time.

The above functionality is working pretty well. I can modify, add or 
subtract members in the common struct, rebuild and run it with no other 
manual changes.  I posted here because of the problems I've encountered 
with Go modules when trying to create new app from a clone of the skeleton.

If I can make the skeleton broadly useful and make it play nice with Go 
modules,  I'll happily share it.  

 

-- 
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/d83c42f9-0892-49f4-b41c-fdd05e216eb1n%40googlegroups.com.

Re: [go-nuts] Modules and internal packages



On Thursday, March 4, 2021 at 10:14:03 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Thu, Mar 4, 2021 at 3:54 PM Michael Ellis  wrote:
>
>> Not sure if my case is all that special.  Seems like the requirement for 
>> a full path to an internal package breaks the concept of "internal" because 
>> it gives everyone import access to whatever the internal package exports.
>>
>
> Really? I can't reproduce that. If I create a minimal module importing "
> github.com/Merovius/srvfb/internal/fb" and try to build that, I get an 
> error message:
>
>  foo.go:3:8: use of internal package github.com/Merovius/srvfb/internal/fb 
> not allowed
>
> So, the internal mechanism seems to work just fine, to me? Note that 
> "every importer needs to mention the full path" is not the same as 
> "everyone mentioning the full path can import".
>

My bad. I should have tested before writing that.  Thanks for checking.  
Good to know the tools are enforcing the distinction.  Still, the import 
path requirement does get in the way of being able to create a new 
application by cloning and revising an existing one without doing a 
recursive sed (or equivalent thereof).

-- 
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/35e46b0e-a730-4b27-9ca0-313ddfccf855n%40googlegroups.com.

Re: [go-nuts] Modules and internal packages

On Thursday, March 4, 2021 at 2:24:11 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Thu, Mar 4, 2021 at 12:55 AM Michael Ellis  
> wrote:
>
>> Thanks even though it's not the answer I was hoping for.  Seems to me 
>> that since the Go Authors have accorded special status to directories named 
>> "internal"  the module mechanism should recognize references to it and not 
>> require a globally unique path string.  
>>
>  

>  
>>
> Maybe. There seem to be few downsides. Then again, your case is also 
> fairly special.
>

Not sure if my case is all that special.  Seems like the requirement for a 
full path to an internal package breaks the concept of "internal" because 
it gives everyone import access to whatever the internal package exports.  
It would be good to have Russ and/or Ian weigh in on this.  My feeling at 
this point is that either "internal" should be deprecated or the module 
mechanism needs to honor it.

>
> On Thu, Mar 4, 2021 at 3:34 AM 'Bryan C. Mills' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> You should be able to use a `replace` directive to replace the full path "
>> github.com/Michael-F-Ellis/skeleton/internal/common" or similar.
>
>
> Using replace would still mean that a module doesn't work, when used as a 
> library. Generally, I feel that `replace` is being used for more and more 
> things it wasn't designed for, leading to more and more friction and 
> problems. I don't think we should encourage more off-label uses. 
>

Agree. Replace in this instance feels like a hack. Don't get me wrong, I 
like the concept behind go.mod and think it's generally a strong and useful 
design. That being said, I also agree with the sentiment expressed in a 
couple of other recent thread that the present implementation imposes a 
burden on coders who want to quickly sketch and test ideas in a local 
directory.  It ought to be possible to progress at least a little way 
beyond Hello World before needing an external repo.

-- 
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/c7f87f45-b944-4f00-a6a6-ad3a8d1c5d4bn%40googlegroups.com.

Re: [go-nuts] Modules and internal packages

2021-03-03 Thread Michael Ellis



On Wednesday, March 3, 2021 at 6:11:38 PM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Thu, Mar 4, 2021 at 12:02 AM Michael Ellis  
> wrote:
>
>> What's the right way to handle this use case?
>>
>
> I think the right way to handle it is to modify the file. In the final 
> code, the import path should unambiguously point to where the code can be 
> found - regardless of whether it was using your skeleton to get started. 
> You might write a tool to do that modification automatically, if you want 
> to simplify things.
>

Thanks even though it's not the answer I was hoping for.  Seems to me that 
since the Go Authors have accorded special status to directories named 
"internal"  the module mechanism should recognize references to it and not 
require a globally unique path string.  

-- 
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/63067d97-1aa3-4efb-92af-7ea0f831a873n%40googlegroups.com.

[go-nuts] Modules and internal packages

2021-03-03 Thread Michael Ellis


I recently coded up a skeleton app to use as a starting point for projects 
that include a server component and a wasm (WebAssembly) client that does 
local work in a user's browser while communicating with the server.  

The skeleton is hosted  on Github (in a private repo until I think it's 
ready to publish).  

Today I decided to clone it and start an actual project.  I've run into a 
problem with internal package imports.  

Briefly,  the skeleton has multiple source files  that import from internal 
packages, e.g.

import  "github.com/Michael-F-Ellis/skeleton/internal/common"

The purpose of the internal/common package is to define structs that need 
to be known by both the server and the wasm component.  As such, the 
package will be different in each application built from the skeleton and, 
hence, the import statements all need to be modified to reference the new 
project's module name, e.g.,

import  "gitlab.com/SomeOneElse/someproject/internal/common"

Is there now no way to simply refer to "internal/common" in the import 
statement and have the toolchain treat it as a local import.  I've tried 
using the various argument to a replace directive in go.mod with no luck so 
far.

What's the right way to handle this use case?



-- 
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/669b426e-5d0a-43a4-b086-e9e0c7213a9en%40googlegroups.com.

[go-nuts] Added polish translation of Tour of Go

2021-03-03 Thread Michael

Hi!

I've been recently working on a translation of "A Tour of Go" to Polish
language and wanted to let you know that I have a PR ready!

Kind regards
Michal Stokluska

-- 
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/CAB8%3DeVG6cyB4F67AmBFK1g-fpEhLH_T9ZJ6q6TsF22e_uzw1VQ%40mail.gmail.com.

Re: [go-nuts] Error handling

2021-02-25 Thread Michael MacInnis


>
> I realize that this thread ended up diverging into a wider discussion of 
> exceptions and error handling in general but I wanted mention one of the 
> problems I discovered and maybe a potential solution for others who may be 
> tempted to play around with something like this.
>
> I originally thought that one of bigger problems with (ab)using panic and 
> recover for control flow and trying to wrap this up in a package would be 
> forgetting to defer the function performing the recover. As mentioned 
> previously I think it's possible to structure things so that it is harder 
> to make this mistake and I think a linter could also be written to catch 
> these cases.
>
> But I think the bigger problem is the function that panics being used 
> after the function with the deferred recover exits or in a different 
> goroutine.
>
> It looks like the Go compiler's escape analysis can be used to detect this 
> though. At least currently. With an inline definition of check and a 
> deferred recover that looks like this:
>
> var check func(error)
> {
> pnc := false
>
> check = func(ce error) { // watch for "func literal escapes to 
> heap"
> if ce != nil {
> err = ce
>
> // Only panic if we haven't previously.
> if !pnc {
> pnc = true
> panic("escaping")
> }
> }
> }
>
> defer func() {
> if pnc {
> _ = recover()
> }
> }()
> }
>
> // Code that uses check.
>
> When compiled with `go build -gcflags -m` if the Go compiler says that the 
> func literal assigned to check escapes to the heap there's a good chance it 
> is being used in a way that won't end well. It even catches uses like this:
>
> c := make(chan struct{})
>
> go func() {
> check(nil)
>
> close(c)
> }()
>
> <-c
>
> where check doesn't out live the function with the deferred recover but it 
> is being used in a different goroutine. So, at least currently, it looks 
> like the compiler can be used to check for unsafe uses of a function like 
> this.
>
> What I'm wondering is are there cases that the compiler won't catch and is 
> this likely to stop working in some future release where, in a block of 
> code like the one above, the compiler will decide that the function doesn't 
> need to escape to the heap?
>
> Michael.
>

-- 
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/d99b705e-d78a-4078-8f8a-ef89a824f58cn%40googlegroups.com.

Re: [go-nuts] Error handling

2021-02-20 Thread Michael MacInnis

I don't believe anyone is talking about not handling errors. There are 
functions that perform a sequence of actions and need to go no further when 
an error is encountered. An example of this type of function is presented 
in the "Errors are Values" post:

https://blog.golang.org/errors-are-values

Another example is the CopyFile function from "Error Handling - Problem 
Overview":

https://github.com/golang/proposal/blob/master/design/go2draft-error-handling-overview.md

In these cases the caller may be better equipped to know what to do next 
when there is an error.

The "Errors are Values" post gives some examples of using the language to 
simplify error handling. The check/handle and try proposals do the same 
thing but by proposing language changes. I don't believe any of them are 
proposing not checking and/or not handling errors.

I can tell you most emphatically that I am not proposing not checking 
and/or not handling errors. I'd like to know if, for functions like the 
ones just mentioned, a pattern exists for "eliminating much of the 
boilerplate that arises if every error is checked with a rote if 
statement." And further if that pattern can be implemented as a 
library/package with acceptable trade offs.

Michael.

On Saturday, February 20, 2021 at 6:54:39 PM UTC-5 ohir wrote:

> Dnia 2021-02-20, o godz. 13:21:09
> Michael Ellis  napisał(a):
>
> > FWIW, I've put together a tiny package that, with some tradeoffs, seems 
> > useful for reducing boilerplate in the common case where a function 
> simply 
> > wants to return an error to its caller. 
>
> > The code is almost trivial. It consists of two small functions, 
> > ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:
>
> > in the common case where a function simply wants to return an error to 
> its caller.
>
> There is no trade off here for me (an likely many others). It is idiomatic 
> versus weird:
>
> 1. hit !er move on coding (in fact MY shortcut puts panic instead 
> of return).
>
> 2. USE: import (write) a module, setup defer stack, confuse first-time 
> reader, write a call, move on.
>
> Note that both versions on my vim take just one line off the screen 
> estate. This is true for any IDE able to fold. OK - idiomatic would take 
> two lines more if code is viewed in pager or using MS Word.
>
> > in the common case where a function simply wants to return an error to 
> its caller.
>
> It is NOT a "common" case.
>
> In the "boring" production code we are expected that any service exposed 
> to the end-user will never refuse to work, our code must try really hard to 
> complete, retrying at other server here, then at other city's or continent 
> server room until its real task can be successfully done. Resources (eg. 
> network services) needs to be acquired, then vetted, then operated on, then 
> finally released in a consistent state. 
>
> So we don't throw "something went wrong" (ie. unhandled exception) up. Nor 
> we do "Return if any error". We do check errors, then
> retry in loops. Go explicit, IN PLACE handling helps with that alot.
>
> TC,
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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/c54ded01-20af-4a92-b10c-f85438ed136bn%40googlegroups.com.

Re: [go-nuts] Error handling

2021-02-20 Thread Michael MacInnis

Neat. What you and I are doing is very similar. Particularly how the 
handler is "bound" to the error and checks to make sure that the error is 
non-nil before attempting to recover.

The differences I see in our approaches are as follows:

I support wrapping an error or performing some arbitrary action. This 
wouldn't be difficult for you to add - just add a func() parameter to 
RecoverOn that is invoked when *err != nil. If you did that then we would 
both support performing actions whether an early return was triggered by 
check/ro.ReturnOn or a regular return with err set (assuming named return 
values).

I bind the check function (what you call ro.ReturnOn) to the error so that 
it can set that when passed a non-nil error. This allows check to be used 
directly, for example, on a function that only returns an error:

check(functionThatReturnsAnError())

Instead of having to do:

err = functionThatReturnsAnError()
ro.ReturnOn(err)

Binding the check and done functions means returning them both from a call 
to handle.Error. This adds one more line of code (defer done()) but means 
that check doesn't exist without this step and given that Go complains 
about unused variables it takes some work to forget to do something with 
done. My hope is that this significantly reduces the risk of an unhandled 
panic. (It's still possible to just call done and forget to defer it or 
name done _ so that the compiler won't complain, etc., etc.) As an added 
bonus people can call this pair of functions whatever they want 
(check/done, try/handle, ReturnOn/RecoverOn...). When I first posted I 
thought it would be neat to do:

check, handle := handle.Error // ...
so that the shadowing would make it impossible to call handle.Error again. 
But then I added Chain.

(It would be nice to get the handle.Errorf case down to one line but I 
haven't figured out a way to do that. Maybe something with how arguments to 
deferred function are evaluated but the function call itself isn't...)

In check I wrap the error in an unexported type:

type failure struct {
error
}

If this manages to slip by the idea is that it should be reported as an 
"unhandled error" plus the text of the actual error. It is the 
responsibility of done to unwrap the error and perform any actions on that. 
I'm paranoid about invoking recover, only invoke it when the error is the 
unexported failure type and even then check to make sure that the recovered 
value matches the error value. It is possible to always recover and then if 
we recover something we weren't supposed to, re-panic, but then we lose all 
the context for the original panic.

Looking back at the error handling problem outline I realized that I did 
not have the ability to add additional error handling actions. I added 
Chain a few days after my original post.

Michael.

On Saturday, February 20, 2021 at 4:21:10 PM UTC-5 michael...@gmail.com 
wrote:

> FWIW,  I've put together a tiny package that, with some tradeoffs, seems 
> useful for reducing boilerplate in the common case where a function simply 
> wants to return an error to its caller.  
>
> https://github.com/Michael-F-Ellis/ro
>
> The code is almost trivial. It consists of two small functions, 
> ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:
>
> import "github.com/Michael-F-Ellis/ro" 
>
> func myfunc() (err error) { 
> defer ro.RecoverOn() 
>
> err = SomeFunctionCall() 
> ro.ReturnOn(err)
>
> // Do more stuff 
> // ... 
> return 
> }
>
> ReturnOn panics if err is not nil.
>
> RecoverOn recovers from the panic raised by ReturnOn and the function 
> exits with whatever error value would have been returned 
> normally. RecoverOn does not interfere with panics arising outside 
> of ReturnOn.
>
> Benefits and tradeoffs (coding discipline, debugging, performance) are 
> discussed in the README.
>
> Feedback welcomed either in this thread or in the repo issues.
>

-- 
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/87c73aa0-2ea2-4125-8cc9-3fe7972a4db9n%40googlegroups.com.

Re: [go-nuts] Error handling

2021-02-20 Thread Michael Ellis

FWIW,  I've put together a tiny package that, with some tradeoffs, seems 
useful for reducing boilerplate in the common case where a function simply 
wants to return an error to its caller.  

https://github.com/Michael-F-Ellis/ro

The code is almost trivial. It consists of two small functions, 
ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:

import "github.com/Michael-F-Ellis/ro" 

func myfunc() (err error) { 
defer ro.RecoverOn() 

err = SomeFunctionCall() 
ro.ReturnOn(err)

// Do more stuff 
// ... 
return 
}

ReturnOn panics if err is not nil.

RecoverOn recovers from the panic raised by ReturnOn and the function exits 
with whatever error value would have been returned normally. RecoverOn does 
not interfere with panics arising outside of ReturnOn.

Benefits and tradeoffs (coding discipline, debugging, performance) are 
discussed in the README.

Feedback welcomed either in this thread or in the repo issues.

On Saturday, February 20, 2021 at 3:31:22 PM UTC-5 matthew...@nytimes.com 
wrote:

> I'm referring to errors found in the function (i.e., by calling 
> other functions). It's the responsibility of the callers of a function to 
> handle the errors it returns, and not the function itself. How can one 
> function claim responsibility for the error handling strategy of all 
> programs using it?
>
> Yes, I suppose in some sense exceptions guarantee all errors are handled 
> somewhere. Unfortunately, what I've seen of exception handling over the 
> years is that it's often "log the stack trace and keep moving", which isn't 
> all that useful, and tends to cover up real bugs. A better approach would 
> be not to catch exceptions at all, and let them crash the program (which is 
> what Go's panic will do); this ensures the bugs are really handled by 
> removing them from the program.
>
> [And given this type of exception "handling" it's not much value to the 
> author of a single function to know that the errors will all be "handled" 
> somewhere.]
>
> Unfortunately, exception handling languages tend to put all types of 
> errors, normal and abnormal *, into the same basket. Which means you can't 
> do sensible error handling for, e.g., JSON that doesn't decode, while 
> allowing the program to crash when there's a logic bug. (For non-safety 
> critical software, a crash failure is typically the safest way to fail. 
> Safety-critical software, on the other hand, avoids exception handling like 
> the plague.)
>
> * A normal error is some behavior that can reasonably be expected, such as 
> "file not found" or "no route to host", etc. Abnormal errors are logic bugs 
> in the program.
>
> An aside:
>
> Assuming you had a cyclomatic complexity calculator that took exceptions 
> into consideration, such that exceptions passing through a function counted 
> as a branch, what kind of numbers would you get? Probably pretty awful, 
> given just about any line of code would be capable of throwing an 
> exception. But exceptions typically aren't counted, so that functions are 
> thought to be far less complex than they really are in the presence of 
> exceptions.
>
> Invisible (magic) return paths through a function go against the notion of 
> "the code does what it says on the page".
>
> On Sat, Feb 20, 2021 at 1:11 PM Robert Engels  
> wrote:
>
>> Can you clarify what you mean mean by “the code does exactly what it 
>> shows on the page”? How do you know by looking at the code, or even 
>> compiling the code, that all possible errors returned by a function are 
>> handled? That to me is biggest difficult in reading (or using) others Go 
>> code. Exceptions (well written) handle this by declaring all possible error 
>> (or categories) thrown by the method. 
>>
>> This seems a real problem with long term maintenance of Go code. 
>>
>> On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
>> wrote:
>>
>> 
>> Roger beat me to it.
>>
>> But allow me to rephrase,
>>
>> "The users of Go for a long time have resisted any changes to its simple, 
>> clear method of error handling despite it being a major concern of folks 
>> who don't use Go much." *
>>
>> * I'm referring to the original survey, which was worded along the lines 
>> of "what keeps you from adopting Go?"
>> (implying that the responders are those who haven't adopted Go)
>>
>> Any type of error handling that creates invisible returns in a function 
>> is a bad idea IMNSHO (an opinion backed up by various researches into the 
>> complexity of exception handling). Speaking for myself, I'd like to retain 
>> that quality of

Re: [go-nuts] Error handling

2021-02-18 Thread Michael MacInnis

At the risk of getting caught in the crossfire, I will point out again that 
I just found it interesting how close it was possible to get to something 
like check/handle with just standard language constructs. If you'll excuse 
the cuddled checks, I think this:

func CopyFile(src, dst string) (err error) {
check, done := handle.Errorf(, "copy %s %s", src, dst);
defer done()

r, err := os.Open(src); check(err)
defer r.Close()

w, err := os.Create(dst); check(err)
defer handle.Chain(, func() {
w.Close()
os.Remove(dst)
})

_, err = io.Copy(w, r); check(err)
return w.Close()
}

looks pretty similar to this:

func CopyFile(src, dst string) error {
handle err {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

r := check os.Open(src)
defer r.Close()

w := check os.Create(dst)
handle err {
w.Close()
os.Remove(dst) // (only if a check fails)
}

check io.Copy(w, r)
check w.Close()
return nil
}

I'll probably continue playing with this. If others would like to take a 
look the code is here:

https://github.com/michaelmacinnis/handle

I'm particularly interested in any problems I may have overlooked and 
similar packages that may exist but that I haven't stumbled across.

Thanks,

Michael.

On Thursday, February 18, 2021 at 2:27:33 PM UTC-5 ren...@ix.netcom.com 
wrote:

> Yes but without robust error information (stack trace, typed error) it is 
> very hard to write that top-level handler - at least not a robust one. Plus 
> you are relying on the proper use of defer etc up the chain. This is much 
> simpler with exceptions - to me anyway. 
>
> > On Feb 18, 2021, at 10:39 AM, Kevin Chadwick  wrote:
> > 
> > 
> >> don’t think ‘single shot, short lived processes’ are the typical Go
> >> paradigm - they are usually larger , multi layer, long lived “server”
> >> processes. It’s my opinion that Gos error handling is a problem for
> >> these types. I am not saying it can’t be done but it’s harder to
> >> design/deliver/maintain.
> >> 
> > 
> > I can't agree. Long lived go server processes are made of many single 
> shot worker tasks that can send errors back just the same.
> > 
> >> Exceptions (used properly) provide a lot of information when reading
> >> the code. I don’t get the same feedback with Gos error returns. 
> > 
> > AFAICT, this is just structuring. There is nothing stopping your server 
> processes from having a documented error processor, handling returned error 
> types, possibly even from distributed services.
> > 
> > The only real difference is if the errors are tunnelled in plain sight 
> or behind the scenes. You could store rather than returning errors if you 
> wanted to. I don't think Go users should be encouraged to hide errors away.
> > 
> > -- 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/65F3B450-5507-4E3C-A09B-905DCF4C0006%40gmail.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/1c510a2c-981b-4980-8f47-7a025769e233n%40googlegroups.com.

Re: [go-nuts] Error handling

2021-02-15 Thread Michael MacInnis


>
> Go helps with that. Even team's proposal was finally retracted: 
> https://github.com/golang/go/issues/32437 Discussion there is lengthy, 
> but worth 
> reading to sense why wider community considers "boilerplate" as asset.
>

Thanks, I did follow the try proposal and the earlier check/handle proposal.

I agree that handling errors, and doing so close to where they occur, is a 
good thing. I also agree with the goals as outlined in the error handling 
problem statement. Specifically, that it would be nice if it was possible 
to make "error checks more lightweight, reducing the amount of Go program 
text dedicated to error checking". But that in doing so "error checks and 
error handling must remain explicit".

What I find interesting is how close we can get to something resembling try 
or check/handle with existing constructs.

While

f, err := os.Open(filename); check(err)
is not as terse as

f := try(os.Open(filename))

there is less much less text dedicated to error checking than with

f, err := os.Open(filename)
if err != nil {
// Handle err.
}

and passing err explicitly also means there isn't something to unwrap when 
debugging (to get to err) which I thought was an interesting objection to 
try.

Similarly, while

check, handle := handle.Errorf(, "copy %s %s", src, dst)
defer handle()

requires the enclosing function to use named return values and is not as 
terse as

handle err {
fmt.Errorf("copy %s %s: %v", src, dst, err)
}

it is close to the suggestion for decorating errors in the try proposal

defer fmt.HandleErrorf(, "copy %s %s", src, dst)

The problem is that forgetting to defer handle (in my version) means that 
check will cause an unrecovered panic. I'm also wondering if there are 
other interactions that I've overlooked. It is these more mechanism than 
policy considerations where I'm looking for feedback.

Michael.

-- 
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/f6673e29-1366-476a-8fcc-31f6a4efe22dn%40googlegroups.com.

Re: [go-nuts] What compatibility of go/ast, go/types, go/packages packages is planned, if any, when transitioning toward go2 ?

On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:
To be clear, there is no Go 2, and there are no plans for Go 2.

Speaking as one who suffered through the ill-conceived and interminable 
Python3 transition, this is the best news I've heard since discovering and 
falling in love (well, it *is* Valentines Day) with Go a couple of years 
ago.  Thank you!

On Thursday, January 28, 2021 at 2:26:37 PM UTC-5 Ian Lance Taylor wrote:

> On Thu, Jan 28, 2021 at 3:43 AM 'Carla Pfaff' via golang-nuts
>  wrote:
> >
> > On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:
> >>
> >> To be clear, there is no Go 2, and there are no plans for Go 2.
> >
> >
> > For someone who follows the mailing lists and issue comments this has 
> been known for a while, but it's easy to see where the confusion comes 
> from, given these blog posts:
> >
> > https://blog.golang.org/toward-go2
> > https://blog.golang.org/go2-here-we-come
> > https://blog.golang.org/go2-next-steps
> >
> > They mention backward-compatibility, but only for the initial proposals 
> "to get the ball rolling". There hasn't been a blog post titled "There are 
> no plans for Go 2" or "Go 2 is not what you think it is" so far. The 
> current policy seems to be this document:
> >
> > "Proposal: Go 2 transition": 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
> > "If the above process works as planned, then in an important sense there 
> never will be a Go 2."
> >
> > It is labeled "Proposal", but it doesn't seem to be a proposal in the 
> usual proposal process sense, and many may have missed it.
>
> You're right, I wrote that poorly. People use "Go 2" in various
> different ways. I should have said: there is no plan to ever break
> backward compatibility with earlier versions of Go.
>
> Ian
>

-- 
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/77ade682-6cb2-45ee-b7bd-7447d3b41a7dn%40googlegroups.com.

Re: [go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?

I've opened https://github.com/golang/vscode-go/issues/1225.

-- 
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/CAK6kDbZXw1HRs5tqX50LFfv%3Dg_drosjMXbN13_ELD5pYCyt8bQ%40mail.gmail.com.

Re: [go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?

>
> As vscode-go is now curated by the Go team [
> https://blog.golang.org/vscode-go]
> I think you should raise issue at https://github.com/golang/vscode-go.
> Your project layout (original one) seems good and straightforward, and the
> need
> for having per-folder environment settings or build-tags is real.
> It shouldn't be the IDE that dictates Go project structure, IMO.
>

I agree about wanting project structure independent of IDE.  I'm not so
sure if this is something vscode-go can reasonably be expected to solve,
though.

If I'm understanding correctly,  vscode-go would need to parse each file
for build-tags and pass that information to the go tool chain, presumably
as environment variables.

That sounds doable for standard tags that map to supported values for GOOS,
GOARCH, etc., but I wonder what problems would be caused by non-standard
tags, e.g. "+build mage" for magefiles.


Cheers,
Mike

*“I want you to act as if the house was on fire. Because it is.” — Greta
Thunberg*


On Sun, Feb 14, 2021 at 11:32 AM Wojciech S. Czarnecki 
wrote:

> Dnia 2021-02-14, o godz. 10:54:02
> Michael Ellis  napisał(a):
>
> > I wrote a detailed answer on StackOverflow
>
> Thank you.
>
> As vscode-go is now curated by the Go team [
> https://blog.golang.org/vscode-go]
> I think you should raise issue at https://github.com/golang/vscode-go.
> Your project layout (original one) seems good and straightforward, and the
> need
> for having per-folder environment settings or build-tags is real.
> It shouldn't be the IDE that dictates Go project structure, IMO.
>
> TC,
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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/2vI1CA76HPI/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/20210214173156.1a9edbfa%40xmint
> .
>

-- 
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/CAK6kDbZ8E7py6hX_8Bp7Z-gixoZg6MNeJzZy00Vr0y4zoBhyow%40mail.gmail.com.

Re: [go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?