Re: [go-nuts] Re: assert library with generics?

[Pierre Durand]

https://pkg.go.dev/github.com/pierrre/assert#section-readme

Le vendredi 23 février 2024 à 09:34:43 UTC+1, Harmen a écrit :

> On Thu, Feb 22, 2024 at 04:41:53PM -0800, Seth Hoenig wrote:
> > https://github.com/shoenig/test
> > 
> > We've been using this for a couple years now, and it's been great. I am 
> > biased though, for obvious reasons. It makes use of the go-cmp library 
> > under the hood for creating legible diffs, and integrates well with 
> > protocmp for when you need to work with protobufs. 
>
> That's exactly what I was looking for:
>
> func Eq[A any](t T, exp, val A, settings ...Setting)
>
> Will give it a try, thanks!
>
>
> > 
> > On Thursday, February 22, 2024 at 2:20:57 AM UTC-6 Harmen wrote:
> > 
> > > Hi,
> > >
> > > anyone has a tip for a nice (small) "assert" test help library which 
> uses 
> > > generics for the "equals" and "not equals" functions?
> > >
> > > testify is the obvious library to use for tests, which works fine, but 
> it 
> > > would
> > > be nice to have something which uses generics here.
> > >
> > > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/61fe55d0-8e3d-4dc0-a12e-00f48dbc7856n%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/342cad17-1a1e-42b9-b5d0-cb9134a44e59n%40googlegroups.com.

[go-nuts] testing: add a global cleanup function.

[Pierre Durand]

Currently we can register a cleanup function on a single test. This 
function is executed when the test finishes.
But there is no way to execute a cleanup function after all the tests of a 
package are executed.

Use case: let's say I want to build a "test helper" library that is used by 
other projects in their tests.
This library allocates some global resources that must be cleaned after all 
the tests in a package are executed.

Yes it's possible to do it with TestMain.
But it requires to declare it in each tested packages.
It would be more convenient to be able to register a cleanup function from 
the "test helper" library.

-- 
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/3f7d1270-a151-4c39-b382-883b9ee401fbn%40googlegroups.com.

Re: [go-nuts] Re: Generic "nillable" constraint

[Pierre Durand]

OK thank you, that confirms what I was thinking.

Indeed it's not a common need.
I wanted to know if it was possible to 
rewrite https://pkg.go.dev/github.com/stretchr/testify/assert#Nil with a 
"nillable" constraint instead of "interface{}".


Le jeudi 22 décembre 2022 à 14:43:51 UTC+1, axel.wa...@googlemail.com a 
écrit :

> On Thu, Dec 22, 2022 at 2:24 PM Pierre Durand  wrote:
>
>> Same question for `len()`: is there a way to declare a constraint that 
>> matches types that support `len()` ?
>
>
> For this, the workaround you posted works, at least. It's not convenient, 
> but it also does not seem like a common need - again I'd be kind of curious 
> what you want it for.
>  
>
>>
>> Le jeudi 22 décembre 2022 à 14:23:22 UTC+1, Pierre Durand a écrit :
>>
>>> Is there a way to declare a "nillable" constraint that matches all types 
>>> that can be nil (pointer, slice, map, etc.) ?
>>>
>>> I would like to write a function, that receives a parameter (with a 
>>> generic type), and check if this parameter is nil.
>>> I found a very ugly way to write it: https://go.dev/play/p/0g0SoTlBEgs
>>> The problem: the map type needs more than 1 type, so I need to provide 
>>> the 3 types when I call the `IsNil()` function/
>>> Is there a better way ?
>>>
>>> Yes I know I could use `any`, and check with reflect if the value inside 
>>> the interface is nil.
>>> But I want to know if it's possible to do it with generics.
>>>
>>> Thank you.
>>>
>> -- 
>>
> 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/5101cdb3-601a-4eec-b278-5be07a891590n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/5101cdb3-601a-4eec-b278-5be07a891590n%40googlegroups.com?utm_medium=email&utm_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/da2eea56-65b6-4534-af8b-1b58b95d6d56n%40googlegroups.com.

