[go-nuts] Re: Bcrypt isn't comparing stored password hash properly

[Gabriel Simmer]

I guess I should update this with the solution;

As it turns out, the method I was using for getting user input was 
returning the user input in some funky way that I couldn't trace/replicate. 
I went with randomly generating the password, and that inserts/verifies 
just fine.

On Tuesday, December 5, 2017 at 11:39:38 AM UTC-8, Gabriel Simmer wrote:
>
> Hey Gophers,
>
> I have a bit of a headscratcher for you guys today, hoping someone will be 
> able to help me track down where I've gone wrong. I have an SQLite3 
> database with user login info, including username, hashed password w/ 
> bcrypt, and so on. I also have a "setup" method that is triggered on the 
> first run of the application, which includes creating the database, setting 
> an admin password and fetching assets. There's one hitch - the hashed 
> password doesn't seem to be either:
>
>  - Stored properly
>  - Hashed properly
>  - Compared properly
>
> I've done some extensive testing and it appears bcrypt *is* hashing the 
> password, and I can compare it successfully right after, and before I put 
> it into the database. All good. However when I pull the hash from the 
> database later (on user login), bcrypt doesn't see the hash and the 
> password as equal and errors out. 
>
> Here is the GitHub repository's branch 
> , if you want to fully test 
> the application, but the relevant files are setup.go 
>  and 
> router/router.go 
> . 
> I've left in some debugging checks, and will happily answer any questions I 
> haven't clarified. 
>

-- 
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 go1.10beta1 a debug or unoptimized build? (possible regression)

[Jack]

I ran the same benchmarks on my local linux NUC and the code actually had 
small performance improvements between 1.9 and 1.10 (some better some not).

It appears to be isolated to running the benchmarks on my mac.

On Saturday, December 23, 2017 at 5:38:31 PM UTC-6, Krzysztof Kowalczyk 
wrote:
>
> Most likely it's 
> https://github.com/golang/go/commit/d8ff3d592088ef175222dbf69991887f0dd458d6#diff-b884a414ef2918cd3d75c6799cb62581
>  
> which seems to add fair amount of code to time.Now()
>
> You can see history of commits to that file with 
> https://github.com/golang/go/commits/master/src/runtime/sys_darwin_amd64.s
>
> On Saturday, December 23, 2017 at 9:32:38 AM UTC-8, Daniel Theophanes 
> wrote:
>>
>> It did change. See https://golang.org/cl/76990 and 
>> https://github.com/golang/go/issues/20427
>> .
>>
>> The numbers you posted look larger then anticipated if it is the same one.
>>
>

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

[go-nuts] Re: dep and versioning : how are conflicts dealt with ?

[David Collier-Brown]

>
>
> A bit of an unresolved problem in several universes, one of which contains 
Go (;-)) 

I have some definite opinions: I grew up in a universe where it was 
resoilved in Multics, rediscoverd in Solaris and independantly rediscovered 
in Linux glibc. Way more information that you want in 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/

The best advice I can give in the current context is to chose an A-B pair 
with a common C, even if it causes you to go back to an undesirably early 
release of either A or B. 

It is, after all, an NP-complete problem: there is no guarantee that there 
is a good answer, save to *not have* the problem, as the Multicians found.

--dave

-- 
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 go1.10beta1 a debug or unoptimized build? (possible regression)

[Krzysztof Kowalczyk]

Most likely 
it's 
https://github.com/golang/go/commit/d8ff3d592088ef175222dbf69991887f0dd458d6#diff-b884a414ef2918cd3d75c6799cb62581
 
which seems to add fair amount of code to time.Now()

You can see history of commits to that file with 
https://github.com/golang/go/commits/master/src/runtime/sys_darwin_amd64.s

On Saturday, December 23, 2017 at 9:32:38 AM UTC-8, Daniel Theophanes wrote:
>
> It did change. See https://golang.org/cl/76990 and 
> https://github.com/golang/go/issues/20427
> .
>
> The numbers you posted look larger then anticipated if it is the same one.
>

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

[go-nuts] Re: github repo names with "go-" prefix?

[Manlio Perillo]

Il giorno sabato 23 dicembre 2017 19:18:14 UTC+1, Tim Peoples ha scritto:
>
>
> I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages.
>
> Is this recommended somewhere?  If so, where?
>
> Conversely, is it explicitly discouraged?
>
>
>
The only reason to use the go prefix is when, on the same github account, 
you want to publish an implementation of a protocol (e.g. a client for 
Amazon S3) in multiple programming languages (e.g. go-s3, python-s3, 
rust-s3).


Manlio Perillo

