Re: [go-nuts] Hello, world! - A technical overview of the software powering bgammon.org

[Ian Davis]

On Tue, 2 Jan 2024, at 2:39 AM, Trevor Slocum wrote:
> I’ve just published a blog post about the software powering bgammon.org and 
> my experience creating it using free and open source tools:
> 
> https://bgammon.org/blog/20240101-hello-world/

This was a great read, 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/fac33f2a-a1d7-4a3f-9cde-1a78d56c5029%40app.fastmail.com.

Re: [go-nuts] Go routine context

[Ian Davis]

On Fri, 30 Sep 2022, at 3:32 PM, Robert Engels wrote:
> Very interesting article came out recently. 
> https://www.infoq.com/articles/java-virtual-threads/ and it has implications 
> for the Go context discussion and the author makes a very good case as to why 
> using the thread local to hold the context - rather than coloring every 
> method in the chain is a better approach. If the “virtual thread aka Go 
> routine” is extremely cheap to create you are far better off creating one per 
> request than pooling - in fact pooling becomes an anti pattern. If you are 
> creating one per request then the thread/routine becomes the context that is 
> required. No need for a distinct Context to be passed to every method. 

I don't think it is usual to pool goroutines. Normal usage is to spin one up 
for each incoming request, which is the pattern used by Go's http server for 
example.

I skimmed the article but my knowledge of Java's thread local storage is 
limited. In Go it's common for requests to spawn subrequests in their own 
goroutines. With a context you would derive a child context, potentially with a 
shorter lifetime. What is the equivalent in thread local storage? Is there a 
way to access parent thread storage from a child (analogous to how a child 
context has access to all the values assigned to the parent)?

-- 
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/b35520c7-87b2-4b83-be1b-2d2f4257d283%40app.fastmail.com.

Re: [go-nuts] Sets

[Ian Davis]

On Tue, 27 Sep 2022, at 6:57 PM, Robert Engels wrote:
> The github set issue is impossible to follow without using github. 
>
> Please simply define the interfaces. The implementations will follow. 
> You can have simple iterators, indexed iterators, map (key/value) 
> iterators, errorable iterators, closable iterators. 
>
> You can define how to provide/adapt for/range support to these 
> interfaces later. It is confusing the discussion. Since range is a 
> built in - once the interfaces are defined it is straightforward to 
> discuss for/range support. 
>

Do you have a link to your proposed interface?

-- 
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/b18539f6-dce0-4a63-950f-994c3b4cf4f9%40www.fastmail.com.

Re: [go-nuts] understanding interface conversions

[Ian Davis]

On Thu, 22 Sep 2022, at 11:27 PM, Rory Campbell-Lange wrote:

I just wanted to respond to this part:

> I suppose my question is (and forgive me if this is a terrifically 
> naive), how can one negotiate the go landscape of commonly used modules 
> to re-utilise, where possible, a more commonly named interface 
> implementing "Speak()" or convertible to provide "Speak()"?
>

Generally, when writing Go, the consumer of the object defines the interface it 
requires. So rather than you looking for interfaces that might exist in the 
wild, it's better to focus on your application and its needs. If you have a 
component that uses the Speak method on objects then define that as an 
interface that your component can accept. Any other user of your component can 
see that interface is needed and provide a suitable object that implements it 
or create a shim to adapt one.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1fb8a3c4-b135-4ab1-b969-d6f4c239b7d9%40www.fastmail.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[Ian Davis]

Perhaps https://github.com/kortschak/utter might suit your needs?

On Mon, 15 Aug 2022, at 4:07 PM, John wrote:
> Hey axel,
> 
> I recognize the problem space you are discussing. There are a couple 
> strategies I could implement to try and solve the problems.  And I'm not 100% 
> sure you can solve all of them.  But I certainly don't want to jump down the 
> rabbit hole of reflection myself if I don't have to.  So I'm looking for a 
> package that has attempted to do this.  I'd certainly take something that 
> can't handle every case.
> 
> So far my googlefoo hasn't found the key words that differentiate this from 
> pretty printing, or this type of package doesn't exist.
> 
> Thanks for your response axel.
> 
> 
> 
> On Monday, August 15, 2022 at 7:53:16 AM UTC-7 axel.wa...@googlemail.com 
> wrote:
>> I don't believe this is possible, in general. For example, consider
>> 
>> type S struct {
>> A *int
>> B *int
>> }
>> var x S
>> x.A = new(int)
>> x.B = x.A
>> 
>> There is no single expression for the value of x. Or
>> 
>> type P *P
>> x := new(P)
>> *x = x
>> 
>> Then you have values which represent more than just their plain memory 
>> resources. For example, an *os.File - restoring that would not give you the 
>> same thing.
>> 
>> There's lots of design space here and I don't think you can solve it in full 
>> generality. So, at the very least, you have to be very deliberate about what 
>> you want and what you are willing to give up.
>> 
>> But. Maybe someone else has suggestions for a library doing an approximation 
>> of this you'd like better.
>> 
>> 
>> 
>> On Mon, Aug 15, 2022 at 4:42 PM John  wrote:
>>> Hey axel,
>>> 
>>> Thanks for the reply, but unfortunately not. Because that is going to 
>>> simply print pointer values out.  I want it to unwind all of that (and 
>>> handle the difficulty of recursive references).  I want to be able to take 
>>> what is printed and simply paste it into a file assigned to a variable, add 
>>> the needed imports and have it compile.
>>> On Monday, August 15, 2022 at 7:34:08 AM UTC-7 axel.wa...@googlemail.com 
>>> wrote:
 Does fmt.Printf("%#v", v) do what you want?
 
 
 On Mon, Aug 15, 2022 at 4:27 PM John  wrote:
> I know we have plenty of pretty printing out there, but i'm looking for a 
> package that can print the Go representation of a Struct out to screen.
> 
> So given:
> 
> var x := {
>   A: "hello"
> }
> 
> someLib.Print(x)
> 
> I get:
> 
> {
>   A: "hello"
> }
> 
> I'm sure someone has used reflection to do this and figured out how they 
> want to deal with recursive pointers, so don't want to go recreate the 
> wheel 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/f4fa3f7b-318e-407b-96ef-16102db1e037n%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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%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/0e2af167-4bad-49a1-8a12-e5218204b47fn%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/bf70fe87-7d83-4b28-9401-3ef846def9be%40www.fastmail.com.

Re: [go-nuts] What goes wrong when embedding goroutines inside a for loop?

[Ian Davis]

On Thu, 17 Feb 2022, at 5:20 AM, Zhaoxun Yan wrote:
> package main
> import "fmt"
> 
> func main() {
> targetIndice := make([]int, 3)
> targetIndice[0] = 5
> targetIndice[2] = 4
> 
> for i,n := range targetIndice{
> fmt.Printf("%d : %d \n", i, n)
> }
> 
> c := make(chan int)
> for i, n:= range targetIndice{
> go func(){
> fmt.Printf("targetIndice[%d]=%d \n", i, n)
> c <- 1
> }()
> }
> 
> for i:=0; i<3; i++{
> <- c
> }
> 
> }
> 
> -go run main.go-
> 0 : 5 
> 1 : 0 
> 2 : 4 
> targetIndice[2]=4 
> targetIndice[2]=4 
> targetIndice[2]=4 

This is in the FAQ. https://go.dev/doc/faq#closures_and_goroutines

Try passing i and n to the closure as arguments. See 
https://go.dev/play/p/qzPgDWiE4Og for example



-- 
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/c6a15fb7-517a-400c-93c7-c995c56ca2d2%40www.fastmail.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Ian Davis]

On Mon, 31 Jan 2022, at 8:33 PM, Uli Kunitz wrote:
> Please have a look at golang.org/x/time/rate 
> . This package should solve your 
> problem.
> 
> Here is an example with 10 events per second.
> 
> func main() {
> log.SetFlags(log.Lmicroseconds)
> 
> l := rate.NewLimiter(10, 1)
> ctx := context.Background()
> for {
> if err := l.Wait(ctx); err != nil {
> log.Fatal(err)
> }
> log.Print("event!")
> }
> }
> 
> The package is intended to rate external events, but the simple loop above 
> works as well. You can generate/handle events also in parallel threads if  
> one CPU is not sufficient. Note that for high frequencies it doesn't ensure 
> that the time intervals are exact, but it ensures that the rate limit is 
> maintained.

I agree that this is the right solution for the OP task, but note that the rate 
package is also affected by the same timer issues: 
https://github.com/golang/go/issues/47084

-- 
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/36291963-efaa-4957-bb69-387dd1721487%40www.fastmail.com.

Re: [go-nuts] Parse JSON case-sensitively

[Ian Davis]

On Fri, 24 Sep 2021, at 10:36 AM, 'Dan Kortschak' via golang-nuts wrote:
> On Fri, 2021-09-24 at 10:22 +0100, Ian Davis wrote:
>> I was responding to your statement that it doesn't appear to use
>> exact match in preference. It does, as the example I gave
>> demonstrated. It's not about guarding case.
>
>
> I'll clarify.
>
> In the example I posted https://play.golang.org/p/SQyE3R-GGNn, their is
> clearly an assignment to a non-exact match despite an exact match being
> present. In the example you posted, you show that this can be prevented
> by providing another exactly matching field (this may not be what you
> intended to show, but it does show that). This feature can be used to
> prevent an incorrect assignment of the other-cased key-value like here
> https://play.golang.org/p/Fk8CHy_v7Gg. This may be necessary if you
> have incoming JSON that expects case to be considered and you don't
> want/need of the cases in your deserialisation (this is what I mean by
> case guarding).

This is not a correct interpretation.  In your example the unmarshaller reads 
the incoming json. The first key encountered is "Name" and it matches exactly 
with the field named and tagged as Name so that field is assigned the value. 
The next json key encountered is "name" which does not match any field exactly 
so the unmarshaller falls back to a case insensitive match and assigns the 
value to the Name field, overwriting the previous value.

Both the exact match and the case insensitive match are performed in this 
example. There is no "incorrect" assignment as you describe.

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/5de22c72-5776-48c1-b302-6c89fdff4b2f%40www.fastmail.com.

Re: [go-nuts] Parse JSON case-sensitively

[Ian Davis]

On Fri, 24 Sep 2021, at 10:00 AM, 'Dan Kortschak' via golang-nuts wrote:
> On Fri, 2021-09-24 at 09:55 +0100, Ian Davis wrote:
>> On Fri, 24 Sep 2021, at 9:36 AM, 'Dan Kortschak' via golang-nuts
>> wrote:
>> > On Fri, 2021-09-24 at 01:03 -0700, Brian Candler wrote:
>> > > On Friday, 24 September 2021 at 08:25:31 UTC+1 Brian Candler
>> > > wrote:
>> > > > The documentation says it prefers exact match over case-
>> > > > insensitive, but example 3 contradicts that.  It seems to be
>> > > > last-
>> > > > match that wins.
>> > > >
>> > > >
>> > >
>> > > I realise now what they mean now: if there are multiple struct
>> > > tags
>> > > defined which differ only in case, then the one which matches the
>> > > incoming field exactly is preferred.
>> > > https://play.golang.org/p/Do1dPxLOaCj
>> > >
>> >
>> > This still seems to conflict with the JSON-RPC spec:
>> >
> https://jsonrpc.org/historical/json-rpc-1-1-alt.html#service-procedure-and-parameter-names
>> >
>> > And it doesn't even appear to use the exact match in preference
>> > depending on the order of the JSON keys
>> > https://play.golang.org/p/SQyE3R-GGNn
>> >
>>
>> I think this is working as expected.  For each key in the input json
>> the unmarshaller looks for a matching struct field to hold the data
>> preferring an exact match and falling back to case insensitivity. If
>> there are multiple json keys that map to a single field then they
>> will overwrite any previously matched keys.
>>
>> This modification to your example illustrates it better:
>> https://play.golang.org/p/Ipp67LMG1Kt
>>
>> Ian
>>
>
> I agree that it can be made to work; I constructed the example that way
> it is to demonstrate the failure. Needing to guard case that way is
> pretty surprising and certainly makes it impossible to implement a
> spec-compliant JSON-RPC on top of encoding/json.
>

I was responding to your statement that it doesn't appear to use exact match in 
preference. It does, as the example I gave demonstrated. It's not about 
guarding case.

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/dabd5bf2-d327-4c8c-8055-6d90be47bbb2%40www.fastmail.com.

Re: [go-nuts] Parse JSON case-sensitively

[Ian Davis]

On Fri, 24 Sep 2021, at 9:36 AM, 'Dan Kortschak' via golang-nuts wrote:
> On Fri, 2021-09-24 at 01:03 -0700, Brian Candler wrote:
>> On Friday, 24 September 2021 at 08:25:31 UTC+1 Brian Candler wrote:
>> > The documentation says it prefers exact match over case-
>> > insensitive, but example 3 contradicts that.  It seems to be last-
>> > match that wins.
>> >
>> >
>>
>> I realise now what they mean now: if there are multiple struct tags
>> defined which differ only in case, then the one which matches the
>> incoming field exactly is preferred.
>> https://play.golang.org/p/Do1dPxLOaCj
>>
>
> This still seems to conflict with the JSON-RPC spec:
> https://jsonrpc.org/historical/json-rpc-1-1-alt.html#service-procedure-and-parameter-names
>
> And it doesn't even appear to use the exact match in preference
> depending on the order of the JSON keys
> https://play.golang.org/p/SQyE3R-GGNn
>

I think this is working as expected.  For each key in the input json the 
unmarshaller looks for a matching struct field to hold the data preferring an 
exact match and falling back to case insensitivity. If there are multiple json 
keys that map to a single field then they will overwrite any previously matched 
keys.

This modification to your example illustrates it better: 
https://play.golang.org/p/Ipp67LMG1Kt

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/11c9e6cb-dcad-4d48-8a8a-de8ecef4fb75%40www.fastmail.com.

Re: [go-nuts] Re: [security] Go 1.17.1 and Go 1.16.8 are released

[Ian Davis]

On Fri, 10 Sep 2021, at 11:11 AM, Jérôme LAFORGE wrote:
> Hello all,
> For testing purpose, how can I install Go 1.16.8 with Go 1.17?
> 
> ```
> $go version
> go version go1.17 linux/amd64
> 
> $go get golang.org/dl/go1.16.8 
> go get: installing executables with 'go get' in module mode is deprecated. 
>Use 'go install pkg@version' instead. 
>For more information, see 
> https://golang.org/doc/go-get-install-deprecation 
>or run 'go help get' or 'go help install'.
> 
> $go install golang.org/dl/go@1.16.8 
> go install: golang.org/dl/go@1.16.8: unrecognized import path 
> "golang.org/dl/go": reading https://golang.org/dl/go?go-get=1: 404 Not Found 
>server response: 404 page not found
> ```


Try go install golang.org/dl/go1.16.8@latest which is documented here 
https://golang.org/doc/manage-install


-- 
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/2139ee47-d705-4308-b714-d7c76654252d%40www.fastmail.com.

Re: [go-nuts] Managing perpetually running goroutines

[Ian Davis]

On Sun, 29 Aug 2021, at 10:45 PM, sansaid wrote:
> Hello,
> 
> Does anybody know of some reference code or common patterns I can use to keep 
> track of worker goroutines? For context, I want a user to be able to issue a 
> "stop" command using a CLI tool which will prompt my server to gracefully 
> terminate one of my workers. 
> 
> For example, when a user issues a "start" command through a CLI tool, this 
> will signal my server to spawn a goroutine that perpetually runs and polls an 
> HTTP endpoint until a user initiates a "stop" command. When the user issues a 
> "stop" command through the same CLI tool, I want the server to be able to 
> signal the goroutine to stop. Any reference code would be much appreciated!
> 
> One approach I thought of was by passing a `context.WithCancel()` and holding 
> a reference to the cancel function in a global map (with the worker ID as 
> keys). When the user issues a "stop" command against the worker ID, another 
> function is executed which calls the context's cancel function. Example code 
> below (appreciate this is horrendously breaking a lot of rules, but I want to 
> focus only on the elements around passing the cancel function around - happy 
> to discuss anything else that is of concern to someone though):
> 
> ```
> // invoked when a CLI start subcommand is issued to my main CLI tool
> func (w *WorkerGroup) Start(ctx context.Context, id string) {
>   _, cancel := context.WithCancel(ctx)
> 
>   w.Workers.Lock()
>   w.Workers[id] := cancel
>   w.Workers.Unlock()
> 
>   go startWorker(id)
> }
> 
> // invoked when a CLI stop subcommand is issued to my main CLI tool
> func (w *WorkerGroup) Stop(id string) {
>   cancelWorker := w.Workers[id]
> 
>   cancelWorker()
> }
> ``` 
> 
> I have read that passing a context's cancel function around is a bad idea, 
> but in an example like this, is it justified?