[go-nuts] Re: Generic "nillable" constraint

[Pierre Durand]

Same question for `len()`: is there a way to declare a constraint that 
matches types that support `len()` ?

Le jeudi 22 décembre 2022 à 14:23:22 UTC+1, Pierre Durand a écrit :

> Is there a way to declare a "nillable" constraint that matches all types 
> that can be nil (pointer, slice, map, etc.) ?
>
> I would like to write a function, that receives a parameter (with a 
> generic type), and check if this parameter is nil.
> I found a very ugly way to write it: https://go.dev/play/p/0g0SoTlBEgs
> The problem: the map type needs more than 1 type, so I need to provide the 
> 3 types when I call the `IsNil()` function/
> Is there a better way ?
>
> Yes I know I could use `any`, and check with reflect if the value inside 
> the interface is nil.
> But I want to know if it's possible to do it with generics.
>
> Thank you.
>

-- 
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/5101cdb3-601a-4eec-b278-5be07a891590n%40googlegroups.com.

[go-nuts] Generic "nillable" constraint

[Pierre Durand]

Is there a way to declare a "nillable" constraint that matches all types 
that can be nil (pointer, slice, map, etc.) ?

I would like to write a function, that receives a parameter (with a generic 
type), and check if this parameter is nil.
I found a very ugly way to write it: https://go.dev/play/p/0g0SoTlBEgs
The problem: the map type needs more than 1 type, so I need to provide the 
3 types when I call the `IsNil()` function/
Is there a better way ?

Yes I know I could use `any`, and check with reflect if the value inside 
the interface is nil.
But I want to know if it's possible to do it with generics.

Thank you.

-- 
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/2043afe5-3d18-445a-90a9-75b48d3ec078n%40googlegroups.com.

[go-nuts] Re: Why does race detector only throw out warning rather than fatal error?

[Pierre Durand]

See "halt_on_error"
https://golang.org/doc/articles/race_detector.html#Options

Le mardi 8 septembre 2020 à 14:47:11 UTC+2, chole...@gmail.com a écrit :

> Code with data races is invalid code, we shouldn't let it run once we find 
> a data race. Actually, since Go 1.5, when runtime finds concurrent read and 
> write to a map, it does throw a fatal error rather than just warning. Maybe 
> it's not consistent that race detector only print out warning message.

-- 
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/055c7885-db90-4729-84ac-8c6e6a2aabc1n%40googlegroups.com.

Re: [go-nuts] http.client.Do(request) panics in highly concurrent apps (Go 1.14.1)

[Pierre Durand]

The stack trace is identical to https://github.com/golang/go/issues/3

