Thanks again @thepudds for the helpful info.
with module aware go get -u at tip on golang.org, it says
"""
The -u flag instructs get to update dependencies to use newer minor or
patch releases when available. Continuing the previous example, 'go get -u
A' will use the latest A with B v1.3.1 (not B v1.2.3).
"""
For example, if I have a requirements for M vQ.R.S and the latest available
minor or patch release is
M vQ.R.{S+1}-alpha.1, with nothing else after vQ.R.S available.
Then does go get -u in module aware mode update to the alpha? If so,
should it? (I would think not,
but reading the docs I would think it would update to the alpha)
Scott
On 16 September 2018 at 16:44, <thepudds1...@gmail.com> wrote:
> Hi Scott,
>
> Modules do provide support for semver pre-release notation. You can read
> more about it in these sections of the documentation, for example:
>
> https://tip.golang.org/cmd/go/#hdr-Module_queries
> https://tip.golang.org/cmd/go/#hdr-Pseudo_versions
> https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get
>
> --thepudds
>
> On Sunday, September 16, 2018 at 10:31:43 AM UTC-4, Scott Cotton wrote:
>>
>> Thanks Sameer,
>>
>> I have a question about semver and modules, perhaps it was already
>> answered somewhere, but if so I don't know where.
>>
>> The question is: semver.org allows for pre-release notation, the
>> document below does not mention pre-release.
>> To some extent Go uses pre-releases.
>>
>> I, for one, find the idea useful and would like to use pre-release info
>> with modules.
>>
>> So can anyone comment, inform, or provide a pointer to some documentation
>> about pre-releases as they relate to modules?
>>
>> Best,
>> Scott
>>
>> On 15 September 2018 at 22:11, Sameer Ajmani <sam...@golang.org> wrote:
>>
>>> Thanks. The relationship between semantic versioning and Go packages is
>>> described in detail here: https://research.swtch.com/vgo-import
>>> On Sat, Sep 15, 2018 at 3:52 PM <thepud...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> One additional set of brief comments.
>>>>
>>>> This was a fairly nuanced and long thread, and I'm pretty sure I did
>>>> not follow all of it, but I think a question related to the conversation
>>>> here is -- what does 'require foo v1.1.1' really mean?
>>>>
>>>> Perhaps one way to think about that usage of the verb 'require' is that
>>>> it really needs to be read in the context of semantic versioning (
>>>> https://semver.org).
>>>>
>>>> If something states it requires v1.1.1 of foo, in the context of
>>>> semantic versioning that really means that particular requirement for
>>>> v1.1.1 would be satisfied by foo >= v1.1.1 and < v2, given semver defines
>>>> versions in that interval to be valid and backwards compatible
>>>> substitutions for v1.1.1 (and anything v2 or higher is considered
>>>> incompatible with any v1 version).
>>>>
>>>> And a variation of that first question is -- what does it mean for a
>>>> build if you have both a 'require foo v1.1.1' and a 'require foo v1.2.2'?
>>>>
>>>> One initial guess might be that the build ends up with two copies of
>>>> foo (v1.1.1 and v1.2.2) given there are two 'require' statements with those
>>>> two different versions. That is a reasonable guess, but not actually what
>>>> happens.
>>>>
>>>> If you instead read that verb 'require' in the context of semantic
>>>> versioning, it means that if the build instead picks a _single_ copy of foo
>>>> at version v1.2.2, that actually would satisfy _both_ of the requirements
>>>> for v1.1.1 and v1.2.2 (given v1.2.2 is defined by semver to be a backwards
>>>> compatible substitution for v1.1.1). And of course, this is what the go
>>>> build system actually would do in this scenario.
>>>>
>>>> Said another way, when you use modules, the go command _mandates_ that
>>>> modules use semantic versioning and expects that the versions accurately
>>>> describe compatibility: it assumes that v1.2.2 is a backwards compatible
>>>> replacement for v1.1.1, and hence v1.2.2 is a valid answer if you have both
>>>> 'require foo v1.1.1' and a 'require foo v1.2.2'.
>>>>
>>>> In any event, this is all still fairly new, and everyone is still
>>>> learning about the overall system. (The broader community is of course
>>>> learning about the new system, but even the people who implemented this
>>>> system are in a learning phase, including because they are learning about
>>>> how the community will use the new system).
>>>>
>>>> --thepudds
>>>>
>>>> On Saturday, September 15, 2018 at 1:11:49 PM UTC-4, Scott Cotton wrote:
>>>>>
>>>>> Thanks! Very useful.
>>>>>
>>>>> +1 for aliasing "go mod list" to "go list -m"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 15 September 2018 at 18:59, <thepud...@gmail.com> wrote:
>>>>>
>>>> > "Maybe having a way for "go mod" to output what is used would be
>>>>>> less confusing?"
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> To see a list of the selected module versions, one way is to use use
>>>>>> 'go list -m all'. This shows the actual versions used based on all of
>>>>>> the
>>>>>> various requirements in a build. Sample output:
>>>>>>
>>>>>> $ go list -m all
>>>>>> example.com/my/module
>>>>>> github.com/aws/aws-sdk-go v1.15.35
>>>>>> github.com/go-ini/ini v1.25.4
>>>>>>
>>>>>> Another other useful tool is for inspecting requirements is 'go mod
>>>>>> graph' (which prints the module requirement graph), and if you are
>>>>>> curious
>>>>>> why a particular module is showing up in your go.mod, you can run 'go mod
>>>>>> why -m <module>' to answer that question.
>>>>>>
>>>>>> You can read some more about these here:
>>>>>>
>>>>>> https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_
>>>>>> build_list
>>>>>> https://tip.golang.org/cmd/go/#hdr-Explain_why_packages_or_
>>>>>> modules_are_needed
>>>>>> https://tip.golang.org/cmd/go/#hdr-Print_module_requirement_graph
>>>>>>
>>>>>> The first link above also provides a short description of the build
>>>>>> list, which is related to several of the questions raised in this thread:
>>>>>>
>>>>>> ----------------
>>>>>> "The set of modules providing packages to builds is called the
>>>>>> "build list". The build list initially contains only the main module.
>>>>>> Then
>>>>>> the go command adds to the list the exact module versions required by
>>>>>> modules already on the list, recursively, until there is nothing left to
>>>>>> add to the list. If multiple versions of a particular module are added to
>>>>>> the list, then at the end only the latest version (according to semantic
>>>>>> version ordering) is kept for use in the build."
>>>>>> ----------------
>>>>>>
>>>>>> --thepudds
>>>>>>
>>>>>> On Saturday, September 15, 2018 at 6:34:55 AM UTC-4, Scott Cotton
>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks for the clarification.
>>>>>>>
>>>>>>> Maybe having a way for "go mod" to output what is used would be less
>>>>>>> confusing? I would have found so at least.
>>>>>>>
>>>>>>> Cycles crossing major versions may be more problematic.
>>>>>>>
>>>>>>> similarly in the case of coordinating a collection of modules,
>>>>>>> dependency cycles may lead unintentionally to different used versions
>>>>>>> depending on the build context. While the potential use of multiple
>>>>>>> versions is a useful feature of modules, I am not convinced
>>>>>>> that in this context it is desirable. Also, if cycles can span
>>>>>>> arbitrarily large sets of uncoordinated modules, then it seems to me
>>>>>>> that
>>>>>>> is not the intended use case for cycles and that might be
>>>>>>> undesirable or even lead to the inability of a module maintainer in the
>>>>>>> cycle
>>>>>>> to effectively propagate an update.
>>>>>>>
>>>>>>> If I come across anything more concrete, I'll file an issue. Just
>>>>>>> food for thought at this point.
>>>>>>>
>>>>>>> Best
>>>>>>> Scott
>>>>>>>
>>>>>>> On Saturday, 15 September 2018 02:45:50 UTC+2, Sameer Ajmani wrote:
>>>>>>>>
>>>>>>>> Go modules can use the listed version or later minor versions. So
>>>>>>>> if B depends on v1.11 of A, then it can also work with v1.12 of A.
>>>>>>>> Therefore a valid set of versions for the build is A v1.12 and B v1.3.
>>>>>>>>
>>>>>>>> On Mon, Sep 10, 2018 at 1:28 AM Scott Cotton <w...@iri-labs.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Well, ok.
>>>>>>>>>
>>>>>>>>> Did you mean if A v1.12 of a module depends on v1.3 of B which
>>>>>>>>> depends on v1.11 of A?
>>>>>>>>>
>>>>>>>>> So go modules don't actually necessarily depend on the listed
>>>>>>>>> dependencies?
>>>>>>>>>
>>>>>>>>> That is quite counteruintintive to me.
>>>>>>>>>
>>>>>>>>> It is much simpler in any case to use acyclic dependencies.
>>>>>>>>>
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 10 September 2018 at 04:25, Sameer Ajmani <sam...@golang.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I think there's a disconnection between how you and I understand
>>>>>>>>>> this system works. In a given build, there is only a single version
>>>>>>>>>> of a
>>>>>>>>>> module; there cannot be multiple copies, let alone many copies.So if
>>>>>>>>>> v1.11
>>>>>>>>>> of module A depends on v1.3 of module B, which in turn depends on
>>>>>>>>>> v1.12 of
>>>>>>>>>> module A, then the build will choose A v1.12. The is only one
>>>>>>>>>> version of A
>>>>>>>>>> in the build.
>>>>>>>>>>
>>>>>>>>>> On Sun, Sep 9, 2018 at 1:40 PM Scott Cotton <w...@iri-labs.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Sameer,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for asking, here are some thoughts,
>>>>>>>>>>>
>>>>>>>>>>> With time, this could create man many many copies of (different
>>>>>>>>>>> versions) of a module.
>>>>>>>>>>> this would slow down fetch, storage, compilation, etc
>>>>>>>>>>> potentially a lot, and it would only
>>>>>>>>>>> get worse and worse over time.
>>>>>>>>>>>
>>>>>>>>>>> if a security patch is applied to the most recent version in a
>>>>>>>>>>> version-compatible space of
>>>>>>>>>>> a module that depends on an earlier version of itself, then the
>>>>>>>>>>> security hole may still exist.
>>>>>>>>>>> Moreover, if the SCC of module dependencies is outside the
>>>>>>>>>>> control of the authors of the
>>>>>>>>>>> module being patched, it seems there is might be no way they
>>>>>>>>>>> could propagate the patch
>>>>>>>>>>> without editing history, which violates the very notion of
>>>>>>>>>>> versioning to begin with.
>>>>>>>>>>>
>>>>>>>>>>> The notion of software moving forward by versioning is in part
>>>>>>>>>>> an increase in reliability,
>>>>>>>>>>> not just security patches, so I would be frightened to use
>>>>>>>>>>> cyclic modules even in code
>>>>>>>>>>> for which I were certain there would be no security patches
>>>>>>>>>>> (like fixed memory, known cpu bounds
>>>>>>>>>>> math algorithms for example)
>>>>>>>>>>>
>>>>>>>>>>> Other than that, it is to me very confusing and
>>>>>>>>>>> counter-intuitive that a version of some software
>>>>>>>>>>> depend on a previous version of itself. Maybe I'm missing
>>>>>>>>>>> something in the modules
>>>>>>>>>>> specification or vision, and maybe, (even hopefully) I am wrong
>>>>>>>>>>> about these concerns.
>>>>>>>>>>>
>>>>>>>>>>> I could list more related ideas, but given that I might be wrong
>>>>>>>>>>> I'll leave it at that.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Scott
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9 September 2018 at 19:19, Sameer Ajmani <sam...@golang.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If a module depends on an earlier version itself, and
>>>>>>>>>>>> successive versions are backwards compatible, why is it not OK for
>>>>>>>>>>>> the
>>>>>>>>>>>> current version to satisfy that dependency?
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton <w...@iri-labs.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Sameer,
>>>>>>>>>>>>>
>>>>>>>>>>>>> When I had a module self-dependency, I considered the fact
>>>>>>>>>>>>> that it worked a bug. I had not followed
>>>>>>>>>>>>> closely enough til this discussion to think of it as expected.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As someone who has a tendency to often ask themself: "worse
>>>>>>>>>>>>> case how can this be a problem?"
>>>>>>>>>>>>>
>>>>>>>>>>>>> the list is indeed long and severe for modules which depend on
>>>>>>>>>>>>> themselves backwards in time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For cyclic dependencies which are somehow synchronised so that
>>>>>>>>>>>>> there is no backwards in time
>>>>>>>>>>>>> propagation, my impression would be "that's complicated", but
>>>>>>>>>>>>> I can't see offhand how it would be
>>>>>>>>>>>>> as problematic as backward in time self dependencies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9 September 2018 at 18:38, Sameer Ajmani <sam...@golang.org
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> With respect to errors, I'm asking how things failed when you
>>>>>>>>>>>>>> had a cyclic module dependency. My expectation is that this
>>>>>>>>>>>>>> should just
>>>>>>>>>>>>>> work. If your module 0.12 has a dependency on itself with min
>>>>>>>>>>>>>> version 0.11,
>>>>>>>>>>>>>> then 0.12 satisfies that dependency (as long as it's following
>>>>>>>>>>>>>> the import
>>>>>>>>>>>>>> compatibility rule, which isn't necessarily expected for pre-1.0
>>>>>>>>>>>>>> modules).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Sep 9, 2018 at 9:10 AM Scott Cotton <
>>>>>>>>>>>>>> w...@iri-labs.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Sameer,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't know what is considered an error and not an error
>>>>>>>>>>>>>>> with cyclic module dependencies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Honestly, it makes my head hurt and simply requires too much
>>>>>>>>>>>>>>> thought that I'd rather spend on the code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For example, I don't want to think what will happen to some
>>>>>>>>>>>>>>> SCC in a module dependency graph after
>>>>>>>>>>>>>>> a decade of development, in particular if a module can
>>>>>>>>>>>>>>> depend on an earlier version of itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9 September 2018 at 14:19, Sameer Ajmani <
>>>>>>>>>>>>>>> sam...@golang.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Are you seeing errors when there are cyclic module
>>>>>>>>>>>>>>>> dependencies? As I recall, cyclic dependencies between modules
>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>> packages) must be allowed:
>>>>>>>>>>>>>>>> https://research.swtch.com/vgo-mvs
>>>>>>>>>>>>>>>> "Note that F 1.1 requires G 1.1, but G 1.1 also requires F
>>>>>>>>>>>>>>>> 1.1. Declaring this kind of cycle can be important when
>>>>>>>>>>>>>>>> singleton
>>>>>>>>>>>>>>>> functionality moves from one module to another. Our algorithms
>>>>>>>>>>>>>>>> must not
>>>>>>>>>>>>>>>> assume the module requirement graph is acyclic."
>>>>>>>>>>>>>>>> On Sun, Sep 9, 2018 at 7:58 AM Scott Cotton <
>>>>>>>>>>>>>>>> w...@iri-labs.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Paul,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9 September 2018 at 13:44, Paul Jolly <pa...@myitcv.io>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Scott,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> > Should cyclic module dependencies be allowed?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, indeed in some situations they are totally necessary.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I wrote up an experience report on this very topic:
>>>>>>>>>>>>>>>>>> https://gist.github.com/myitcv
>>>>>>>>>>>>>>>>>> /79c3f12372e13b0cbbdf0411c8c46fd5
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Interesting. I'm not sure what cyclic module dependencies
>>>>>>>>>>>>>>>>> means. I do know some package managers (not go) boast of
>>>>>>>>>>>>>>>>> having a "solid
>>>>>>>>>>>>>>>>> transitive dependency model". I hope that any cycles in
>>>>>>>>>>>>>>>>> modules
>>>>>>>>>>>>>>>>> dependencies are either avoided or treated in a very clear
>>>>>>>>>>>>>>>>> simple way by
>>>>>>>>>>>>>>>>> go's modules.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> > Should a module, following a cycle, be able to depend
>>>>>>>>>>>>>>>>>> on an earlier version of itself? (I saw this once...)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I can't see how this would work; indeed I can't even
>>>>>>>>>>>>>>>>>> unravel it in my
>>>>>>>>>>>>>>>>>> head! Do you have a concrete example to help explain?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Unfortunately, my concrete example is lost in sands of
>>>>>>>>>>>>>>>>> time, so I can only give a rough idea. I had cyclic module
>>>>>>>>>>>>>>>>> dependencies,
>>>>>>>>>>>>>>>>> somewhat unintended, but it crept in via some test case. I
>>>>>>>>>>>>>>>>> was playing
>>>>>>>>>>>>>>>>> with 111 or late 111 release candidate with it and asked it
>>>>>>>>>>>>>>>>> to rebuild
>>>>>>>>>>>>>>>>> go.mod at an untagged HEAD (I think) that was a few commits
>>>>>>>>>>>>>>>>> ahead of say
>>>>>>>>>>>>>>>>> v0.1.2. Then go.mod had that my module required v0.1.1 of
>>>>>>>>>>>>>>>>> itself in go.mod
>>>>>>>>>>>>>>>>> "indirectly". All I could figure out was that the module
>>>>>>>>>>>>>>>>> dependency cycle
>>>>>>>>>>>>>>>>> A -> B -> A had B depending on an older version of A via a
>>>>>>>>>>>>>>>>> test case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Scott Cotton
>>>>>>>>>>>>>>>>> President, IRI France SAS
>>>>>>>>>>>>>>>>> http://www.iri-labs.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.
>>>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Scott Cotton
>>>>>>>>>>>>>>> President, IRI France SAS
>>>>>>>>>>>>>>> http://www.iri-labs.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Scott Cotton
>>>>>>>>>>>>> President, IRI France SAS
>>>>>>>>>>>>> http://www.iri-labs.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Scott Cotton
>>>>>>>>>>> President, IRI France SAS
>>>>>>>>>>> http://www.iri-labs.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Scott Cotton
>>>>>>>>> http://www.iri-labs.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "golang-nuts" group.
>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>>>> pic/golang-nuts/h2r8ktgOOZI/unsubscribe.
>>>>>>
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> golang-nuts...@googlegroups.com.
>>>>>>
>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Scott Cotton
>>>>> http://www.iri-labs.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.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/golang-nuts/h2r8ktgOOZI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Scott Cotton
>> http://www.iri-labs.com
>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/h2r8ktgOOZI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Scott Cotton
http://www.iri-labs.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.
For more options, visit https://groups.google.com/d/optout.
