Re: [go-nuts] Re: Currying in Go

[evan . digby]

I played around tonight trying to come up with a better way, but instead I 
came up with 2 decidedly worse ways (particularly considering 
readability/maintenance is the primary concern of the question). I think 
they're novel enough to share! 

https://play.golang.org/p/w9YxsEFlF8

1) Original
2) Defining types with a consistent naming scheme - less typing, more 
obscurity!
3) Make a function that auto-currys - Like a curry-compiler... except 
requires you to type a whole auto-curry function along with some magic 
types to compile every possible combination of params and outputs! MAGIC!

I think if you lift the burden of pure currying (one argument always) and 
use closures with multiple arguments unless you specifically need to be 
able to pass around partial functions with one argument you will free 
yourself from producing cumbersome code like this.

That said, if each single argument partial function has a purpose as 
understood by its users, then you should be able to come up with a type 
name for each nested function and use that in your definition to clarify 
the intent of each "layer". It's pretty standard in Go to give type names 
to functions make explicit what you need. I parody this in my second 
example, but with proper names I think it could be quite readable 
code--it's really hard to say without seeing your specific use-case.

If you can't come up with adequate names for each layer, you may want to 
ask yourself: If each of your partial functions doesn't have a purpose on 
its own, then why are you doing it?

Just my 2 cents.


On Thursday, June 16, 2016 at 10:59:56 PM UTC-7, Henrik Johansson wrote:
>
> Note the _excessive_ caveat. Used with some restraint I think it is a very 
> powerful construct. 
>
> On Fri, Jun 17, 2016, 03:42 adonovan via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> On Thursday, 16 June 2016 18:00:43 UTC-4, Zauberkraut wrote:
>>>
>>> would an extended usage of this paradigm be considered unidiomatic in Go?
>>>
>>
>> Short answer: yes.  Excessive use of function values as arguments and 
>> results of other functions can make the flow of control hard to follow.
>>
>> -- 
>> 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] Re: Currying in Go

[Patrick Logan]

Go allows functions to have multiple arguments.  The upside is currying is much 
 less necessary in languages like Go. The downside is combining one-argument 
functions to make new one-argument functions is syntactically more cumbersome. 

-- 
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: Currying in Go

[Henrik Johansson]

Note the _excessive_ caveat. Used with some restraint I think it is a very
powerful construct.

On Fri, Jun 17, 2016, 03:42 adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Thursday, 16 June 2016 18:00:43 UTC-4, Zauberkraut wrote:
>>
>> would an extended usage of this paradigm be considered unidiomatic in Go?
>>
>
> Short answer: yes.  Excessive use of function values as arguments and
> results of other functions can make the flow of control hard to follow.
>
> --
> 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] How string can be converted into smaller size?

[Harry]

Hi guys,

Let's say there is something big size string data.
To store that data, I want to convert or compress this string.

Though I've already tried compress/gzip package. 
What else how can I do that? What is most effective in size?

Thanks.

Harry.

-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

['Keith Randall' via golang-nuts]

Looks like something is wrong with immediate loading for the 1 << ... 
operation.  Could you open a bug with repro instructions?  I can look at it 
when 1.8 opens.

On Thursday, June 16, 2016 at 5:30:12 PM UTC-7, gordo...@gmail.com wrote:
>
> > Modern x86 CPUs don't work like that. 
>
> > In general, optimally scheduled assembly code which uses more registers 
> has higher performance than optimally scheduled assembly code which uses 
> smaller number of registers. Assuming both assembly codes correspond to the 
> same source code. 
>
> > Register renaming: since Intel Pentium Pro and AMD K5. 
>
> > Suggestion for reading: 
> http://www.agner.org/optimize/microarchitecture.pdf 
>
> > An excerpt from the above PDF document (Section 10 about Haswell and 
> Broadwell pipeline): "... the register file has 168 integer registers and 
> 168 vector registers ..." 
>
> I am aware of all of the above and have already read Agner Fogg's 
> publications.  In addition modern CPU's do Out of Order Execution (OOE) so 
> rearrange the instructions to best reduce instruction latencies and 
> increase throughput given that there are parallel execution pipelines and 
> ahead-of-time execution, so the actual execution order is almost certainly 
> not as per the assembly listing. 
>
> Yes, both assembly listings are from the same tight loop code, but the 
> "C/C++" one has been converted from another assembly format to the golang 
> assembly format. 
>
> Daniel Bernstein, the author of "primegen" wrote for the Pentium 3 in x86 
> (32-bit) code, as the Pentium Pro processor wasn't commonly available at 
> that time and 64-bit code didn't exist.  His hand optimized C code for the 
> Sieve of Eratosthenes ("eratspeed.c" in the "doit()" function for the 
> "while k < B loop") uses six registers for this inner culling loop being 
> discussed, and takes about 3.5 CPU clock cycles per loop on a modern CPU 
> (Haswell). 
>
> The number of internal CPU registers actually used by the CPU to effect 
> OOE is beside the point, as they have to do with the CPU's internal 
> optimizations and not compiler optimizations; my point is that the 
> compiler's incorrect use of registers still costs time. 
>
> While I don't expect golang, with its philosophy of preserving "safe" 
> paradigms in doing array bounds checks by default, to run as fast as C/C++ 
> code that doesn't have that philosophy, I do expect it to run at least as 
> fast as C#/Java code which are Just In Time (JIT) compiled and do have the 
> "safe" philosophy.  The golang compiler version 1.7beta1 is not quite there 
> yet for the indicated reasons:  inconsistent use of registers, using one 
> too many in one place in order to avoid an immediate load which doesn't 
> cost any execution time, and saving one register by use of the "trick" 
> which does cost execution time as compared to the use of a single register. 
>
> However, there is hope as version 1.7 has made great advances since 
> version 1.6; surely version 1.8, which is said to intend to improve this 
> further will be faster yet.  At any rate, version 1.7 speed is "adequate" 
> for many purposes as at least it comes close (probably within about 15% to 
> 20% or less) of C#/Java speed in many of the most demanding tight loop 
> algorithms, and thus is quite usable as compared to previous versions.  But 
> even the most avid golang protagonists must admit that it isn't the 
> language to re-write Kim Walisch's "primesieve" with its extreme loop 
> unrolling that takes an average of about 1.4 CPU clock cycles per composite 
> number cull for small ranges of primes, as even with array bounds checking 
> turned off, golang would still take at least twice and more likely three 
> times as long. 
>
> That is also why I first started posting to this thread:  the only reason 
> the golang version of "primegen" is reasonably comparable in speed to C/C++ 
> "primegen" is that it uses multi-threading on a multi-core processor, which 
> weren't available to Daniel Bernstein when he wrote "primegen".  My point 
> was one should compare like with like. 
>

-- 
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] Testing best practice: passing and failing test

[Henry]

Typically, you should use one test case for each scenario. That being said, 
there is nothing preventing you to cram many scenarios into one test case.

-- 
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: Currying in Go

[adonovan via golang-nuts]

On Thursday, 16 June 2016 18:00:43 UTC-4, Zauberkraut wrote:
>
> would an extended usage of this paradigm be considered unidiomatic in Go?
>

Short answer: yes.  Excessive use of function values as arguments and 
results of other functions can make the flow of control hard to follow.

-- 
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] Detecting address family of net.IP

[google]

Ok, that's sufficient for me. It's only dangerous that if you switch the 
cases (To16() first) it does not work any more.

Am Donnerstag, 16. Juni 2016 17:18:37 UTC+2 schrieb Paul Borman:
>
> Do you mean like To4 and To16 that are defined on net.IP?
>
> switch {
> case ip.To4() != nil:
> // is an IPv4 address
> case ip.To16() != nil:
> // is an IPv6 address
> default:
> // is something else
> }
>