Le jeudi 2 avril 2020 23:23:02 UTC+2, Robert Engels a écrit :
>
> Does your code use any unsafe or cgo?
>
> On Apr 2, 2020, at 11:38 AM, 'hamid...@live.com ' via 
> golang-nuts > wrote:
>
> 
> Hi folks,
>
> An issue with the latest version of Go (1.14.1). My application panics 
> when making concurrent http GET requests to another API.
>
> Unfortunately it's not possible to post the code here but it should be 
> pretty straightforward to reproduce this.
>
> My application makes concurrent GET requests to another Go API at around 
> 280 req/sec using goroutines. This application is supposed to make about 3 
> million requests to that API every day. We use the latest version of Go in 
> our deployments (1.14.1 in this case), however this application panics 
> after 10-120 minutes of running and unfortunately the running time is not 
> quite deterministic. Rolling back to Go 1.13.5 fixes this issue.
>
> I have seen other github threads that refer to the same issue in older 
> versions of Go, however this seems to have re-appeared again in 1.14.1.
>
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x451cad]
>
> goroutine 646692 [running]:
> time.stopTimer(0xc00035fa48, 0x0)
> /usr/local/go/src/runtime/time.go:224 +0x2b
> time.(*Timer).Stop(...)
> /usr/local/go/src/time/sleep.go:78
> net/http.(*http2ClientConn).roundTrip(0xc001e68780, 0xc001e8c900, 0x0, 
> 0x0, 0x0, 0x0)
> /usr/local/go/src/net/http/h2_bundle.go:7480 +0x9f
> net/http.(*http2Transport).RoundTripOpt(0xc0001965a0, 0xc001e8c900, 
> 0x9b3800, 0xc0001af080, 0xc000809770, 0x5)
> /usr/local/go/src/net/http/h2_bundle.go:6948 +0x16f
> net/http.(*http2Transport).RoundTrip(...)
> /usr/local/go/src/net/http/h2_bundle.go:6909
> net/http.http2noDialH2RoundTripper.RoundTrip(0xc0001965a0, 0xc001e8c900, 
> 0xb53460, 0xc0001965a0, 0x0)
> /usr/local/go/src/net/http/h2_bundle.go:9103 +0x3e
> net/http.(*Transport).roundTrip(0xf4e580, 0xc001e8c900, 0xc002c91e60, 
> 0xc001080840, 0x40c7f8)
> /usr/local/go/src/net/http/transport.go:515 +0xd94
> net/http.(*Transport).RoundTrip(0xf4e580, 0xc001e8c900, 0xf4e580, 0x0, 0x0)
> /usr/local/go/src/net/http/roundtrip.go:17 +0x35
> net/http.send(0xc001e8c900, 0xb52420, 0xf4e580, 0x0, 0x0, 0x0, 
> 0xc00073c2f8, 0xc2a015, 0x1, 0x0)
> /usr/local/go/src/net/http/client.go:252 +0x43e
> net/http.(*Client).send(0xf58ba0, 0xc001e8c900, 0x0, 0x0, 0x0, 
> 0xc00073c2f8, 0x0, 0x1, 0xc001e8c900)
> /usr/local/go/src/net/http/client.go:176 +0xfa
> net/http.(*Client).do(0xf58ba0, 0xc001e8c900, 0x0, 0x0, 0x0)
> /usr/local/go/src/net/http/client.go:699 +0x44a
> net/http.(*Client).Do(...)
> /usr/local/go/src/net/http/client.go:567
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/91bf3382-8c71-481a-98e5-c9020dbd66b9%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/b0969c35-f531-4172-9dbc-35b40d7b7de2%40googlegroups.com.

Re: [go-nuts] Go string and UTF-8

[Pierre Durand]

Well, in my case I don't want to convert the []byte to hexadecimal string, 
because it uses 2x more memory.
The code contains a huge map where the key is an MD5 hash.

Please note that I'm not personally working on this.
I was reviewing the code written by a coworker, and I noticed that there 
was a string variable containing "invalid UTF-8 bytes".
It felt very strange to have a string containing invalid text.

So I have another question: since md5.Sum() is returning a [16]byte, is it 
better to use [16]byte as a map key ?
Or should I use a string containing invalid text as a map key ?

Le mardi 20 août 2019 14:01:38 UTC+2, Sam Whited a écrit :
>
>
>
> On August 20, 2019 11:50:54 AM UTC, Rob Pike  > wrote: 
> >Printf can print hexadecimal just fine. Never understood the point of 
> >encoding/hex. 
>
> I always thought that the C style format strings were unreadable and the 
> hex package methods were much clearer, personally. 
>
> —Sam 
>

-- 
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/4d600bee-5aae-454e-8419-cf6560af37bb%40googlegroups.com.

[go-nuts] Re: Go string and UTF-8

[Pierre Durand]

OK, thank you !

