[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...

[Dave Cheney]

If your code has a dependency on github.com/pkg/log then place the contents of 
that repository into

$PROJECT/vendor/src/github.com/pkg/log

Where $PROJECT is the root of your gb project.

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

[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...

[Jeff Kayser]

Hi, Dave.

Thank you for your clarifications about how gb works.  I appreciate your 
specific examples of how to get the needed code into the gb directory trees.  I 
didn’t know about git submodules or the gb-vendor plugin; I’ll check it out.



Jeff Kayser

Jibe Consulting | Managing Principal Consultant

5000 Meadows Rd. Suite 300

Lake Oswego, OR 97035

O: 503-517-3266 | C: 503.901.5021

jeff.kay...@jibeconsulting.com



From: Dave Cheney [mailto:d...@cheney.net]
Sent: Sunday, February 05, 2017 9:40 PM
To: golang-nuts 
Cc: manlio.peri...@gmail.com; jeffkays...@gmail.com; Jeff Kayser 

Subject: Re: Go package/version management, vendoring, dep, gb, etc...



On Monday, 6 February 2017 15:03:03 UTC+11, Jeff Kayser wrote:
Hi, Manlio.

Thank you for your reply!

The project is an application, however, I’m planning to write the underlying 
components so they are reusable, so they can be leveraged elsewhere.  Since I 
will be using the packages to build an app, I need to make sure the builds are 
reproducible.  ☺

I had a very helpful email exchange with Dave Cheney, and he suggested gb + 
semver.  With the current lack of convergence on go package 
versioning/dependency management, it seems wise to me to follow his 
recommendation, since he is one of the Go gurus.

Hey, go+ is a cool script!  Thanks for sharing!

I’m finding out (the hard way) how to deal with cyclic dependencies, so package 
management has become really important to me.

Question: is it possible for gb to vendor a specific version of a package?

Yes

 If I have a dependency on package xyz version 2.4, can I configure gb to know 
that I need xyz version 2.4, or do I have to deal with that separately (e.g. in 
a Makefile that calls git)?

No

gb only cares what is in your project (that includes vendor/src). How you, as 
the project owner, do this is your problem. As long as all the packages that 
are imported by your program are represented, gb doesn't care.

You can do this manually, by forking code into vendor/src, you can use git 
submodules if your politics permit, or you could use the gb-vendor plugin.

I’m a Go newbie, and am making some notes about learning Go.  I’ve put them 
here:

https://github.com/jeffkayser2/learningGo/wiki

It will not contain much of interest for experienced Go programs, but might 
help some other newbies.  Items 6 and 7 have info I've gleaned from Internet 
and Dave Cheney about package management, dependency management, package 
versioning, cyclic dependencies, etc.

Jeff Kayser
Jibe Consulting | Managing Principal Consultant
5000 Meadows Rd. Suite 300
Lake Oswego, OR 97035
O: 503-517-3266 | C: 503.901.5021
jeff@jibeconsulting.com



From: Manlio Perillo [mailto:manlio@gmail.com]
Sent: Sunday, February 05, 2017 4:03 AM
To: golang-nuts 
Cc: Jeff Kayser ; 
jeffk...@gmail.com
Subject: Re: Go package/version management, vendoring, dep, gb, etc...

Il giorno domenica 5 febbraio 2017 06:35:18 UTC+1, 
jeffk...@gmail.com ha scritto:
I can’t seem to converge on a decent package/version management scheme.  I 
asked Dave Cheney, and he recommended that I email this list.

I’ve written a Go project.  I started with a directory tree like this:

$GOPATH/src/project/objects/agent_v1/agent_v1.go (import 
“project/objects/agent_v1”)
$GOPATH/src/project/objects/customer_v1/customer_v1.go (import 
“project/objects/customer_v1”) Etc.

I know that I needed to be able to support different versions of my objects, so 
that is the directory structure I started using.


Is your project a package (for other developers to use) or an application?


What I’m looking for: A solution that will:
a)make builds reproducible.

If your project is a package, usually (IMHO) you should forget about making 
builds reproducible.
This is responsibility of the develper that uses your package in his project.

b)use SemVer 2.0.0 versioning.

You can just add tags or branches on your git repository following, as an 
example, the convention proposed by Dave Cheney.

> [...]
e)use the standard Go tooling as much as possible.  Only use other 
tooling where the standard Go tooling won’t work for package/version management.

For web applications I use the layout proposed by Dave Cheney in db (but this 
layout seems to be used by other projects, too).
I use gb build when building, since it is convenient, but I use standard go 
tools for everything else, using this script named go+"
#!/bin/sh
# Execute the go tool for the current project.
# The project should have the layout as defined by the gb tool.
GOPATH="$PWD:$PWD/vendor" GOBIN="$PWD/bin" go $@

When importing dependencies I use gb vendor fetch, but for some cases I just 
clone the repository inside vendor/src/.

If your project is a package you can import the dependency in a vendor 
directory.  There are 

[go-nuts] Re: How to run go testing code with "go run"

[Manlio Perillo]

Il giorno sabato 4 febbraio 2017 23:59:34 UTC+1, Tong Sun ha scritto:
>
> I know all go testing code are invoked with "*go test*", however, I want 
> to easily test out some of the test code of the package I'm trying, so the 
> easiest way is to test them out as-is, but with "*go run*" instead. Is it 
> possible, or how can I make such thing possible? 
>
> For e.g., here is a piece of test code I that want to test out (just for 
> illustration), 
>
> func TestSomething(t *testing.T) {
>  fmt.Println("Say hi")
>  t.Log("Say bye")
>  t.Error("Error is equivalent to Log followed by Fail")
> }
>
>
> and I want to test out in my own program like this:
>
> package main
> func main() {
> }
>
>
> how can I make it possible?
>
>
It is possible, but not with `go run` but instead with `go test`.

Add a _test prefix to your test file and run it with go test.
As an example:
go test code_test.go

Is there any reason why you want to run it with go run?
If you need, you can define a TestMain function, see
https://golang.org/pkg/testing/#hdr-Main


Manlio 

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

[go-nuts] Re: [Beginner question] Which language supports more concurrency models: Go or Java?

[Kiswono Prayogo]

Fastest concurrent map that I found (and use): github.com/OneOfOne/cmap

On Monday, 6 February 2017 11:03:03 UTC+7, yins...@gmail.com wrote:
>
> Question is in the title.
>
> I want to learn more about concurrency. So I am looking for a language 
> that can teach me the greatest number of concurrency models.
>
> It seems that Java supports these models:
>
>- Plain old threads & locks
>- In addition, Java also has various concurrent data structures in the 
> java.util.concurrent 
>package 
>
> 
>  
>(ConcurrentHashMap, CopyOnWriteArrayList, etc)
>- Actor model: Akka 
>- CSP / lightweight threads & channels: Quasar 
>
>- Software Transactional Memory: built in into Clojure (I don't know 
>if it can be used from Java), Akka version <= 2.2
>- Dataflow: Quasar 
>
>
> I'm not very familiar with Go, but here's what I found:
>
>- CSP: built in into the language
>- Actor model: Proto Actor 
>- I probably missed a lot of things, so feel free to correct me
>
>
>
>
> Thank you in advance,
>
> Rio
>

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

