Re: [go-nuts] Contracts and fused multiply add

[Wojciech S. Czarnecki]

On Wed, 12 Sep 2018 10:54:15 -0700
jimmy frasche  wrote:

> because that misses cases like
>   type Float float64

I am working on constraint examples for CGG.
[https://github.com/ohir/gonerics] (Appendix A)

With CGG `for type` contracts now you can use constraint
that allows for any custom type of base float64

`for type T = float64() // T must be assignable to given base via a cast`

so example func becomes:

func maMustFMA(a, b, c type T) type T {

   for type T = float64()

   // Here yours Float match and
   // a, b, c are treated by the code as float64
   //...

}

I assume that this is not enough for you to narrow
contract to 'FMA capable'. Or is it?

(As by the https://github.com/golang/go/issues/25819
comments, given float64 compiler should know).

Is that true? If so, what kind of constraint 
(in terms of Go type system) would fit your needs
in place of below "someConstraint".

func maMustFMA(a, b, c type T) type T {
for type (
T = float64()
T = someConstraint // 
)
// ...
}

Thanks in advance for the answer

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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] liteide x34.2 released

[visualfc]

Hi, all.
LiteIDE X34.2 released!
This version fix and update x34.1 to better support go1.11 modules

* LiteIDE Home
 
* LiteIDE Source code
 
* Release downloads
* 
* 

### 2018.09.15 Ver X34.2
* LiteIDE
* fix gotools & gocode support go1.11 modules sub folder
* support custom GO111MODULE setup
* LiteApp
* fix #939 display right margin at column wrong
* change mime type check fullname first
* GolangCode
* fix #970 goplay editor cgo crash
* GolangEdit
* find usages / rename symbol add skip GOROOT actions
* GolangPackage
* add custom GO111MODULE setup
* LiteEditor
* add extra mouse navagite go back and forward
* add gomod.xml for go.mod syntax
* LiteBuild
* add gomod.xml for go.mod build command
* gotools & gocode
* fix go1.11 modules sub folder

Sent from YoMail for Gmail

-- 
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] modules and package cyclic dips

[Scott Cotton]

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  > 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 > > 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 >> > 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 >>> > 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  > 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 > > wrote:
>>
>>> With respect to errors, I'm asking how things failed when you had a 
>>> 

Re: [go-nuts] Contracts and fused multiply add

[Robert Engels]

Why do you need the for...

Keywords with dual meaning is never a good idea. 

Sent from my iPhone