Le mardi 20 août 2019 10:34:55 UTC+2, djeg...@gmail.com a écrit :
>
> On Tue, Aug 20, 2019 at 10:12 AM Pierre Durand wrote:
> >
> > I know that by convention Go string contain UTF-8 encoded text.
>
> To my understanding this is not entirely true -- see 
> https://blog.golang.org/strings#TOC_2. -- It is simply a readonly slice 
> of bytes. However there is at least 2 places where UTF-8 encoding is used 
> for strings in the language spec: source code file is expected to be UTF-8 
> (thus string literals are partially influenced), and when using the `for 
> range` construct on a string. Otherwise there are various packages (e.g. 
> unicode/utf8) which expect UTF-8 encoded strings as arguments.
>
> > Is it recommended/a good practice to store invalid bytes in a string ?
>
> Thus the concept of _invalid bytes in a string_ doesn't really exist ;-).
>
> > The use case:
> > - compute a hash => get a []byte
> > - convert the []byte to string (this string is not UTF-8 valid)
> > - use the string as a map key
>
> I don't see any issues with 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/e8610962-732e-4744-9faf-c8581c444064%40googlegroups.com.

[go-nuts] Go string and UTF-8

[Pierre Durand]

I know that by convention Go string contain UTF-8 encoded text.

Is it recommended/a good practice to store invalid bytes in a string ?

The use case:
- compute a hash => get a []byte
- convert the []byte to string (this string is not UTF-8 valid)
- use the string as a map key

In my case, the hash algorithm is md5.

-- 
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/ec99fbdb-338b-4094-8b37-1d19b3851c72%40googlegroups.com.

[go-nuts] go/types: check if *ast.Ident is a function parameter

[Pierre Durand]

Hello !

I'm trying to write a tool that will:
- parse my code, and find variable assignment
- check if the assigned variable is a parameter in the current function (or 
a function parameter in the current scope)

func myFunc(a *A){
a.foo = "bar"
}

In the code above, I want to detect that "a" in "a.foo" is referencing the 
"a *A" parameter in my function.

I already know how to use ast.Walk(), and find the *ast.Ident for "a" in 
"a.foo".
I also know that I can use types.Info.Defs with conf.Check().

Can someone give me some advice please ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] "go vet -shadow" and named return variable

[Pierre Durand]

ok, thank you !

Le lundi 1 octobre 2018 19:31:58 UTC+2, Ian Lance Taylor a écrit :
>
> On Mon, Oct 1, 2018 at 7:56 AM, Pierre Durand  > wrote: 
> > 
> > My code: 
> > package main 
> > 
> > func main() { 
> > a := 1 
> > _ = func() { 
> > a := 2 
> > _ = a 
> > } 
> > _ = func() (a int) { 
> > a = 2 
> > return a 
> > } 
> > _ = a 
> > } 
> > 
> > "go vet -shadow" reports a problem with the first function/closure, but 
> > nothing for the second one. 
> > Why ? 
> > 
> > If I understand correctly, it doesn't consider variable declaration in a 
> > named return value to be a shadowing issue. 
> > Is it expected ? 
>
> It does seem that vet's -shadow option ignores the case where the 
> parameter name (both ordinary parameter and result parameter) in a 
> function literal shadows a local variable in the function.  That seems 
> like a reasonable choice to me.  If you disagree, please open an issue 
> at https://golang.org/issue, and we can sort it out.  Thanks. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] "go vet -shadow" and named return variable

[Pierre Durand]

My code:
package main

func main() {
a := 1
_ = func() {
a := 2
_ = a
}
_ = func() (a int) {
a = 2
return a
}
_ = a
}

"go vet -shadow" reports a problem with the first function/closure, but 
nothing for the second one.
Why ?

If I understand correctly, it doesn't consider variable declaration in a 
named return value to be a shadowing issue.
Is it expected ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is it needed to close a HTTP request body ?

[Pierre Durand]

OK ! thanks.