[go-nuts] Re: Is there something wrong with performance of select in a for loop

[fwang2002]

each go routine only handle less than 10 events concurrently, why you said 
it's 100?

I found if serverDone is not globally defined, the result is better, but 
still not as expected.

在 2017年2月6日星期一 UTC+8上午3:00:15，fwan...@gmail.com写道：
>
> I make a test to see the performance of select, and found the result is 
> not good.
>
> I make 1000 SeqQueue objects and run its messageLoop function (which does 
> a small piece of work, and is listed as below) in 1000 separate go 
> routines. The CPU cost is more than 20%.
> If I make the ticker 1 second, the CPU cost can slow down to about 2%.
>
> With pprof, I see the most top cost are methods related to 
> runtime.selectGo, runtime.lock.
>
> Who knows is there anything wrong in my case?
>
> func (this *SeqQueue) messageLoop() {
> var ticker = time.NewTicker(100 * time.Millisecond)
> defer ticker.Stop()
> for {
> select {
> case <-serverDone:
> return
> case <-this.done:
> return
> case <-ticker.C:
> this.tickCounter += 1
> case message := <-this.messages:
> this.messageCounter += 1
> _ = message
> }
> }
> }
>
>
>
>

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

[go-nuts] Re: Go package/version management, vendoring, dep, gb, etc...

[Dave Cheney]

On Monday, 6 February 2017 15:03:03 UTC+11, Jeff Kayser wrote:
>
> Hi, Manlio. 
>
> Thank you for your reply! 
>
> The project is an application, however, I’m planning to write the 
> underlying components so they are reusable, so they can be leveraged 
> elsewhere.  Since I will be using the packages to build an app, I need to 
> make sure the builds are reproducible.  ☺ 
>
> I had a very helpful email exchange with Dave Cheney, and he suggested gb 
> + semver.  With the current lack of convergence on go package 
> versioning/dependency management, it seems wise to me to follow his 
> recommendation, since he is one of the Go gurus. 
>
> Hey, go+ is a cool script!  Thanks for sharing! 
>
> I’m finding out (the hard way) how to deal with cyclic dependencies, so 
> package management has become really important to me. 
>
> Question: is it possible for gb to vendor a specific version of a package? 


Yes
 

>  If I have a dependency on package xyz version 2.4, can I configure gb to 
> know that I need xyz version 2.4, or do I have to deal with that separately 
> (e.g. in a Makefile that calls git)? 
>

No

gb only cares what is in your project (that includes vendor/src). How you, 
as the project owner, do this is your problem. As long as all the packages 
that are imported by your program are represented, gb doesn't care.

You can do this manually, by forking code into vendor/src, you can use git 
submodules if your politics permit, or you could use the gb-vendor plugin.

>
> I’m a Go newbie, and am making some notes about learning Go.  I’ve put 
> them here: 
>
> https://github.com/jeffkayser2/learningGo/wiki 
>
> It will not contain much of interest for experienced Go programs, but 
> might help some other newbies.  Items 6 and 7 have info I've gleaned from 
> Internet and Dave Cheney about package management, dependency management, 
> package versioning, cyclic dependencies, etc. 
>
> Jeff Kayser 
> Jibe Consulting | Managing Principal Consultant 
> 5000 Meadows Rd. Suite 300 
> Lake Oswego, OR 97035 
> O: 503-517-3266 | C: 503.901.5021 
> jeff@jibeconsulting.com  
>
>
>
> From: Manlio Perillo [mailto:manlio@gmail.com ] 
> Sent: Sunday, February 05, 2017 4:03 AM 
> To: golang-nuts  
> Cc: Jeff Kayser ; 
> jeffk...@gmail.com  
> Subject: Re: Go package/version management, vendoring, dep, gb, etc... 
>
> Il giorno domenica 5 febbraio 2017 06:35:18 UTC+1, jeffk...@gmail.com ha 
> scritto: 
> I can’t seem to converge on a decent package/version management scheme.  I 
> asked Dave Cheney, and he recommended that I email this list. 
>   
> I’ve written a Go project.  I started with a directory tree like this: 
>   
> $GOPATH/src/project/objects/agent_v1/agent_v1.go (import 
> “project/objects/agent_v1”) 
> $GOPATH/src/project/objects/customer_v1/customer_v1.go (import 
> “project/objects/customer_v1”) Etc. 
>   
> I know that I needed to be able to support different versions of my 
> objects, so that is the directory structure I started using.  
>   
>
> Is your project a package (for other developers to use) or an application? 
>
>   
> What I’m looking for: A solution that will: 
> a)make builds reproducible. 
>
> If your project is a package, usually (IMHO) you should forget about 
> making builds reproducible. 
> This is responsibility of the develper that uses your package in his 
> project. 
>
> b)use SemVer 2.0.0 versioning. 
>
> You can just add tags or branches on your git repository following, as an 
> example, the convention proposed by Dave Cheney. 
>
> > [...] 
> e)use the standard Go tooling as much as possible.  Only use 
> other tooling where the standard Go tooling won’t work for package/version 
> management. 
>
> For web applications I use the layout proposed by Dave Cheney in db (but 
> this layout seems to be used by other projects, too). 
> I use gb build when building, since it is convenient, but I use standard 
> go tools for everything else, using this script named go+" 
> #!/bin/sh 
> # Execute the go tool for the current project. 
> # The project should have the layout as defined by the gb tool. 
> GOPATH="$PWD:$PWD/vendor" GOBIN="$PWD/bin" go $@ 
>
> When importing dependencies I use gb vendor fetch, but for some cases I 
> just clone the repository inside vendor/src/. 
>
> If your project is a package you can import the dependency in a vendor 
> directory.  There are some example in the Go standard library. 
> However you should be careful, since some packages can not be imported 
> multiple time (like the SQL drivers). 
>
>
> Manlio  
>
> Disclaimer: This electronic message may contain information that is 
> Confidential or legally privileged. It is intended only for the use of the 
> individual(s) and entity named in the message. If you are not an intended 
> recipient of this message, please notify the sender immediately and delete 
> the material from your 

[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...

[Jeff Kayser]

Hi, Manlio.

I like your idea of putting the reusable code in a separate Git repository, and 
then vendoring it into the application project.  That makes a lot of sense.  I 
hadn't thought of that.  Thanks for the idea.

I also like the idea of making it an internal package, and move it to a 
separate repository once it is stable.  My first Go code, and my first 
architecture for the program, was not very good, but as I learn Go, I'm 
learning ways to improve it.  In my first version, I had way too many package 
dependencies.  I kept hitting the cyclic dependency compiler error.  I finally 
decided that, instead of dealing with the dependency problems one at a time, I 
needed to rearchitect the program.  So, I am doing that now.  Ugh.  Oh well, my 
second version will be a real improvement over the first version.  :-)

Thanks for the pointer about "gb vendor help fetch".  That is exactly what I 
needed to know!  I just started to use gb a couple of days ago, so I'm a newbie 
with that too.

Thank you for your help.  Much appreciated.

Jeff Kayser
Jibe Consulting | Managing Principal Consultant
5000 Meadows Rd. Suite 300
Lake Oswego, OR 97035
O: 503-517-3266 | C: 503.901.5021
jeff.kay...@jibeconsulting.com