> On Sep 15, 2018, at 4:53 AM, Wojciech S. Czarnecki  wrote:
> 
> On Wed, 12 Sep 2018 10:54:15 -0700
> jimmy frasche  wrote:
> 
>> because that misses cases like
>>  type Float float64
> 
> I am working on constraint examples for CGG.
> [https://github.com/ohir/gonerics] (Appendix A)
> 
> With CGG `for type` contracts now you can use constraint
> that allows for any custom type of base float64
> 
> `for type T = float64() // T must be assignable to given base via a cast`
> 
> so example func becomes:
> 
> func maMustFMA(a, b, c type T) type T {
> 
>   for type T = float64()
> 
>   // Here yours Float match and
>   // a, b, c are treated by the code as float64
>   //...
> 
> }
> 
> I assume that this is not enough for you to narrow
> contract to 'FMA capable'. Or is it?
> 
> (As by the https://github.com/golang/go/issues/25819
> comments, given float64 compiler should know).
> 
> Is that true? If so, what kind of constraint 
> (in terms of Go type system) would fit your needs
> in place of below "someConstraint".
> 
> func maMustFMA(a, b, c type T) type T {
> for type (
>T = float64()
>T = someConstraint // 
> )
> // ...
> }
> 
> Thanks in advance for the answer
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Create a tcp proxy cluster

[sebassch]

Hello I want to create a tcp proxy that support seamless fail over I will like 
to know if there is a way to sync net.conn objects between 2 server active 
standby.

I use keepalived to have a flooting ip address but if one machine goes down all 
the users need to reconnect. 

Thanks! 

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

Re: [go-nuts] Is it possible to build a module without a hosted repository?

[K Davidson]

Well, my embarrassingly incorrect assumption came about from a package I 
was writing recently; I was using the go mod tool to initialize my go.mod 
rather than writing the file myself, and as an import statement I first 
tried using the local filepath, which of coarse didn't work. Then I tried 
things like: "." (yielding error: unknown import path 
"_/home/k/code/go/delete": internal error: module loader did not resolve 
import" upon build (but it let me initialize the module without issue). 
What finally did work, was when I used a GitHub repo URL that I created 
only for this purpose, which is what ultimately brought about my 
assumption. It never occurred to me to use a fictitious import path 
because, well, there is nothing there. 

So it was my mistake (*egg on my face ¯\_(ツ)_/¯)

But thx for the replies.

-K

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

Re: [go-nuts] Is it possible to build a module without a hosted repository?

[K Davidson]

Well, my embarrassingly incorrect assumption came about from a package I 
was writing recently; I was using the go mod tool to initialize my go.mod 
rather than writing the file myself, and as an import statement I first 
tried using the local filepath, which of coarse didn't work. Then I tried 
things like: "." (yielding error: unknown import path 
"_/home/k/code/go/delete": internal error: module loader did not resolve 
import" upon build (but it let me initialize the module without issue). 
What finally did work, was when I used a GitHub repo URL that I created 
only for this purpose, which is what ultimately brought about my 
assumption. It never occurred to me to use a fictitious import path 
because, well, there is nothing there. 

So it was my mistake (*egg on my face ¯\_(ツ)_/¯)

But thx for the replies.

-K

On Friday, September 14, 2018 at 11:09:03 PM UTC-7, Jakob Borg wrote:
>
> I’m not sure I understand. My "go build" doesn’t reach out anywhere to 
> build a local program: 
>
> $ mkdir /tmp/project && cd /tmp/project/
>
> $ cat > main.go
> package main
>
> import "fmt"
>
> func main() { fmt.Println("Oi") }
>
> $ cat > go.mod
> module totally/fake/project
>
> $ go build
>
> $ ./project
> Oi
>
>
>
> On 15 Sep 2018, at 03:32, K Davidson > 
> wrote:
>
> I appologize if this has been asked before, I tried searching but all the 
> posts I could find of a similar nature were asking about dependencies, 
> rather than about the module specifically.
>
> Is it possible to have a package as a module without having it hosted 
> somewhere (like Github, or other internet endpoint?) 
>
> I often like to prototype ideas locally, but the idea usually isn't worth 
> all the effort of making a new repository, and all the work to set up git, 
> as most of the time I end up scrapping it. However with GO111MODULE=on, go 
> build seems to require a module line that is hosted at a url (ie: 
> github.com/kidoda/quikcam) in order to build. With dependencies I can 
> just use the -replace directive to point to a local directory, but I can't 
> seem to find a way to do the same with the module.
>
> Is there a way that I can build my package as a module without having to 
> host it on the internet?
>
> Thanks in advance,
>
> -K
>
> -- 
> 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 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] modules and package cyclic dips

[thepudds1460]

   > "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 
' 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  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  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  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 me

Re: [go-nuts] modules and package cyclic dips

[Scott Cotton]

Thanks!  Very useful.

+1 for aliasing "go mod list" to "go list -m"





On 15 September 2018 at 18:59,  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
> ' 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  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  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  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 par

Re: [go-nuts] Contracts and fused multiply add

[robert engels]

> On Sep 15, 2018, at 7:31 AM, Wojciech S. Czarnecki  wrote:
> 
> On Sat, 15 Sep 2018 06:36:35 -0500
> Robert Engels  wrote:
> 
>> Why do you need the for...
> 
> Because 'for type' means 'contract'
> Because CGG contracts are for each typeholder
> and expressed in terms of already familiar types.
> 
> Thats why right after `for type` you see `T`.
> 
> `for type T = constraint` "execute the body".
> 
> It just reads.
> 
>> Keywords with dual meaning is never a good idea. 
> There always is some context to read within.
> 

Not for standardized keywords like ‘for’.

Just my opinion of your proposals, the syntax is very clumsy, and not intuitive.

> See https://github.com/ohir/gonerics examples
> and point where it could be confusing. 
> 
> I am also open for any other contrived examples
> showing possible confusion.
> 
> Note the contract placement rules as described, please.
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] modules and package cyclic dips

[thepudds1460]

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, > 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 ' 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 tha

Re: [go-nuts] modules and package cyclic dips

[Sameer Ajmani]

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  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,  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 ' 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

[go-nuts] efficient way to csv.Reader() from a chan of string

[Sherif Eldeeb]

Greetings all,
I have a channel of 'string', where each item is a single CSV log line that 
I want to convert to columns using "encoding/csv"
Currently, I am creating a new csv.Reader at each iteration for each item, 
which is much more work than it needs to be.


for i := range feederChan {
r := csv.NewReader(strings.NewReader(i))
a := r.Read()
// Do stuff with a
// ...
}


I would really appreciate sharing with me if there's a way to iterate 
through a 'chan string' using 'csv.Reader()' without the need to create a 
new Reader for each item.
Thanks.

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

Re: [go-nuts] efficient way to csv.Reader() from a chan of string

[Yannic Bonenberger]

You can use a bytes.Buffer to create a single csv.Reader and write the log 
lines into that buffer.
The code will look roughly like this https://play.golang.org/p/gbCPwSsx5gy .
However, depending on the implementation of strings.Reader and the level of 
optimization the Go compiler does, your approach of creating a new csv.Reader 
for every iteration might actually be faster and consume less memory than my 
code.


Greetings all,
I have a channel of 'string', where each item is a single CSV log line that I 
want to convert to columns using "encoding/csv"
Currently, I am creating a new csv.Reader at each iteration for each item, 
which is much more work than it needs to be.


for i := range feederChan {
r := csv.NewReader(strings.NewReader(i))
a := r.Read()
// Do stuff with a
// ...
}


I would really appreciate sharing with me if there's a way to iterate through a 
'chan string' using 'csv.Reader()' without the need to create a new Reader for 
each item.
Thanks.

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

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

[go-nuts] Snapshot data with Go

[Kasun Vithanage]

I'm developing a *redis **like *server with Go. You can see the code repo 
here .
I need to dump my *Mutex Protected map* to a *file*. Simply *snapshot data 
to a file*.

In redis, it take snapshots of data using a fork as described in here 
.

// DB holds a thread safe struct for store data
type DB struct {
file map[string]*DataNode
mux sync.RWMutex
}

Here is my map. 

Is there a possibility in go to do this? I want to be my original DB to be 
lock free and non touched while the persistent carries on.

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