Le lundi 10 septembre 2018 16:39:28 UTC+2, Sam Whited a écrit :
>
>
>
> On Mon, Sep 10, 2018, at 09:27, Pierre Durand wrote: 
> > When I learned Go a few years ago, I was told to always defer/close the 
> > HTTP request body, otherwise it will cause a resource leak. 
> > 
> > But today I read this: https://golang.org/pkg/net/http/#Request.Body 
> > // The Server will close the request body. The ServeHTTP 
> > // Handler does not need to. 
> > 
> > Am I misunderstanding something ? 
>
> The rule is that HTTP *clients* must close the *response* body. Servers 
> handle closing the request body themselves. 
>
> —Sam 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is it needed to close a HTTP request body ?

[Pierre Durand]

When I learned Go a few years ago, I was told to always defer/close the 
HTTP request body, otherwise it will cause a resource leak.

But today I read this: https://golang.org/pkg/net/http/#Request.Body
// The Server will close the request body. The ServeHTTP
// Handler does not need to.

Am I misunderstanding something ?

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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] gometalinter v2.0.0 released - much faster linting

[Pierre Durand]

Thank you! :)

Le mardi 5 décembre 2017 08:10:50 UTC+1, Alec Thomas a écrit :
>
> Hello,
>
> Through the efforts of many contributors, and in particular those of 
> Daniel Nephin, v2.0.0 has been released. You can grab it here:
>
> https://github.com/alecthomas/gometalinter/releases/tag/v2.0.0
>
> The biggest change since v1.x is that linting is now MUCH more efficient, 
> thanks to the changes by Daniel. Instead of invoking each linter for every 
> directory, linters are invoked the minimum number of times necessary by 
> passing as many directories, packages or files as they will accept in a 
> single invocation.
>
> The configuration format has also changed, but should be mostly backwards 
> compatible.
>
> Another major change is that from now on we will be releasing binary 
> packages. This also means that: gometalinter's management of linter 
> installation will soon be deprecated, and eventually removed, and that 
> gopkg.in will no longer be used.
>
> Going forward we have several interesting things planned for gometalinter:
>
> 1. Support for in-process invocation of linters via an interface + 
> adapters. See https://github.com/alecthomas/gometalinter/issues/380. This 
> should make linting even more efficient, as packages will only need to be 
> parsed/compiled once, and the FileSet (etc.) can be reused.
> 2. Configuration handling will be rewritten/rethought. This will encompass 
> automatic .gometalinterrc loading, among other things.
> 3. Lots of internal refactoring to clean up the codebase.
>
> As always, if you encounter any problems please create a new issue.
>
> Regards,
> Alec
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.9 introduced error on UDP Multicast JoinGroup

[Pierre Durand]

Did you test Go 1.9 betas or RCs ?

Le lundi 28 août 2017 01:14:20 UTC+2, oldCoderException a écrit :
>
> Hi all,
>
> I upgraded to Go 1.9 and since then UDP multicast code that has been 
> running fine for over a year is now failing on JoinGroup.  I run this 
> program on linux Mint 18 as root (using sudo), both for the multicast 
> permissions and also to allow listening on TCP port 80 and redirecting to 
> port 443 for SSL.  The error returned from JoinGroup is "operation not 
> permitted" which I could expect for a non-privileged user, but not for 
> root.  
>
> If I recompile the program using Go 1.8.3 the exact same works again.
>
> I won't show all the code since there are several structs and "objects" 
> involved, but here's the failing bit, with the interface, listen address, 
> and group address all hard coded just for this example:
>
> iFace := "eno1"
> listenAddr := "0.0.0.0:12080"
> grpAddress := "224.0.0.12"
> inetConn, err3 := net.ListenPacket("udp4", listenAddr)
> if err3 != nil {
> alertMsg = bsutils.CreateFormattedBSAlert(bsutils.ALERT_CRITICAL, 
> "ListenPacket Failed: %s", err3.Error())
> return nil, alertMsg
> }
>
> mConn := ipv4.NewPacketConn(inetConn)
> if err := mConn.JoinGroup(iFace, &net.UDPAddr{IP: grpAddress}); err != nil 
> {
> alertMsg = bsutils.CreateFormattedBSAlert(bsutils.ALERT_CRITICAL, 
> "JoinGroup Failed: %s", err.Error())
> return nil, alertMsg
> }
>
> If it gets past the above code, I then do a SetControlMessage and return 
> mConn for normal serving.
>
> thanks,
> Paul
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: when to switch a goroutine to be executed