-- 
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] [mysql] 2017/12/23 11:09:37 packets.go:141: write tcp 127.0.0.1:20630->127.0.0.1:3306: write: broken pipe

[Justin Israel]

On Sun, Dec 24, 2017, 2:22 AM jobs jobs  wrote:

> how to fix it?



2017/12/23 11:09:37 packets.go:141: write tcp 127.0.0.1:20630->
127.0.0.1:3306: write: broken pipe

You haven't provided any information or code, so anyone offering help is
only going to be guessing.
Try and figure out if you are using a connection after it has been closed
by the server.  Are you checking all errors from your calls?

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

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

Re: [go-nuts] Re: golang for AI

[Maurizio Totti]

2017-12-22 15:08 GMT+01:00 Fabien :
> I'm working in an AI research lab and use golang a lot, so I would tend to
> say yes. We're working in the symbolic AI field though (ontologies,
> constraint solving and that stuff), not machine learning.
>
> Le vendredi 22 décembre 2017 07:33:04 UTC+1, Lee Rick a écrit :
>>
>> hi,
>>Artificial intelligence is a big trend, and i want to know whether or
>> not to consider golang playing a role in artificial intelligence?
>>Whether to consider developing some basic artificial intelligence
>> package with support package, use just as python.
>
Hi have found https://github.com/josephmisiti/awesome-machine-learning#go

-- 
Maurizio Totti

-- 
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: [ANN] A Typed ORM Library

[Eyal Posener]

Nice stuff Alexey! thanks for this link, haven't seen it so far.
Seems like we both got frustrated from the same issues with existing 
solutions :-)

We took pretty different approaches to solve the typed-ORM problem though.
The reform library has a larger run-time content, and keeps the generated 
code minimal, which is a very nice idea!
However, as it seems to me, there are still a lot of interface{}s, and 
strings to pass to the library functions, which I try to avoid. The current 
proposed orm implementation leaves zero guessing - the user does not need 
to know column names, SQL queries, expressions or types. All the functions 
are fully typed, which leaves no room for run-time bugs. I intend to keep 
it like that as much as possible.
I would love to hear your opinion about it, and if you could enlighten me 
with obstacles I will find in future development of this library, since it 
seem like you have some experience in this field.

Cheers!

On Saturday, December 23, 2017 at 9:21:09 PM UTC+2, Alexey Palazhchenko 
wrote:
>
> Hi,
>
> There is also https://github.com/go-reform/reform.
>
> –-–
> Alexey «AlekSi» Palazhchenko
>
>

-- 
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] github repo names with "go-" prefix?

[Tim Peoples]

On Saturday, December 23, 2017 at 11:36:45 AM UTC-8, Jakob Borg wrote:
>
> On 23 Dec 2017, at 19:18, Tim Peoples  
> wrote: 
> > 
> > I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages. 
>
> I think this is acceptable when you’re providing a library foo implemented 
> in several languages and naturally get go-foo, python-foo, ruby-foo etc 
> repositories. It’s still annoying but a natural effect of using the GitHub 
> etc namespace for package naming and not having a Go specific package 
> namespace. 
>
> In all other cases it’s discouraged. 
>
> //jb 
>

Sadly, that is rarely the case.

In fact, I often find authors with dozens of repos covering a number of 
languages -- yet, only their "go" repos are named as such (repos with no 
corresponding implementation in another language, mind you).

Oh well... :/

t.

-- 
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: github repo names with "go-" prefix?

[Tim Peoples]

On Saturday, December 23, 2017 at 11:06:35 AM UTC-8, Dave Cheney wrote:
>
> On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples  wrote: 
> > I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages. 
> > 
>
> I believe the zeitgeist originated with JavaScript. 
>
> > 
> > Is this recommended somewhere?  If so, where? 
> > 
>
> It is not recommended for your package’s  repository or directory name to 
> differ from its  package declaration. 
>
> > 
> > Conversely, is it explicitly discouraged? 
>
> Yes, for the reasons above, it’s confusing, also it’s redudant for the 
> same reasons go programmers do not start interface declarations with a 
> capital I. 
>
>
Thanks Dave, that's exactly what I'd assumed (but didn't want to overly 
expose my original bias).

I only asked because every time I see this, it tends to make me wince (and 
I often end up forking the repo just so I can rename it).

I suppose the real question is, "How do we get people to stop?" :D

-- 
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] github repo names with "go-" prefix?

[Jakob Borg]

On 23 Dec 2017, at 19:18, Tim Peoples  wrote:
> 
> I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently dropping 
> the prefix in the actual package name) -- yet a similar naming scheme doesn't 
> seem to be commonplace among many other languages.