-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

> Modern x86 CPUs don't work like that.

> In general, optimally scheduled assembly code which uses more registers has 
> higher performance than optimally scheduled assembly code which uses smaller 
> number of registers. Assuming both assembly codes correspond to the same 
> source code.

> Register renaming: since Intel Pentium Pro and AMD K5.

> Suggestion for reading: http://www.agner.org/optimize/microarchitecture.pdf

> An excerpt from the above PDF document (Section 10 about Haswell and 
> Broadwell pipeline): "... the register file has 168 integer registers and 168 
> vector registers ..."

I am aware of all of the above and have already read Agner Fogg's publications. 
 In addition modern CPU's do Out of Order Execution (OOE) so rearrange the 
instructions to best reduce instruction latencies and increase throughput given 
that there are parallel execution pipelines and ahead-of-time execution, so the 
actual execution order is almost certainly not as per the assembly listing.

Yes, both assembly listings are from the same tight loop code, but the "C/C++" 
one has been converted from another assembly format to the golang assembly 
format.

Daniel Bernstein, the author of "primegen" wrote for the Pentium 3 in x86 
(32-bit) code, as the Pentium Pro processor wasn't commonly available at that 
time and 64-bit code didn't exist.  His hand optimized C code for the Sieve of 
Eratosthenes ("eratspeed.c" in the "doit()" function for the "while k < B 
loop") uses six registers for this inner culling loop being discussed, and 
takes about 3.5 CPU clock cycles per loop on a modern CPU (Haswell).

The number of internal CPU registers actually used by the CPU to effect OOE is 
beside the point, as they have to do with the CPU's internal optimizations and 
not compiler optimizations; my point is that the compiler's incorrect use of 
registers still costs time.

While I don't expect golang, with its philosophy of preserving "safe" paradigms 
in doing array bounds checks by default, to run as fast as C/C++ code that 
doesn't have that philosophy, I do expect it to run at least as fast as C#/Java 
code which are Just In Time (JIT) compiled and do have the "safe" philosophy.  
The golang compiler version 1.7beta1 is not quite there yet for the indicated 
reasons:  inconsistent use of registers, using one too many in one place in 
order to avoid an immediate load which doesn't cost any execution time, and 
saving one register by use of the "trick" which does cost execution time as 
compared to the use of a single register.

However, there is hope as version 1.7 has made great advances since version 
1.6; surely version 1.8, which is said to intend to improve this further will 
be faster yet.  At any rate, version 1.7 speed is "adequate" for many purposes 
as at least it comes close (probably within about 15% to 20% or less) of 
C#/Java speed in many of the most demanding tight loop algorithms, and thus is 
quite usable as compared to previous versions.  But even the most avid golang 
protagonists must admit that it isn't the language to re-write Kim Walisch's 
"primesieve" with its extreme loop unrolling that takes an average of about 1.4 
CPU clock cycles per composite number cull for small ranges of primes, as even 
with array bounds checking turned off, golang would still take at least twice 
and more likely three times as long.

That is also why I first started posting to this thread:  the only reason the 
golang version of "primegen" is reasonably comparable in speed to C/C++ 
"primegen" is that it uses multi-threading on a multi-core processor, which 
weren't available to Daniel Bernstein when he wrote "primegen".  My point was 
one should compare like with like.

-- 
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] godoc.org giving a 503 error

[Traun Leyden]

It's working for me too now.  So, nevermind!

On Thu, Jun 16, 2016 at 5:04 PM, Ian Lance Taylor  wrote:

> On Thu, Jun 16, 2016 at 4:49 PM, Traun Leyden 
> wrote:
> > godoc.org is returning:
> >
> > Error: Server Error
> >
> > The service you requested is not available yet.
> >
> > Please try again in 30 seconds.
>
> Works for me, for what it's worth.
>
> Ian
>

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

Re: [go-nuts] map memory usage question

[Ian Lance Taylor]

On Thu, Jun 16, 2016 at 4:59 PM, Dan Kortschak
 wrote:
> I'm running a terabyte-scale (minor compiler changes are necessary to get
> this to run) genome resequencing simulation at the moment and an interesting
> question has arisen.
>
> The simulation involved hashing over ~all positions of a genome, either with
> the key being a string or a [2]string. The difference in the resident memory
> size for the entire program for these two cases is about a factor of two.
>
> What is an estimate of the contribution of key size to the number of bytes
> required per element for a map?

A map is primarily an array of buckets.  A bucket is 8 bytes followed
by 8 keys followed by 8 values.  So, in general, doubling the key size
will double the memory requirements of the map.

Ian

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

Re: [go-nuts] godoc.org giving a 503 error

[Ian Lance Taylor]

On Thu, Jun 16, 2016 at 4:49 PM, Traun Leyden  wrote:
> godoc.org is returning:
>
> Error: Server Error
>
> The service you requested is not available yet.
>
> Please try again in 30 seconds.

Works for me, for what it's worth.

Ian

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

[go-nuts] map memory usage question

[Dan Kortschak]

I'm running a terabyte-scale (minor compiler changes are necessary to get this 
to run) genome resequencing simulation at the moment and an interesting 
question has arisen.

The simulation involved hashing over ~all positions of a genome, either with 
the key being a string or a [2]string. The difference in the resident memory 
size for the entire program for these two cases is about a factor of two.

What is an estimate of the contribution of key size to the number of bytes 
required per element for a map?
--
afk
Dan

-- 
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] godoc.org giving a 503 error

[Traun Leyden]

godoc.org is returning:

Error: Server ErrorThe service you requested is not available yet.

Please try again in 30 seconds.

-- 
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] [ANN] Buford v0.9.0 Apple Push Notifications for iOS 10 beta

[Nathan Youngman]

Buford is a Go library for remote notifications on iOS, macOS, tvOS, and 
watchOS. It uses the HTTP/2 protocol that Apple has supported since last 
year.

This releases adds a few new fields based on the sessions at WWDC 2016 for 
features coming in iOS 10.

https://github.com/RobotsAndPencils/buford/releases/tag/v0.9.0

Documentation is still sparse, so more may be addd later. Also, the new 
JSON Web Token (JWT) based authentication is not implemented yet.

Nathan.


-- 
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] Go 1.7 Beta 2 is released

[Chris Broadfoot]

Hello gophers,

We have just released go1.7beta2, a beta version of Go 1.7.
It is cut from the master branch at the revision tagged go1.7beta2.

Please help us by testing your Go programs with the release, and report any
problems using the issue tracker:
https://golang.org/issue/new

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.7beta2

To find out what has changed in Go 1.7, read the draft release notes:
https://tip.golang.org/doc/go1.7

Documentation for Go 1.7 is available at:
https://tip.golang.org/

Our goal is to release the final version of Go 1.7 on the 1st of August.

Cheers,
Chris

-- 
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] Currying in Go

[Zauberkraut]

Hello,

Go enables the evaluation of functions using currying over function 
literals. Every example I've found of this is rather shallow; a "deeper" 
example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:

func f(x int) func(int) func(int) int {
return func(y int) func(int) int {
return func(z int) int {
return x*x + y*y + z*z
}
}
}

Go's limited type inference makes the explicit, cascading function types 
necessary; this seems like an eyesore and maintenance concern. While I 
don't really mind it, it does cause me to hear code review sirens going off 
in the distance. Generally speaking, would an extended usage of this 
paradigm be considered unidiomatic in Go? Obviously, the above example is 
contrived and not the sort of use case in question. 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] Misunderstanding interface types as return types

[Ian Lance Taylor]

