[go-nuts] Re: go 1.13.1 (linux x64): time.After not working as expected
On Monday, October 14, 2019 at 5:53:23 AM UTC-7, Jeff Kayser wrote: > > I'm working through the most excellent book "Concurrency in Go", doing the > example on page 162-166. My code is here: > > https://play.golang.org/p/7kokkAIdhov > > The program is not triggering the timeout section of the code (lines > 103-103 in the playground code). > > All of the other examples have worked as expected, including the one just > before this, which is almost identical, except for a couple of tweaks. > This is the first one that hasn't worked. > > What am I doing wrong? > > ~Jeff Kayser > > Forgot to increment the variable "i" (the loop counter). Doh! My bad. I found it. Thanks for looking over my buggy code. After I fixed that, I also discovered that, by ending the loop after two iterations, the goroutine ended, closed the channels, and then the main program detected the channel closing, rather than the timeout. Lovely. As Benny Hill would say: "Learning all the time". The book "Concurrency in Go" is absolutely fabulous, second only to The Go Programming Language. We are so lucky to have all those good Go books. Thanks again. Jeff Kayser -- You received this message because you are subscribed to the Google 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/683804bf-b6de-4ebe-a559-f167d17391e5%40googlegroups.com.
[go-nuts] go 1.13.1 (linux x64): time.After not working as expected
I'm working through the most excellent book "Concurrency in Go", doing the example on page 162-166. My code is here: https://play.golang.org/p/7kokkAIdhov The program is not triggering the timeout section of the code (lines 103-103 in the playground code). All of the other examples have worked as expected, including the one just before this, which is almost identical, except for a couple of tweaks. This is the first one that hasn't worked. What am I doing wrong? ~Jeff Kayser -- You received this message because you are subscribed to the Google 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/6316c901-9425-4d4f-9bb3-2f7d4aed94a5%40googlegroups.com.
[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...
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 <golang-nuts@googlegroups.com> Cc: manlio.peri...@gmail.com; jeffkays...@gmail.com; Jeff Kayser <jeff.kay...@jibeconsulting.com> 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 <golan...@googlegroups.com> Cc: Jeff Kayser <jeff@jibeconsulting.com>; 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<mailto: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 pa
[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...
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 <jeff.kay...@jibeconsulting.com> Cc: golang-nuts <golang-nuts@googlegroups.com>; jeffkays...@gmail.com Subject: Re: Go package/version management, vendoring, dep, gb, etc... On Sun, Feb 5, 2017 at 11:39 PM, Jeff Kayser <jeff.kay...@jibeconsulting.com> 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.
[go-nuts] RE: Go package/version management, vendoring, dep, gb, etc...
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 <golang-nuts@googlegroups.com> Cc: Jeff Kayser <jeff.kay...@jibeconsulting.com>; 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.