Passing the cancel function is fine and storing it for use later is fine too.

-- 
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/0cbcbf2a-544c-409e-b39b-66464edc96ee%40www.fastmail.com.

[go-nuts] Are receiver copies atomic?

[Ian Davis]

This question came to me while reading the recent thread titled "Knowing from 
documentation whether an interface is holding a pointer or a struct?"

When a method with a non-pointer receiver is called, is the copy made 
atomically? My intuition says it must be but perhaps someone else can confirm 
it?

If so, how does it work? 

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/cb79c482-42ed-4213-9fc3-381f179e3fa6%40www.fastmail.com.

Re: [go-nuts] Re: Table-driven benchmarks defeat inlining

[Ian Davis]

Go does a good job of making it easy to do the right thing, especially in tests 
(such as parallel benchmarks or setting env variables), and avoiding the need 
for tricks like package level variables or noinline directives seems a useful 
feature.

On Mon, 7 Jun 2021, at 4:47 PM, peterGo wrote:
> Ian,
> 
> I don't know whether it is feasible. It is unnecessary.
> 
> A benchmark should be treated as a scientific experiment. If we do that with 
> Paul's benchmarks and write them in scientific form, then we get the expected 
> results.
> 
> $ benchstat xpt.txt
> name  time/op
> PopCountSimple-4  5.71ns ± 0%
> PopCountSlowSimple-4  5.70ms ± 0%
> PopCountAlmostSimple/BenchmarkPopCountAlmostSimple-4  5.70ns ± 0%
> PopCountNearlySimple/PopCountNearlySimple-4   5.69ns ± 0%
> $
> 
> Peter
> 
> 
> On Monday, June 7, 2021 at 6:14:05 AM UTC-4 Ian Davis wrote:
>> __
>> Would it be feasible for the Go tool to disable inlining and deadcode 
>> elimination of code within the bodies of Benchmarks and Tests? Not the code 
>> under test of course. It could be as crude as disabling these optimizations 
>> for files in _test.go files.
>> 
>> 
>> 
>> On Sun, 6 Jun 2021, at 1:33 PM, Paul S. R. Chisholm wrote:
>>> Thanks! I'd seen the "dead code elimination" comment somewhere and 
>>> questioned it, but not enough.
>>> 
>>> If I worry about what some future Go compiler might optimize, I end up 
>>> worrying quite a lot! For example, could this code:
>>> 
>>> func BenchmarkPopCountAlive(b *testing.B) {
>>> sum = 0
>>> for i := 0; i < b.N; i++ {
>>> sum += PopCount(0x1234567890abcdef)
>>> }
>>> }
>>> 
>>> hypothetically be optimized to:
>>> 
>>> func BenchmarkPopCountAlive(b *testing.B) {
>>> sum = PopCount(0x1234567890abcdef) * b.N
>>> }
>>> 
>>> since PopCount() always returns the same value for the same argument? It 
>>> probably wouldn't, since that would break many existing benchmarks.
>>> 
>>> Maybe more reasonably worrisome: If sum is initialized and incremented but 
>>> never read, could all references to it be optimized away? That's easy 
>>> enough to avoid, as is the optimization I worried about above:
>>> 
>>> var sum = 0 // Avoid dead code elimination
>>> const firstInput uint64 = 0x1234567890abcdef
>>> 
>>> func BenchmarkPopCountSimple(b *testing.B) {
>>> for i, input := 0, firstInput; i < b.N; i++ {
>>> sum += PopCount(input)
>>> input++
>>> }
>>> if sum == 0 {
>>> b.Error("BenchmarkPopCountSimple: sum == 0")
>>> }
>>> }
>>> 
>>> Here are my new benchmark results:
>>> 
>>> $ go version
>>> go version go1.16.5 windows/amd64
>>> $ go test -cpu=1 -bench=.
>>> goos: windows
>>> goarch: amd64
>>> pkg: gopl.io/popcount
>>> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
>>> BenchmarkPopCountSimple 2710047904.419 ns/op
>>> BenchmarkPopCountSlowSimple  278   4235890 ns/op
>>> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple 
>>> 2727591344.434 ns/op
>>> BenchmarkPopCountNearlySimple/PopCountNearlySimple  
>>> 1456130778.172 ns/op
>>> PASS
>>> ok  gopl.io/popcount7.061s
>>> 
>>> The anomalistically-low "simple" and "almost simple" results are now more 
>>> reasonable, but still nearly a factor of two lower than the "nearly simple" 
>>> results. They're still inlining the calls, as is the "slow simple" 
>>> benchmark, where the "nearly simple" one isn't:
>>> 
>>> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to 
>>> PopCount'
>>> .\popcount_test.go:10:18: inlining call to PopCount
>>> .\popcount_test.go:22:19: inlining call to PopCount
>>> .\popcount_test.go:34:19: inlining call to PopCount
>>> 
>>> Overkill, right? --PSRC
>>> 
>>> P.S.: For better or worse, I discovered I can -- but shouldn't, based on 
>>> the feedback I got! -- get "fancy" formatting by copying from vscode and 
>>> pasting into Gmail.
>>> 

Re: [go-nuts] Re: Table-driven benchmarks defeat inlining

[Ian Davis]

Would it be feasible for the Go tool to disable inlining and deadcode 
elimination of code within the bodies of Benchmarks and Tests? Not the code 
under test of course. It could be as crude as disabling these optimizations for 
files in _test.go files.