On Thu, Jun 16, 2016 at 1:56 PM, ccahoon  wrote:
> I haven't fully grasped the type inference/promotion/demotion rules yet,
> particularly with respect to having function arguments & return values with
> interface types.
>
> Here is a distilled example that I think illustrates some confusion I have:
> https://play.golang.org/p/-1YXdK1R0T
>
> Any clues on why (commented) BrokenExampleFinder doesn't work? Is there
> something that I can do to make it work without wrapping it in a function?

https://golang.org/doc/faq#covariant_types

Ian

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

[go-nuts] Misunderstanding interface types as return types

[ccahoon]

I haven't fully grasped the type inference/promotion/demotion rules yet, 
particularly with respect to having function arguments & return values with 
interface types.

Here is a distilled example that I think illustrates some confusion I have: 
https://play.golang.org/p/-1YXdK1R0T

Any clues on why (commented) BrokenExampleFinder doesn't work? Is there 
something that I can do to make it work without wrapping it in a function? 

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] Re: Getting a lot of i/o timeouts in Go 1.4

[Ian Lance Taylor]

On Thu, Jun 16, 2016 at 11:49 AM, Peter Kleiweg  wrote:
> Op donderdag 16 juni 2016 10:14:56 UTC+2 schreef Dave Cheney:
>> Go 1.4 isn't supported anymore, so you should upgrade.
>
> How am I going to compile Go without Go 1.4?

Go 1.4 is supported for building later releases of Go, but not for any
other purpose.

Ian

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

Re: [go-nuts] CPU fairness in goroutine scheuding

[Ian Lance Taylor]

On Thu, Jun 16, 2016 at 11:27 AM, Dmitry Orlov
 wrote:
>
> I am curious how does goroutine scheduler picks what goroutine to run, among
> several runnable. Does it optimize for fairness in any way?

The current scheduler does not optimize for fairness.  Of course, the
scheduler has changed in the past and it will change in the future.

The current scheduler (approximately) associates goroutines with
threads.  When a thread has to choose a new goroutine to run, it will
preferentially choose one of its associated goroutines.  If it doesn't
have any ready to run, it will steal one from another thread.


> I ran a quick experiment and found out that goroutines that run for longer
> intervals between yield points receive proportionally larger CPU share.

Yes, that is what I would have guessed from the current scheduler.


> Does this test expose the scheduler's cpu policy correctly, or it is biased?
> What is the best reading about scheduler's policies?

The comment at the top of runtime/proc.go and https://golang.org/s/go11sched.


It's a more or less understood design goal that the goroutine
scheduler is optimized for network servers, where each goroutine
typically does some relatively small amount of work followed by
network or disk I/O.  The scheduler is not optimized for goroutines
that do a lengthy CPU-bound computation.  We leave the kernel
scheduler to handle those, and we expect that programs will set
GOMAXPROCS to a value larger than the number of lengthy CPU-bound
computations they expect to run in parallel.  While I'm sure we'd all
be happy to see the scheduler do a better job of handling CPU-bound
goroutines, that would only be acceptable if there were no noticeable
cost to the normal case of I/O-bound goroutines.

Ian

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

[go-nuts] Re: Getting a lot of i/o timeouts in Go 1.4

[Peter Kleiweg]

Op donderdag 16 juni 2016 10:14:56 UTC+2 schreef Dave Cheney:
> Go 1.4 isn't supported anymore, so you should upgrade.

How am I going to compile Go without Go 1.4?

-- 
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] CPU fairness in goroutine scheuding

[Dmitry Orlov]

Hello golang experts,

I am curious how does goroutine scheduler picks what goroutine to run, 
among several runnable. Does it optimize for fairness in any way?

I ran a quick experiment and found out that goroutines that run for longer 
intervals between yield points receive proportionally larger CPU share.
In the following code:
package main

import (
"fmt"
"runtime"
"time"
)

func run(n int) int {
ret := 1
for i := 0; i < n; i++ {
ret *= i
}
return ret
}

func foo(ch chan float64, n, m int) {
f := 0
var run_time, wait_time, start_time, end_time int64
for i := 0; i < m; i++ {
start_time = time.Now().UnixNano()
if end_time != 0 {
wait_time += start_time - end_time;
}
f += run(n)
end_time = time.Now().UnixNano();
run_time += end_time - start_time;
runtime.Gosched()
}
ch <- float64(run_time) / float64(run_time + wait_time)
}

func main() {
ch := make(chan float64)
go foo(ch, 10, 100)
go foo(ch, 100, 100)

v := <-ch
fmt.Printf("first: %f\n", v)
v = <-ch
fmt.Printf("second: %f\n", v)
}

Here, one goroutine gets 10x cpu time compared to the other.
$ GOMAXPROCS=1 ./ss 
first: 0.911957
second: 0.091656

Does this test expose the scheduler's cpu policy correctly, or it is 
biased? What is the best reading about scheduler's policies?

Thank you!
Dmitry.

-- 
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] [ANN] Mirror of Go SSA

[Rob Pike]

Yes, it's internal because the authors do not want to support external
uses. Others are free to fork the package but the original may change
incompatibly and without warning. The Go 1 compatibility rules do not apply
to this package.

-rob


On Thu, Jun 16, 2016 at 10:42 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I assume it's internal for a reason.
>
> On Thu, Jun 16, 2016 at 7:10 PM,  wrote:
>
>> That's because you are mirroring the compiler's internal ssa package.
>> Sharing it as compile/ssa would probably remove this unintuitive name
>> clash.
>>
>> On Thursday, June 16, 2016 at 1:52:31 AM UTC-7, JW Bell wrote:
>>>
>>> I've used golang.org/x/tools/go/ssa, it doesn't have everything this
>>> does.
>>> On Jun 16, 2016 12:41 AM,  wrote:
>>>
>>> Have you tried to *go get golang.org/x/tools/go/ssa
>>>  *?
>>>
>>>
>>> On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:

 >>I have to say that I don't see a big benefit to mirroring a github
 repo on github itself.
 There isn't another way to use the ssa package.

 On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Jun 14, 2016 at 7:07 PM,   wrote:
> > Mirror of the Go compiler SSA library -
> https://github.com/bjwbell/ssa
> > The mirror is automatically updated daily.
> >
> > Any feedback is welcome. I'm unsure on the licensing requirements
> for
> > mirroring.
>
> The license requirements in general are in the LICENSE file.  It's no
> different from mirroring than for any other use.
>
> I have to say that I don't see a big benefit to mirroring a github
> repo on github itself.
>
> Ian
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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] [ANN] Mirror of Go SSA

['Axel Wagner' via golang-nuts]

I assume it's internal for a reason.

On Thu, Jun 16, 2016 at 7:10 PM,  wrote:

> That's because you are mirroring the compiler's internal ssa package.
> Sharing it as compile/ssa would probably remove this unintuitive name
> clash.
>
> On Thursday, June 16, 2016 at 1:52:31 AM UTC-7, JW Bell wrote:
>>
>> I've used golang.org/x/tools/go/ssa, it doesn't have everything this
>> does.
>> On Jun 16, 2016 12:41 AM,  wrote:
>>
>> Have you tried to *go get golang.org/x/tools/go/ssa
>>  *?
>>
>>
>> On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>>>
>>> >>I have to say that I don't see a big benefit to mirroring a github
>>> repo on github itself.
>>> There isn't another way to use the ssa package.
>>>
>>> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:

 On Tue, Jun 14, 2016 at 7:07 PM,   wrote:
 > Mirror of the Go compiler SSA library -
 https://github.com/bjwbell/ssa
 > The mirror is automatically updated daily.
 >
 > Any feedback is welcome. I'm unsure on the licensing requirements for
 > mirroring.

 The license requirements in general are in the LICENSE file.  It's no
 different from mirroring than for any other use.

 I have to say that I don't see a big benefit to mirroring a github
 repo on github itself.

 Ian

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