-Original Message-
From: Manlio Perillo [mailto:manlio.peri...@gmail.com] 
Sent: Sunday, February 05, 2017 3:55 PM
To: Jeff Kayser 
Cc: golang-nuts ; jeffkays...@gmail.com
Subject: Re: Go package/version management, vendoring, dep, gb, etc...

On Sun, Feb 5, 2017 at 11:39 PM, Jeff Kayser  
wrote:
> Hi, Manlio.
>
> Thank you for your reply!
>
> The project is an application, however, I’m planning to write the 
> underlying components so they are reusable, so they can be leveraged 
> elsewhere.  Since I will be using the packages to build an app, I need 
> to make sure the builds are reproducible.  ☺
>

In this case move them to a separate package/project.
As an example, create a git repository in $GOPATH/src/github.com/$USER/project/

Use this git repository for the main development, and tag your versions with 
tags and branches.

Then in your application, clone the repository in vendor/src/github.com/$USER

In this case you have full control over the version used, and you can also 
modify the code and pull/push changes to the original repository.
For your first project, probably all the development will be in the cloned 
repository, and you will push the changes to the original repository once the 
code is stable and needs to be used by other projects.

Another solution is to put the reusable components in an internal package (of 
your application), and once you like the code you move it to a new project.
I like this one, because it will allow you to start with a draft.

> I had a very helpful email exchange with Dave Cheney, and he suggested gb + 
> semver.  With the current lack of convergence on go package 
> versioning/dependency management, it seems wise to me to follow his 
> recommendation, since he is one of the Go gurus.
>
> Hey, go+ is a cool script!  Thanks for sharing!
>
> I’m finding out (the hard way) how to deal with cyclic dependencies, so 
> package management has become really important to me.
>

Go does not support cyclic dependencies, and I don't see how package management 
is related to cyclic dependencies.

> Question: is it possible for gb to vendor a specific version of a package?

Yes.
It is specified in the documentation
gb vendor help fetch

You can specify a tag, branch or exact revision.

> [...]

Manlio

Disclaimer: This electronic message may contain information that is 
Confidential or legally privileged. It is intended only for the use of the 
individual(s) and entity named in the message. If you are not an intended 
recipient of this message, please notify the sender immediately and delete the 
material from your computer. Do not deliver, distribute or copy this message 
and do not disclose its contents or take any action in reliance on the 
information it contains.

-- 
You received this message because you are subscribed 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] About 64bits alignment

[T L]

On Monday, February 6, 2017 at 12:44:38 PM UTC+8, Ian Lance Taylor wrote:
>
> On Sun, Feb 5, 2017 at 8:15 PM, T L  
> wrote: 
> > 
> > In fact, I still have another question needs to be clarify: what does 
> the 
> > "word" in "The first word in a global variable or in an allocated struct 
> or 
> > slice" mean? 
> > A field with the same length with int values? 
>
> In this case it means a 64-bit value stored in memory, as mentioned in 
> the previous sentence. 
>
> Ian 
>

Thanks for the clarification! 

-- 
You received this message because you are subscribed 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] About 64bits alignment

[Ian Lance Taylor]

On Sun, Feb 5, 2017 at 8:15 PM, T L  wrote:
>
> In fact, I still have another question needs to be clarify: what does the
> "word" in "The first word in a global variable or in an allocated struct or
> slice" mean?
> A field with the same length with int values?

In this case it means a 64-bit value stored in memory, as mentioned in
the previous sentence.

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] About 64bits alignment

[Ian Lance Taylor]

On Sun, Feb 5, 2017 at 11:55 AM, T L  wrote:
>
> In short, when structs and slices are used as the non-first fields of other
> structs,
> then the struct and slice fields may be not 64bit aligned on 32bit OSes.
>
> But what about arrays? Can the first word in an allocated array be relied
> upon to be 64-bit aligned?

Yes.

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] Is there something wrong with performance of select in a for loop

[Ian Lance Taylor]

On Sun, Feb 5, 2017 at 6:53 PM,   wrote:
> I attached the code. Build and run it, and look the cpu usage.
> Each time when comment out one of serverDone case, the cpu usage will down
> about 5% in my book.
> When all the serverDone case are commented out, the cpu is still about 5%,
> not good compared to nodejs.

I don't see consistent results with the number of cases in the select.
It does seem that the number of cases tends to increase CPU usage
slightly, but it's unpredictable.  I agree that the CPU usage is
noticeable when there no cases, but after all you are starting 1000
goroutines each of which is handling 100 channel events, for a total
of 100,000 events being handled.  Of course that takes some CPU time.
I don't know how long Node.js takes for this kind of operation, but Go
and Node.js are not directly comparable in any case.

I've attached the program I ran for which I see unpredictable results.
It will only work on GNU/Linux since I'm calling clock_gettime
directly.

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

import (
	"fmt"
	"log"
	"os"
	"runtime/pprof"
	"sync"
	"syscall"
	"time"
	"unsafe"
)

var serverDone = make(chan struct{})
var serverDone1 = make(chan struct{})
var serverDone2 = make(chan struct{})
var serverDone3 = make(chan struct{})
var serverDone4 = make(chan struct{})
var serverDone5 = make(chan struct{})

func main() {
	f, err := os.Create("cpu.pprof")
	if err != nil {
		log.Fatal(err)
	}
	pprof.StartCPUProfile(f)
	defer pprof.StopCPUProfile()

	run(1, messageLoop1)
	run(2, messageLoop2)
	run(3, messageLoop3)
	run(4, messageLoop4)
	run(5, messageLoop5)
	run(6, messageLoop6)
}

func run(name int, f func()) {
	var start syscall.Timespec
	r, _, errno := syscall.Syscall(syscall.SYS_CLOCK_GETTIME, 2, uintptr(unsafe.Pointer()), 0)
	if r != 0 {
		log.Fatal(errno)
	}

	var wg sync.WaitGroup
	wg.Add(1000)
	for i := 0; i < 1000; i++ {
		go func() {
			f()
			wg.Done()
		}()
	}
	<-time.After(10 * time.Second)
	close(serverDone)

	wg.Wait()

	var end syscall.Timespec
	r, _, errno = syscall.Syscall(syscall.SYS_CLOCK_GETTIME, 2, uintptr(unsafe.Pointer()), 0)
	if r != 0 {
		log.Fatal(errno)
	}
	d := time.Duration(end.Sec - start.Sec) * time.Second + time.Duration(end.Nsec - start.Nsec) * time.Nanosecond
	fmt.Println(name, d)

	serverDone = make(chan struct{})
}

func messageLoop1() {
	var ticker = time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()
	var counter = 0
	for {
		select {
		case <-serverDone:
			return
		case <-ticker.C:
			counter += 1
		}
	}
}

func messageLoop2() {
	var ticker = time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()
	var counter = 0
	for {
		select {
		case <-serverDone:
			return
		case <-serverDone1:
		 	return
		case <-ticker.C:
			counter += 1
		}
	}
}

func messageLoop3() {
	var ticker = time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()
	var counter = 0
	for {
		select {
		case <-serverDone:
			return
		case <-serverDone1:
		 	return
		case <-serverDone2:
			return
		case <-ticker.C:
			counter += 1
		}
	}
}