[Pierre Durand]

Goroutine execution is not deterministic.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: To panic or not to panic, that's the question

[Pierre Durand]

I use these functions in init():
https://golang.org/pkg/html/template/#Must
https://golang.org/pkg/regexp/#MustCompile

Le mercredi 31 mai 2017 21:24:58 UTC+2, Peter Kleiweg a écrit :
>
> If a package can't be used because some precondition can't be fulfilled, 
> you can use a panic. Then the whole program will crash at start-up.
>
> The alternative would be to not panic in the init, but have all function 
> calls return an error. If the package is used in a large program, part of 
> it may still be functional.
>
> Using panic in an init function of a package, do or don't?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Do I need to unset variables in a for loop?

[Pierre Durand]

>
> I "believe" in PHP a for loop keeps the variable in memory until the end 
> of the script and if you want to remove the variable from memory you need 
> to unset the variable to help conserve memory. 


https://en.wikipedia.org/wiki/Cargo_cult

Le mardi 9 mai 2017 00:29:14 UTC+2, var...@gmail.com a écrit :
>
> I have heard that golang has excellent memory management / garbage 
> collection. If I am preforming millions of calculations in a for loop do I 
> need to unset a variable before the end of the for loop to help with memory 
> or does golang do that for me? I "believe" in PHP a for loop keeps the 
> variable in memory until the end of the script and if you want to remove 
> the variable from memory you need to unset the variable to help conserve 
> memory. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Stop HTTP Server with Context cancel

[Pierre Durand]

Yes you're right, the processing order is pseudo random.

But my code also handle another edge case:
If `srv.ListenAndServe()` returns an error BEFORE we reach the code `case 
err := <-errCh:`,
with `default` the error is ignored.

My code ensure that:
- there is no leaking goroutine
- returned error is not ignored

Le jeudi 6 avril 2017 11:04:29 UTC+2, Kemal Hadimli a écrit :
>
> Isn't the select processing order random? IIRC the only guarantee is 
> "default" case is handled as a low priority.
>
> So, something like this maybe?
>
> select {
> case errCh <- err:
> default:
> select {
> case <-ctx.Done():
> }
> }
>
> Again, take this with a grain of salt. I didn't check the spec or code, 
> just off the top of my head.
>
>
> Best,
>
> On Thursday, April 6, 2017 at 11:29:58 AM UTC+3, Pierre Durand wrote:
>>
>> I did it for a good reason:
>> If the context is canceled `srv.Shutdown` is called.
>> Then, `<-errCh` is not called anymore.
>> This code ensures that there is not leaking goroutine.
>>
>> Le mercredi 5 avril 2017 07:13:19 UTC+2, Johnny Luo a écrit :
>>>
>>> func listenAndServe(ctx context.Context, srv *http.Server, errCh chan<- 
>>> error) {
>>>  err := srv.ListenAndServe()
>>>  select {
>>>  case errCh <- err:
>>>  case <-ctx.Done():
>>>  }
>>> }
>>> ListenAndServe is blocking function, so the select will not happen until 
>>> ListenAndServe return.  and errCh become no use
>>>
>>>
>>> On Wednesday, April 5, 2017 at 4:02:16 AM UTC+10, Pierre Durand wrote:
>>>>
>>>> Hello
>>>>
>>>> I wrote a small helper to stop an HTTP Server when a Context is 
>>>> canceled.
>>>> https://play.golang.org/p/Gl8APynVdh
>>>>
>>>> What do you think ?
>>>> Is it OK to use context cancellation for stopping long running 
>>>> functions ?
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Stop HTTP Server with Context cancel