I think this is acceptable when you’re providing a library foo implemented in 
several languages and naturally get go-foo, python-foo, ruby-foo etc 
repositories. It’s still annoying but a natural effect of using the GitHub etc 
namespace for package naming and not having a Go specific package namespace.

In all other cases it’s discouraged.

//jb

-- 
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: [ANN] A Typed ORM Library

[Alexey Palazhchenko]

Hi,

There is also https://github.com/go-reform/reform.

–-–
Alexey «AlekSi» Palazhchenko

-- 
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: github repo names with "go-" prefix?

[Dave Cheney]

On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples  wrote:
> I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently dropping 
> the prefix in the actual package name) -- yet a similar naming scheme doesn't 
> seem to be commonplace among many other languages.
> 

I believe the zeitgeist originated with JavaScript.

> 
> Is this recommended somewhere?  If so, where?
>

It is not recommended for your package’s  repository or directory name to 
differ from its  package declaration. 

> 
> Conversely, is it explicitly discouraged?

Yes, for the reasons above, it’s confusing, also it’s redudant for the same 
reasons go programmers do not start interface declarations with a capital I. 

-- 
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: github repo names with "go-" prefix?

[Tim Peoples]

[*yes, I'm responding to myself (I tend to do that sometimes)*]

Hmm I suspect part of it may be coming from this PackagePublishing wiki 
page , 
where 
it's mentioned almost as a foregone conclusion yet may often be interpreted 
as a recommendation.

However, I'll assume the genesis is elsewhere.


On Saturday, December 23, 2017 at 10:18:14 AM UTC-8, Tim Peoples wrote:
>
>
> I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages.
>
> Is this recommended somewhere?  If so, where?
>
> Conversely, is it explicitly discouraged?
>
>
>

-- 
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] github repo names with "go-" prefix?

[Tim Peoples]

I've noticed a somewhat common practice of people naming their github 
repositories with a "go-" prefix (and then, of course, subsequently 
dropping the prefix in the actual package name) -- yet a similar naming 
scheme doesn't seem to be commonplace among many other languages.

Is this recommended somewhere?  If so, where?

Conversely, is it explicitly discouraged?


-- 
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: Announcing gophersat, a SAT and Pseudo-Boolean solver, v1.0.0

[Fabien]

Thanks for the link, I'll write a description of my problem.

Le samedi 23 décembre 2017 13:29:59 UTC+1, Mandolyte a écrit :
>
> Fabien, you mention below that generics would help... I encourage you to 
> make a fuller description of why/how generics would help and update this 
> wiki page to point to it:
> https://github.com/golang/go/wiki/ExperienceReports#generics
>
>
> On Thursday, December 21, 2017 at 8:25:53 PM UTC-5, Fabien wrote:
>>
>> Short answer : according to the few tests I ran, they are pretty close. 
>> You can use any of them, or, even better, both of them.
>>
>> Long answer :
>>
>> I have only compared them on about a dozen industrial problems, so take 
>> it with a grain of salt, but it's hard to name a winner. Gini is usually a 
>> little faster, but when it is slower, it is way slower than Gophersat. Gini 
>> is very good (sometimes even better than state-of-the-art C++ solvers, like 
>> glucose) on some very easy problems (those that can be solved in about 10 
>> to 50 ms), probably because it has a very good parser and low warmup costs. 
>> But it is not as good on harder problems, and it can only deal with pure 
>> SAT, CNF problems (and they can be exponentially bigger than their 
>> pseudo-boolean counterparts).
>>
>> So, if you must solve hundreds of easy problems in a second, and if your 
>> problem is described as a CNF and you have no control over that, picking 
>> gini might be a good choice. If your problem is a little harder, or if you 
>> have the possibility to describe it as a pseudo-boolean problem, gophersat 
>> will probably be better.
>>
>> Since they are not efficient on the same kinds of problems, using both of 
>> them concurrently might be interesting, too. Making them solve the same 
>> problem and stop them when an answer was found.
>>
>> When solving pure CNF problems, the current version of gophersat suffers 
>> from the fact that it can natively deal with cardinality constraints and 
>> pseudo-boolean constraints: binary clauses take a lot of space in memory, 
>> and a lot of time is spent in the solver figuring out whether we are 
>> dealing with a clause or a more complex constraint. In the next future, we 
>> will probably include the ability to compile an optimized version of the 
>> solver for pure sat problems via build tags. Having generics in the 
>> language would solve that issue too ;)
>>
>> Le jeudi 21 décembre 2017 16:44:24 UTC+1, Damian Gryski a écrit :
>>>
>>> How does it compare to https://github.com/IRIFrance/gini ?
>>
>>

-- 
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] dep and versioning : how are conflicts dealt with ?

[Fabien]

Hello gophers,