func messageLoop4() {
	var ticker = time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()
	var counter = 0
	for {
		select {
		case <-serverDone:
			return
		case <-serverDone1:
		 	return
		case <-serverDone2:
			return
		case <-serverDone3:
			return
		case <-ticker.C:
			counter += 1
		}
	}
}

func messageLoop5() {
	var ticker = time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()
	var counter = 0
	for {
		select {
		case <-serverDone:
			return
		case <-serverDone1:
		 	return
		case <-serverDone2:
			return
		case <-serverDone3:
			return
		case <-serverDone4:
			return
		case <-ticker.C:
			counter += 1
		}
	}
}

func messageLoop6() {
	var ticker = time.NewTicker(100 * time.Millisecond)
	defer ticker.Stop()
	var counter = 0
	for {
		select {
		case <-serverDone:
			return
		case <-serverDone1:
		 	return
		case <-serverDone2:
			return
		case <-serverDone3:
			return
		case <-serverDone4:
			return
		case <-serverDone5:
			return
		case <-ticker.C:
			counter += 1
		}
	}
}

Re: [go-nuts] About 64bits alignment

[T L]

On Monday, February 6, 2017 at 3:55:35 AM UTC+8, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Sun, Feb 5, 2017 at 10:52 AM, T L  wrote: 
>> > Ian, thanks for the answers. 
>> > 
>> > But I still not very confirm on many points. 
>> > 
>> > Up to now, there are two places mention the alignments in Go. 
>> > 
>> > The first is in the end of Go spec: 
>> > 
>> > 
>> > Size and alignment guarantees 
>> > 
>> > For the numeric types, the following sizes are guaranteed: 
>> > 
>> > type size in bytes 
>> > 
>> > byte, uint8, int8 1 
>> > uint16, int16 2 
>> > uint32, int32, float324 
>> > uint64, int64, float64, complex64 8 
>> > complex128   16 
>> > 
>> > The following minimal alignment properties are guaranteed: 
>> > 
>> > For a variable x of any type: unsafe.Alignof(x) is at least 1. 
>> > For a variable x of struct type: unsafe.Alignof(x) is the largest of 
>> all the 
>> > values unsafe.Alignof(x.f) for each field f of x, but at least 1. 
>> > For a variable x of array type: unsafe.Alignof(x) is the same as 
>> > unsafe.Alignof(x[0]), but at least 1. 
>> > 
>> > A struct or array type has size zero if it contains no fields (or 
>> elements, 
>> > respectively) that have a size greater than zero. Two distinct 
>> zero-size 
>> > variables may have the same address in memory. 
>> > 
>> > 
>> > The second is at the end of sync/atomic docs: 
>> > 
>> > 
>> > On x86-32, the 64-bit functions use instructions unavailable before the 
>> > Pentium MMX. 
>> > 
>> > On non-Linux ARM, the 64-bit functions use instructions unavailable 
>> before 
>> > the ARMv6k core. 
>> > 
>> > On both ARM and x86-32, it is the caller's responsibility to arrange 
>> for 
>> > 64-bit alignment of 64-bit words accessed atomically. The first word in 
>> a 
>> > global variable or in an allocated struct or slice can be relied upon 
>> to be 
>> > 64-bit aligned. 
>> > 
>> > 
>> > I feel the two are not enough to remove all my confusions. 
>> > 
>> > So could you help me remove the following confusions: 
>> > 
>> > 
>> > 1. What does the "allocated struct or slice" mean? 
>> > 
>> > 
>> > Currently, I think it means the structs or slices created by new, or 
>> the 
>> > structs or slices escape to heap. 
>> > 
>> > Is my understanding right? 
>>
>> Those cases are "allocated struct or slice," yes.  The phrase also 
>> includes variables defined with a struct or slice type. 
>>
>>
>> > 2. Are local 8-bytes variables 64bit aligned on 32bit OSes? 
>> > 
>> > 
>> > I found there are many usages of the 64bit functions of atomic package 
>> being 
>> > used on local 8-bytes variables in go source. 
>> > 
>> > So I think the answer is yes. Right? 
>>
>> Yes. 
>>
>>
>> > 3. Are expvar.Int and expvar.Float safe to be embedded in other structs 
>> on 
>> > 32bit OSes? 
>> > 
>> > 
>> > I think the answer is no. Is my opinion right? 
>>
>> You could embed them as the first field of a struct (if you were then 
>> careful to not embed that struct, (except as the first field)). 
>>
>> It would not be portable to embed them as anything other than the first 
>> field. 
>>
>> I think this is problematic, and it would be nice to figure out a way to 
>> fix it. 
>>
>> Ian 
>>
>
> Thanks! I think I almost get it.
>
> In short, when structs and slices are used as the non-first fields of 
> other structs, 
> then the struct and slice fields may be not 64bit aligned on 32bit OSes.
>
> But what about arrays? Can the first word in an allocated array be relied 
> upon to be 64-bit aligned?
>
>
In fact, I still have another question needs to be clarify: what does the 
"word" in "The first word in a global variable or in an allocated struct or 
slice" mean?
A field with the same length with int values?
 

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

[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...

[Jeff Kayser]

Hi, Manlio.

Thank you for your reply!

The project is an application, however, I’m planning to write the underlying 
components so they are reusable, so they can be leveraged elsewhere.  Since I 
will be using the packages to build an app, I need to make sure the builds are 
reproducible.  ☺

I had a very helpful email exchange with Dave Cheney, and he suggested gb + 
semver.  With the current lack of convergence on go package 
versioning/dependency management, it seems wise to me to follow his 
recommendation, since he is one of the Go gurus.

Hey, go+ is a cool script!  Thanks for sharing!

I’m finding out (the hard way) how to deal with cyclic dependencies, so package 
management has become really important to me.

Question: is it possible for gb to vendor a specific version of a package?  If 
I have a dependency on package xyz version 2.4, can I configure gb to know that 
I need xyz version 2.4, or do I have to deal with that separately (e.g. in a 
Makefile that calls git)?

I’m a Go newbie, and am making some notes about learning Go.  I’ve put them 
here:

https://github.com/jeffkayser2/learningGo/wiki

It will not contain much of interest for experienced Go programs, but might 
help some other newbies.  Items 6 and 7 have info I've gleaned from Internet 
and Dave Cheney about package management, dependency management, package 
versioning, cyclic dependencies, etc.

Jeff Kayser
Jibe Consulting | Managing Principal Consultant
5000 Meadows Rd. Suite 300
Lake Oswego, OR 97035
O: 503-517-3266 | C: 503.901.5021
jeff.kay...@jibeconsulting.com



From: Manlio Perillo [mailto:manlio.peri...@gmail.com] 
Sent: Sunday, February 05, 2017 4:03 AM
To: golang-nuts 
Cc: Jeff Kayser ; jeffkays...@gmail.com
Subject: Re: Go package/version management, vendoring, dep, gb, etc...

Il giorno domenica 5 febbraio 2017 06:35:18 UTC+1, jeffk...@gmail.com ha 
scritto:
I can’t seem to converge on a decent package/version management scheme.  I 
asked Dave Cheney, and he recommended that I email this list.
 
I’ve written a Go project.  I started with a directory tree like this:
 
$GOPATH/src/project/objects/agent_v1/agent_v1.go (import 
“project/objects/agent_v1”) 
$GOPATH/src/project/objects/customer_v1/customer_v1.go (import 
“project/objects/customer_v1”) Etc.
 
I know that I needed to be able to support different versions of my objects, so 
that is the directory structure I started using.  
 

Is your project a package (for other developers to use) or an application?

 
What I’m looking for: A solution that will:
a)    make builds reproducible.