[Pierre Durand]

I did it for a good reason:
If the context is canceled `srv.Shutdown` is called.
Then, `<-errCh` is not called anymore.
This code ensures that there is not leaking goroutine.

Le mercredi 5 avril 2017 07:13:19 UTC+2, Johnny Luo a écrit :
>
> func listenAndServe(ctx context.Context, srv *http.Server, errCh chan<- 
> error) {
>  err := srv.ListenAndServe()
>  select {
>  case errCh <- err:
>  case <-ctx.Done():
>  }
> }
> ListenAndServe is blocking function, so the select will not happen until 
> ListenAndServe return.  and errCh become no use
>
>
> On Wednesday, April 5, 2017 at 4:02:16 AM UTC+10, Pierre Durand wrote:
>>
>> Hello
>>
>> I wrote a small helper to stop an HTTP Server when a Context is canceled.
>> https://play.golang.org/p/Gl8APynVdh
>>
>> What do you think ?
>> Is it OK to use context cancellation for stopping long running functions ?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Stop HTTP Server with Context cancel

[Pierre Durand]

Hello

I wrote a small helper to stop an HTTP Server when a Context is canceled.
https://play.golang.org/p/Gl8APynVdh

What do you think ?
Is it OK to use context cancellation for stopping long running functions ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Explosion in memory usage when compiling a big file

[Pierre Durand]

This option ? https://github.com/jteeuwen/go-bindata#lower-memory-footprint

Le dimanche 8 janvier 2017 21:46:15 UTC+1, Dave Cheney a écrit :
>
> This is a somewhat known issue. Each token in a parsered .go file is 
> represented by a Node structure inside the program. The Node structure is 
> large, especially on 64 bit systems. 
>
> Normally this is not a problem, but in th e case where code has large 
> tables of data memory usage when compiling can be unexpectedly high. 
>
> This problem is being worked on, but not solution exists in a shipping 
> version of Go yet.
>
> The mitigation to this problem is to reduce the number of parsed tokens, 
> so, rather than
>
> var data = []byte{ 65, 66, 67, 68, 69, 70}
>
> Do
>
> const data = "abcdef"
>
> The latter produces O(1) tokens per declaration vs O(N) tokens for the 
> former. 
>
> If the data cannot be represented as text, compressing and base64 encoding 
> can help. 
>
> I'm not sure what strategy go-bindata uses, but you can check this 
> yourself looking at its generated output. 
>
> Dave
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is it a compiler bug?

[Pierre Durand]

https://golang.org/ref/spec#Comments

Le samedi 12 novembre 2016 19:20:10 UTC+1, John Souvestre a écrit :
>
> Ø  Also, prefixing all of the need-to-be-commented-out lines with // is 
> always safe: https://play.golang.org/p/8Cot8lssO3
>
>  
>
> Except for perhaps: https://play.golang.org/p/9xiWFI-SgB
>
>  
>
> John
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Pure Golang Online Mandelbrot Viewer and MORE

[Pierre Durand]

https://mandelbrot.pierredurand.fr

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] calling file.Write() concurrently

[Pierre Durand]

@Tamás Gulácsi: thank you for your review.

@Daniel K: yes, it was my original idea, but I quickly discarded it, 
because I can't guarantee that LineAppender is safe for concurrent usage.
If you give it a wrong io.WriteCloser, it will be unsafe to use 
concurrently.