-- 
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] python bencoded list equivalent in golang

[Matt Harden]

We use the type interface{} for data that can contain any type. So you
might use bencode([]interface{}{4456, "Rakesh", 27}).

On Thu, Jun 16, 2016 at 9:31 AM  wrote:

> The server which I am contacting to is written in python and excepts
> bencoded list.
>
> In my existing python client code I do something like this:
> >>> import bencode
> >>> data = [4456, 'Rakesh', 27]
> >>> bdata = bencode.bencode(data)
> >>> bdata
> 'li4456e6:Rakeshi27ee'
>
>
> Server gets back the list by:
> >>> bencode.bdecode(bdata)
> [4456, 'Rakesh', 27]
>
>
> How do I achieve the client part in golang? I know that there is bencode
> packages already written, but the trick here is how do I arrive at
> 'li4456e6:Rakeshi27ee' in golang by providing a sequence of elements of
> 'different data types' so that when server(written in python) does bdecode,
> it gets back list [4456, 'Rakesh', 27].
>
> I am writing only the client in golang and don't want to change anything
> on the server side.
>
> Regards,
> Rakesh
>
>
>
>
> --
> 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] Re: Testing best practice: passing and failing test

[paraiso . marc]

A test shouldn't fail it should check that the result of an operation is 
what is expected. As for your question, whether you should have many 
expectations in one test or just one is up to you. 

Le jeudi 16 juin 2016 16:04:11 UTC+2, Rayland a écrit :
>
> Let's say I have some piece of code like this:
>
> type Foo struct {
> }
>
> func (this *Foo) Do() {
> }
>
>
> If I want to test that method Foo will pass in a certain scenario and fail 
> in another scenario should I have a test for each scenario or should I have 
> all scenarios tested in a method TestFoo_Do()?
>
>
>
>

-- 
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] [ANN] Mirror of Go SSA

[as . utf8]

That's because you are mirroring the compiler's internal ssa package. 
Sharing it as compile/ssa would probably remove this unintuitive name 
clash. 

On Thursday, June 16, 2016 at 1:52:31 AM UTC-7, JW Bell wrote:
>
> I've used golang.org/x/tools/go/ssa, it doesn't have everything this does.
> On Jun 16, 2016 12:41 AM, > wrote:
>
> Have you tried to *go get golang.org/x/tools/go/ssa 
>  *?
>
>
> On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>>
>> >>I have to say that I don't see a big benefit to mirroring a github 
>> repo on github itself. 
>> There isn't another way to use the ssa package.
>>
>> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>>>
>>> On Tue, Jun 14, 2016 at 7:07 PM,   wrote: 
>>> > Mirror of the Go compiler SSA library -  
>>> https://github.com/bjwbell/ssa 
>>> > The mirror is automatically updated daily. 
>>> > 
>>> > Any feedback is welcome. I'm unsure on the licensing requirements for 
>>> > mirroring. 
>>>
>>> The license requirements in general are in the LICENSE file.  It's no 
>>> different from mirroring than for any other use. 
>>>
>>> I have to say that I don't see a big benefit to mirroring a github 
>>> repo on github itself. 
>>>
>>> Ian 
>>>
>>

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

Re: [go-nuts] Re: [ANN] primegen.go: Sieve of Atkin prime number generator

[Konstantin Khomoutov]

On Thu, 16 Jun 2016 08:50:19 -0700 (PDT)
⚛ <0xe2.0x9a.0...@gmail.com> wrote:

> > > The current beta will work not too badly with amd64 code but
> > > still doesn't use registers efficiently enough to support x86
> > > code as it uses too many register.  optimized C/C++ code only
> > > uses six or at most 7 registers, which the x86 architecture has,
> > > but not the nine registers that the above requires. 
> > > 
> > > So for this tight loop, golang is still slower than optimized C/C+
> > > + code, but not by very much if array bounds checks are disabled. 
> >
> > It appears you're well versed in the x86 process instruction set
> > and code generation.  Could you may be offer help to the folks
> > working on improving the code generation backend of the gc
> > compiler? 
> 
> Will golang or google pay money for such a work?

IANAG [*] but I beleive it will not. ;-)

My line of reasoning resulted in the friently nudge you're discussing
was something like: "the person appears to be well-versed in this
subject", "he is also interested in making Go programs go faster",
"therefore, it would be good to contribute directly to where the speed
is a concern".

[*] I Am Not At Google.

-- 
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: broadcasting on a set of channels

[Øyvind Teig]

torsdag 16. juni 2016 17.19.58 UTC+2 skrev Øyvind Teig følgende:
>
> occam pi has/had mobile channels, where data pointed to by the pointer 
> that's implicitly sent over the channel will fall out of scope on the 
> sender side. I don't even think that data is converted to a const, the data 
> won't exist anymore. The language takes care of this.
>
> Sending a pointer across without such a mechanism is rather risky, isn't 
> it - if one doesn't introduce a "taken" return message and all parties 
> respect it. If not, is it avoidable to insert data state and eventual 
> polling? 
>
> Øyvind
>
> fredag 8. april 2011 22.13.44 UTC+2 skrev Ian Lance Taylor følgende:
>>
>> siddarth shankar  writes:
>>
>> > The reason I asked if it is discouraged is because of the absence of a
>> > const-style type-constraint.
>> >
>> > In that case there won't be an error thrown if the code on the
>> > subscriber-side modifies the data passed as a pointer(library design
>> > for instance)
>>
>> That is true.
>>
>> > Could the compiler do this optimization if it knows that the data sent
>> > is not modified?
>> > This could help the GC a lot..
>> > Or would that lead to too much automagic-code/over-engineering?
>>
>> The compiler could do that in principle in some cases, but I think the
>> context would be so limited that it's unlikely that this optimization
>> would ever be implemented.  It could only be done if all the relevant
>> code were in the same package.  The compiler would have to be able to
>> prove that it could see all possible sends and receives on the channel
>> in question.  Without thinking about it too hard, I suspect that there
>> would be many cases where it would seem that the optimization would
>> apply but where the compiler could not quite prove that it would apply.
>>
>> Ian
>>
>>

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

[go-nuts] python bencoded list equivalent in golang

[rakeshhs1]

The server which I am contacting to is written in python and excepts 
bencoded list.

In my existing python client code I do something like this:
>>> import bencode
>>> data = [4456, 'Rakesh', 27]
>>> bdata = bencode.bencode(data)
>>> bdata
'li4456e6:Rakeshi27ee'


Server gets back the list by:
>>> bencode.bdecode(bdata)
[4456, 'Rakesh', 27]


How do I achieve the client part in golang? I know that there is bencode 
packages already written, but the trick here is how do I arrive at 
'li4456e6:Rakeshi27ee' in golang by providing a sequence of elements of 
'different data types' so that when server(written in python) does bdecode, 
it gets back list [4456, 'Rakesh', 27].

I am writing only the client in golang and don't want to change anything on 
the server side.

Regards,
Rakesh




-- 
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] How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[Tamás Gulácsi]

You will need some form of graceful restart - I.e. without losing connections.
For example github.com/jpillora/overseer can help.

-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

[⚛]