If your project is a package, usually (IMHO) you should forget about making 
builds reproducible.
This is responsibility of the develper that uses your package in his project.

b)    use SemVer 2.0.0 versioning.

You can just add tags or branches on your git repository following, as an 
example, the convention proposed by Dave Cheney.

> [...]
e)    use the standard Go tooling as much as possible.  Only use other 
tooling where the standard Go tooling won’t work for package/version management.

For web applications I use the layout proposed by Dave Cheney in db (but this 
layout seems to be used by other projects, too).
I use gb build when building, since it is convenient, but I use standard go 
tools for everything else, using this script named go+"
    #!/bin/sh
    # Execute the go tool for the current project.
    # The project should have the layout as defined by the gb tool.
    GOPATH="$PWD:$PWD/vendor" GOBIN="$PWD/bin" go $@

When importing dependencies I use gb vendor fetch, but for some cases I just 
clone the repository inside vendor/src/.

If your project is a package you can import the dependency in a vendor 
directory.  There are some example in the Go standard library.
However you should be careful, since some packages can not be imported multiple 
time (like the SQL drivers).


Manlio 

Disclaimer: This electronic message may contain information that is 
Confidential or legally privileged. It is intended only for the use of the 
individual(s) and entity named in the message. If you are not an intended 
recipient of this message, please notify the sender immediately and delete the 
material from your computer. Do not deliver, distribute or copy this message 
and do not disclose its contents or take any action in reliance on the 
information it contains.

-- 
You received this message because you are subscribed 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] [Beginner question] Which language supports more concurrency models: Go or Java?

[yinsi . rio]

Question is in the title.

I want to learn more about concurrency. So I am looking for a language that 
can teach me the greatest number of concurrency models.

It seems that Java supports these models:

   - Plain old threads & locks
   - In addition, Java also has various concurrent data structures in the 
java.util.concurrent 
   package 
   

 
   (ConcurrentHashMap, CopyOnWriteArrayList, etc)
   - Actor model: Akka 
   - CSP / lightweight threads & channels: Quasar 
   
   - Software Transactional Memory: built in into Clojure (I don't know if 
   it can be used from Java), Akka version <= 2.2
   - Dataflow: Quasar 

I'm not very familiar with Go, but here's what I found:

   - CSP: built in into the language
   - Actor model: Proto Actor 
   - I probably missed a lot of things, so feel free to correct me




Thank you in advance,

Rio

-- 
You received this message because you are subscribed 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 there something wrong with performance of select in a for loop

[fwang2002]

I attached the code. Build and run it, and look the cpu usage. 
Each time when comment out one of serverDone case, the cpu usage will down 
about 5% in my book. 
When all the serverDone case are commented out, the cpu is still about 5%, 
not good compared to nodejs.