Le mercredi 6 juillet 2016 12:49:24 UTC+2, Daniel K a écrit :
>
> Looks good, but you could take advantage of the io writer interface.
> I made a quick example, not sure if it runs (did not test)
>
> https://play.golang.org/p/cYcz2ktoiG
>
> Den onsdag den 6. juli 2016 kl. 11.44.33 UTC+2 skrev Pierre Durand:
>>
>> My solution: https://play.golang.org/p/f5H0svLFE0
>> What do you think ?
>>
>> Le mardi 5 juillet 2016 15:30:38 UTC+2, Jan Mercl a écrit :
>>>
>>>
>>> On Tue, Jul 5, 2016 at 11:38 AM Pierre Durand  
>>> wrote:
>>>
>>> > It works as expected, but in my real code, I'd prefer to avoid mutex.
>>>
>>> Sounds like a case for using a writer goroutine and sending it the 
>>> should-be-atomic log items via a chan string or chan []byte.
>>>
>>>
>>>
>>> -- 
>>>
>>> -j
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] calling file.Write() concurrently

[Pierre Durand]

Ooops, fixed my code: https://play.golang.org/p/vdwDT9WMVr

Le mercredi 6 juillet 2016 11:44:33 UTC+2, Pierre Durand a écrit :
>
> My solution: https://play.golang.org/p/f5H0svLFE0
> What do you think ?
>
> Le mardi 5 juillet 2016 15:30:38 UTC+2, Jan Mercl a écrit :
>>
>>
>> On Tue, Jul 5, 2016 at 11:38 AM Pierre Durand  
>> wrote:
>>
>> > It works as expected, but in my real code, I'd prefer to avoid mutex.
>>
>> Sounds like a case for using a writer goroutine and sending it the 
>> should-be-atomic log items via a chan string or chan []byte.
>>
>>
>>
>> -- 
>>
>> -j
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] calling file.Write() concurrently

[Pierre Durand]

My solution: https://play.golang.org/p/f5H0svLFE0
What do you think ?

Le mardi 5 juillet 2016 15:30:38 UTC+2, Jan Mercl a écrit :
>
>
> On Tue, Jul 5, 2016 at 11:38 AM Pierre Durand  > wrote:
>
> > It works as expected, but in my real code, I'd prefer to avoid mutex.
>
> Sounds like a case for using a writer goroutine and sending it the 
> should-be-atomic log items via a chan string or chan []byte.
>
>
>
> -- 
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] calling file.Write() concurrently

[Pierre Durand]

@Dave Cheney: I want to avoid a *global* mutex, because my function can 
write to different files.

@Konstantin Khomoutov: You are right, I could use a map of mutexes.
As Alex Bligh said, I also need to add a mutex on this map, which is a bit 
complicated...

I'm not using concurrency to write faster.
I have several goroutines (started by HTTP request) that append strings to 
the same file.

@Konstantin Khomoutov + @Alex Bligh: I like this idea about using a channel 
+ goroutine for each file.
It would also help me to not open/close file for each write.

My real question is: is there a problem in the *writeBuffer()* function ?
It is very simple, and it looks that it works.

Le mardi 5 juillet 2016 13:46:38 UTC+2, Alex Bligh a écrit :
>
>
> > On 5 Jul 2016, at 10:38, Pierre Durand  > wrote: 
> > 
> > So, I've written writeMutex(), that uses a mutex. 
> > It works as expected, but in my real code, I'd prefer to avoid mutex. 
> > (in my real code write() can write to different files; the file's name 
> is given as argument) 
>
> ... or more idiomatically, set up a channel per file you are writing, make 
> write() write to that channel, and have a writer go-routine which reads 
> from that channel and writes to the file itself. 
>
> -- 
> Alex Bligh 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] calling file.Write() concurrently

[Pierre Durand]

Hello!

My code: https://play.golang.org/p/pg-p17UuEW
I'm trying to append lines to a file concurrently.

My first write() function is buggy, because WriteString() are called by 
several goroutines in unexpected order.

So, I've written writeMutex(), that uses a mutex.
It works as expected, but in my real code, I'd prefer to avoid mutex.
(in my real code write() can write to different files; the file's name is 
given as argument)

I've also written writeBuffer().
Is it OK to call f.Write() 1 time from several goroutines?
It looks like it works, but I'm not 100% sure this is correct.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.