On Sun, 6 Jun 2021, at 1:33 PM, Paul S. R. Chisholm wrote:
> Thanks! I'd seen the "dead code elimination" comment somewhere and questioned 
> it, but not enough.
> 
> If I worry about what some future Go compiler might optimize, I end up 
> worrying quite a lot! For example, could this code:
> 
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
> 
> hypothetically be optimized to:
> 
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = PopCount(0x1234567890abcdef) * b.N
> }
> 
> since PopCount() always returns the same value for the same argument? It 
> probably wouldn't, since that would break many existing benchmarks.
> 
> Maybe more reasonably worrisome: If sum is initialized and incremented but 
> never read, could all references to it be optimized away? That's easy enough 
> to avoid, as is the optimization I worried about above:
> 
> var sum = 0 // Avoid dead code elimination
> const firstInput uint64 = 0x1234567890abcdef
> 
> func BenchmarkPopCountSimple(b *testing.B) {
> for i, input := 0, firstInput; i < b.N; i++ {
> sum += PopCount(input)
> input++
> }
> if sum == 0 {
> b.Error("BenchmarkPopCountSimple: sum == 0")
> }
> }
> 
> Here are my new benchmark results:
> 
> $ go version
> go version go1.16.5 windows/amd64
> $ go test -cpu=1 -bench=.
> goos: windows
> goarch: amd64
> pkg: gopl.io/popcount
> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
> BenchmarkPopCountSimple 2710047904.419 ns/op
> BenchmarkPopCountSlowSimple  278   4235890 ns/op
> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple 
> 2727591344.434 ns/op
> BenchmarkPopCountNearlySimple/PopCountNearlySimple  
> 1456130778.172 ns/op
> PASS
> ok  gopl.io/popcount7.061s
> 
> The anomalistically-low "simple" and "almost simple" results are now more 
> reasonable, but still nearly a factor of two lower than the "nearly simple" 
> results. They're still inlining the calls, as is the "slow simple" benchmark, 
> where the "nearly simple" one isn't:
> 
> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to PopCount'
> .\popcount_test.go:10:18: inlining call to PopCount
> .\popcount_test.go:22:19: inlining call to PopCount
> .\popcount_test.go:34:19: inlining call to PopCount
> 
> Overkill, right? --PSRC
> 
> P.S.: For better or worse, I discovered I can -- but shouldn't, based on the 
> feedback I got! -- get "fancy" formatting by copying from vscode and pasting 
> into Gmail.
> 
> 
> 
> On Tuesday, June 1, 2021 at 12:01:51 PM UTC-4 peterGo wrote:
>> Here is a more definitive reply than my original reply.
>> 
>> 
>> I got as far as this
>> func BenchmarkPopCountSimple(b *testing.B) {
>> sum := 0 // Avoid dead code elimination.
>> for i := 0; i < b.N; i++ {
>> sum += PopCount(0x1234567890abcdef)
>> }
>> }
>> 
>> As you can see from the objdump, BenchmarkPopCountSimple dead code is 
>> eliminated.
>> 
>> func BenchmarkPopCountSimple(b *testing.B) {
>>   0x4e38c031c9XORL CX, CX
>> 
>> for i := 0; i < b.N; i++ {
>>   0x4e38c2eb03JMP 0x4e38c7
>>   0x4e38c448ffc1INCQ CX
>>   0x4e38c74839889001CMPQ CX, 0x190(AX)
>>   0x4e38ce7ff4JG 0x4e38c4
>> }
>>   0x4e38d0c3RET
>> I added an additional BenchmarkPopCountAlive benchmark.
>> 
>> var sum = 0 // Avoid dead code elimination.
>> 
>> func BenchmarkPopCountAlive(b *testing.B) {
>> sum = 0
>> 
>> for i := 0; i < b.N; i++ {
>> sum += PopCount(0x1234567890abcdef)
>> }
>> }
>> 
>> As you can see from the objdump, BenchmarkPopCountAlive code is not 
>> eliminated.
>> 
>> For details, see the popcount.txt attachment.
>> 
>> Peter
>> 
>> 
>> On Monday, May 31, 2021 at 6:29:27 PM UTC-4 Paul S. R. Chisholm wrote:
>>> This is not a serious problem, but it surprised me. (By the way, how can I 
>>> post a message with code formatting?)
>>> 
>>> I'd like to create table-driven benchmarks:
>>> https://blog.golang.org/subtests.
>>> 
>>> To that end, I started with code from *The Go Programming Language*:
>>> 
>>> // PopCount is based on an example from chapter 2 of THE GO PROGRAMMING 
>>> LANGUAGE.
>>> // Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
>>> // License: https://creativecommons.org/licenses/by-nc-sa/4.0/
>>> 
>>> package popcount
>>> 
>>> // pc[i] is the population count of i.
>>> var pc [256]byte
>>> 
>>> func init() {
>>> for i := range pc {

Re: [go-nuts] time.ParseInLocation fails silently

[Ian Davis]

On Fri, 28 May 2021, at 11:32 AM, NieomylnieJa wrote:
> But the docs state something different:
> 
> // ParseInLocation is like Parse but differs in two important ways.
> // First, in the absence of time zone information, Parse interprets a time as 
> UTC;
> // ParseInLocation interprets the time as in the given location.
> // Second, when given a zone offset or abbreviation, Parse tries to match it
> // against the Local location; ParseInLocation uses the given location. 
> 
> The docs explicitly state that: "*ParseInLocation interprets the time *as in 
> the given location**". This behavior in conjunction with the docs were 
> confusing to me and a number of my coworkers, shouldn't they be updated? It's 
> not quiet straightforward that this line "*First, in the absence of time zone 
> information (...)*" refers to "ParseInLocation" too, the semicolon doesn't 
> help either, as the interpretation may differ: Merriam-Webster reference 
>  

I think those docs are clear: 

(1) in the absence of time zone information Parse assumes UTC but 
ParseInLocation uses the location's timezone.

(2) when a timezone is given Parse uses the Local (current) location to resolve 
the name of the timezone, but ParseInLocation uses the location passed. This 
allows local names for timezones to be resolved correctly. For example CST has 
several different possible meanings.

However Z is an unambiguous timezone - it always means UTC. So your example 
will use UTC for the timezone.

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/29e7e4d7-9e20-4a69-851c-0536df27ed0f%40www.fastmail.com.

Re: [go-nuts] Still "missing" priority or ordered select in go?

[Ian Davis]

On Thu, 29 Apr 2021, at 3:09 PM, robert engels wrote:
> I will give you the pseudo code:
> 
> { // step #1 do select on both
>select high
>select low
> }
> 
> if high read:
>return high
> else:
>// we read a low so do a high poll
>{
>select high:
>default:
>}
> 
>  if high read:
>   enqueue low and return high
>  else:
>   if queue empty:
>  return low
>   else:
>use queue and enqueue low from step #1 // FIFO order on low reads 
> 
> The above code will always return high values over low values (if high 
> available), and return low values in order of events

This seems likely deadlock if the low channel is being filled continually by 
another goroutine. In addition I usually aim to give ownership of the channel 
to the writer so it can close cleanly, but mixing reads and writes in a single 
function greatly complicates that.

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/f26ee7f2-a518-433f-89d4-d55aa0a9b07d%40www.fastmail.com.

Re: [go-nuts] Error handling

[Ian Davis]

On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote:
> Can someone please explain the benefit of ‘error return’ over ‘checked 
> exceptions’ ? I have made the point a few times and it goes to crickets 
> - I have to believe that is because there is none, or it is difficult 
> to communicate.
> 

I think since this is a Go list, the onus is on advocates of exceptions to 
demonstrate the benefit of checked exceptions over error return values.

Here are a couple of scenarios that I encountered recently that had logical 
linear flow with error returns. I'm curious how they would be improved with 
checked exceptions:

1) open three files for writing, closing the earlier ones if a subsequent one 
fails to open

2) open a file for append, falling back to creating a new writeable file if the 
original is read-only or doesn't exist. The new file creation may also fail due 
to disk errors or permissions.

I can envisage how to write them with exceptions but I'm struggling to see 
where it would be more succinct or easier to read.


-- 
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/9f3cf023-5bb4-49da-a842-0be97904d21a%40www.fastmail.com.

Re: [go-nuts] A value saved in an interface{} field in a struct not usable in func with interace{} arg

[Ian Davis]

This is highly unlikely to be a compiler issue. Note that there are more 
arguments in the stack trace than in the signature of your method so you can't 
assume correspondence by placement. It looks like the first two arguments in 
the stack trace are the type and value pointers for arg (which is interface{} 
which is a two slot composite type) and the second pair of arguments are both 
zero indicating an interface with a nil type and nil value, which is what I 
would expect if you had passed nil as the second argument to gen**Box

On Tue, 12 Jan 2021, at 3:16 PM, Steve Murphy wrote:
> Ian--
> 
> You missed the part about the arguments being "shifted left" above, which 
> kinda looks like a compiler issue. Maybe something I wrote contributed to the 
> problem, but I have no idea what.
> If this is a known problem, perhaps I can hand-install aa newer version, or 
> something...?
> 
> murf
> On Tuesday, January 12, 2021 at 7:52:40 AM UTC-7 Ian Davis wrote:
>> __
>> Note the error says that val was nil, so your type assertion will panic. You 
>> can read more about how to make type assertions that report success or 
>> failure in the Go Tour: https://tour.golang.org/methods/15
>> 
>> Have you tried printing the type of what you receive before attempting the 
>> type assertion? I suspect that the system you are working with is passing 
>> you a variety of different types depending on the context, so you'll need to 
>> be flexible in what you handle.
>> 
>> 
>> 
>> 
>> 
>> On Tue, 12 Jan 2021, at 5:55 AM, Steve Murphy wrote:
>>> Many thanks, Ian, I appreciate your suggestions!
>>> 
>>> I added your code snippet to my program, and got:
>>> 
>>> panic: interface conversion: interface {} is nil, not *interface {} 
>>> [recovered]
>>> panic: interface conversion: interface {} is nil, not *interface {}
>>> 
>>> According to the trace, it looks like it's crashing while trying to 
>>> evaluate the valDeref := line.
>>> 
>>> Looking at the trace provided:
>>> 
>>> genBox: arg type=*int64 argval=0xc1a150, val type=, val 
>>> val= offset=0
>>> genBox: box=
>>> --- FAIL: TestKd1 (0.09s)
>>> panic: interface conversion: interface {} is nil, not *interface {} 
>>> [recovered]
>>> panic: interface conversion: interface {} is nil, not *interface {}
>>> 
>>> goroutine 6 [running]:
>>> testing.tRunner.func1(0xc20200)
>>> /usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
>>> panic(0x523360, 0xcbc330)
>>> /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
>>> parsetree.com/kdtree.genBox(0x50eec0, 0xc1a150, 0x0, 0x0, 0x0, 0x2)
>>> /home/murf/go/kdtree/kdtree1_test.go:43 +0x43e
>>> 
>>> It kinda looks like the %T and %v aren't working for val; but the stack 
>>> trace shows 0xc1a150 in the second argument to genBox.
>>> 
>>> Uh, wait a minute! According to the stack, the first arg (called arg) is 
>>> 0x50eec0; but the debug output from genbox shows arg's val is 0xc1a150,
>>> which is what the second arg should be. So it looks like the args have 
>>> shifted to the left one position! And no errors on compilation?
>>> 
>>> I don't know what to think.
>>> 
>>> BTW, I'm on ubuntu 20.04, and the version of go is 1.13.
>>> 
>>> murf
>>> 
>>> On Monday, January 11, 2021 at 10:45:29 AM UTC-7 Ian Davis wrote:
>>>> __
>>>> In genBox your code is saying that val contains a pointer to interface{}. 
>>>> In other words its an interface{} that contains a *interface{}. That is a 
>>>> weird but valid construct.
>>>> 
>>>> I suggest you dereference it and see what the contained interface holds. 
>>>> Something like:
>>>> 
>>>> valDeref := val.(*interface{})
>>>> 
>>>>  fmt.Printf("val contains=%T", valDeref)
>>>> 
>>>> You may find that valDeref contains the *int64 you are looking for.
>>>> 
>>>> As an aside, *interface{} is usually an indication that someone somewhere 
>>>> is passing the wrong value to the function since it almost never makes 
>>>> sense to pass a pointer to interface{}.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mon, 11 Jan 2021, at 4:03 PM, Steve Murphy wrote:
>>>>> Hello!
>>>>> 
>>>>> I keep getting:
>>>>> panic: interface conversion: interface {}

Re: [go-nuts] A value saved in an interface{} field in a struct not usable in func with interace{} arg

[Ian Davis]

Note the error says that val was nil, so your type assertion will panic. You 
can read more about how to make type assertions that report success or failure 
in the Go Tour: https://tour.golang.org/methods/15

Have you tried printing the type of what you receive before attempting the type 
assertion? I suspect that the system you are working with is passing you a 
variety of different types depending on the context, so you'll need to be 
flexible in what you handle.





On Tue, 12 Jan 2021, at 5:55 AM, Steve Murphy wrote:
> Many thanks, Ian, I appreciate your suggestions!
> 
> I added your code snippet to my program, and got:
> 
> panic: interface conversion: interface {} is nil, not *interface {} 
> [recovered]
> panic: interface conversion: interface {} is nil, not *interface {}
> 
> According to the trace, it looks like it's crashing while trying to evaluate 
> the valDeref := line.
> 
> Looking at the trace provided:
> 
> genBox: arg type=*int64 argval=0xc1a150, val type=, val 
> val= offset=0
> genBox: box=
> --- FAIL: TestKd1 (0.09s)
> panic: interface conversion: interface {} is nil, not *interface {} 
> [recovered]
> panic: interface conversion: interface {} is nil, not *interface {}
> 
> goroutine 6 [running]:
> testing.tRunner.func1(0xc20200)
> /usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
> panic(0x523360, 0xcbc330)
> /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
> parsetree.com/kdtree.genBox(0x50eec0, 0xc1a150, 0x0, 0x0, 0x0, 0x2)
> /home/murf/go/kdtree/kdtree1_test.go:43 +0x43e
> 
> It kinda looks like the %T and %v aren't working for val; but the stack trace 
> shows 0xc1a150 in the second argument to genBox.
> 
> Uh, wait a minute! According to the stack, the first arg (called arg) is 
> 0x50eec0; but the debug output from genbox shows arg's val is 0xc1a150,
> which is what the second arg should be. So it looks like the args have 
> shifted to the left one position! And no errors on compilation?
> 
> I don't know what to think.
> 
> BTW, I'm on ubuntu 20.04, and the version of go is 1.13.
> 
> murf
> 
> On Monday, January 11, 2021 at 10:45:29 AM UTC-7 Ian Davis wrote:
>> __
>> In genBox your code is saying that val contains a pointer to interface{}. In 
>> other words its an interface{} that contains a *interface{}. That is a weird 
>> but valid construct.
>> 
>> I suggest you dereference it and see what the contained interface holds. 
>> Something like:
>> 
>> valDeref := val.(*interface{})
>> 
>>  fmt.Printf("val contains=%T", valDeref)
>> 
>> You may find that valDeref contains the *int64 you are looking for.
>> 
>> As an aside, *interface{} is usually an indication that someone somewhere is 
>> passing the wrong value to the function since it almost never makes sense to 
>> pass a pointer to interface{}.
>> 
>> 
>> 
>> 
>> 
>> On Mon, 11 Jan 2021, at 4:03 PM, Steve Murphy wrote:
>>> Hello!
>>> 
>>> I keep getting:
>>> panic: interface conversion: interface {} is *interface {}, not *int64 
>>> [recovered]
>>> panic: interface conversion: interface {} is *interface {}, not *int64
>>> 
>>> I *suspect* what is happening is that the KDElem struct has an item field 
>>> whose 
>>> type is interface{}, so that you can store a pointer to some struct (of 
>>> your own making),
>>> or an index into an array of structs, or... *whatever*, but in my case, 
>>> it's an index into an array
>>> of objects. The itemfunc (or genBox in my test code) is supposed to set the 
>>> item field in 
>>> the KDElem struct to the proper index, as the struct has just been created, 
>>> and the job
>>> of the itemfunc is to make it point to the right object, and set the bounds 
>>> info in the new struct.
>>> 
>>> type KdElem struct {
>>> item   interface{} // a ptr to a particular struct, or an index 
>>> into an array of objects, or
>>> ...
>>> }
>>> 
>>> And the func that calls the itemfunc (genBox) looks like this:
>>> 
>>> func loadItems(itemfunc func(arg interface{}, val interface{}, size *KdBox) 
>>> int, arg interface{}, extent KdBox, length *int64, mean *float64) *KdElem {
>>>  ...
>>>  newItem = new(KdElem)
>>>  if itemfunc(arg, , newItem.size) != 0 {
>>>  ...
>>> 
>>> 
>>> And, in this case the itemfunc declaration looks like this:
>>> 
>>> func genBox(arg interface{}, val interface{}, box *KdBox) int {
>>

Re: [go-nuts] A value saved in an interface{} field in a struct not usable in func with interace{} arg

[Ian Davis]

In genBox your code is saying that val contains a pointer to interface{}. In 
other words its an interface{} that contains a *interface{}. That is a weird 
but valid construct.

I suggest you dereference it and see what the contained interface holds. 
Something like:

valDeref := val.(*interface{})

 fmt.Printf("val contains=%T", valDeref)

You may find that valDeref contains the *int64 you are looking for.

As an aside, *interface{} is usually an indication that someone somewhere is 
passing the wrong value to the function since it almost never makes sense to 
pass a pointer to interface{}.





On Mon, 11 Jan 2021, at 4:03 PM, Steve Murphy wrote:
> Hello!
> 
> I keep getting:
> panic: interface conversion: interface {} is *interface {}, not *int64 
> [recovered]
> panic: interface conversion: interface {} is *interface {}, not *int64
> 
> I *suspect* what is happening is that the KDElem struct has an item field 
> whose 
> type is interface{}, so that you can store a pointer to some struct (of your 
> own making),
> or an index into an array of structs, or... *whatever*, but in my case, it's 
> an index into an array
> of objects. The itemfunc (or genBox in my test code) is supposed to set the 
> item field in 
> the KDElem struct to the proper index, as the struct has just been created, 
> and the job
> of the itemfunc is to make it point to the right object, and set the bounds 
> info in the new struct.
> 
> type KdElem struct {
> item   interface{} // a ptr to a particular struct, or an index into 
> an array of objects, or
> ...
> }
> 
> And the func that calls the itemfunc (genBox) looks like this:
> 
> func loadItems(itemfunc func(arg interface{}, val interface{}, size *KdBox) 
> int, arg interface{}, extent KdBox, length *int64, mean *float64) *KdElem {
>  ...
>  newItem = new(KdElem)
>  if itemfunc(arg, , newItem.size) != 0 {
>  ...
> 
> 
> And, in this case the itemfunc declaration looks like this:
> 
> func genBox(arg interface{}, val interface{}, box *KdBox) int {
>  var offsetp = arg.(*int64) // successful
>  var offset = *offsetp // successful
>  // fmt.Printf("genBox: offset=%v offsetp=%v\n", offset, offsetp)
>  fmt.Printf("genBox: arg type=%T argval=%v, val type=%T, val 
> val=%v\n", arg, arg, val, val)
>  if offset < KDBoxes {
>   fmt.Printf("genBox: val=%v  *int64=%v\n", val, val)
>   var realval *int64 = val.(*int64) //  <<-- This is line 43!  
> Compiles but... Crash!!!
>   *realval = offset + 1
> ...
> 
> Now, I get this from a go test:
> 
> KdBuild: arg type=*int64  argval=0xcd2078; 
> genBox: arg type=*int64 argval=0xcd2078, val type=*interface {}, val 
> val=0xcba640
> genBox: val=0xcba640  *int64=0xcba640
> --- FAIL: TestKd1 (0.08s)
> panic: interface conversion: interface {} is *interface {}, not *int64 
> [recovered]
> panic: interface conversion: interface {} is *interface {}, not *int64
> 
> goroutine 19 [running]:
> testing.tRunner.func1(0xc000108100)
> /usr/lib/go-1.13/src/testing/testing.go:874 +0x3a3
> panic(0x523360, 0xcc2360)
> /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
> parsetree.com/kdtree.genBox(0x50eec0, 0xcd2078, 0x50ef40, 0xcba640, 
> 0x0, 0x0)
> /home/murf/go/kdtree/kdtree1_test.go:43 +0x270
> parsetree.com/kdtree.loadItems(0x5570f8, 0x50eec0, 0xcd2078, 
> 0x7fff, 0x7fff, 0x8000, 
> 0x8000, 0xc00096ab38, 0xc00096ab30, 0x0)
> /home/murf/go/kdtree/kdtree.go:683 +0xec
> parsetree.com/kdtree.KdBuild(0x5570f8, 0x50eec0, 0xcd2078, 0x0)
> /home/murf/go/kdtree/kdtree.go:168 +0x17e
> parsetree.com/kdtree.TestKd1(0xc000108100)
> /home/murf/go/kdtree/kdtree1_test.go:72 +0x13a
> testing.tRunner(0xc000108100, 0x5570f0)
> /usr/lib/go-1.13/src/testing/testing.go:909 +0
> 
> How do I set realval to the (*int64) value that's in val?
> 
> murf
> 
> 
> -- 
> 
> Steve Murphy
> ParseTree Corporation
> 57 Lane 17
> Cody, WY 82414
> ✉  murf at parsetree dot com
> ☎ 307-899-0510
> 

> -- 
> 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/CAPPCp8HGQAcdw7J_vFLW8NKsXqfh5kgUtCrQn41dBLRamQggNA%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 

Re: [go-nuts] How to set the "godebug" environment variable from the go file?

[Ian Davis]

On Fri, 18 Dec 2020, at 4:18 PM, Sean wrote:
> My previous reply was sent to Ian. Sorry.
> The point I don't understand is "os.Args".
> I think the parameter here is the name of my program. So like "program.exe".
> 

Args is a variable in the os package. Go ensures that the the first element 
contains the name of the program.

-- 
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/6e4cde79-8729-4cf7-b144-afc259b19e6e%40www.fastmail.com.

Re: [go-nuts] How to plug git version when using "go get" to fetch a cli?

[Ian Davis]

The version is really a property of the code (and binary) not the repository. I 
think it's better to put the version in the code that is committed.

This is the approach taken by packages such as protobuf  
https://pkg.go.dev/google.golang.org/protobuf@v1.25.0/internal/version



On Wed, 25 Nov 2020, at 6:14 PM, changkun wrote:
> That is really unfortunate. Is there any alternative solution so that I can 
> burn at least the version information to the binary when a user uses `go get`?
> 
> On Wednesday, November 25, 2020 at 6:36:17 PM UTC+1 Jan Mercl wrote:
>> On Wed, Nov 25, 2020 at 6:25 PM changkun  wrote: 
>> 
>> > As far as I know, there are two approaches to add extra information at 
>> > build time: 
>> > 1. using -ldflags="-X path/pkg.Var=${ENV_VAR}", in a Makefile 
>> > 2. using `go generate ./...`, before `go build` 
>> > 
>> > These approaches are good as it is if I build my binary and distribute it 
>> > to other users. 
>> > However, none of these are possible if a user uses `go get 
>> > github.com/user/pkg/cmd/x-cli`, because: 
>> > 1. `go get` does not understand Makefile 
>> > 2. `go generate` does not execute with `go build` automatically. 
>> > 
>> > What should I do in order to plug the extra information (in my case, the 
>> > git version) if my user uses "go get"? 
>> 
>> I don't think that can be done. Also IINM, in module mode `go get` no 
>> longer uses git. It just downloads the zipped version of the 
>> appropriate tag via http from the hosting service. 
> 

> -- 
> 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/a628138a-cc0c-40db-afc4-141b14e3fbd1n%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/058e5bf4-2972-4569-b214-5d69bdddf9be%40www.fastmail.com.

Re: [go-nuts] Limiting the max heap size of a Go process

[Ian Davis]

On Wed, 25 Nov 2020, at 12:44 PM, Viktor Kojouharov wrote:
> 
> Hi,
> 
> Is there a way to set a hard limit on the max heap size a process is allowed 
> to consume, from within it?
> It's almost never a problem for a process to consume as much memory as is 
> available, however, I've ran into real-life cases in a k8s environment, where 
> a pod with a Go process will get evicted, when the pod approaches the memory 
> limit of the node it's on.
> 
> Reducing GOGC improves the situation, however it doesn't act as a limit. And 
> depending on the amount of data that's going through the process, it will 
> still get evicted when it saturates the memory. I could also slow the whole 
> process down, giving the GC even more time to reclaim the memory, but that 
> sounds like a big workaround.

You may be interested in this issue, which also links to several relevant ones  
https://github.com/golang/go/issues/42805

The short answer is that there is currently no way to set a hard limit but 
there are discussions in progress on the best approach to handle the situation 
you describe.




-- 
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/88cffd97-5e93-4e07-b59f-9e18c47ab94b%40www.fastmail.com.

Re: [go-nuts] Re: Getting syntax-error on from assignment in if statements

[Ian Davis]

On Thu, 15 Oct 2020, at 4:16 PM, Brian Candler wrote:
> It looks like a parsing ambiguity to me.  The error suggests that the 
> open-brace is being treated as the start of the body of the if-statement, i.e.
> 
> if v := T {
> }.F()
> 
> Try changing it to
> 
> if v == T{}.F(); v {}
> 
> and you'll get a different error: "syntax error: unexpected . at end of 
> statement"
> 

It is a parsing ambiguity and is mentioned in the specification towards the end 
of https://golang.org/ref/spec#Composite_literals

-- 
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/f9b1019b-5294-42f1-9177-dc72b7373e27%40www.fastmail.com.

Re: [go-nuts] How to find repeated string?

[Ian Davis]

On Wed, 19 Aug 2020, at 12:02 PM, Ian Davis wrote:
> 
> 
> On Wed, 19 Aug 2020, at 11:54 AM, Brian Candler wrote:
>> Or another thought - perhaps you are looking for *adjacent* repeats only?
>> 
>> In that case strings.Count doesn't help because it counts all occurrences, 
>> not just adjacent ones.
> 
> I suspect the OP is looking for the longest repeating substring.

Hmm, that's not correct. Sorry for the noise.

-- 
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/bbc89836-e955-45ed-aaa5-f06669128281%40www.fastmail.com.

Re: [go-nuts] How to find repeated string?

[Ian Davis]

On Wed, 19 Aug 2020, at 11:54 AM, Brian Candler wrote:
> Or another thought - perhaps you are looking for *adjacent* repeats only?
> 
> In that case strings.Count doesn't help because it counts all occurrences, 
> not just adjacent ones.

I suspect the OP is looking for the longest repeating substring.

-- 
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/7de9-dca1-483a-86ca-7695f59dd0f2%40www.fastmail.com.

Re: [go-nuts] Sum type experiment

[Ian Davis]

On Tue, 11 Aug 2020, at 3:38 PM, Sina Siadat wrote:
> Hi golang-dev :)
> 
> I was wondering what would be an idiomatic Go way
> to implement a basic sum type in Go. After several
> iterations I came up with 2 approaches I will share here.

You may be interested in the discussions on 
https://github.com/golang/go/issues/19412 if you haven't already seen them.

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/6e9619d0-d232-4d2b-85b9-1ef5e3bf2634%40www.fastmail.com.

Re: [go-nuts] Go 2 review process

[Ian Davis]

On Sun, 19 Jul 2020, at 2:08 AM, Ian Lance Taylor wrote:
> On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton  wrote:
> >
> > I'm beginning to think that community members (like myself) can't 
> > reasonably be expected to put in the necessary effort to champion a sizable 
> > language change. I think it was Ian who made multiple generics draft 
> > proposals just to reject them himself, then Ian and Robert Griesemer spent 
> > more untold hours writing the contracts draft design only to have that 
> > rejected as well. For people outside the core Go team, these probably would 
> > have been unpaid hours. It's hard to justify spending that kind of time 
> > when there's such a high chance that the proposal may not amount to 
> > anything. I think it's for this reason that community proposals are usually 
> > nowhere near as fleshed out as the draft proposals we've been getting from 
> > the core team.
> 
> In fairness, though, there is no language change proposal that is as
> large as generics.  The changes that were made in recent releases were
> much smaller.  (And, for what it's worth, they did not all come from
> Googlers; e.g., https://golang.org/issue/12711,
> https://golang.org/issue/19308, https://golang.org/issue/29008.)
> 

I think the multidimensional slices proposal 
(https://github.com/golang/go/issues/6282 and several spawned from there) is an 
example of a major proposed change that the community put great effort into 
with multiple detailed specifications. There is an asymmetry of time and 
expertise at play here. I suspect many people would use and benefit from native 
matrices in Go but the number of people with the necessary skills to design the 
spec and the amount of available time to devote to it is vanishingly small. 

We need a way for knowledgable experts to be able to take a sabbatical or 
similar to spend time refining and guiding their proposal with the Go team. Is 
this something that the Go project or another corporate sponsor could help 
with? 

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/37ed3f4e-460f-48b6-a636-61d3eadc5c8a%40www.fastmail.com.

Re: [go-nuts] the go archive size must be smaller？

[Ian Davis]

Note that progress for reducing binary size is tracked under this issue: 
https://github.com/golang/go/issues/6853

-- 
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/83d2930f-347d-41a0-b8cd-f0b51ba22e5a%40www.fastmail.com.

Re: [go-nuts] Clean shutdown when blocked on I/O

[Ian Davis]

Can you write your own ContextReader that checks ctx.Done in its Read method?

On Mon, 6 Jul 2020, at 2:40 PM, Brian Candler wrote:
> I am looking for the safe way to do a clean shutdown when blocked on I/O. 
> Here is a basic example:
> 
> package main
> 
> import (
> "encoding/json"
> "fmt"
> "io"
> "os"
> "os/signal"
> "syscall"
> )
> 
> func main() {
> rx := json.NewDecoder(os.Stdin)
> 
> chanTERM := make(chan os.Signal, 1)
> signal.Notify(chanTERM, syscall.SIGTERM)
> 
> for {
> select {
> case <-chanTERM:
> fmt.Println("Shutdown requested via signal")
> os.Exit(0)
> default:
> }
> 
> var msg interface{}
> 
> err := rx.Decode()
> if err != nil {
> if err == io.EOF {
> os.Exit(0)
> }
> fmt.Printf("Error: %v\n", err)
> os.Exit(1)
> }
> fmt.Printf("Message: %v\n", msg)
> }
> }
> 
> This sort-of works, except that once the code is blocked in rx.Decode(), 
> the termination signal is not handled until another message arrives. 
> (Actually I'm using sockets - os.Stdin is just for example here). I'd like it 
> to shutdown immediately if it's not in the middle of doing something.
> 
> The question is then how to unblock this reader.
> 
> 1. Is there a way to link an io.Reader to a context, so I can just send the 
> ctx.Done() signal? If so, I couldn't find it.
> 
> (I found this post 
> ,
>  but the library 
>  has the 
> same issue: the context is checked before the read, but a cancel won't 
> unblock the read)
> 
> 2. I can just close the input stream from another goroutine. This seems 
> fairly brutal. Also, to distinguish this condition from an actual error, it 
> seems I need to parse the error message and look for the text "use of closed 
> network connection" (github: #4373 )
> 
> 3. I can move the rx.Decode() into a goroutine which passes a message 
> over a channel, and just let it lock up if there's no data coming in. This 
> isn't a problem here where I want to exit the entire program. If this was a 
> network server with many connections and I wanted to disconnect just one, 
> then I think I'd end up having to close the channel anyway to disconnect the 
> client.
> 
> Is there another option I should be looking at?
> 
> Thanks,
> 
> Brian.
> 

> --
>  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/3f3b6f98-ff9c-4829-844b-a0d0abc5d753o%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/d1c9f0d0-dbb3-4730-997d-2e13155509b6%40www.fastmail.com.

Re: [go-nuts] Is there +v Stringer interface?

[Ian Davis]

fmt.Formatter is woefully under documented. The second argument (called c in 
the interface definition) is the verb, i.e. 's', 'v', 'd' etc. The first 
argument provides a state interface with functions to allow you to emit the 
format of your type. The Flag function on this interface lets you test the type 
of format requested. Despite this being an int (also confusingly called c) it's 
actually a character, i.e. '#', '+', ' ' etc.

So if someone writes fmt.Sprintf("%+v", yourtype) you will be passed 'v' as the 
verb and you must call Flag('+') to test if the caller wants the '+' form.

On Wed, 24 Jun 2020, at 10:32 PM, 'Ian Cottrell' via golang-nuts wrote:
> You want to implement fmt.Formatter 
> .
> In general I prefer implementing Formatter to either Stringer or GoStringer 
> if I am only doing it for printing, even for the simple cases, as I feel it 
> better reflects the intent.
> I reserve implementing the String method for when I really do want to be able 
> to access the value programmatically as a string and it is possible to do so 
> in a way that is more efficient than printing it.
> 
> On Wed, Jun 24, 2020 at 4:33 PM yves baumes  wrote:
>> When I want to override the '%v' format, I declare a String() method.
>> When I want to override the '%#v' format, I declare a GoString() method.
>> 
>> But there is nothing about '%+v'? There is no PlusStringer() method ?
>> 
>> Let's take the following exemple, the %v and %+v formatter prints the exact 
>> same results. Which is annoying somehow.. 
>> 
>> ```
>> package main
>> 
>> import ("fmt")
>> 
>> type page struct {
>> title string
>> body []byte
>> }
>> 
>> func (p *page) String() string {
>> return fmt.Sprint("{ ", p.title, " ", string(p.body), " }")
>> }
>> 
>> func main() {
>> const title = "helloworld"
>> const text = "Hello everyone"
>> p := {title: title, body: []byte(text)}
>> log.Printf("p = %v", p) // prints p = { helloworld Hello everyone }
>> log.Printf("p = %+v", p) // prints p = { helloworld Hello everyone }
>> log.Printf("p = %#v", p) // prints p = {title:"helloworld", 
>> body:[]uint8{0x48, 0x65, 0x6c, [etc]
>> }
>> 
>> ```
>> 
>> Any clue on how to adapt the String() method to print the fields names?
>> 
>> 
>> 
>> 

>> --
>>  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/2506ab0c-5558-4c72-8ad4-a8ad0006ea08o%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/CAA%3DsxTiLGqBsJh2Kv_PBcCZ0hHZ2zAmLoGibKfbrvtBCR7eeUg%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/a62e5292-1497-47a9-9070-978b153b163b%40www.fastmail.com.

Re: [go-nuts] url.QueryEscape unexpectedly slow

[Ian Davis]

Don't use a byte for your loops, use an int.

When your loop reaches 255 it is incremented to 0 which is still <= 255 so your 
loop never terminates.

On Mon, 25 May 2020, at 10:54 PM, Liam wrote:
> I would expect this to complete pretty quickly, but after 40 minutes (on 
> 1.13, linux/amd64), it hasn't printed a thing.
> 
> I'm following up a report of panic in QueryEscape: 
> https://github.com/golang/go/issues/38643
> 
> package main
> 
> import (
>  "net/url"
>  "fmt"
> )
> 
> func main() {
>  for a := byte(0); a <= 255; a++ {
>  if (a+1) % 8 == 0 { fmt.Println(a) }
>  for b := byte(0); b <= 255; b++ {
>  _ = url.QueryEscape(string([]byte{a,b}))
>  }
>  }
> }
> 

> --
>  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/17295814-834f-47a2-b6fb-76bbf4f5f95b%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/ba3881c4-30dd-4d64-b268-86176e4c02f7%40www.fastmail.com.

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

[Ian Davis]

If the purpose of adding "killer features" is just to make Go more popular then 
I'm completely against it. That doesn't seem like a sustainable way of growing 
and retaining a community, who may just move onto the next killer feature in 
another language. I'm not even sure that explicitly growing Go's attention 
should even be a goal. People will use Go when it fits the problems they need 
to solve.

I don't personally see any slowdown in Go's adoption in the areas I'm working 
in which is high scale web services. 

On Thu, 16 Jan 2020, at 11:12 AM, JuciÊ Andrade wrote:
> Liam has a point. Go is not attracting attention as it used to do. Go ceased 
> to generate news.
> 
> Other projects attracts attention by aggregating new features often. So there 
> is always a flux of news about the project, news that attracts interest, that 
> bring new users to the project. However, that approach ultimately leads to 
> disaster. Each new wave of developers want to employ the latest and greatest 
> features and after some years you end up with a nightmare in form of millions 
> of lines of source code using a plethora of competing techniques.
> 
> The minimalism in Go is its strength, but few people are mature enough to 
> appreciate that. So what now?
> 
> I think we need to add a killer feature now and then. Not so often as to 
> create a nightmare, but only a few, very sparse. Such a feature would be 
> something that is very desirable but utterly difficult to achieve, something 
> that only a selected group of the best professionals in the world backed by 
> one of the biggest tech companies in the world could make.
> 

> --
>  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/e14daa6c-b55b-43a4-9af8-f983057ba0ab%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/e18ab6a7-1c8b-44fc-a83c-d292d4befaf6%40www.fastmail.com.

Re: [go-nuts] Language spec question: why is k, v := k, v allowed in a for loop with range?

[Ian Davis]

The range clause introduces a new scope. See this version of your second 
example: https://play.golang.org/p/UXI_w6B4DW5

-- Ian

On Sun, 12 Jan 2020, at 8:09 AM, Silvan Jegen wrote:
> Hi fellow gophers
> 
> The following code compiles
> 
> 
> package main
> 
> import (
>   "fmt"
> )
> 
> func main() {
>   mymap := map[string]int{"a": 1, "b": 2}
>   for k, v := range mymap {
>   k, v := k, v
>   fmt.Printf("k %s, v: %d\n", k, v)
>   }
> }
> 
> 
> while this one doesn't.
> 
> 
> package main
> 
> import (
>   "fmt"
> )
> 
> func main() {
>   a := 1
>   b := 2
>   a, b := a, b
>   fmt.Printf("a %d, b: %d\n", a, b)
> }
> 
> 
> I looked at the language spec and for the ':=' (the "walrus operator") in
> the "Short variable declarations"[0] section the spec says the following.
> 
> "Unlike regular variable declarations, a short variable declaration
> may redeclare variables provided they were originally declared earlier
> in the same block (or the parameter lists if the block is the function
> body) with the same type, and at least one of the non-blank variables is
> new. As a consequence, redeclaration can only appear in a multi-variable
> short declaration."
> 
> This explains why the second example doesn't compile since none of the
> variables in the second short variable declaration is new.
> 
> The same is true for the first example however and this one compiles
> just fine (even when using a short variable declaration on only one
> variable like in 'k := k' which shouldn't be allowed either according
> to this quote).
> 
> The only explanation for this that I could come up with after being asked
> about this case is that the variables declared in the range clause are
> a special case, the so called "iteration variables" according to the
> "For statements" section[1]. The spec does not mention this but for
> these "iteration variables" the rules for the regular short variable
> declaration don't seem to uply. If that is indeed the case, I wonder if
> the spec shouldn't be updated to reflect this.
> 
> Is this really the case or am I missing something?
> 
> 
> Cheers,
> 
> Silvan
> 
> 
> [0] https://golang.org/ref/spec#Short_variable_declarations
> [1] https://golang.org/ref/spec#For_statements
> 
> -- 
> 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/3L6DOOAAM4RP6.2NDJ7GRYRRO2B%40homearch.localdomain.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e61675a2-7e2e-449b-b443-cc6487d9cfe5%40www.fastmail.com.

Re: [go-nuts] Locking goroutine to "main" thread

[Ian Davis]

On Sat, 14 Dec 2019, at 7:51 PM, bucha...@gmail.com wrote:
> If I understand correctly, that would prevent me from starting any other 
> goroutines. The following program deadlocks:

I doesn't prevent you starting other goroutines but you need to ensure that all 
calls to the OpenGL context are performed on the thread you initialised it with 
(my understanding is that this is because OpenGL uses thread local storage). 
Typically you can do this by sending closures containing OpenGL calls via a 
channel to an executor running in a goroutine locked to the main thread. There 
is/was an example of this in the gomobile codebase. I can share more detail if 
you get stuck.

-- 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/0adcdc5a-dd2c-4506-9110-a3ecabc508b9%40www.fastmail.com.

Re: [go-nuts] How to mock structs with interdependent interface methods?

[Ian Davis]

On Thu, 12 Dec 2019, at 10:27 PM, karthik3...@gmail.com wrote:
> Specifically, I couldn't find how to partially mock the `struct`. Most 
> suggestions revolve around breaking such `struct`s but in this case, the 
> `struct` is already at its bare minimum. It seems like a fair ask to not 
> break the `ResourceManager` interface (into single and multi) for the sake of 
> testing as that would not make much sense and would be kludgy at best and 
> wouldn't scale well as more such methods make into the interface.


I think your problems likely stem from having interfaces that are too large. 
Interfaces in Go are more flexible than in many other languages since there is 
no "implements" keyword that binds a struct to a particular interface. This 
means that you can have many more specialised interfaces that your struct may 
automatically satisfy.

One consequence of this is that In Go it is usually preferable to define the 
interface where it is consumed instead of where the implementations are. This 
tends to make interfaces smaller, having just the methods needed for the 
consumer. It also implies that testing via the interface is the wrong approach.

First write your tests against the struct to verify that getting one or all 
resources work. Break the interface into smaller specialised ones and move them 
next to the consuming code. In your case you may have an endpoint that uses a 
GetResource method, so you define that interface. Another endpoint may need 
just the GetAllResources method: another interface. You can then test your 
endpoints by supplying a test struct that implements the smaller interface 
needed.


-- 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/a7c46809-bb03-442b-9297-81cb588df72e%40www.fastmail.com.

Re: [go-nuts] Inconsistent rounding with float printf ?

[Ian Davis]

On Fri, 6 Dec 2019, at 9:25 AM, Christophe Meessen wrote:
> I have noticed that printf performs an apparently inconsistent rounding of 
> floating point values.
> 
> I divide a big number by 1000 and printf the resulting value with "%.1f".
> Here is the code: https://play.golang.org/p/e7dD3c6IHq2

I think you are just seeing the usual problems of floating point 
representation. 

You may wonder why 999450/1000=999.45, 999500/1000=999.50 and 
999550/1000=999.55 all format as 999.5. The answer is that the internal 
representation of the three results cannot correspond to the mathematical 
result you expect.

This link shows the internal representation of each answer: 
https://play.golang.org/p/bBTNCdsAttR

You can see that 999550/1000 = 999.5499954525264911353588104248046875 
which is printed as 999.5


> I would expect the rounding rule to be "round away from zero" as defined 
> here: https://math.stackexchange.com/a/2252888/33796
> In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 to 
> -0.1). 

The strconv and fmt packages use round to even as a rule. Use math.Round to 
round away from zero.

-- 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/ee94624c-5485-4daf-98ad-8e59055056dd%40www.fastmail.com.

Re: [go-nuts] Re: [golang-dev] go.dev is live!

[Ian Davis]

On Thu, 14 Nov 2019, at 4:54 AM, Dan Kortschak wrote:
> Hi,
> 
> It looks like license detection needs work.
> 
> See https://pkg.go.dev/gonum.org/v1/gonum?tab=overview and note it has
> a BSD 3 clause, as shown by GitHub's assessment (just above the "Clone
> or download" button) at https://github.com/gonum/gonum and the LICENSE
> file that it links to.
> 

It does seem that something is amiss with license detection. For example Github 
detects the use of the UNLICENSE just fine for https://github.com/iand/salience 
but go.dev misses it completely and refuses to display the readme. 

-- 
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/625cb68d-116d-4b17-a251-94d6ae9b208a%40www.fastmail.com.

Re: [go-nuts] Forking gotk3 not working?

[Ian Davis]

On Tue, 24 Sep 2019, at 11:02 AM, erich.r...@gmail.com wrote:
> Hi! This is perhaps more a question about git than Go but must have something 
> to do with go get, too. I tried to fork gotk3 from github on the web page 
> (using Fork button), because I need to merge some important 3rd party pull 
> requests and the maintainer is no longer active.
> 
> However, after creating a fresh fork and without making any changes, if I add 
> the repo into an import statement, go get -u fails with the message: cannot 
> load github.com/rasteric/gotk3/gtk: zip: not a valid zip file

I don't know what would cause this specific error. I suspect it is emitted by 
this code 
https://github.com/golang/go/blob/master/src/cmd/go/internal/modload/build.go#L240
 which points to it being a problem with your local package cache, perhaps an 
interrupted download. Try running go clean --modcache and see if that fixes it.

I got the example from the readme to almost work by copying it into a main.go, 
editing the import to refer to your fork, running go mod init and adding this 
to the go.mod:

replace github.com/gotk3/gotk3 => github.com/rasteric/gotk3 GOTK3_0_3_0

It fetches the module but fails with some compile errors but at least it looks 
like it could work in theory:

09:42 $ go get -u -v
go: finding github.com/gotk3/gotk3 latest
github.com/rasteric/gotk3/gtk
# github.com/rasteric/gotk3/gtk
../../pkg/mod/github.com/rasteric/gotk3@v0.0.1/gtk/glarea.go:146:33: undefined: 
gdk.GLContext
../../pkg/mod/github.com/rasteric/gotk3@v0.0.1/gtk/glarea.go:152:11: undefined: 
gdk.GLContext
../../pkg/mod/github.com/rasteric/gotk3@v0.0.1/gtk/gtk_since_3_8.go:46:52: 
undefined: gdk.FrameClock
../../pkg/mod/github.com/rasteric/gotk3@v0.0.1/gtk/widget_export_since_3_8.go:25:3:
 undefined: gdk.WrapFrameClock
../../pkg/mod/github.com/rasteric/gotk3@v0.0.1/gtk/widget_since_3_8.go:58:35: 
undefined: gdk.FrameClock
../../pkg/mod/github.com/rasteric/gotk3@v0.0.1/gtk/widget_since_3_8.go:60:9: 
undefined: gdk.WrapFrameClock

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/5e6db676-282d-4647-9dcf-3241f480ca47%40www.fastmail.com.

Re: [go-nuts] Cannot find libraries at go.pedge.io by Peter Edge

[Ian Davis]

On Tue, 24 Sep 2019, at 10:48 PM, Craig Rodrigues wrote:
> I have a package where the dependencies were vendored in a few years ago 
> using govendor.
> 
> I am trying to convert the vendor tree from govendor to go modules.
> 
> I a having problems finding libraries written by Peter Edge,
> which had a DNS entry of go.pedge.io:
> 
>  "path": "go.pedge.io/env",
>  "path": "go.pedge.io/lion",
>  "path": "go.pedge.io/lion/current",
>  "path": "go.pedge.io/lion/env",
>  "path": "go.pedge.io/lion/grpc",
>  "path": "go.pedge.io/lion/syslog",
>  "path": "go.pedge.io/pb/go/google/protobuf",
>  "path": "go.pedge.io/pkg/cobra",
>  "path": "go.pedge.io/proto/time",
> 
> go.pedge.io does not seems to resolve in DNS for me.
> 
> Also https://github.com.com/peter-edge does not point to a valid GitHub 
> account.
> 
> For this particular case where:
> 
> 1. dependencies were vendored in a few few years ago using govendor
> 2. I want to convert from govendor to go modules, and rebuild the vendor tree
> 
> What should I do?

It sounds like you have the source code in your current vendor folder. If the 
license is permissive you could copy the code to new packages in your own 
codebase. Or you could republish the code you need in your own github repo and 
then update your go.mod to replace references to those packages to their new 
location. .

Either way you need to find replacements for them. The new Go proxy 
infrastructure will make this situation less common in the future.

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/5c596118-2f4d-4519-b1c2-ddf82694563f%40www.fastmail.com.

Re: [go-nuts] GO Mod (modules) for dummies. Please help.

[Ian Davis]

Hi,

On Mon, 23 Sep 2019, at 11:04 AM, sdd.dav...@gmail.com wrote:
> 
> If I have a reasonably large and complex (pet) project with local packages in 
> it. I like to split my project in to small units with 'namespaces' to keep it 
> manageable. These are NOT reusable components until I decide they qualify and 
> publish on Github.

>  * Why MUST I import them as if they are from github and then 'replace' them, 
> and if I don’t 'MUST' then you have failed to explain this feature to me!

Can you provide an example of what you are doing or a link to the documentation 
that is telling you to do this?

Every module in Go has a name and when you have modules in different locations, 
even just peer directories on your local machine, you need to write the mapping 
in go.mod between the name of the module and its location. For example, I have 
a non-public library that is used by another module on my machine. I have this 
in my go.mod to link the two together without needing to publish the library: 
replace ian.local/tools => ../tools


>  * My local packages are part of my application. They are, I agree still 
> 'dependencies' but they are not 'DEPENDENCIES' that I need (or even want) to 
> import from a repository. They are part of my project.

That's fine. Packages that are in subdirectories are usually simply part of the 
parent module. However you still need to name them so you can import them in 
your code. The pattern is that each package name is appended to the module name 
like a path, so in my example above a subpackage of tools would be referred to 
as ian.local/tools/subpackage


>  * What if I do not want to host my project on a GIT repo (Shock horror!).
The go tool also supports Bazaar, Fossil, Mercurial and Subversion. See 
https://golang.org/cmd/go/#hdr-Remote_import_paths



>  * Why do all imports start with github.com. Is that a requirement, what is 
> the rational for this.

It is not a requirement. You are simply seeing the consequences of 90% of 
packages being hosted there. You may also commonly see packages hosted at 
golang.org, gopkg.in, bitbucket.org and many others. There are no restrictions 
and you can host on your own domain. 


>  * How does a 'import' resolve its 'reference'.

The go tool uses go.mod to find out how to resolve a package name. Usually it 
simply maps directly to a remote repository (in which case go.mod will also 
contain some version information) but it could also map to another compatible 
package or to a location on your local machine.


>  * Should I add the go.mod and go.sum files to my repository or should the 
> developer who cloned my project have to do a go mod init (bummer!).
> 

You should do it. Give your module a name so people know what to use when 
importing it. As far as I know the only restriction is that the name must have 
a dot in it. By convention people name their modules with the repository name 
but that is not required. If you don't plan to share your code then you can 
make up a name like I did above: example.local works for instance.


> *Can someone please explain, properly!*

I feel your pain! Modules are conceptually simple (a collection of related 
packages) but the interactions with code repositories, tools, build systems and 
user expectations are phenomenally complicated. The documentation is 
comprehensive and extensive but still misses some important "getting started" 
information. If you have specific requirements or problems with it then raising 
an issue for the Go team to track would be useful.

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/66c4b89f-d0bd-43d7-b46f-77c9be680092%40www.fastmail.com.

Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400

[Ian Davis]

On Tue, 20 Aug 2019, at 9:33 AM, changkun wrote:
> Hi Robert,
> 
> Thanks for your explanation. But how could I "logged the number of operations 
> done per Go routine", which particular debug settings you referring to?
> It is reasonable that sync.Mutex rely on runtime scheduler but channels do 
> not. However, it is unclear why a significant performance drop appears. Is it 
> possible to determine when the performance will appear?

This comment by Dmitry Vyukov on a very old issue might help (I have no idea if 
it is still valid after 6 years though) 

If you are interested why chan does not have the same issue, runtime handles 
chan's in a
special way (active/passive spinning + thread parking instead of goroutine 
parking),
because it knowns that the critical section is bounded and small. For 
sync.Mutex it does
not have any knowledge as to critical section size.

See https://github.com/golang/go/issues/5183

-- 
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/55e8058b-cf7e-40c5-a81e-c3643a4ba507%40www.fastmail.com.

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

[Ian Davis]

On Fri, 16 Aug 2019, at 7:09 PM, dr.ch.mau...@gmail.com wrote:
> Dear Community and dear Go-developers,
> 
> Meanwhile it is clear why things do not work:
> The Go-Scheduler is unable to allow to switch to another goroutine in 
> busy-waiting-loops -
> the only possibility to get around that problem is either to put 
> "switch-steps" into the source
> - either "time.Sleep(1)" or "runtime.Gosched()".
> I think that THIS SHOULD BE DOCUMENTED IN THE LANGUAGE SPECIFICATION !

I don't believe this is a language issue. Different compiler implementations 
could support pre-emption if they chose to.

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/1d53eed0-2702-450c-a3bd-50473c98b862%40www.fastmail.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Ian Davis]

On Fri, 9 Aug 2019, at 3:33 PM, Jonathan Hall wrote:
> *I debated posting here, or straight to GitHub. If that's the better place, I 
> can move the thread there. * I have long wanted proper streaming support in 
> the `encoding/json` library. Lately I’ve been doing some digging to 
> understand the current state of things, and I think I’ve come to grips with 
> most of it.

> 
> A number of previous issues relate to this topic: 
> https://github.com/golang/go/issues/7872, 
> https://github.com/golang/go/issues/11046, 
> https://github.com/golang/go/issues/12001, 
> https://github.com/golang/go/issues/14140

> 
> I have read through each of these issues, and believe I have a fair 
> understanding of the problems associated with streaming JSON input/output. If 
> I'm overlooking something please enlighten me.

> 
> In a nutshell: The library implicitly guarantees that marshaling will never 
> write an incomplete JSON object due to an error, and that during 
> unmarshaling, it will never pass an incomplete JSON message to 
> `UnmarshalJSON`.

> 
> Work toward this was done about 3 years ago, on this CL: 
> https://go-review.googlesource.com/c/go/+/13818/

> Workt was eventually abandoned, apparently when the author was unsure how to 
> make the new behavior opt-in. I believe this proposal will solve that issue.


You may also be interested in a CL I created last year to add an unbuffered 
write mode to the encoder

https://go-review.googlesource.com/c/go/+/135595

I think I addressed all the review comments but it stalled behind a tangential 
issue around the current version's use of sync.Pool 
https://github.com/golang/go/issues/27735

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/70e5a2a1-70bf-4917-81c5-6504e110d9b2%40www.fastmail.com.

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

[Ian Davis]

On Tue, 9 Jul 2019, at 11:43 AM, Nicolas Grilly wrote:
> 
>> So why complicate the language with a new keyword which has really no 
>> purpose.
> 
> As mentioned in the proposal, try is not a new keyword, it's just a new 
> built-in function.

It's quite a bit more than a just new function since it brings some new 
behaviours that we don't have for functions in Go at the moment:

1. like panic it interrupts its caller's control flow

2. It may only be used within functions/methods that have a particular 
signature. Presumably it's a compile error to attempt to use it elsewhere.

3. It accepts any number of mixed type arguments without boxing into an 
interface{}

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/02225c85-a48d-4fde-b067-b94d863f4d24%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A proof-of-concept implementation of my generics proposal for Go

[Ian Davis]

Syntactically this looks very good. I have read your gist but I'd like to see 
this as a proposal in the Go issue tracker.

Ian


On Thu, 27 Jun 2019, at 3:29 PM, Michal Strba wrote:
> Hey everybody!
> 
> A few weeks ago, I posted about my proposal for generics in Go 2. You can 
> find it here. 
> 
> 
> Today, I finished a proof-of-concept implementation. It was a lot of fun and 
> I learned a lot about the internals of Go.
> 
> The implementation is a program that takes a Go file that uses generics and 
> translates it to a regular Go file that you can run.
> 
> Try it out here :) 
> 
> I'm looking forwad to all your feedback!
> 
> Michal Štrba
> 

> --
>  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/0a042b10-acdc-48e1-80f6-cd05b4f687c8%40googlegroups.com
>  
> .
>  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5653ff15-8adc-4c45-8aec-ce3f48c07cb0%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Ian Davis]

Yes, I wrote minimum when I meant to write maximum! Sorry for the confusion.

On Tue, 11 Jun 2019, at 3:37 PM, t hepudds wrote:
>  As far as I understand, it is not a minimum version of the language. 
> 
>  Also, a key point that is easy to miss is that the language version is 
> distinct from tooling version, and newer tooling versions will know how 
> to compile older language versions. At least, that is my understanding, 
> though I am also aware there is some confusion on the topic, so I don’t 
> fully trust my understanding. 
> 
> Some related text from the document Ian cited:
> 
> ———
> The Go compiler released with Go version 1.20 must be able to build 
> packages using Go language 1.19. This can be done by adding an option 
> to cmd/compile [...]. When cmd/compile sees the option, perhaps 
> -lang=go1.19, it will compile the code using the Go 1.19 syntax.
> 
> Importantly, specifying the maximum version of the Go language should 
> not be taken to imply the maximum version of the Go tools.
> 
> [...]
> 
> When cmd/compile sees the option, perhaps -lang=go1.19, it will compile 
> the code using the Go 1.19 syntax.
> This requires cmd/compile to support all previous versions, one way or 
> another.
> 
> [...]
> 
> Naturally, even though the package is built with the language version 
> 1.19 syntax, it must in other respects be a 1.20 package: it must link 
> with 1.20 code, be able to call and be called by 1.20 code, and so 
> forth.
> 
> The go tool will need to know the maximum language version so that it 
> knows how to invoke cmd/compile. Assuming we continue with the modules 
> experiment, the logical place for this information is the go.mod file. 
> The go.mod file for a module M can specify the maximum language version 
> for the packages that it defines
> ——
> 
> Regards,
> thepudds
> 
> -- 
> 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/810a1cb4-c3fb-4b2f-bc86-02793902d422%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4e18d45a-4382-4ab3-8d9a-e57aa402ecfb%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Ian Davis]

https://golang.org/cmd/go/#hdr-The_go_mod_file documents the go directive as 
the "expected language version".  It seems it would be better described there 
as the "minimum language version".


On Tue, 11 Jun 2019, at 2:43 PM, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:40 AM Ian Lance Taylor  wrote:
> >
> > On Mon, Jun 10, 2019 at 10:51 PM Dan Kortschak  wrote:
> > >
> > > The semantics of the directive are not defined, and there are comments
> > > like this[1] that would introduce breakage for people who target more
> > > than one version of Go.
> >
> > Yes.  A good reason to not do that.  We don't do it today, and there
> > are no plans to do it.
> >
> >
> > > Which version do we choose to write? Gonum support latest and two
> > > previous versions. We have had to write go 1.10 into that line so that
> > > the tests against master don't fail, but this is another line that we
> > > have to edit we we adjust versions for testing. When it becomes
> > > important, I'd be happy to write it down, but the absence of any
> > > semantic definition, it's just another line of text that has an
> > > expected syntax, but no other apparent value.
> >
> > Why do you think you would ever have to change the value go1.10?
> 
> That was perhaps a bit terse.  Let me add: the clearest description of
> the use of the go directive is at
> https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md
> .
> 
> 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/CAOyqgcWoaZkRFvLAUpyMaAo-L5TfZRmOR%3DfEo-U3cEHQ3qNPtg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fbfe11b4-3d65-49fb-ba41-6b28051e3f72%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why add the useless function in interface?

[Ian Davis]

On Tue, 26 Mar 2019, at 12:37 PM, XiaoBing Jiang wrote:
> Hi, all:
> 
> in src/cmd/compile/internal/syntax/nodes.go, why need the aNode() function in 
> the interface?
> 
> type Node interface {
> // Pos() returns the position associated with the node as follows:
> // 1) The position of a node representing a terminal syntax production
> // (Name, BasicLit, etc.) is the position of the respective production
> // in the source.
> // 2) The position of a node representing a non-terminal production
> // (IndexExpr, IfStmt, etc.) is the position of a token uniquely
> // associated with that production; usually the left-most one
> // ('[' for IndexExpr, 'if' for IfStmt, etc.)
> Pos() Pos
> aNode()
> }
> 
> type node struct {
> // commented out for now since not yet used
> // doc *Comment // nil means no comment(s) attached
> pos Pos
> }
> 
> func (n *node) Pos() Pos { return n.pos }
> func (*node) aNode() {}
> 

It prevents implementations of the interface outside of that package. The code 
can then assume it knows all the possible implementations of Node.

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.

Re: [go-nuts] Go modules do not respect vendor folder of dependencies (is this by design?)

[Ian Davis]

On Sun, 10 Feb 2019, at 12:03 AM, s...@pion.ly wrote:
> * I have a project 'A' that is importing 'B'
> * 'B' uses a vendor folder, if you delete the vendor folder the project does 
> not compile.
> * With `GO111MODULE=on` I am unable to project 'A'. It tries to pull the 
> latest of 'B', and everything 'B' depends on (instead of using 'B's vendor 
> folder)
> 
> Does anyone have suggestions on what I should do here? I don't control 
> project 'B' only 'A'


This sounds like issue https://github.com/golang/go/issues/27227 which is still 
under discussion

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.

Re: [go-nuts] What does a deadlock mean in golang?

[Ian Davis]

It's because the goroutine executing the main function blocks until the last 
channel send completes. But since you don't have another goroutine receiving 
from the channel the program cannot continue and remains in a blocked state. 
This is the cause of the deadlock.

On Tue, 29 Jan 2019, at 8:55 AM, 伊藤和也 wrote:
> I know the general meaning of a deadlock, but I don't know the meaning of a 
> deadlock in golang. For example, I send 4 values to a buffered channel whose 
> maxmum size is 3 and a deadlock occurs. I think this is just "values are out 
> of bounds" like array. What does a deaklock mean in golang?
> func main() {
>ch1 := make(chan int, 3)**
   **ch1<- 10**
   **ch1<- 20**
   **ch1<- 30**
   **ch1<- 40**
**}
> 
> fatal error: all goroutines are asleep - deadlock!
> 


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

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

Re: [go-nuts] Using "er" and "able" for interfaces

[Ian Davis]

On Thu, 17 Jan 2019, at 7:48 PM, Jakob Borg wrote:
> On 16 Jan 2019, at 15:42, Victor Giordano  wrote:
>  
>> 
>> As far i can get to understand the english language (i'm not a native 
>> speaker), the "er" seems to denotes or describe things in a more "active 
>> way" (the thing that they actually do by itself), and the "able" describes 
>> things in a more "passive way" (the thing that you can "ask it/his/her" to 
>> do). Do you find this appreciation correct?
> 
> This was a mental stumbling block for me for a long time when I started out 
> with Go. For me, the "Reader" is the one who calls Read(), so an io.Reader 
> seemed like the opposite of what I wanted. I would have better understood it 
> as io.Readee. It works out better if I see the Reader as some sort of 
> intermediate entity that affects reads on whatever the underlying thing is 
> you want to read from… Or if I see it as just an interface-indicating 
> nonsense suffix, like a capital-I prefix…

I had similar problems at first and I am an native English speaker. I now think 
of it like this: a Reader is something that can Read, just as a Logger is 
something that can Log

All the best,

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.

Re: [go-nuts] Unable to delete multiple records (multiple ids) on hitting endpoint

[Ian Davis]

On Thu, 17 Jan 2019, at 8:13 AM, aniruddha.dwiv...@nytimes.com wrote:
> Hi I am using NYT's Marvin framework which internally uses gorilla mux. I am 
> able to delete single record when I pass single id as json object in request 
> body using postman but I don't know how to handle array of json objects here. 
> My code is as below:-
>  
> For decoding ---
> 
> func DecodeDeleteUser(ctx context.Context, r *http.Request) (interface{}, 
> error) {
>  /// uriDeleteRequest := {}
>  uriDeleteRequest := &[]UserDel{}
>  log.Infof(ctx, "DeleteUser before decoding :: %+v", r)
>   if err := json.NewDecoder(r.Body).Decode(uriDeleteRequest); err != nil {
>  log.Errorf(ctx, "Delete User Error : Could not decode body from the request")
>   return nil, marvin.NewJSONStatusResponse(
>   "could not decode request body in DeleteUser",
>   http.StatusBadRequest,
>   )
>   }
>  log.Infof(ctx, "DeleteUser After decoding ::: decoding done successfully", 
> uriDeleteRequest)
>   return uriDeleteRequest, nil
> }
> 
> It successfully decodes array of JSON. Now problem arises is function below-
> 
> func(s service) deleteUserFromDb(ctx context.Context, request interface{}) 
> (interface{}, error) {
> // var userdel []UserDel
>  log.Infof(ctx, "request just inside method deleteUserFromDb : %+V",request)
>  r := request.([]*UserDel)
>  log.Infof(ctx, "request in form of r is : %+V",r)
> // db, err := s.ConnectsService.initPostgreConnection(ctx)
>  _, err := s.ConnectsService.initPostgreConnection(ctx)
>  if err != nil {
>  log.Infof(ctx, "Connection established in deleteUserFromDb method ...")
>  return nil,err
>  }
>  return "all fine",nil
> }
> 
> Here line * r := request.([]*UserDel) *gives following error - panic: 
> interface conversion: interface {} is *[]test_marvin.UserDel, not 
> []*test_marvin.UserDel
> 
> Here test_marvin is my code's package name. Please help as I don't know what 
> is wrong with my above code in golang?
> 

In DecodeDeleteUser it looks like your request is a pointer to a slice of 
UserDel but in deleteUserFromDb you are expecting it to be a slice of pointers 
to UserDel. Change uriDeleteRequest := &[]UserDel{} to be uriDeleteRequest := 
[]*UserDel{} and it should work.

All the best,

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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Ian Davis]

On Wed, 16 Jan 2019, at 2:42 PM, Victor Giordano wrote:
> As far i can get to understand the english language (i'm not a native 
> speaker), the "er" seems to denotes or describe things in a more "active way" 
> (the thing that they actually do by itself), and the "able" describes things 
> in a more "passive way" (the thing that you can "ask it/his/her" to do). Do 
> you find this appreciation correct?

This is correct.

The Go idiomatic style is to use the '-er' suffix. But this can sometimes lead 
to strange or obscure names even for native English speakers.

For example, an interface with a "Stale() bool" method seems very strange when 
named as "Staler". All these sound weird: Lookuper, Errorer, Nexter

My preference is for naming to be clear and understandable as I can make it. I 
use '-er' if it makes sense, then maybe '-able' or even something that captures 
something from the domain the usual ones being Logger or DataStore.

All the best,

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] Missing docker hub images for Go 1.11.4?

[Ian Davis]

Is there a problem with the docker hub build at the moment? Currently only Go 
1.11.3 is available there:

https://hub.docker.com/_/golang/

-- 
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] Json and value

[Ian Davis]

On Wed, 12 Dec 2018, at 9:46 AM, olivier.gale...@gmail.com wrote:
> i have the same response
> [{"id":
> 62,"nom":"TEST","URI":"http://192.168.0.31/param/","IP":"192.168.0.31","MacAdress":"DE:AD:BE:EF:FE:ED","created_at":"2018-
> 12-06T20:44:57.131380+01:00","update_at":"2018-12-
> 06T21:00:40.847034+01:00","Localisation":2,"Type":1}] 
> 

This is what you should expect from the code you supplied. You make the GET 
request and print out the response. That means you just need to parse the JSON 
response.

Create a type that represents the items in your JSON response:


type Message struct {
ID string `json:"id"
Nom string `json:"nom"
   // add more fields

}

Then modify your code to decode the items:

resp, err:=http.Get("http://192.168.0.28:8000/api/filter/192.168.0.31/;)
if err != nil {
log.Fatalln(err)
}
defer resp.Body.Close()

var messages []Message

err := json.NewDecoder(resp.Body).Decode()
if err != nil {
log.Fatalln(err)
}

log.Printf("%s", messages)

-- 
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] Json and value

[Ian Davis]

On Wed, 12 Dec 2018, at 6:03 AM, olivier.gale...@gmail.com wrote:
> Hello,
> 
> I trie to get value from api request
> i have this response 
> [{"id":
> 62,"nom":"TEST","URI":"http://192.168.0.31/param/","IP":"192.168.0.31","MacAdress":"DE:AD:BE:EF:FE:ED","created_at":"2018-
> 12-06T20:44:57.131380+01:00","update_at":"2018-12-
> 06T21:00:40.847034+01:00","Localisation":2,"Type":1}]
> 
> i would get the value from nom and IP for example.
> 
> i do a http.get to get the body response, but I can not recover the values.
> 
> my sample code:
> 
> 
>   resp, 
> err:=http.Get("http://192.168.0.28:8000/api/filter/192.168.0.31/;)
>   if nil !=err {
>   fmt.Printf("%s", err)
>   log.Fatalln(err)
>   } else {
>   defer resp.Body.Close()
>   contents, err := 
> ioutil.ReadAll(resp.Body)
>   if nil !=err {
>   fmt.Printf("%s", err)
>   log.Fatalln(err)
>   }
>   fmt.Printf("%s\n", string(contents))
>   
> 
> 
> Can you help me ?
> 

What is printed when you run your 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Strange glog.V(level) behavior in go.1.11.2 ?

[Ian Davis]

The best thing to do would be to make a self contained example that
reproduces it and file an issue at https://github.com/golang/go/issues

On Sat, 8 Dec 2018, at 8:49 AM, Jan wrote:
> I still haven't solved the issue (I just keep that odd line _ = )
> in the middle of the code.> 
> But I quickly looked at the assembly generated, and there is some
> inlined code from time.go:790 (!?) oddly in the middle of the call to
> glog.V().> 
> The code (a wrapper around alpha-beta-prunning implementation) in more
> details is below. And if I remove the "elpasedTime" line, things
> behave as expected (and I can remove the `_ = ` line:> 
> 
> *func *TimedAlphaBeta(board *Board, scorer ai.BatchScorer, maxDepth
> int, parallelize bool, randomness float32) (
>>bestAction Action, bestBoard *Board, bestScore float32) {
> 
>stats := abStats{}
> 
>start := time.Now()
> 
>bestAction, bestBoard, bestScore = AlphaBeta(board, scorer,
>maxDepth, parallelize, randomness, )
>>elapsedTime := time.Since(start).Seconds() hmm := bool(glog.V(3))
>>_ = 
> 
>*if *hmm {
> 
>   ... logging ...
>}
> }
> 
> It may just be a coincidence, but I thought I would report. 
> 


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

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

Re: [go-nuts] Unable to view go-review.googlesource.com on Firefox 60.x

[Ian Davis]

On Fri, 16 Nov 2018, at 6:05 PM, Wagner Riffel wrote:
> I'm either on 60.3 under linux and it's working fine.


OK thanks, it must be something on my system

-- 
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] Unable to view go-review.googlesource.com on Firefox 60.x

[Ian Davis]

Hi all,

Since upgrading to Firefox 60.3 on Linux I am unable to view any pages on 
https://go-review.googlesource.com/ and I wondered if anyone else was seeing 
this problem or if it's an issue with my setup?

Chromium renders the pages fine. When I view source with Firefox I see the 
following:  which might be a clue to someone.

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.

Re: [go-nuts] Why doesn't this benchmark test end?

[Ian Davis]

On Mon, 22 Oct 2018, at 4:36 PM, Sathish VJ wrote:
> So, I also tried with 
> *go test -v -bench=.  -test.benchtime=0.1s *
> and that does complete.  
> 
> But is the implication that StopTimer/StartTimer is too costly to use
> even for this simple benchmark?
See https://github.com/golang/go/issues/20875 for more information

-- 
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] Variadic functions using ...interface{}

[Ian Davis]

On Sun, 21 Oct 2018, at 10:52 PM, Justin Israel wrote:
> I was getting an error trying to pass a []string to this elasticsearch
> API ctor:> 
> https://github.com/olivere/elastic/blob/v6.2.11/search_queries_terms_set.go#L26>
>  
> func NewTermsSetQuery(name string, values ...interface{})
> *TermsSetQuery> 
> And it was failing with "cannot use vals (type []string) as type
> []interface {}".> See: https://play.golang.org/p/l5pzqyugM29
> 
> When I figured out how to satisfy the signature, it reminded me of the
> issue others have had with assigning slices of concrete values to
> slices of interface values. I get that you can't directly do that
> because the memory layout is different. But I was confused as to why
> this variadic example can't work as had expected? I guess the variadic
> ... instead of seeing []interface{} in the signature threw off my
> expectations. I don't really know whats going on under the hood when a
> variadic function handles do(mySlice...).  Is it exactly the same
> issue as a direct argument mapping between []string and []interface{}
> function parameters?
Yes it's the same issue. Variadic arguments are just syntactic sugar
for a slice.


-- 
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 mod download -json` does not product valid json?

[Ian Davis]

On Sat, 6 Oct 2018, at 3:07 PM, 'kalekold' via golang-nuts wrote:
> `go mod download -json` does not product valid json? Is this a known
> issue or am I missing something?
Do you have an example that shows the invalid json?

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Ian Davis]

On Thu, 27 Sep 2018, at 3:06 PM, Peter Mogensen wrote:
> 
> 
> On 09/27/2018 03:58 PM, Robert Engels wrote:
> > It wasn’t necessarily a warning to you :)
> > 
> > It comes from the days of GC bashing in Java and so everyone tried to 
> > manually write garbage free programs using pools and it had a bad effect on 
> > both performance and reliability. GC is there for a reason, use it... :) I 
> > would just hate to see Go developers “go” down the same path...
> 
> Well... being blissfully ignorant of JVM garbage collection pain I
> occasionally use sync.Pool to improve code in Go with measurable
> results. I've never really found it difficult to know when to call Put()
> 

https://github.com/golang/go/issues/23199 describes another gotcha when using 
pools: pinning of memory buffers.

-- 
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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Ian Davis]

On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote:
> 
> Of course... it requires that you handle any collisions in hashing the
> string key to an int yourself, but wrt. the value I curious if anyone
> can see issued with just storing a uintptr instead of the pointer for
> sync.Pool managed objects. - (provided you remember to call pool.Put()
> before loosing the map reference or doing delete() on a key.)
> 
> m[key] = uintptr(unsafe.Pointer(pool.Get().(*Object)))
> 

sync.Pools are cleared on every GC run so I expect that will cause some issues 
with your approach

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

Re: [go-nuts] Re: Why google doesnt make jdbc like library for go?

[Ian Davis]

On Fri, 21 Sep 2018, at 3:36 AM, ascarra...@gmail.com wrote:
> He has a valid point. Most of the enterprise applications uses Oracle
> DB. I for one is looking for an oracle driver similar to what JDBC
> does (a simple to use, no separate installation needed). All of Go
> oracle drivers available uses Oracle Instant Client. I am currently in
> a hunt to migrate all our Java-based projects to different language.
> Right now, my options are .Net Core 2 and Go. I am more lean to Go in
> terms of memory footprints, but I find it difficult to find the
> necessary packages/libraries to connect to Oracle database.> 
> If Google is very serious to attract enterprises to migrate their
> projects to Go, then I think they should fill those void. Don't expect
> that enterprises will migrate their DBs to PostgreSql or MySQL. That
> will be a big NO for migration.> 
> just my 2 cents. ;)

Hi. The post you are replying to is seven years old. Since then many
database drivers have been written. Please take a look at
https://github.com/golang/go/wiki/SQLDrivers

-- 
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] Announcing a Fyne GUI toolkit

[Ian Davis]

On Fri, 14 Sep 2018, at 6:02 PM, Andrew Williams wrote:
> 
> It's now well into development and ready for people to get involved.
> There is a long way to go but it feels like a solid base.> Instructions for 
> getting started, if you need them, are at
> https://github.com/fyne-io/bootstrap/blob/master/README.md .> If you want to 
> know more we're also in the #fyne channel on the gopher
> Slack server.
This looks very impressive. 

Is it possible to interface it with opengl or vulcan?

-- 
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] Generics - Why contracts?

[Ian Davis]

On Tue, 11 Sep 2018, at 3:23 PM, Jeff wrote:
> TLDR; So why contracts and not templates or something else?  Is there
> a benefit to contracts that I don't appreciate (very likely, cause I
> don't understand them)?  Are there issues with a template approach?
> If this has been addressed elsewhere, please provide links.  I'd like
> a better understanding as to why the Go team has chosen to explore
> contracts over other approaches.
I believe that contracts were inspired by C++ Concepts which are
intended to simplify the experience of using C++ Templates, particularly
in the area of developer debugging experience. The main advantage they
have is that instead of a 50 line template compilation error you get a
cleaner "T did not satisfy concept Sortable" from which you can look up
the definition of Sortable.
I think contracts/concepts do a good job of putting a name to a set of
constraints which can then be reused in multiple function declarations.
They keep declarations cleaner and shorter.
The difficult part is making the contracts themselves readable. The Go2
proposal takes the simple approach of using the existing Go type system
on the assumption that Go programmers already understand how those types
work so there is nothing new to learn.
Recent conversations here and around the proposal suggest that the type
system isn't strong or clear enough to convey the kinds of constraints
that we want to use. Personally I am not a fan of having nonsense,
unexecutable code in contract blocks but I do like the general approach.
I wonder whether a DSL is needed to make assertions stronger. Another
alternative could be to borrow more from C++ and make contracts boolean
functions that must return true although this loses the advantages of
just reusing the compiler's type checking since the contracts would have
to be evaluated at compile time too.

-- 
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] Setting font in draw2d

[Ian Davis]

On Tue, 11 Sep 2018, at 3:01 PM, viktor.oge...@gmail.com wrote:
> Hi,
> 
> I am struggling to load and use custom fonts from ttf files in draw2d
> (used since I need rotated text).> 
> To illustrate: https://play.golang.org/p/6-rswetZOr8 give the output:> 
> 2018/09/11 15:52:43 open ../resource/font/luxisr.ttf: no such file or
> directory> 
> It seems as if GraphicsContext.SetFont() does not work? draw2dimg
> tries to load the default font (from fontData) regardless?> 
> Am i misunderstanding how SetFont is supposed to be used?
> 
> Any hints appreciated. 

You can override how the font is loaded. I have some code that does it
somewhere which I can find if you need it.
However, I switched to github.com/fogleman/gg which I found to be a
better designed packaged.
It has a font example:
https://github.com/fogleman/gg/blob/master/examples/gofont.go

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

Re: [go-nuts] How to deal with binaries compilation with go modules enabled?

[Ian Davis]

On Thu, 30 Aug 2018, at 3:37 PM, Denis Cheremisov wrote:
> Hi!
> With Go 1.10 and earlier one can install binaries via regular `go
> get`, `go get golang.org/x/tools/cmd/goimports` for instance.> It doesn't 
> work with Go modules enabled:
> 
> $ go get golang.org/x/tools/cmd/goimports
> go: cannot find main module; see 'go help modules'
> 
> this is an obvious usability downgrade. I wonder if someone knows
> about some sort of replacement for the functionality?
It should still work (and does for me).

Can you try go get -x -u golang.org/x/tools/cmd/goimports and see what
the output prints about the problem.

-- 
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] How to find other packages using this package?

[Ian Davis]

On Fri, 17 Aug 2018, at 5:08 PM, Tad Vizbaras wrote:
> I have a package. Let say a/b/c. How to find what are other packages
> in my GOPATH using it?> 
> I am basically trying to clean up GOPATH from all unused packages
> installed and downloaded over the years.> Finding "dead" packages in GOPATH.
> 
> Tried go list and go doc but only got list of dependencies: packages
> this package depends on
There are a few tools that can help you. One is
https://github.com/nf/deadleaves

-- 
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] Http/net - post and decode json data part

[Ian Davis]

On Tue, 14 Aug 2018, at 12:44 PM, nicolas_boiteux via golang-nuts wrote:> the 
raw of response.body is this 
> 
> 
> {  "args": {},  "data":
> "{\"firstname\":\"Nic\",\"lastname\":\"Raboy\"}",  "files": {},
> "form": {},  "headers": {"Accept-Encoding": "gzip",
> "Connection": "close","Content-Length": "38","Content-Type":
> "application/json","Host": "httpbin.org","User-Agent": "Go-http-
> client/1.1"  },  "json": {> 
> "firstname": "Nic",
> "lastname": "Raboy"
>
>   }, "origin": "i remove my ip :)", "url": "
>   https://httpbin.org/post; }> 
> 
> for origin with or without the tag it works

That looks like the output of httpbin.org which is a testing service. Is
that what you are trying to parse or do you have a real service that is
returning some JSON?



-- 
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] Http/net - post and decode json data part

[Ian Davis]

On Tue, 14 Aug 2018, at 11:19 AM, nicolas_boiteux via golang-nuts wrote:> Hello
> 
> I need some assistance to decode a json content 
> 
> I tried to use only usefull code to do it but don't success to
> retrieve the data part of the json result.> 
> 
> var user struct {Firstname string `json: "firstname"`
> Lastname string `json: "lastname"`Origin string `"origin"` }
>
> jsonData := map[string]string{"firstname": "Nic", "lastname":
> "Raboy"} jsonValue, _ := json.Marshal(jsonData) response, err :=
> http.Post("https://httpbin.org/post;, "application/json",
> bytes.NewBuffer(jsonValue)) defer response.Body.Close()
> json.NewDecoder(response.Body).Decode() fmt.Println(user)> 
> 
> but this code only map the origin field not the firstname, and
> lastname part.
Please show an example of the JSON you are receiving.

You have some errors in your struct. Remove the spaces between json: and
the quote, like this: `json:"firstname"`
Also your origin tag is missing the json prefix.


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.

Re: [go-nuts] The &(*x) idiom for copying.

[Ian Davis]

On Wed, 28 Mar 2018, at 5:21 PM, thwd wrote:
> https://play.golang.org/p/pjyoPX99Zr1
> 
> Taking the address of an explicit dereference has different behavior
> than implicitly dereferencing and taking address.> 
> Is this the desired behavior? It surprised me.

I think the naming of your functions is misleading you. In the
following code,CopyImplicitDeref is called on the pointer called a
since the method set of the pointer type includes all the methods of
the value type.
a := {0}
b := a.CopyImplicitDeref()

There is no copying in this case.

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.

Re: [go-nuts] A Go Const suggester?

[Ian Davis]

On Wed, 28 Mar 2018, at 8:32 AM, Patrik Iselind wrote:
> Is there such a tool that can go through a GoLang code base and
> suggest values that might be a good idea to convert into constants?> 
> If a value (for example an int or a string, but excluding values that
> are already constants) is hard coded at least X times in the code
> base, could be a candidate for being a constant.> 
> Having all these hard coded and repeated values as constants would
> reduce the risk of typos when typing out the values every time.> 
> Any suggestions?

github.com/jgautheron/goconst works for strings

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.

Re: [go-nuts] what is the out put of this code and why?

[Ian Davis]

If it compiled (there are syntax errors) then I'd expect it to print
each of the numbers 0..99 doubled, followed by a repeat of the last
printed value.
Each iteration of the second loop you set y = x[i]+i

What are you trying to achieve?


On Thu, 1 Feb 2018, at 9:43 AM, Ganesh kumar wrote:
> package main
> 
> import ( "fmt")
> 
> func main() {
> var y int
> var x [100]int
> 
> for i:=0 ; i <=99 ; i++ {
> x[i] = i
> }
> 
> 
> 
> for i := 0 ;i <= 99; i++ {
> y = x[i]
> y += i
> fmt.println(y)
> }
> 
> 
> 
> 
> fmt.Print(y)
> 
> }
> 
> 


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

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

Re: [go-nuts] Re: Table Driven Test (TDT) and log only failed test case

[Ian Davis]

Define a logging interface in your main package, then pass an
implementation of the interface in your test that forwards writes to
t.Logf

On Tue, 30 Jan 2018, at 2:11 PM, Jérôme LAFORGE wrote:
> No, it is not possible to use t.Log within the code you want to test.> The 
> function IsBuggyEven is not defined to be used into testing scope,
> it is defined to be used into production context.> 
> Le mardi 30 janvier 2018 13:48:27 UTC+1, Jordan Krage a écrit :
>> Try using `t.Logf` instead of `fmt.Printf`.
>> 
>> On Saturday, January 27, 2018 at 6:03:13 AM UTC-6, Jérôme
>> LAFORGE wrote:>>> Of course, that was I already did. But I talk about the 
>> log into
>>> function I want to test (in the example of playground:  func
>>> IsBuggyEven) .>>> see: 
>>> https://play.golang.org/p/OWnEntLwfXa
>>> 
>>> 
>>> check 0 is even or odd, but I want see this log only for fail test
>>> case (i.e when i == 5) check 2 is even or odd, but I want see this
>>> log only for fail test case (i.e when i == 5) check 5 is even or
>>> odd, but I want see this log only for fail test case (i.e when i ==
>>> 5) --- FAIL: TestIsEven (0.00s)--- FAIL: TestIsEven/5_is_even
>>> (0.00s)/tmp/somewhere/mmoney_test.go:144: For 5, expected:
>>> false, actual: true FAIL FAILcommon/utils0.044s Error: Tests
>>> failed.>>> 
>>> 
>>> Le samedi 27 janvier 2018 10:30:27 UTC+1, Tamás Gulácsi a écrit :
 Use subtest (t.Run)> 


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

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

Re: [go-nuts] glog + vendor = "flag redefined: log_dir"?

[Ian Davis]

On Tue, 30 Jan 2018, at 7:59 AM, porridge via golang-nuts wrote:
> I admit I'm somewhat new to Golang, how do I solve this problem?
> My program uses two libraries, both of which have
> github.com/golang/glog in their /vendor/ directories.> This results in a 
> panic at runtime, apparently because two copies of
> glog try to initialize the same flag on initialization.
I think the accepted practice is to flatten your library's dependencies
so there is only one copy of the vendored glog package.
In general libraries should not include vendor directories and
dependencies should be managed by the application using the libraries in
its own vendor directory.
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.

Re: [go-nuts] "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

[Ian Davis]

A loop is the usual way.


On Wed, 24 Jan 2018, at 12:57 PM, d...@veryhaha.com wrote:
> except unsafe ways.
> 


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

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

Re: [go-nuts] Underlying arrays and their slices passed to functions

[Ian Davis]

On Thu, 4 Jan 2018, at 6:55 PM, Frank Davidson wrote:
> Thanks!!! Very helpful blog post!!
> 
> So, in proc, the slice header is copied, then an entirely new array is
> created - []byte{5,6,7,8} - and the slice header copy is set to point
> at that new array, and then discarded, whereas in proc 2, the slice
> header is not reset, and so still points to the original array?
Yes

-- 
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] Matrix Operation

[Ian Davis]

Try gonum

https://godoc.org/gonum.org/v1/gonum/mat


On Tue, 2 Jan 2018, at 10:58 AM, meher akshay wrote:
> Hi everyone,
> 
> I want to find the eigen vectors and values of a matrix in golang. 
> Please help me as I am not able to do it using the provided docs
> 
> 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.

-- 
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 the result right or not?

[Ian Davis]

You can see your error if you initialise i to -1 before the loop: v[i]
is evaluated before i is incremented.

On Wed, 6 Dec 2017, at 02:26 PM, T L wrote:
> 
> package main
> 
> import "fmt"
> 
> func main() {
>   var i int
>   var x = []int{3, 5, 7}
>   var y = make([]int, 3)
>   for i, y[i] = range x {
>   fmt.Println(i, ":", y, ", y[", i, "] =", y[i])
>   }
>   fmt.Println("y =", y)
> }
> 
> // output:
> 0 : [3 0 0] , y[ 0 ] = 3
> 1 : [5 0 0] , y[ 1 ] = 0
> 2 : [5 7 0] , y[ 2 ] = 0
> y = [5 7 0]
> 


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

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

Re: [go-nuts] Urgent: race condition with ticker channels

[Ian Davis]

On Mon, 6 Nov 2017, at 12:14 PM, arunabh.ar...@gmail.com wrote:
> Hi,
> 
> I am fairly new to Golang, so please excuse if this is a silly
> question. I could not find any answers on the web.> 
> Code portion A:
> 
>   rf.mu.Lock()
>   rf.electionTicker =  time.NewTicker(rf.currentTimeout)
>      rf.mu.Unlock()
> 
> Code portion B:
> for {
>   select {
> case <-rf.electionTicker.C: // do something
>  default:
>   }
> }
> 
> Can you please tell me why a channel read is facing a race condition.> Is 
> there a way to prevent this race?

The race is caused because you are writing to rf.electionTicker and then
reading from it to access the channel you want to read from. The channel
read itself is not causing the race.
You could read rf.electionTicker into a variable in some code guarded by
the mutex and read from that instead.

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.

Re: [go-nuts] slice of pointer of struct vs slice of struct

[Ian Davis]

On Fri, 20 Oct 2017, at 06:34 AM, Jan Mercl wrote:
> On Fri, Oct 20, 2017 at 7:25 AM Feby Tanzil
>  wrote:> 
> > Which is better & preferable in Go?
> 
> Depends on size of T.

How does that affect the size of []T or []*T ?

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.

Re: [go-nuts] Debugging a mutex/scheduling issue

[Ian Davis]

This sounds like https://github.com/golang/go/issues/13086

On Mon, 16 Oct 2017, at 09:01 PM, Caleb Spare wrote:
> I have a server which is doing log processing and I'm trying to
> improve throughput. The bottleneck is access to a shared resource
> protected by a sync.Mutex. The issue is that even though there are
> nearly always worker goroutines blocked on Lock, only about 10% of the
> time (in aggregate) is spent running the code inside the critical
> section.
> 
> To be concrete, I have 300 worker goroutines, and they collectively
> spend about 280 seconds / second blocked on the mutex, and about 100
> ms / second inside (as measured from Lock returning to Unlock
> returning).
> 
> To investigate this, I added some instrumentation around sync.Mutex. I
> log events when a Lock is called, when Lock returns (acquire lock),
> and when Unlock returns. This shows me that, typically, my code takes
> around 5-15 μs between acquire and unlock, but it takes tens or
> hundreds of μs between unlock and some other goroutine acquiring the
> lock.
> 
> Here's a short section of logged events. The number in square brackets
> is the goroutine ID; the timestamp is μs since the trace started.
> 
> [209]73018.628   acquire lock (+38.798)
> [209]73028.707   unlock
> [298]73049.222   call lock
> [199]73068.748   call lock
> [214]73153.182   call lock
> [355]73259.473   call lock
> [157]73308.336   call lock
> [256]73339.965   call lock
> [389]73517.476   call lock
> [325]73541.077   acquire lock (+512.370)
> [325]73545.650   unlock
> [396]73581.819   call lock
> [174]73645.743   call lock
> [224]73708.319   call lock
> [292]73801.945   call lock
> [285]73855.717   call lock
> [357]73915.478   call lock
> [276]74013.148   acquire lock (+467.498)
> 
> Here you can see that goroutine 209 held the lock for only about 10 μs
> before returning from mu.Unlock at t=73028.707 but the next goroutine
> (325) didn't return from mu.Lock until t=73541.077, more than 500 μs
> after that. Goroutine 325 returned from mu.Unlock after about 5 μs,
> but then it took 467 μs for another goroutine (276) to return from
> mu.Lock.
> What is the best way to debug (and, hopefully, fix) this issue? I'm
> not really sure how to diagnose scheduling problems. I looked at
> GODEBUG=schedtrace=1000 output but I'm not sure how to interpret it.
> Here's a few seconds of that output for this server:
> 
> 2017/10/16 10:38:00 SCHED 253295ms: gomaxprocs=36 idleprocs=0
> threads=56 spinningthreads=18 idlethreads=15 runqueue=1 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:01 SCHED 254305ms: gomaxprocs=36 idleprocs=1
> threads=56 spinningthreads=18 idlethreads=14 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:02 SCHED 255307ms: gomaxprocs=36 idleprocs=2
> threads=56 spinningthreads=18 idlethreads=15 runqueue=0 [0 1 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:03 SCHED 256311ms: gomaxprocs=36 idleprocs=1
> threads=56 spinningthreads=18 idlethreads=13 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0]
> 2017/10/16 10:38:04 SCHED 257313ms: gomaxprocs=36 idleprocs=1
> threads=56 spinningthreads=17 idlethreads=13 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:05 SCHED 258318ms: gomaxprocs=36 idleprocs=1
> threads=56 spinningthreads=18 idlethreads=15 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:06 SCHED 259318ms: gomaxprocs=36 idleprocs=3
> threads=56 spinningthreads=17 idlethreads=17 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:07 SCHED 260323ms: gomaxprocs=36 idleprocs=1
> threads=56 spinningthreads=18 idlethreads=14 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:08 SCHED 261324ms: gomaxprocs=36 idleprocs=2
> threads=56 spinningthreads=18 idlethreads=15 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:09 SCHED 262327ms: gomaxprocs=36 idleprocs=0
> threads=56 spinningthreads=18 idlethreads=15 runqueue=1 [0 0 1 0 0 0 0
> 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:10 SCHED 26ms: gomaxprocs=36 idleprocs=1
> threads=56 spinningthreads=18 idlethreads=14 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:11 SCHED 264333ms: gomaxprocs=36 idleprocs=4
> threads=56 spinningthreads=18 idlethreads=15 runqueue=0 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> 2017/10/16 10:38:12 SCHED 265336ms: gomaxprocs=36 idleprocs=3
> threads=56 spinningthreads=19 idlethreads=14 runqueue=1 [0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 

Re: [go-nuts] Why can't I call a pointer-receiver method on a temperary but addressable struct literal?

[Ian Davis]

On Fri, 13 Oct 2017, at 02:02 PM, Ian Davis wrote:
> On Fri, 13 Oct 2017, at 01:41 PM, Cholerae Hu wrote:
>> https://golang.org/ref/spec#Calls
>>>  If x is addressable[1] and 's method set contains m, x.m() is
>>>  shorthand for ().m()>> 
>> https://golang.org/ref/spec#Address_operators
>> Composite literals is addressable.
>> 
>> So why can't I call DummyMethod like Circle{radius:
>> 1.0}.DummyMethod() ?> 
> It works on the playground: https://play.golang.org/p/kP9emNKWeg
> 
> Ian

Sorry, I misread your question.

Links:

  1. https://golang.org/ref/spec#Address_operators

-- 
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] Strange behavior when dealing with certain emojis

[Ian Davis]

On Wed, 11 Oct 2017, at 11:16 AM, Gianguido Sorà wrote:
> Uhm, so the Replacer sees it as two separate entities, and replaces
> the part of the composite that matches one of the cases.
Sort of. The emoji is really just the "\xE2\x83\xA3" part (or
"\U20e3") which puts a keycap symbol around the previous character.
The "\x32" is just the digit "2".
> 
> What could I do to make the Replacer ignore UTF-8 composites? Is that
> even possible or should I handle the presence of these empty square
> boxes after the substitution phase?

Depends on what you are trying to achieve. You could replace the
"\x32\xE2\x83\xA3" sequence with something else first, then do your
actual replacement and restore the original after.

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.

Re: [go-nuts] Strange behavior when dealing with certain emojis

[Ian Davis]

On Wed, 11 Oct 2017, at 10:33 AM, Ian Davis wrote:
> 
> On Wed, 11 Oct 2017, at 09:57 AM, Gianguido Sorà wrote:
>> 
>> I'm writing a small utility which uses a strings.Replacer to process
>> some substitutions in some strings; these strings contains UTF-8
>> characters as well as emojis.>> 
>> Here you can find a playground with an example:
>> https://play.golang.org/p/gdfZ_zGGiO>> 
>> As you can see from the playground, the occurrence of "2" has been
>> replaced with the string "altered" into the emoji itself, even though
>> the hex representation of it is not directly listed in the Replacer.>> 
>> What could I do to prevent this from happening?
> 
> At first glance this looks like a bug in strings.Replacer. If the
> string you are replacing is a single byte character then NewReplacer
> uses a byteStringReplacer which treats the target as a byte array. I
> suggest opening an issue here https://github.com/golang/go/issues
After a bit more thought, the reason why the replacement happens is
because the emoji you are using is a composite that combines the keycap
image with the number 2. You can see it in this example which shows
various equivalent forms of the emoji:
https://play.golang.org/p/HhaNuZ3JZM

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.

Re: [go-nuts] Strange behavior when dealing with certain emojis

[Ian Davis]

On Wed, 11 Oct 2017, at 09:57 AM, Gianguido Sorà wrote:
> 
> I'm writing a small utility which uses a strings.Replacer to process
> some substitutions in some strings; these strings contains UTF-8
> characters as well as emojis.> 
> Here you can find a playground with an example:
> https://play.golang.org/p/gdfZ_zGGiO> 
> As you can see from the playground, the occurrence of "2" has been
> replaced with the string "altered" into the emoji itself, even though
> the hex representation of it is not directly listed in the Replacer.> 
> What could I do to prevent this from happening?

At first glance this looks like a bug in strings.Replacer. If the string
you are replacing is a single byte character then NewReplacer uses a
byteStringReplacer which treats the target as a byte array. I  suggest
opening an issue here https://github.com/golang/go/issues
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.

Re: [go-nuts] "defer go"

[Ian Davis]

On Tue, 10 Oct 2017, at 02:27 PM, Shawn Milochik wrote:
> On Tue, Oct 10, 2017 at 9:13 AM, Scott Cotton  labs.com> wrote:>> Hi all,
>> 
>> 1. "defer go"   extend defers to work on goroutine exit with
>>mechanism just like defer, but if we say "defer go f()">> instead of 
>> "defer f()" then we run on goroutine exit.  Very big gains
>> for scaling here IMHO.>> 
> 
> You can already "defer go": defer func() { go otherFunc() }()
> 
> https://play.golang.org/p/DkNoFXLACn

Interestingly I read the suggestion the other way round:

go func() { defer otherfunc() }()

Either way, this seems like it's already well supported :)

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.

Re: [go-nuts] binary.Read()

[Ian Davis]

On Thu, 5 Oct 2017, at 08:58 AM, Johan terryn wrote:
> In following code:


> 


> type JPGFile struct {


> Exif_SOI [2]byte Exif } type Exif struct { APP1Marker   [2]byte
> APP1DataSize uint16 ExifHeader   [6]byte TIFFHeader[6]byte }> func 
> ReadFile(filename string) (JPGFile, error) {


> jpgFile := JPGFile{} in, err := os.Open(filename) defer in.Close()
> if err != nil {return jpgFile, err } binary.Read(in,
> binary.LittleEndian, )> return jpgFile, nil
> }
> **


> **


> **


> *binary.Read* accepts "in" (os.File) as a reader, but if I pass the
> file as a parameter to the function I get the (correct ) error message
> that "in" is not a reader, as defined in the documentation: func
> Read(r *io.Reader*, order ByteOrder, data interface{}) error> 


> Or is this working as intended?



Can you provide a fuller example showing imports? Your code looks
correct and "in" is an io.Reader so it's surprising that you are getting
that message. This non-runnable version of your code compiles fine:
https://play.golang.org/p/aruCeIHFEZ
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.

Re: [go-nuts] Parsing a CSV column with partially double-quotes in it

[Ian Davis]

Try setting r.LazyQuotes=true


On Thu, 28 Sep 2017, at 09:56 PM, Lantos István wrote:
> 
> I want to parse the following CSV structure. The column separators
> are tabs:> 
> *package main*
> 
> *import (*
> *"encoding/csv"*
> *"fmt"*
> *"log"*
> *"strings"*
> *)*
> 
> *func main() {*
> *in := `This"is" notfun`*
> *r := csv.NewReader(strings.NewReader(in))*
> *r.Comma = '\t'*
> 
> *records, err := r.ReadAll()*
> *if err != nil {*
> *log.Fatal(err)*
> *}*
> 
> *fmt.Print(records)*
> *}*
> **
> Google Playground[1]*
** *There is a tab after **This** and before **fun**. Between **"is"**
and* *not** there is only a space. This should be one column. I  setted
the column separator with* *r.Comma ="\t"**, but for some reason I'm
getting the following error:> 
> **line 1, column 8: extraneous " in field**
> 
> Is there a way to achieve what I want?
> 
> 
> 


> --
>  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.


Links:

  1. https://play.golang.org/p/ZZ5t-lvfaK

-- 
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] public interface with private method: totally dubious ? In which case is it useful ?

[Ian Davis]

It's a pattern that can be used to prevent external implementations of
the interface. Another example is the text/template package in the
standard library:
https://github.com/golang/go/blob/master/src/text/template/parse/node.go#L21

On Mon, 4 Sep 2017, at 01:21 PM, mhhc...@gmail.com wrote:
> hi,
> 
> in this code
> https://github.com/conformal/gotk3/blob/7a6ce3ecbc883d4d6a7aa1821bbc9633751fd67e/gtk/gtk.go#L7926>
>  
> a public interface with a private method is declared.
> 
> At first read, totally dubious. yeah?
> 
> A bit more testing, and i wonder in which case this is suitable, a
> basic example yields,> 
> ./main2.go:7: cannot use b.XX literal (type b.XX) as type a.WW in
> argument to a.C:  b.XX does not implement a.WW (missing a.private
> method)   have b.private()   want a.private()
>
> _$GOPATH/src/test/a/a.go_> 
> package a
>
> type WW interface { private() }
>
> func C(h WW) {}> 
> 
> _$GOPATH/src/test/b/b.go_
> 
> package b
> 
> type XX struct{}
> 
> func (x XX) private() {}
> 
> 
> _$GOPATH/src/test/main.go_
> 
> package main
>
> import "test/a" import "test/b"
>
> func main() {
>  a.C(b.XX{}) }> 
> 
> 


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

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

Re: [go-nuts] go1.8 and json.NewDecoder(resp.Body)

[Ian Davis]

On Tue, 23 May 2017, at 01:33 PM, John Shahid wrote:
> The only way I can think of to fix this is either using
> ioutil.ReadAll(resp.Body) combined with json.Unmarshal, or use
> json.NewDecoder() followed by ioutil.ReadAll and discard the result.> What do 
> you all think ?


> 

I noticed just yesterday that your first suggestion is used in the
Google API client, e.g. when reading an error response:
https://github.com/google/google-api-go-client/blob/master/googleapi/googleapi.go#L114
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.

Re: [go-nuts] Re: Problem with checking errors when testing

[Ian Davis]

On Sun, 21 May 2017, at 05:32 PM, breamore...@gmail.com wrote:
> 
> On Sunday, May 21, 2017 at 11:52:41 AM UTC+1, Tamás Gulácsi wrote:
>> A nil does not have type
>>  A nil interface may have. See
>>  http://spf13.com/post/when-nil-is-not-nil/>> Why don't you use type switch?


> 
> I've no idea what you're talking about.  I want to know why I
> get, e.g :-> 
>  mytest_test.go:25: got  '-1' is out of range; want  '-1' is
>  out of range
I suspect it's because you return an error created with fmt.Errorf and
compare it to a different error created with errors.New. They are
pointers to different instances.

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.

Re: [go-nuts] Why no return statement for *timerCtx in func parentCancelCtx(context.go)

[Ian Davis]

On Wed, 17 May 2017, at 01:40 PM, Guohua Ouyang wrote:
> I was confusing when I read the lines #L279-#L280
> https://github.com/golang/go/blob/master/src/context/context.go#L279

it will loop with the new value of parent


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

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

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

[Ian Davis]

On Tue, 9 May 2017, at 05:07 PM, Jesper Louis Andersen wrote:
>> 
>> I don't believe this is helpful to the questioner who was simply
>> explaining their understanding.>> 
> 
> A reference to cargo cults is useful insofar one should study why
> something happens rather than copying a hearsay. On the other hand, it
> doesn't give you much tooling: you can't solve the problem just by
> knowing you might have run into the cargo cult trap---which we all do
> from time to time.
Quite. But simply posting a link to wikipedia's page on Cargo Cult is
not helpful to newcomers from other languages and is belittling. The
OP's message was asking about Go. Their belief in some possible PHP
behaviour is irrelevant to the answer about Go's behaviour so no-one
needs to imply they are blindly copying patterns - after all they are
asking a question to find out more.
Let's take the time to be extra welcoming to newcomers.

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.

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

[Ian Davis]

On Tue, 9 May 2017, at 04:31 PM, Pierre Durand wrote:
>> 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

I don't believe this is helpful to the questioner who was simply
explaining their understanding.
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.

Re: [go-nuts] Re: suggest: improve go gen intergration for non core code ?

[Ian Davis]

On Tue, 9 May 2017, at 12:12 PM, mhhc...@gmail.com wrote:
> Maybe that could be a simple go sub command: 
> 
> go gun [...packages]
> 
> gen+run=>gun 
> 
> Sure i could do on my end, it won t be adopted so ... useless.

Usually go generate is intended to be run once and the results committed
to the repository. It's not expected that end users of the code re-run
it regularly.
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.