在 2017年2月6日星期一 UTC+8上午3:16:15，Ian Lance Taylor写道：
>
> On Sun, Feb 5, 2017 at 12:11 AM,   
> wrote: 
> > I make a test to see the performance of select, and found the result is 
> not 
> > good. 
> > 
> > I make 1000 SeqQueue objects and run its messageLoop function (which 
> does a 
> > small piece of work, and is listed as below) in 1000 separate go 
> routines. 
> > The CPU cost is more than 20%. 
> > If I make the ticker 1 second, the CPU cost can slow down to about 2%. 
> > 
> > With pprof, I see the most top cost are methods related to 
> runtime.selectGo, 
> > runtime.lock. 
> > 
> > Who knows is there anything wrong in my case? 
> > 
> > func (this *SeqQueue) messageLoop() { 
> > var ticker = time.NewTicker(100 * time.Millisecond) 
> > defer ticker.Stop() 
> > for { 
> > select { 
> > case <-serverDone: 
> > return 
> > case <-this.done: 
> > return 
> > case <-ticker.C: 
> > this.tickCounter += 1 
> > case message := <-this.messages: 
> > this.messageCounter += 1 
> > _ = message 
> > } 
> > } 
> > } 
>
> It's unfortunately impossible to reasonably analyze a microbenchmark 
> from an incomplete code fragment.  Please post a complete program, 
> ideally written as a Benchmark (as described at 
> https://golang.org/pkg/testing/). 
>
> 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.


main.go
Description: Binary data

[go-nuts] why "go test -coverprofile" report "unknown command"?

[Yulei Xiao]

I execute ```go test -coverprofile```, but it always report "unknown 
command", I can not find the reason.


go test -coverprofile /tmp/test0.cov 
-coverpkg=github.com/clm/agent,github.com/clm/cfg,github.com/clm/cli,github.com/clm/cm,github.com/clm/cm/common,github.com/clm/cm/monitor,github.com/clm/conftool,github.com/clm/etcd_manager,github.com/clm/keys,github.com/clm,github.com/clm/service,github.com/clm/topo,github.com/clm/util/log,github.com/clm/util
 
github.com/clm

Error: unknown command "/usr1/code/src/github.com/squirreldb/clm" for "clm"


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

[go-nuts] Re: Go 1.6.1 Link problem on Windows:

[saurabh . deoras]

Hi Folks,

Putting dll's in the same folder as my GO code solved the problem as 
suggested here: https://github.com/veandco/go-sdl2

Thanks,
Saurabh

On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote:
>
> Hi,
>
> I'm just wondering what is the cause of the following error (multiple 
> definition of __something)?
> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
> C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dyyls01966.o):(.idata$5+0x0):
>  
> multiple definition of `__imp_pow'
>
> This only happens on Windows10 but on Ubuntu/Linux.
>
> The Go code makes a call to LAPACK via a C interface as follows:
> package main
>
> /*
> #cgo CFLAGS: -O3
> #cgo linux   LDFLAGS: -lm -llapack -lgfortran -lblas
> #cgo windows LDFLAGS: -lm -llapack -lgfortran -lblas -LC:/GoslDeps/lib
>
> #include 
>
> void dgesvd_(const char* jobu, const char* jobvt, const int* M, const int* 
> N, double* A, const int* lda, double* S, double* U, const int* ldu, double* 
> VT, const int* ldvt, double* work,const int* lwork, const int* info);
>
> int lapack_svd(double *U, double *S, double *Vt, long m_long, double *A) {
> int m = (int)(m_long);
> int info  = 0;
> charjob   = 'A';
> int lwork = 10*m;
> double* work  = (double*)malloc(lwork*sizeof(double));
> dgesvd_(,   // JOBU
> ,   // JOBVT
> , // M
> , // N
> A,  // A
> , // LDA
> S,  // S
> U,  // U
> , // LDU
> Vt, // VT
> , // LDVT
> work,   // WORK
> , // LWORK
> ); // INFO
> free(work);
> return info;
> }
> */
> import "C"
>
> import (
> "fmt"
> "math"
> "unsafe"
> )
>
> func main() {
> A := []float64{1, 2, 3, 2, -4, -9, 3, 6, -3} // col-major format
> m := int(math.Sqrt(float64(len(A
> I := func(i, j int) int { return j*m + i }
> printmat(m, A, "A")
> U := make([]float64, len(A))
> S := make([]float64, len(A))
> Vt := make([]float64, len(A))
> info := C.lapack_svd(
> (*C.double)(unsafe.Pointer([0])),
> (*C.double)(unsafe.Pointer([0])),
> (*C.double)(unsafe.Pointer([0])),
> (C.long)(m),
> (*C.double)(unsafe.Pointer([0])),
> )
> fmt.Printf("SVD: info = %d\n", info)
> USVt := make([]float64, len(A))
> for i := 0; i < m; i++ {
> for j := 0; j < m; j++ {
> for k := 0; k < m; k++ {
> USVt[I(i, j)] += U[I(i, k)] * S[k] * Vt[I(k, j)]
> }
> }
> }
> printmat(m, USVt, "U*S*Vt")
> }
>
> func printmat(m int, M []float64, msg string) {
> fmt.Printf("%s =\n", msg)
> for i := 0; i < m; i++ {
> for j := 0; j < m; j++ {
> fmt.Printf("%13.8f", M[j*m+i])
> }
> fmt.Println()
> }
> }
>
> Any help is much appreciated.
>
> Cheers.
> Dorival
>

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

[go-nuts] Re: Go package/version management, vendoring, dep, gb, etc...

[Manlio Perillo]

On Sun, Feb 5, 2017 at 11:39 PM, Jeff Kayser
 wrote:
> Hi, Manlio.
>
> Thank you for your reply!
>
> The project is an application, however, I’m planning to write the underlying 
> components so they are reusable, so they can be leveraged elsewhere.  Since I 
> will be using the packages to build an app, I need to make sure the builds 
> are reproducible.  ☺
>

In this case move them to a separate package/project.
As an example, create a git repository in
$GOPATH/src/github.com/$USER/project/

Use this git repository for the main development,
and tag your versions with tags and branches.

Then in your application, clone the repository in
vendor/src/github.com/$USER

In this case you have full control over the version used, and you can
also modify the code and pull/push changes to the original repository.
For your first project, probably all the development will be in the
cloned repository, and you will push the changes to the original
repository once the code is stable and needs to be used by other
projects.

Another solution is to put the reusable components in an internal
package (of your application), and once you like the code you move it
to a new project.
I like this one, because it will allow you to start with a draft.

> I had a very helpful email exchange with Dave Cheney, and he suggested gb + 
> semver.  With the current lack of convergence on go package 
> versioning/dependency management, it seems wise to me to follow his 
> recommendation, since he is one of the Go gurus.
>
> Hey, go+ is a cool script!  Thanks for sharing!
>
> I’m finding out (the hard way) how to deal with cyclic dependencies, so 
> package management has become really important to me.
>

Go does not support cyclic dependencies, and I don't see how package
management is related to cyclic dependencies.

> Question: is it possible for gb to vendor a specific version of a package?

Yes.
It is specified in the documentation
gb vendor help fetch

You can specify a tag, branch or exact revision.

> [...]

Manlio

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

[go-nuts] Re: Go 1.6.1 Link problem on Windows:

[saurabh . deoras]

Hi Folks,

So some good news on the issue but still not out of woods. After getting 
rid of all statically built libs and replacing them by dll's, I was able to 
compile and link against GO code. So far so good, but when running a test I 
get an error code:
exit status 3221225781

getting closer :)
Saurabh


On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote:
>
> Hi,
>
> I'm just wondering what is the cause of the following error (multiple 
> definition of __something)?
> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
> C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dyyls01966.o):(.idata$5+0x0):
>  
> multiple definition of `__imp_pow'
>
> This only happens on Windows10 but on Ubuntu/Linux.
>
> The Go code makes a call to LAPACK via a C interface as follows:
> package main
>
> /*
> #cgo CFLAGS: -O3
> #cgo linux   LDFLAGS: -lm -llapack -lgfortran -lblas
> #cgo windows LDFLAGS: -lm -llapack -lgfortran -lblas -LC:/GoslDeps/lib
>
> #include 
>
> void dgesvd_(const char* jobu, const char* jobvt, const int* M, const int* 
> N, double* A, const int* lda, double* S, double* U, const int* ldu, double* 
> VT, const int* ldvt, double* work,const int* lwork, const int* info);
>
> int lapack_svd(double *U, double *S, double *Vt, long m_long, double *A) {
> int m = (int)(m_long);
> int info  = 0;
> charjob   = 'A';
> int lwork = 10*m;
> double* work  = (double*)malloc(lwork*sizeof(double));
> dgesvd_(,   // JOBU
> ,   // JOBVT
> , // M
> , // N
> A,  // A
> , // LDA
> S,  // S
> U,  // U
> , // LDU
> Vt, // VT
> , // LDVT
> work,   // WORK
> , // LWORK
> ); // INFO
> free(work);
> return info;
> }
> */
> import "C"
>
> import (
> "fmt"
> "math"
> "unsafe"
> )
>
> func main() {
> A := []float64{1, 2, 3, 2, -4, -9, 3, 6, -3} // col-major format
> m := int(math.Sqrt(float64(len(A
> I := func(i, j int) int { return j*m + i }
> printmat(m, A, "A")
> U := make([]float64, len(A))
> S := make([]float64, len(A))
> Vt := make([]float64, len(A))
> info := C.lapack_svd(
> (*C.double)(unsafe.Pointer([0])),
> (*C.double)(unsafe.Pointer([0])),
> (*C.double)(unsafe.Pointer([0])),
> (C.long)(m),
> (*C.double)(unsafe.Pointer([0])),
> )
> fmt.Printf("SVD: info = %d\n", info)
> USVt := make([]float64, len(A))
> for i := 0; i < m; i++ {
> for j := 0; j < m; j++ {
> for k := 0; k < m; k++ {
> USVt[I(i, j)] += U[I(i, k)] * S[k] * Vt[I(k, j)]
> }
> }
> }
> printmat(m, USVt, "U*S*Vt")
> }
>
> func printmat(m int, M []float64, msg string) {
> fmt.Printf("%s =\n", msg)
> for i := 0; i < m; i++ {
> for j := 0; j < m; j++ {
> fmt.Printf("%13.8f", M[j*m+i])
> }
> fmt.Println()
> }
> }
>
> Any help is much appreciated.
>
> Cheers.
> Dorival
>

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

[go-nuts] Re: Does my gofmt work wrongly or I don't understand something ?

[howardcshaw]

What were you expecting to happen?

The documentation says: 

   Both  pattern and replacement must be valid Go expressions. In the 
pat‐
   tern, single-character lowercase identifiers serve as wildcards 
 match‐
   ing  arbitrary  sub-expressions;  those expressions will be 
substituted
   for the same identifiers in the replacement.

So if 'h' had shown up in the replacement, it would get replaced with the 
original identifier - but it did not appear, instead H did.

It *looks* like you were expecting it to change the "hello, world\n" to 
"Hello, world\n"? But gofmt's -r requires that both pattern and replacement 
be valid Go expressions. 

This:
gofmt -r "\"hello, world\\n\" -> \"Hello, world\\n\""

Has the effect I think you might have been going for. I'm not certain what 
you were intending though, so I'm not sure of that.

-- 
You received this message because you are subscribed 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 idiomatically display chained errors?

[Lars Seipel]

On Sat, Feb 04, 2017 at 12:08:20AM -0800, so.qu...@gmail.com wrote:
> The following would print out "ERROR: Foo() ERROR: Bar() ERROR: 
> stdlib.Func() something went wrong with this standard function call", which 
> feels obviously wrong.

Leave out the "ERROR" string as well as the gratuitous parens and you
get something like "foo: bar: open: file does not exist" which looks
almost reasonable.

-- 
You received this message because you are subscribed 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] About 64bits alignment

[T L]

On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>
> On Sun, Feb 5, 2017 at 10:52 AM, T L  
> wrote: 
> > Ian, thanks for the answers. 
> > 
> > But I still not very confirm on many points. 
> > 
> > Up to now, there are two places mention the alignments in Go. 
> > 
> > The first is in the end of Go spec: 
> > 
> > 
> > Size and alignment guarantees 
> > 
> > For the numeric types, the following sizes are guaranteed: 
> > 
> > type size in bytes 
> > 
> > byte, uint8, int8 1 
> > uint16, int16 2 
> > uint32, int32, float324 
> > uint64, int64, float64, complex64 8 
> > complex128   16 
> > 
> > The following minimal alignment properties are guaranteed: 
> > 
> > For a variable x of any type: unsafe.Alignof(x) is at least 1. 
> > For a variable x of struct type: unsafe.Alignof(x) is the largest of all 
> the 
> > values unsafe.Alignof(x.f) for each field f of x, but at least 1. 
> > For a variable x of array type: unsafe.Alignof(x) is the same as 
> > unsafe.Alignof(x[0]), but at least 1. 
> > 
> > A struct or array type has size zero if it contains no fields (or 
> elements, 
> > respectively) that have a size greater than zero. Two distinct zero-size 
> > variables may have the same address in memory. 
> > 
> > 
> > The second is at the end of sync/atomic docs: 
> > 
> > 
> > On x86-32, the 64-bit functions use instructions unavailable before the 
> > Pentium MMX. 
> > 
> > On non-Linux ARM, the 64-bit functions use instructions unavailable 
> before 
> > the ARMv6k core. 
> > 
> > On both ARM and x86-32, it is the caller's responsibility to arrange for 
> > 64-bit alignment of 64-bit words accessed atomically. The first word in 
> a 
> > global variable or in an allocated struct or slice can be relied upon to 
> be 
> > 64-bit aligned. 
> > 
> > 
> > I feel the two are not enough to remove all my confusions. 
> > 
> > So could you help me remove the following confusions: 
> > 
> > 
> > 1. What does the "allocated struct or slice" mean? 
> > 
> > 
> > Currently, I think it means the structs or slices created by new, or the 
> > structs or slices escape to heap. 
> > 
> > Is my understanding right? 
>
> Those cases are "allocated struct or slice," yes.  The phrase also 
> includes variables defined with a struct or slice type. 
>
>
> > 2. Are local 8-bytes variables 64bit aligned on 32bit OSes? 
> > 
> > 
> > I found there are many usages of the 64bit functions of atomic package 
> being 
> > used on local 8-bytes variables in go source. 
> > 
> > So I think the answer is yes. Right? 
>
> Yes. 
>
>
> > 3. Are expvar.Int and expvar.Float safe to be embedded in other structs 
> on 
> > 32bit OSes? 
> > 
> > 
> > I think the answer is no. Is my opinion right? 
>
> You could embed them as the first field of a struct (if you were then 
> careful to not embed that struct, (except as the first field)). 
>
> It would not be portable to embed them as anything other than the first 
> field. 
>
> I think this is problematic, and it would be nice to figure out a way to 
> fix it. 
>
> Ian 
>

Thanks! I think I almost get it.

In short, when structs and slices are used as the non-first fields of other 
structs, 
then the struct and slice fields may be not 64bit aligned on 32bit OSes.

But what about arrays? Can the first word in an allocated array be relied 
upon to be 64-bit aligned?

-- 
You received this message because you are subscribed 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 there something wrong with performance of select in a for loop

[Ian Lance Taylor]

On Sun, Feb 5, 2017 at 12:11 AM,   wrote:
> I make a test to see the performance of select, and found the result is not
> good.
>
> I make 1000 SeqQueue objects and run its messageLoop function (which does a
> small piece of work, and is listed as below) in 1000 separate go routines.
> The CPU cost is more than 20%.
> If I make the ticker 1 second, the CPU cost can slow down to about 2%.
>
> With pprof, I see the most top cost are methods related to runtime.selectGo,
> runtime.lock.
>
> Who knows is there anything wrong in my case?
>
> func (this *SeqQueue) messageLoop() {
> var ticker = time.NewTicker(100 * time.Millisecond)
> defer ticker.Stop()
> for {
> select {
> case <-serverDone:
> return
> case <-this.done:
> return
> case <-ticker.C:
> this.tickCounter += 1
> case message := <-this.messages:
> this.messageCounter += 1
> _ = message
> }
> }
> }

It's unfortunately impossible to reasonably analyze a microbenchmark
from an incomplete code fragment.  Please post a complete program,
ideally written as a Benchmark (as described at
https://golang.org/pkg/testing/).

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] About 64bits alignment

[Ian Lance Taylor]

On Sun, Feb 5, 2017 at 10:52 AM, T L  wrote:
> Ian, thanks for the answers.
>
> But I still not very confirm on many points.
>
> Up to now, there are two places mention the alignments in Go.
>
> The first is in the end of Go spec:
>
>
> Size and alignment guarantees
>
> For the numeric types, the following sizes are guaranteed:
>
> type size in bytes
>
> byte, uint8, int8 1
> uint16, int16 2
> uint32, int32, float324
> uint64, int64, float64, complex64 8
> complex128   16
>
> The following minimal alignment properties are guaranteed:
>
> For a variable x of any type: unsafe.Alignof(x) is at least 1.
> For a variable x of struct type: unsafe.Alignof(x) is the largest of all the
> values unsafe.Alignof(x.f) for each field f of x, but at least 1.
> For a variable x of array type: unsafe.Alignof(x) is the same as
> unsafe.Alignof(x[0]), but at least 1.
>
> A struct or array type has size zero if it contains no fields (or elements,
> respectively) that have a size greater than zero. Two distinct zero-size
> variables may have the same address in memory.
>
>
> The second is at the end of sync/atomic docs:
>
>
> On x86-32, the 64-bit functions use instructions unavailable before the
> Pentium MMX.
>
> On non-Linux ARM, the 64-bit functions use instructions unavailable before
> the ARMv6k core.
>
> On both ARM and x86-32, it is the caller's responsibility to arrange for
> 64-bit alignment of 64-bit words accessed atomically. The first word in a
> global variable or in an allocated struct or slice can be relied upon to be
> 64-bit aligned.
>
>
> I feel the two are not enough to remove all my confusions.
>
> So could you help me remove the following confusions:
>
>
> 1. What does the "allocated struct or slice" mean?
>
>
> Currently, I think it means the structs or slices created by new, or the
> structs or slices escape to heap.
>
> Is my understanding right?

Those cases are "allocated struct or slice," yes.  The phrase also
includes variables defined with a struct or slice type.


> 2. Are local 8-bytes variables 64bit aligned on 32bit OSes?
>
>
> I found there are many usages of the 64bit functions of atomic package being
> used on local 8-bytes variables in go source.
>
> So I think the answer is yes. Right?

Yes.


> 3. Are expvar.Int and expvar.Float safe to be embedded in other structs on
> 32bit OSes?
>
>
> I think the answer is no. Is my opinion right?

You could embed them as the first field of a struct (if you were then
careful to not embed that struct, (except as the first field)).

It would not be portable to embed them as anything other than the first field.

I think this is problematic, and it would be nice to figure out a way to fix it.

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] Is there something wrong with performance of select in a for loop

[fwang2002]

I make a test to see the performance of select, and found the result is not 
good.

I make 1000 SeqQueue objects and run its messageLoop function (which does a 
small piece of work, and is listed as below) in 1000 separate go routines. 
The CPU cost is more than 20%.
If I make the ticker 1 second, the CPU cost can slow down to about 2%.

With pprof, I see the most top cost are methods related to 
runtime.selectGo, runtime.lock.

Who knows is there anything wrong in my case?

func (this *SeqQueue) messageLoop() {
var ticker = time.NewTicker(100 * time.Millisecond)
defer ticker.Stop()
for {
select {
case <-serverDone:
return
case <-this.done:
return
case <-ticker.C:
this.tickCounter += 1
case message := <-this.messages:
this.messageCounter += 1
_ = message
}
}
}



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

Re: [go-nuts] Go Fonts: request for feedback

[Aram Hăvărneanu]

On Fri, Feb 3, 2017 at 8:12 PM, roger peppe  wrote:
> Perhaps a slightly esoteric request: I'd love to see the fonts made
> available in Plan 9 (acme compatible) font format. I tried doing the
> conversion and all bar one font size looked terrible.

I also ask for this, and confirm that the conversion done by fontsrv
(using either FreeType or Quartz) is not great.

Thanks,

-- 
Aram Hăvărneanu

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

[go-nuts] Re: Really weird timezone behavior.

[Uli Kunitz]

The Playground doesn't appear to support correct timezone info. The time 
package is modified on the Playground.

Your program runs as expected on my local machine. You are certainly aware 
that it is not properly formatted and doesn't do proper error handling.


On Saturday, February 4, 2017 at 7:06:57 PM UTC+1, LEGOlord208 wrote:
>
> Trying to convert timezones.
> Works nearly, but they have some minutes off!
>
> For example, these timezones should be equals:
> https://play.golang.org/p/_mnELD1nCv
> They aren't.
>
> Fun fact: Because of the way time is built, I can't just simply round it. 
> So this isn't going very well
>

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

[go-nuts] Re: Go package/version management, vendoring, dep, gb, etc...

[Manlio Perillo]

Il giorno domenica 5 febbraio 2017 06:35:18 UTC+1, jeffk...@gmail.com ha 
scritto:
>
> I can’t seem to converge on a decent package/version management scheme.  I 
> asked Dave Cheney, and he recommended that I email this list.
>
>  
>
> I’ve written a Go project.  I started with a directory tree like this:
>
>  
> $GOPATH/src/project/objects/agent_v1/agent_v1.go (import 
> “project/objects/agent_v1”) 
> $GOPATH/src/project/objects/customer_v1/customer_v1.go (import 
> “project/objects/customer_v1”) Etc.
>
>  
>
> I know that I needed to be able to support different versions of my 
> objects, so that is the directory structure I started using.  
>
>  
>

Is your project a package (for other developers to use) or an application?

 

> What I’m looking for: A solution that will:
>
> a)make builds reproducible.
>

If your project is a package, usually (IMHO) you should forget about making 
builds reproducible.
This is responsibility of the develper that uses your package in his 
project.

b)use SemVer 2.0.0 versioning.
>