On Thursday, June 16, 2016 at 1:06:46 PM UTC+2, Konstantin Khomoutov wrote:
>
> On Thu, 16 Jun 2016 02:12:56 -0700 (PDT) 
> gordo...@gmail.com  wrote: 
>
> [...] 
> > The current beta will work not too badly with amd64 code but still 
> > doesn't use registers efficiently enough to support x86 code as it 
> > uses too many register.  optimized C/C++ code only uses six or at 
> > most 7 registers, which the x86 architecture has, but not the nine 
> > registers that the above requires. 
> > 
> > So for this tight loop, golang is still slower than optimized C/C++ 
> > code, but not by very much if array bounds checks are disabled. 
>
> It appears you're well versed in the x86 process instruction set and 
> code generation.  Could you may be offer help to the folks working on 
> improving the code generation backend of the gc compiler? 
>

Will golang or google pay money for such a work?

-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

[⚛]

On Thursday, June 16, 2016 at 11:13:12 AM UTC+2, gordo...@gmail.com wrote:
>
> No real surprises with the no bounds checks option (-B), it just 
> eliminated the array bounds checks with the rest of the code the same 
> (version 1.7beta1): 
>
> 0x00dd 00221 (main.go:37)MOVQDI, CX 
> 0x00e0 00224 (main.go:37)SHRQ$5, DI 
> 0x00e4 00228 (main.go:37)MOVL(AX)(DI*4), R9 
> 0x00e8 00232 (main.go:37)MOVQCX, R10 
> 0x00eb 00235 (main.go:37)ANDQ$31, CX 
> 0x00ef 00239 (main.go:37)MOVLR8, R11 
> 0x00f2 00242 (main.go:37)SHLLCX, R8 
> 0x00f5 00245 (main.go:37)ORLR8, R9 
> 0x00f8 00248 (main.go:37)MOVLR9, (AX)(DI*4) 
> 0x00fc 00252 (main.go:36)LEAQ3(R10)(SI*2), DI 
> 0x0101 00257 (main.go:37)MOVLR11, R8 
> 0x0104 00260 (main.go:36)CMPQDI, DX 
> 0x0107 00263 (main.go:36)JLS$0, 221 
>
> It is now almost as fast as C/C++ code, and isn't for the same reasons as 
> explained before:  excessively using registers to store things and not 
> using the read/modify/write instruction (which also saves the use of a 
> register). 
>
> The current beta will work not too badly with amd64 code but still doesn't 
> use registers efficiently enough to support x86 code as it uses too many 
> register.  optimized C/C++ code only uses six or at most 7 registers, which 
> the x86 architecture has, but not the nine registers that the above 
> requires. 
>
> So for this tight loop, golang is still slower than optimized C/C++ code, 
> but not by very much if array bounds checks are disabled.
>

Modern x86 CPUs don't work like that.

In general, optimally scheduled assembly code which uses more registers has 
higher performance than optimally scheduled assembly code which uses 
smaller number of registers. Assuming both assembly codes correspond to the 
same source code.

Register renaming: since Intel Pentium Pro and AMD K5.

Suggestion for reading: http://www.agner.org/optimize/microarchitecture.pdf

An excerpt from the above PDF document (Section 10 about Haswell and 
Broadwell pipeline): "... the register file has 168 integer registers and 
168 vector registers ..."

-- 
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: broadcasting on a set of channels

[Øyvind Teig]

occam pi has/had mobile channels, where data pointed to by the pointer 
that's implicitly sent over the channel will fall out of scope in the 
sender side. I don't even think that data is converted to a const, the data 
won't exist anymore. The language takes care of this.

Sending a pointer across without such a mechanism is rather risky, isn't it 
- of one doesn't introduce a "taken" return message and all parties respect 
it. If not, is it avoidable to insert data state and eventual polling? 

Øyvind

fredag 8. april 2011 22.13.44 UTC+2 skrev Ian Lance Taylor følgende:
>
> siddarth shankar > writes:
>
> > The reason I asked if it is discouraged is because of the absence of a
> > const-style type-constraint.
> >
> > In that case there won't be an error thrown if the code on the
> > subscriber-side modifies the data passed as a pointer(library design
> > for instance)
>
> That is true.
>
> > Could the compiler do this optimization if it knows that the data sent
> > is not modified?
> > This could help the GC a lot..
> > Or would that lead to too much automagic-code/over-engineering?
>
> The compiler could do that in principle in some cases, but I think the
> context would be so limited that it's unlikely that this optimization
> would ever be implemented.  It could only be done if all the relevant
> code were in the same package.  The compiler would have to be able to
> prove that it could see all possible sends and receives on the channel
> in question.  Without thinking about it too hard, I suspect that there
> would be many cases where it would seem that the optimization would
> apply but where the compiler could not quite prove that it would apply.
>
> Ian
>
>

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

Re: [go-nuts] Detecting address family of net.IP

['Paul Borman' via golang-nuts]

Do you mean like To4 and To16 that are defined on net.IP?

switch {
case ip.To4() != nil:
// is an IPv4 address
case ip.To16() != nil:
// is an IPv6 address
default:
// is something else
}

On Wed, Jun 15, 2016 at 11:29 PM,  wrote:

> Hi,
>
> In many software projects I have to get the address family of a net.IP
> object. I always duplicate the following code:
>
> func isIPv4(ip net.IP) bool {
> return len(ip) == net.IPv4len || (len(ip) > 11 && isZeros(ip[0:10]) &&
> ip[10] == 0xff && ip[11] == 0xff)
> }
>
> func isZeros(ip net.IP) bool {
> for _, b := range ip {
> if b != 0 {
> return false
> }
> }
> return true
> }
>
> Instead it would be very very useful to have a Family(), IsIPv4 or IsIPv6
> function on net.IP.
> What is your opinion on that?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[romano . panzacchi]

Hi All,

Forgive me if I posted in the wrong group, as it could be more of a 
question related to design patterns rather than to golang itself.

*The context*
Imagine to create a full portal with users, profiles, ... and multiple 
services that can be activated for different customers.
I can organise the code of my portal in modules so to have a "quite" clear 
use of golang packages, but at the end of the day I get to a unique EXE 
file that represents my server/portal.

When I start it, the portal runs. Perfect.

To make an example, think of google, where you have Drive (Service 1) and 
Gmail (Service 2).

*MY DOUBT*
If I want to fix a bug (or add a feature to) in Service 1 without affecting 
the use of Service 2 how do I do?

Having a unique exe file, from my understanding I see that I need to fix 
the bug, build a new exe and deploy that one.
In other words I can't but to restart the full portal just to touch one 
part of it.

In Layman terms, if I had a portal in php I could (of course it depends on 
situations) simply replace the pages of the module for the Service 1 
without the need to stop everything (not only Service 2,3,4 and so on but 
the whole portal).


   1. Is there a simple design pattern to face a similar scenario?
   2. Should the portal be made of more exe files, one for the main portal, 
   one for each Service/Product? it worries me in terms of complexity of the 
   organisation of coding... and I do not know how I would pass stuff between 
   the main exe (listening and serving http calls) and the modules that woud 
   take care of services...

I hope my explanation makes sense.
Well, honestly I hope it is a silly question as it would mean that the 
solution would be simple as well.. :)

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.

[go-nuts] Detecting address family of net.IP

[google]

Hi,

In many software projects I have to get the address family of a net.IP 
object. I always duplicate the following code:

func isIPv4(ip net.IP) bool {
return len(ip) == net.IPv4len || (len(ip) > 11 && isZeros(ip[0:10]) && 
ip[10] == 0xff && ip[11] == 0xff)
}

func isZeros(ip net.IP) bool {
for _, b := range ip {
if b != 0 {
return false
}
}
return true
}

Instead it would be very very useful to have a Family(), IsIPv4 or IsIPv6 
function on net.IP.
What is your opinion on that?


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

Re: [go-nuts] Re: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