I'm currently trying to understand how versioning via dep currently works. 
There are a few things I don't understand. I know this is work in progress, 
and I don't know what's the current status about the famous diamond 
dependency issue : what happens when two dependencies A & B require a 
package C, but A requires version ^1.0 and B requires ^2.0 ? Is dep simply 
failing ? Are there two versions of the package in the vendor directory ? 
What are the good practice to follow for a package developper ?

-- 
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 go1.10beta1 a debug or unoptimized build? (possible regression)

[Daniel Theophanes]

It did change. See https://golang.org/cl/76990 and 
https://github.com/golang/go/issues/20427
.

The numbers you posted look larger then anticipated if it is the same one.

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

[go-nuts] [mysql] 2017/12/23 11:09:37 packets.go:141: write tcp 127.0.0.1:20630->127.0.0.1:3306: write: broken pipe

[jobs jobs]

how to fix it?

-- 
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 go1.10beta1 a debug or unoptimized build? (possible regression)

[jlindamo]

Hard to get a public test case (private code), but I noticed with go10, the 
profiler puts 99% flat time in time.now.  Did time.now change somehow?

(pprof) top1
Showing nodes accounting for 2.11mins, 99.90% of 2.11mins total
Dropped 26 nodes (cum <= 0.01mins)
Showing top 1 nodes out of 10
  flat  flat%   sum%cum   cum%
  2.11mins 99.90% 99.90%   2.11mins 99.90%  time.now
(pprof) list time.now
Total: 2.11mins
ROUTINE  time.now in 
/Users/jlindamo/sdk/go1.10beta1/src/runtime/sys_darwin_amd64.s
  2.11mins   2.11mins (flat, cum) 99.90% of Total
 .  .303: MOVQ SP, DI
 .  .304: MOVQ $0, SI
 .  .305: MOVQ $0, DX  // required as of Sierra; Issue 
16570
 .  .306: MOVL $(0x200+116), AX // gettimeofday
 .  .307: SYSCALL
  2.11mins   2.11mins308: CMPQ AX, $0
 .  .309: JNE inreg
 .  .310: MOVQ 0(SP), AX
 .  .311: MOVL 8(SP), DX
 .  .312:inreg:
 .  .313: // sec is in AX, usec in DX


On Friday, December 22, 2017 at 9:35:15 PM UTC-8, Daniel Theophanes wrote:
>
> The beta is a normal release, not debug or no opt. File an issue, if 
> possible try to get a minimal repro case you can post.

-- 
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: Announcing gophersat, a SAT and Pseudo-Boolean solver, v1.0.0

[Mandolyte]

Fabien, you mention below that generics would help... I encourage you to 
make a fuller description of why/how generics would help and update this 
wiki page to point to it:
https://github.com/golang/go/wiki/ExperienceReports#generics


On Thursday, December 21, 2017 at 8:25:53 PM UTC-5, Fabien wrote:
>
> Short answer : according to the few tests I ran, they are pretty close. 
> You can use any of them, or, even better, both of them.
>
> Long answer :
>
> I have only compared them on about a dozen industrial problems, so take it 
> with a grain of salt, but it's hard to name a winner. Gini is usually a 
> little faster, but when it is slower, it is way slower than Gophersat. Gini 
> is very good (sometimes even better than state-of-the-art C++ solvers, like 
> glucose) on some very easy problems (those that can be solved in about 10 
> to 50 ms), probably because it has a very good parser and low warmup costs. 
> But it is not as good on harder problems, and it can only deal with pure 
> SAT, CNF problems (and they can be exponentially bigger than their 
> pseudo-boolean counterparts).
>
> So, if you must solve hundreds of easy problems in a second, and if your 
> problem is described as a CNF and you have no control over that, picking 
> gini might be a good choice. If your problem is a little harder, or if you 
> have the possibility to describe it as a pseudo-boolean problem, gophersat 
> will probably be better.
>
> Since they are not efficient on the same kinds of problems, using both of 
> them concurrently might be interesting, too. Making them solve the same 
> problem and stop them when an answer was found.
>
> When solving pure CNF problems, the current version of gophersat suffers 
> from the fact that it can natively deal with cardinality constraints and 
> pseudo-boolean constraints: binary clauses take a lot of space in memory, 
> and a lot of time is spent in the solver figuring out whether we are 
> dealing with a clause or a more complex constraint. In the next future, we 
> will probably include the ability to compile an optimized version of the 
> solver for pure sat problems via build tags. Having generics in the 
> language would solve that issue too ;)
>
> Le jeudi 21 décembre 2017 16:44:24 UTC+1, Damian Gryski a écrit :
>>
>> How does it compare to https://github.com/IRIFrance/gini ?
>
>

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