You can just add tags or branches on your git repository following, as an 
example, the convention proposed by Dave Cheney.

> [...]

> e)use the standard Go tooling as much as possible.  Only use 
> other tooling where the standard Go tooling won’t work for package/version 
> management.
>

For web applications I use the layout proposed by Dave Cheney in db (but 
this layout seems to be used by other projects, too).
I use gb build when building, since it is convenient, but I use standard go 
tools for everything else, using this script named go+"
#!/bin/sh
# Execute the go tool for the current project.
# The project should have the layout as defined by the gb tool.
GOPATH="$PWD:$PWD/vendor" GOBIN="$PWD/bin" go $@

When importing dependencies I use gb vendor fetch, but for some cases I 
just clone the repository inside vendor/src/.

If your project is a package you can import the dependency in a vendor 
directory.  There are some example in the Go standard library.
However you should be careful, since some packages can not be imported 
multiple time (like the SQL drivers).


Manlio 

-- 
You received this message because you are subscribed 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] Handshake failed when using builtin TLS package: no cipher suite supported by both client and server

[Alexandr Emelin]

When using builtin TLS for http/websocket server I noticed that handshakes 
from some old browser clients fail. The reason why I find this strange is 
that other TLS implementations work with those connections without any 
problems. I used ssllabs.com/ssltest/  to 
emulate handshakes.