>. So for this tight loop, golang is still slower than optimized C/C++ 
>. code, but not by very much if array bounds checks are disabled. 

> It appears you're well versed in the x86 process instruction set and 
> code generation.  Could you may be offer help to the folks working on 
> improving the code generation backend of the gc compiler? 

I am a machine language and assembler programmer from over 40 years ago, but 
have little knowledge of writing compiler backends, and while I know what kind 
of optimizations they make, I have no experience in actually writing programs 
to achieve those optimizations.  Thus I would not likely to be able to make 
significant contributions to the gc backend other that to make comments on what 
I see in the generated output as here.

-- 
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] Testing best practice: passing and failing test

[Rayland]

Let's say I have some piece of code like this:

type Foo struct {
}

func (this *Foo) Do() {
}


If I want to test that method Foo will pass in a certain scenario and fail 
in another scenario should I have a test for each scenario or should I have 
all scenarios tested in a method TestFoo_Do()?



-- 
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 Error - When marshelling data

[Konstantin Khomoutov]

On Thu, 16 Jun 2016 04:55:41 -0700 (PDT)
User123  wrote:

> Is it giving error since it has null values? 
> 
> I'm just not able to get it. Since this code works perfectly fine in
> 1.4.2

A wild guess:

1) Your error message is:

 json: unsupported type: <-chan struct {}

   and indeed the docs of encoding/json clearly state that certain
   types cannot be sensibly marshalled and unmarshalled.
   Channel types are among them.

2) Some value contained as a field of your value -- which is supposedly
   of some custom struct type -- started to contain a variable of type

 <-chan struct{}

   somewhere between 1.4.2 and 1.6.

   This might be not an immediate field of your struct-typed value
   but a field of a value which is an immediate field, and so on --
   deeper down the hierarchy -- because the json encoder is recursive.

Hence inspect what your value might clinge on which is not *pure data.*
Say, an http.Client instance is not pure data.

Once identified, make sure you convert your existing value you're
encoding to a value of some other type which contains nothing but pure
data values.

[...]
> > I did fmt.println on the data that I am trying to marshall and it
> > looks like this
> >
> > *%!(EXTRA main.JobResponseRoot={{92b4f95b309e8db0f8d56afadefc}
> > http.res {[{{  map[] }
> > "Date","Time","Time_Zone","Source","Name","Raw_Data"*
> > *  0x10a3c2d0}]}})*
[...]
> >>> The data  I am trying to marshal contains serialized data. This
> >>> data is received in http response.
> >>>
> >>> It works perfectly when I try in version 1.4.1/ 1.4.2.
> >>>
> >>> But when I try this to the latest version 1.6 it gives an error:
> >>> *json: unsupported type: <-chan struct {}*
[...]

-- 
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] caching of cgo compilation

[Rob Pike]

If you're testing a binary, go install will overwrite the installed
version, which is usually not what you want. In that case, go build makes
sense.

-rob


On Thu, Jun 16, 2016 at 1:17 AM, Dave Cheney  wrote:

> I don't understand why that flag even exists, if feels like a symptomatic
> misfeature. Just use go install -v, always*
>
> * except when cross compiling.
>
> On 16 Jun 2016, at 18:11, Harmen B  wrote:
>
> Or build with `go build -i`
>
> On Thu, Jun 16, 2016 at 1:52 AM, Hugh Emberson 
> wrote:
>
>> He might be running go test which also seems to rebuild everything every
>> time unless it has been installed.
>>
>> go test -i installs all the dependencies for a test and fixes this
>> problem.
>>
>>
>> On Wed, Jun 15, 2016 at 6:14 PM, Dave Cheney  wrote:
>>
>>> My guess is you are using go build, which compiles then discards
>>> everything it just compiled (unless what was compiled was a main package,
>>> in which case the binary will be left in your current working directory)
>>>
>>> I recommend using go install -v rather than go build for general use.
>>>
>>> --
>>> 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.
>>
>
> --
> 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] Re: polymorphism (for Go 2.0), new fast playground is live

[Sean Russell]

I'm sorry -- the "share" button doesn't seem to be working, or doesn't work 
in Firefox or Chrome.  And I have a window hung on "waiting for remote 
server," so I might have broken your playground.  

Here's my code in (hopefully) compileable form for your processor:

package main

impoort "strconv"

// Given:
func map(f(*), a []*, result []*) {
   for i, k := range a {
  result[i] = f(k)
   }
}

func main() {
   a := "a" ; aa := "aa"; aaa = "aaa"
   mylen := func(k *string) *int { 
  rv := len(*k)
  return &rv
   }
   map(mylen, []*string{&a, &aa, &aaa}, make([]*int, 3))  // Is this 
possible?

   one := 1; two := 2; three := 3
   myItoA := func(k *int) *string {
  rv := strconv.Itoa(*k)
  return &rv
   }
   map(myItoa, []*int{&one,&two,&three}, make([]*string, 3))  // once more, 
for profit

   map(strconv.Itoa, []*int{&a}, make([]*float, 1)) // Is this a 
runtime error?
}

And, yeah... the pointers are a bit of trouble.  By the time all of the 
wrapping and referencing is done, it's only a little easier than just using 
interface{} everywhere with casts.  If you don't get type safety with this, 
I feel like the syntactic sugar value is pretty modest.

--- SER

-- 
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: polymorphism (for Go 2.0), new fast playground is live

[Sean Russell]

Hi,

On Monday, June 13, 2016 at 9:41:52 AM UTC-4, charr...@gmail.com wrote:
>
> for reference, here is the mymap()
>
> http://tsoh.host/test.html#8e4ae712 
>
> it simply runs the callback on every slice member
>

I apologize; I didn't communicate my question well.  Your map example 
functions on a single type; is the implementation *restricted* to a single 
type?  In a given scope, do all instances of "*" have to refer to the same 
type, or can it refer to multiple types?  If the latter, how do you ensure 
type safety?  How does this work:

// Given:
func map(f(*), a []*, result []*) {
   for i, k := range a {
  result[i] = f(k)
   }
}

map(len, []*string{"a","aa","aaa"}, make([]*int, 3))  // Is this possible?
map(strconv.Itoa, []*int{1,2,3}, make([]*string, 3))  // once more, for 
profit
map(strconv.Itoa, []*int{"a"}, make([]*float, 1)) // Is this a runtime 
error?

Note these wouldn't work because the stdlib functions don't work on 
pointers, which is an unfortunate limitation.  It would necessitate 
wrapping (nearly) every stdlib function that you wanted to use with this.  
I left out the wrappers for brevity, and yes, I'm throwing away the 
results.  Just trying to head off the pedants.

I'm unable to use your playground at the moment; I'm getting an "error 
communicating with remote server," so I can't test what happens.

--- SER

-- 
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: Getting a lot of i/o timeouts in Go 1.4

[Dave Cheney]

I think so.

-- 
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: Getting a lot of i/o timeouts in Go 1.4

[Mayank Jha]

Can this problem be due to a limit on the number of file descriptors 
available to my process ? The Go process has 1024 soft limit and 4096 hard 
limit, the overall system limit is very high, 400k. The other end is 
capable of handling the number of connections I am making, I have it 
verified with another load generation tool wrk. 

On Thursday, June 16, 2016 at 5:45:39 PM UTC+5:30, Dave Cheney wrote:
>
> Have you adjusted th number of file descriptors available to your program, 
> and the server you are connecting to?
>
> Have you used another program to verify that your target can handle the 
> number of connections you are making?
>

-- 
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: polymorphism (for Go 2.0), new fast playground is live

[Sean Russell]

For others: use Firefox for his playground; it doesn't function in Chrome 
on either my tablet and or my laptop.

--- SER

On Monday, June 13, 2016 at 9:41:52 AM UTC-4, charr...@gmail.com wrote:
>
>
>
> On Monday, June 13, 2016 at 1:28:26 PM UTC+2, Sean Russell wrote:
>>
>> Interesting work.  I understand this is very much a work in progress; how 
>> would you (eventually) see the implementation of map(), e.g.:
>
>
> for reference, here is the mymap()
>
> http://tsoh.host/test.html#8e4ae712 
>
> it simply runs the callback on every slice member
>

-- 
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: Getting a lot of i/o timeouts in Go 1.4

[Dave Cheney]

Have you adjusted th number of file descriptors available to your program, and 
the server you are connecting to?

Have you used another program to verify that your target can handle the number 
of connections you are making?

-- 
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: Getting a lot of i/o timeouts in Go 1.4

[Mayank Jha]

The error message is "dial tcp 10.32.61.19:80: i/o timeout", and am using 
linux amd64, built using  env GOOS=linux GOARCH=amd64 option and am running 
this on a SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux box. 

On Thursday, June 16, 2016 at 5:11:29 PM UTC+5:30, Dave Cheney wrote:
>
> Can you please show the exact output you receive.
>
> Also, which operating system are you using,
>
> Also, please use go 1.6.2, this is the supported release.
>
>

-- 
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] Golang Error - When marshelling data

[Jakob Borg]

2016-06-16 11:44 GMT+02:00 User123 :
> json: unsupported type: <-chan struct {}

A channel type is not serializable, as the error says. It's possible
that older versions of Go just skipped this without generating an
error, I don't know. If that's the case you may be able to continue
getting that behavior by using a `json:"-"` field tag.

//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: Golang Error - When marshelling data

[User123]

Is it giving error since it has null values? 

I'm just not able to get it. Since this code works perfectly fine in 1.4.2

On Thursday, June 16, 2016 at 4:08:38 PM UTC+5:30, User123 wrote:
>
> I cannot provide the full code sincethere are some dependencies.
>
> I did fmt.println on the data that I am trying to marshall and it looks 
> like this
>
> *%!(EXTRA main.JobResponseRoot={{92b4f95b309e8db0f8d56afadefc} http.res 
> {[{{  map[] } "Date","Time","Time_Zone","Source","Name","Raw_Data"*
> *  0x10a3c2d0}]}})*
>
> On Thursday, June 16, 2016 at 3:21:48 PM UTC+5:30, Dave Cheney wrote:
>>
>> Hello,
>>
>> Can you please provide a runnable code sample that shows the problem.
>>
>> Thanks
>>
>> Dave
>>
>> On Thursday, 16 June 2016 19:44:00 UTC+10, User123 wrote:
>>>
>>> The data  I am trying to marshal contains serialized data. This data is 
>>> received in http response.
>>>
>>> It works perfectly when I try in version 1.4.1/ 1.4.2.
>>>
>>> But when I try this to the latest version 1.6 it gives an error: *json: 
>>> unsupported type: <-chan struct {}*
>>>
>>> Why is it so? 
>>>
>>> I am not able to upgrade to the latest version because of this.
>>>
>>> Please help!
>>>
>>>
>>>
>>>
>>>

-- 
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: Getting a lot of i/o timeouts in Go 1.4

[Dave Cheney]

Can you please show the exact output you receive.

Also, which operating system are you using,

Also, please use go 1.6.2, this is the supported release.

-- 
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: Getting a lot of i/o timeouts in Go 1.4

[Mayank Jha]

Tried with Go 1.5, the problem persists. And the IP I gave was for showing 
purposes. I actually used an IP of a node which is a part of a closed 
network, and ran it from another node in the same network.

On Thursday, June 16, 2016 at 1:44:56 PM UTC+5:30, Dave Cheney wrote:
>
> Go 1.4 isn't supported anymore, so you should upgrade.
>
> Maybe 8.8.8.8 is rate limiting you.
>

-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

[Konstantin Khomoutov]

On Thu, 16 Jun 2016 02:12:56 -0700 (PDT)
gordonbg...@gmail.com wrote:

[...]
> The current beta will work not too badly with amd64 code but still
> doesn't use registers efficiently enough to support x86 code as it
> uses too many register.  optimized C/C++ code only uses six or at
> most 7 registers, which the x86 architecture has, but not the nine
> registers that the above requires.
> 
> So for this tight loop, golang is still slower than optimized C/C++
> code, but not by very much if array bounds checks are disabled.

It appears you're well versed in the x86 process instruction set and
code generation.  Could you may be offer help to the folks working on
improving the code generation backend of the gc compiler?

-- 
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: A proposal for generic in go

[paraiso . marc]

A good compromise would be to only implement "parametric" functions. append 
and make are" parametric" functions as they know what is their return type 
at *compile time , *no matter what type the array/slice argument is . That 
way people who don't want a generic type are happy as no generic type is 
introduced, and people who want to write functions like push/pop/map on 
arrays of any type in a type safe way. 

Go is full of compromises of that sort so it shouldn't be an "all or 
nothing" debate. 

Aside from the implementation, the most difficult matter is choosing the 
right syntax, such as

func XOR(array1 []T,array2 []T)array[]T{
// implementation
}

So yes, people would not be able to define their own type of container 
(set,queues,binary trees,...). But all these containers can be build from 
array or map structures and methods specific to each data structure could 
now be written in a "generic" way. 

At the end of the day we all want the same thing, *compile time type safety*, 
no more, no less.

Le mercredi 15 juin 2016 03:04:05 UTC+2, xingtao zhao a écrit :
>
> Here is my proposal for generic in go: 
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>
> Many parts has not been finished, and just initial thoughts. In the 
> proposal, I want to keep back compatibility. And I try to add the 
> orthogonal feature only and keep the language still simple enough. 
>
> Please add your comments on it. Hope it is useful and could inspire some 
> new features in go 2.0
>
> 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.

[go-nuts] Re: Golang Error - When marshelling data

[User123]

I cannot provide the full code sincethere are some dependencies.

I did fmt.println on the data that I am trying to marshall and it looks 
like this

*%!(EXTRA main.JobResponseRoot={{92b4f95b309e8db0f8d56afadefc} http.res 
{[{{  map[] } "Date","Time","Time_Zone","Source","Name","Raw_Data"*
*  0x10a3c2d0}]}})*

On Thursday, June 16, 2016 at 3:21:48 PM UTC+5:30, Dave Cheney wrote:
>
> Hello,
>
> Can you please provide a runnable code sample that shows the problem.
>
> Thanks
>
> Dave
>
> On Thursday, 16 June 2016 19:44:00 UTC+10, User123 wrote:
>>
>> The data  I am trying to marshal contains serialized data. This data is 
>> received in http response.
>>
>> It works perfectly when I try in version 1.4.1/ 1.4.2.
>>
>> But when I try this to the latest version 1.6 it gives an error: *json: 
>> unsupported type: <-chan struct {}*
>>
>> Why is it so? 
>>
>> I am not able to upgrade to the latest version because of this.
>>
>> Please help!
>>
>>
>>
>>
>>

-- 
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: Golang Error - When marshelling data

[Dave Cheney]

Hello,

Can you please provide a runnable code sample that shows the problem.

Thanks

Dave

On Thursday, 16 June 2016 19:44:00 UTC+10, User123 wrote:
>
> The data  I am trying to marshal contains serialized data. This data is 
> received in http response.
>
> It works perfectly when I try in version 1.4.1/ 1.4.2.
>
> But when I try this to the latest version 1.6 it gives an error: *json: 
> unsupported type: <-chan struct {}*
>
> Why is it so? 
>
> I am not able to upgrade to the latest version because of this.
>
> Please help!
>
>
>
>
>