To be more specific: clients using Chrome 49 on Windows XP SP3 can't 
establish secure connection with my Go server. When I use Heroku reverse 
proxy in front of the app - connection succesfully established using TLS 
1.2. In case of Go I see "*tls: no cipher suite supported by both client 
and server*" message in server log.

I investigated this a bit and found that actually client and server have 
many cipher suites in common but none of them set in setCipherSuite 

 
function. Here is list of supported and preference suites:

Supported: []uint16{0xc02f, 0xcca8, 0xcc13, 0xc014, 0xc013, 0x9c, 0x35, 0x2f, 
0xa}
Preference: []uint16{0x5600, 0xc02f, 0xc02b, 0xc030, 0xc02c, 0xc011, 0xc007, 
0xc013, 0xc009, 0xc014, 0xc00a, 0x9c, 0x9d, 0x5, 0x2f, 0x35, 0xc012, 0xa}


They are all rejected by this code 

 (some 
because there were no rsaSignOk set, some because there was no rsaDecryptOk 
set).

trying 0xc02f for version 0x303 
reason rejected: !rsaSignOk

trying 0xc013 for version 0x303 
reason rejected: !rsaSignOk

trying 0xc014 for version 0x303 
reason rejected: !rsaSignOk

trying 0x9c for version 0x303   
reason rejected: !rsaDecryptOk

trying 0x2f for version 0x303   
reason rejected: !rsaDecryptOk

trying 0x35 for version 0x303   
reason rejected: !rsaDecryptOk

trying 0xa for version 0x303
reason rejected: !rsaDecryptOk


I am not skilled in TLS area so looking for help – what's going on here, 
why Go implementation does not support connections supported by other TLS 
termination proxies?

-- 
You received this message because you are subscribed 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.