-- 
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] Golang Error - When marshelling data

[User123]

The data  I am trying to marshal contains serialized data. This data is 
received in http response.

It works perfectly when I try in version 1.4.1/ 1.4.2.

But when I try this to the latest version 1.6 it gives an error: *json: 
unsupported type: <-chan struct {}*

Why is it so? 

I am not able to upgrade to the latest version because of this.

Please help!




-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

No real surprises with the no bounds checks option (-B), it just eliminated the 
array bounds checks with the rest of the code the same (version 1.7beta1):

0x00dd 00221 (main.go:37)   MOVQDI, CX
0x00e0 00224 (main.go:37)   SHRQ$5, DI
0x00e4 00228 (main.go:37)   MOVL(AX)(DI*4), R9
0x00e8 00232 (main.go:37)   MOVQCX, R10
0x00eb 00235 (main.go:37)   ANDQ$31, CX
0x00ef 00239 (main.go:37)   MOVLR8, R11
0x00f2 00242 (main.go:37)   SHLLCX, R8
0x00f5 00245 (main.go:37)   ORL R8, R9
0x00f8 00248 (main.go:37)   MOVLR9, (AX)(DI*4)
0x00fc 00252 (main.go:36)   LEAQ3(R10)(SI*2), DI
0x0101 00257 (main.go:37)   MOVLR11, R8
0x0104 00260 (main.go:36)   CMPQDI, DX
0x0107 00263 (main.go:36)   JLS $0, 221

It is now almost as fast as C/C++ code, and isn't for the same reasons as 
explained before:  excessively using registers to store things and not using 
the read/modify/write instruction (which also saves the use of a register).

The current beta will work not too badly with amd64 code but still doesn't use 
registers efficiently enough to support x86 code as it uses too many register.  
optimized C/C++ code only uses six or at most 7 registers, which the x86 
architecture has, but not the nine registers that the above requires.

So for this tight loop, golang is still slower than optimized C/C++ code, but 
not by very much if array bounds checks are disabled.

-- 
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: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

No real surprises with the no bounds checks option (-B), it just eliminated the 
array bounds checks with the rest of the code the same (version 1.7beta1):

0x00dd 00221 (main.go:37)   MOVQDI, CX
0x00e0 00224 (main.go:37)   SHRQ$5, DI
0x00e4 00228 (main.go:37)   MOVL(AX)(DI*4), R9
0x00e8 00232 (main.go:37)   MOVQCX, R10
0x00eb 00235 (main.go:37)   ANDQ$31, CX
0x00ef 00239 (main.go:37)   MOVLR8, R11
0x00f2 00242 (main.go:37)   SHLLCX, R8
0x00f5 00245 (main.go:37)   ORL R8, R9
0x00f8 00248 (main.go:37)   MOVLR9, (AX)(DI*4)
0x00fc 00252 (main.go:36)   LEAQ3(R10)(SI*2), DI
0x0101 00257 (main.go:37)   MOVLR11, R8
0x0104 00260 (main.go:36)   CMPQDI, DX
0x0107 00263 (main.go:36)   JLS $0, 221

It is now almost as fast as C/C++ code, and isn't for the same reasons as 
explained before:  excessively using registers to store things and not using 
the read/modify/write instruction (which also saves the use of a register).

The current beta will work not too badly with amd64 code but still doesn't use 
registers efficiently enough to support x86 code as it uses too many register.  
optimized C/C++ code only uses six or at most 7 registers, which the x86 
architecture has, but not the nine registers that the above requires.

So for this tight loop, golang is still slower than optimized C/C++ code, but 
not by very much if array bounds checks are disabled.

-- 
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] [ANN] Mirror of Go SSA

[JW Bell]

I've used golang.org/x/tools/go/ssa, it doesn't have everything this does.
On Jun 16, 2016 12:41 AM,  wrote:

Have you tried to *go get golang.org/x/tools/go/ssa
 *?


On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>
> >>I have to say that I don't see a big benefit to mirroring a github
> repo on github itself.
> There isn't another way to use the ssa package.
>
> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Tue, Jun 14, 2016 at 7:07 PM,   wrote:
>> > Mirror of the Go compiler SSA library -  https://github.com/bjwbell/ssa
>> > The mirror is automatically updated daily.
>> >
>> > Any feedback is welcome. I'm unsure on the licensing requirements for
>> > mirroring.
>>
>> The license requirements in general are in the LICENSE file.  It's no
>> different from mirroring than for any other use.
>>
>> I have to say that I don't see a big benefit to mirroring a github
>> repo on github itself.
>>
>> Ian
>>
>

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

Re: [go-nuts] caching of cgo compilation

[Dave Cheney]

I don't understand why that flag even exists, if feels like a symptomatic 
misfeature. Just use go install -v, always*

* except when cross compiling. 

> On 16 Jun 2016, at 18:11, Harmen B  wrote:
> 
> Or build with `go build -i`
> 
>> On Thu, Jun 16, 2016 at 1:52 AM, Hugh Emberson  
>> wrote:
>> He might be running go test which also seems to rebuild everything every 
>> time unless it has been installed.
>> 
>> go test -i installs all the dependencies for a test and fixes this problem.
>> 
>> 
>>> On Wed, Jun 15, 2016 at 6:14 PM, Dave Cheney  wrote:
>>> My guess is you are using go build, which compiles then discards everything 
>>> it just compiled (unless what was compiled was a main package, in which 
>>> case the binary will be left in your current working directory)
>>> 
>>> I recommend using go install -v rather than go build for general use.
>>> 
>>> --
>>> 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.
> 

-- 
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] Getting a lot of i/o timeouts in Go 1.4

[Dave Cheney]

Go 1.4 isn't supported anymore, so you should upgrade.

Maybe 8.8.8.8 is rate limiting you.

-- 
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] caching of cgo compilation

[Harmen B]

Or build with `go build -i`

On Thu, Jun 16, 2016 at 1:52 AM, Hugh Emberson 
wrote:

> He might be running go test which also seems to rebuild everything every
> time unless it has been installed.
>
> go test -i installs all the dependencies for a test and fixes this problem.
>
>
> On Wed, Jun 15, 2016 at 6:14 PM, Dave Cheney  wrote:
>
>> My guess is you are using go build, which compiles then discards
>> everything it just compiled (unless what was compiled was a main package,
>> in which case the binary will be left in your current working directory)
>>
>> I recommend using go install -v rather than go build for general use.
>>
>> --
>> 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.
>

-- 
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] Getting a lot of i/o timeouts in Go 1.4

[Mayank Jha]

I am trying to run a large number of tcp 
connects https://play.golang.org/p/lNGWD-q028. However I am getting a lot 
of i/o timeouts. Is this a know issue, or I am missing something.

-- 
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] [ANN] Mirror of Go SSA

[as . utf8]

Have you tried to *go get golang.org/x/tools/go/ssa *?

On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>
> >>I have to say that I don't see a big benefit to mirroring a github 
> repo on github itself. 
> There isn't another way to use the ssa package.
>
> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Tue, Jun 14, 2016 at 7:07 PM,   wrote: 
>> > Mirror of the Go compiler SSA library -  https://github.com/bjwbell/ssa 
>> > The mirror is automatically updated daily. 
>> > 
>> > Any feedback is welcome. I'm unsure on the licensing requirements for 
>> > mirroring. 
>>
>> The license requirements in general are in the LICENSE file.  It's no 
>> different from mirroring than for any other use. 
>>
>> I have to say that I don't see a big benefit to mirroring a github 
>> repo on github itself. 
>>
>> Ian 
>>
>

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