[go-nuts] Re: Why doesn't std lib use the method in this article to make err variables constant?

[Dave Cheney]

Because we cannot change symbols covered by the Go 1 contract.

On Thursday, 4 August 2016 14:20:18 UTC+10, T L wrote:
>
> http://dave.cheney.net/2016/04/07/constant-errors
>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[T L]

On Thursday, August 4, 2016 at 12:16:37 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Aug 3, 2016 at 9:12 AM, T L  
> wrote: 
> > 
> > On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote: 
> >> 
> >> True, but it would still be just the same loop, it wouldn't actually be 
> >> significantly faster. And you'd need to put quite some machinery into a 
> >> pretty rarely used functionality, which means it also wouldn't be 
> cleaner. 
> >> 
> >> The thing is, that the memory representation of []T and []J, with J 
> being 
> >> an interface type, is very different form each other and differs also 
> for 
> >> each (T, J) pair, AIUI. So you can't really efficiently generalize 
> this. The 
> >> only thing it could possibly safe you, is writing the actual loop and 
> in 
> >> general go doesn't really do this kind of tradeoff (saving small 
> amounts of 
> >> trivial work by complicating the language and -implementation). 
> > 
> > 
> > so the copy buitlin function is not essential? 
>
> Correct. 
>
> Although it is worth noting that, in the absence of significant 
> compiler optimizations that the gc compiler does not currently 
> implement, the copy builtin can be much more efficient than the 
> ordinary user written loop; see 
> https://golang.org/src/runtime/memmove_amd64.s.  That is not true of a 
> function that converts from []T to []interface. 
>

With some special memory optimizations for slice, I think it is possible to 
make efficient conversions from []T to []interface.
For example, we don't need to convert every element in []T to interface{}, 
we can just use following struct to represent a special []interface{},
the concrete type of all interface{} values in the []interface{} is the 
same one.

> type specialInterfaceSlice struct {
>   typ *_type
>   values []T
> }
>

 

>
> 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: files, readers, byte arrays (slices?), byte buffers and http.requests

[Sri G]

Doh. Thanks. I did the setup but didnt click "execute".

Revisiting this because its now a bottleneck since it directly impact user 
experience (how long a request will take to process) and scalability 
(requests per second a single instance can handle). It wasn't pre-mature 
optimization, rather proper architecture planning :)

In C, the request would come into a ring buffer of Struct of Arrays (read 
SoAs vs AoS on Intel x86) -> a pointer to the post data is kept. This is 
used to check the mime type as well as compute the md5. Then it passed to 
be written to disk before it is released. No copies are needed.

How can I accomplish this in idiomatically Go? When I say idiomatic, I mean 
efficient in space, time and verbosity depending on the requirements and 
most importantly, not fighting the language. 

I'm having difficulty grokking whether a command copies data or uses a 
reference to the underlying buffer (pointer). Or does everything copy 
because data needs to be in each stack for each go routine? 

I've read the source code of io.copy, if there is a reader.ReadFrom or 
writer.WriteTo, the copy uses the existing buffer, avoiding allocation and 
a copy. However crypto/md5 does not have either of these, so its not 
possible to compute the md5 without copying data. Is this because the md5 
library is written for streaming data vs static data?

Is there a way to accomplish this? i.e. here's a buffer of data, compute 
the md5 on it.

Re: the mimetype, I should be able to create a 1024 byte slice of the file 
and pass it to mimemagic. This should avoid the copy.


On Saturday, July 2, 2016 at 9:27:15 PM UTC-4, Dave Cheney wrote:
>
> The hash is always the same because you ask for the hash value before 
> writing any data through it with io.Copy.


On Saturday, July 2, 2016 at 9:27:15 PM UTC-4, Dave Cheney wrote:
>
> The hash is always the same because you ask for the hash value before 
> writing any data through it with io.Copy. 

-- 
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: Will compiler do optimization here?

[T L]

I surely will use the first version in practice.

I just want to make things clear, :)

On Thursday, August 4, 2016 at 3:23:11 AM UTC+8, Hotei wrote:
>
> If you create the source as a byte array by converting it ([]byte("abcde") 
> then the compiler can NOT optimize it away.  However - I don't think it 
> will *use* the capacity information in the source since it's not relevant 
> and it's going to copy the data bytes and length in any case. 
>
> If you're worried about speed impacts I'd suggest benchmarking it.  I 
> think the second one may be a nanosecond or two slower per copy. If you're 
> looking for significant gains from optimizing this I believe you will be 
> wasting time looking here.  
>
> In my unsolicited opinion the first version is arguably "better", because 
> it's easier to read/understand, not because it's faster.
>
>
> I am still not clear about your answer, yes or not?
>>
>

-- 
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] Why doesn't std lib use the method in this article to make err variables constant?

[T L]

http://dave.cheney.net/2016/04/07/constant-errors

-- 
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] rsa.GenerateKey does not return on sepcial bits

[steve wang]

done.

https://github.com/golang/go/issues/16596

On Thursday, August 4, 2016 at 12:01:55 PM UTC+8, bradfitz wrote:
>
> Please file a bug.
>
>
> On Wed, Aug 3, 2016 at 8:20 PM, steve wang  > wrote:
>
>> https://play.golang.org/p/gYYUDxj6Z5
>>
>> Is this an issue?
>>
>> -- 
>> 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.

[go-nuts] rsa.GenerateKey does not return on sepcial bits

[steve wang]

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

Is this an issue?

-- 
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: Data locality in large slices

[Dave Cheney]

Those arguments must live beyond the scope of the enclosing function. 

-- 
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] Server TCP

[Brad Fitzpatrick]

What's the "login package"?


On Wed, Aug 3, 2016 at 3:12 PM,  wrote:

> Anyone know why the tcp server closes its connection after of answer the
> login package?
>
> --
> 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: Data locality in large slices

[ondrej . kokes]

(I have now recreated it on my Mac, under 1.7rc5, the runtime differences 
are still there.) I thought the compiler was removing these as you suggest, 
but then StartEnd and EndStart had wildly different running times, despite 
using the very same values. So I added dummy assignments to double check 
and nothing has changed

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

So it seems the behaviour changed between 1.6 and 1.7 - either it better 
hints the CPU, or it eliminates some instructions in the new SSA backend.

On Wednesday, 3 August 2016 23:15:05 UTC+1, Dave Cheney wrote:
>
> You need to use the values to ensure that compiler does not remove the 
> code. Even if the compiler does not do this, your Intel CPU will, if 
> effectively runs an ssa implementation in hardware and will spot the dead 
> stores and skip the load.

-- 
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] Server TCP

[freddymontero324]

Anyone know why the tcp server closes its connection after of answer the 
login package?

-- 
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: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?

[David Marceau]

I tried just what you mentioned.  Unfortunately even my interim solution 
when it is outside of the net.http package and within mine, there are many 
services that are not exported meaning I can't use them at all and the 
variables themselves are inaccessible.
I tried copying pasting some functions and tweaking them and I ended up 
going down a rabbit hole never to get out of.  The only way to achieve what 
I want would be to tweak the original golang sources for 
net.http.ListenAndServeTLS and stuff surrounding it.


On Wednesday, August 3, 2016 at 9:19:40 AM UTC-4, Nathan Kerr wrote:
>
> Your research revealed the essential lines from ListenAndServeTLS that 
> basically say: 
>
> 1. create a tls listener 
> 2. have the server serve using that listener 
>
> The LimitListener example follows this same pattern, just with 
> net.Listener instead of a tls.Listener. A careful reading reveals that 
> ListenAndServeTLS does not do anything to http.Server that you cannot do 
> from outside the http package. This means that you can implement it in your 
> own code; changing it to fit your needs. Your code will probably flow 
> something like: 
>
> 1. get a listener 
> 2. limit that listener 
> 3. create a tls.Config 
> 4. tlslistener on LimitedListener with config 
> 5. Server.Serve(tlsListener) 
>
> I am not sure if it would be better to limit before or after the tls 
> listener. 
>
> I call this trick expanding convenience functions and explain it in 
> regards to another problem at 
> http://pocketgophers.com/expanding-convenience-functions/ (
> http://pocketgophers.com/expanding-convenience-functions/). 
>
> To answer your other questions: 
>
> I think that tlsListener is not part of the Server structure (so that you 
> could easily fetch it and limit it) is for two reasons. First, it keeps the 
> server and the listener separate. There is no fundamental reason that a 
> single server could not serve on multiple listeners. 
>
> Second, Serve is basically an infinite loop waiting on Listener.Accept. 
> What would it mean to change the server's listener while it is blocked 
> accepting a new connection? The old listener would be blocking. If a 
> connection was never made to it, the new listener would never accept any 
> connections. 
>
> The API does give the control you need, just not in the way you looked for 
> it. 
>
> For that last question, controlling connections is usually done as a way 
> to control the use of some other resource such as cpu, memory, database 
> access, etc. Managing resources must be done at both the OS and server 
> level. What needs to be done depends on what the server needs to do, what 
> hardware it is running on, service level agreements, etc. Sometimes 
> limiting, sometimes expanding limits, sometime increasing performance. 
>
> Hope this helps.

-- 
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] Data locality in large slices

[Dave Cheney]

You need to use the values to ensure that compiler does not remove the code. 
Even if the compiler does not do this, your Intel CPU will, if effectively runs 
an ssa implementation in hardware and will spot the dead stores and skip the 
load.

-- 
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: How to check that a Go package has not been modified?

[Michael Jones]

A few years ago, I uploaded a parallel “find duplicate files in a filesystem” 
utility to GitHub. It is called “dup” for “find duplicates.”

 

https://github.com/MichaelTJones/dup/blob/master/dup.go

 

In that program, which first groups files by size, then compares the first few 
bytes, then compares hashes, and then entire files byte-by-byte (all options), 
is this code:

 

if bytes.Compare(a, b) != 0 {

log.Printf("Congratulations! You have found two files that differ(*), yet 
have\n")

    log.Printf("the same hash value. Publish these two files for a 
moment of fame:\n")

    log.Printf("    file %q\n", path[0])

    log.Printf("    file %q\n", path[i])

    log.Printf("* Or, the files were modified while this program was 
executing, in\n")

    log.Printf("  which case there is no fame to be had. Just run the 
program again.")

    return false

}

 

It reflects common understanding about the probability of hash collisions when 
using good hashes.

--

Michael T. Jones

 

From:  on behalf of "atd...@gmail.com" 

Date: Wednesday, August 3, 2016 at 4:57 PM
To: golang-nuts 
Subject: [go-nuts] Re: How to check that a Go package has not been modified?

 

Yes, I suppose that clamping the file size, and the requirement that the 
package must pass compilation, even md5 shall do. Thanks to the avalanche 
effect.

On Wednesday, August 3, 2016 at 9:36:34 PM UTC+2, Hotei wrote:

The fact that collisions are possible does not make them "easy to create" 
especially when you add the compileable requirement.  If you're uneasy about 
md5 you could always use more bits - like SHA1 used by "git" or SHA256 (or 
larger) if you're really paranoid.

On Wednesday, August 3, 2016 at 1:14:53 PM UTC-4, atd...@gmail.com wrote:

Would a md5 hash suffice?

 

I mean, it is probably easy to create collisions, but the source still needs to 
compile so...

 

Or an md5 hash and using go/types to make sure that any object escaping the 
package boundaries is still present and none other have been added.

 

Any idea?

 

 

-- 
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: How to check that a Go package has not been modified?

[atd...@gmail.com]

Yes, I suppose that clamping the file size, and the requirement that the 
package must pass compilation, even md5 shall do. Thanks to the avalanche 
effect.

On Wednesday, August 3, 2016 at 9:36:34 PM UTC+2, Hotei wrote:
>
> The fact that collisions are possible does not make them "easy to create" 
> especially when you add the compileable requirement.  If you're uneasy 
> about md5 you could always use more bits - like SHA1 used by "git" or 
> SHA256 (or larger) if you're really paranoid.
>
> On Wednesday, August 3, 2016 at 1:14:53 PM UTC-4, atd...@gmail.com wrote:
>>
>> Would a md5 hash suffice?
>>
>> I mean, it is probably easy to create collisions, but the source still 
>> needs to compile so...
>>
>> Or an md5 hash and using go/types to make sure that any object escaping 
>> the package boundaries is still present and none other have been added.
>>
>> Any idea?
>>
>>
>>

-- 
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: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?

[David Marceau]

I perused your blog entry you mentioned.  It's very interesting and will 
come in handy in the future.  Thank you.  

I can appreciate your point of view about accepting the fact that currently 
listeners are not part of the Server and just proceed to produce code and 
get it done ASAP.  My interim approach will require me to do as you 
suggested "expand the convenience function" as an entirely different 
function within my own package.

That said, if we:
1)change the Server duck-type's existing ListenAndServeTLS() contents a 
touch without affecting its API signature 
2)add a few new properties to Server's structure
2.1)MaxListenersCount. The global max count of Listener we want.
2.2)MaxListenerPoolsCount.  The global max count of ListenerPool we want.
2.3)ListenerPools with the preferred type (ring, array, channel...) 
2.4)Each ListenerPool would hold Listeners with the preferred type (ring, 
array, channel...)
3)When we add a listener to the Server, it would manage the balancing of 
the listeners across the pools while keeping to the constraints 
MaxListenersCount and MaxListenerPoolsCount.

This would prevent others from having to individually invest effort to 
"expand the convenience function" on the very same feature request: 
limiting connections to a tls server.



On Wednesday, August 3, 2016 at 9:19:40 AM UTC-4, Nathan Kerr wrote:
>
> Your research revealed the essential lines from ListenAndServeTLS that 
> basically say: 
>
> 1. create a tls listener 
> 2. have the server serve using that listener 
>
> The LimitListener example follows this same pattern, just with 
> net.Listener instead of a tls.Listener. A careful reading reveals that 
> ListenAndServeTLS does not do anything to http.Server that you cannot do 
> from outside the http package. This means that you can implement it in your 
> own code; changing it to fit your needs. Your code will probably flow 
> something like: 
>
> 1. get a listener 
> 2. limit that listener 
> 3. create a tls.Config 
> 4. tlslistener on LimitedListener with config 
> 5. Server.Serve(tlsListener) 
>
> I am not sure if it would be better to limit before or after the tls 
> listener. 
>
> I call this trick expanding convenience functions and explain it in 
> regards to another problem at 
> http://pocketgophers.com/expanding-convenience-functions/ (
> http://pocketgophers.com/expanding-convenience-functions/). 
>
> To answer your other questions: 
>
> I think that tlsListener is not part of the Server structure (so that you 
> could easily fetch it and limit it) is for two reasons. First, it keeps the 
> server and the listener separate. There is no fundamental reason that a 
> single server could not serve on multiple listeners. 
>
> Second, Serve is basically an infinite loop waiting on Listener.Accept. 
> What would it mean to change the server's listener while it is blocked 
> accepting a new connection? The old listener would be blocking. If a 
> connection was never made to it, the new listener would never accept any 
> connections. 
>
> The API does give the control you need, just not in the way you looked for 
> it. 
>
> For that last question, controlling connections is usually done as a way 
> to control the use of some other resource such as cpu, memory, database 
> access, etc. Managing resources must be done at both the OS and server 
> level. What needs to be done depends on what the server needs to do, what 
> hardware it is running on, service level agreements, etc. Sometimes 
> limiting, sometimes expanding limits, sometime increasing performance. 
>
> Hope this helps.

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

[go-nuts] Re: Go test package names

[Uli Kunitz]

Tests are usually included in the package. Testing a package cannot become 
easier this way and it is the only way to test internal functions, types, 
variables or constants. However if you have large test files, it may make 
sense to keep them in a separate repository because go-getting the package 
would become extremely slow if included in the package.

On Wednesday, August 3, 2016 at 3:39:47 PM UTC+2, ffohw...@gmail.com wrote:
>
> I've got a question about best practices for test file packages, I've seen 
> this post 
> http://stackoverflow.com/questions/19998250/proper-package-naming-for-testing-in-golang
>  
> and wanted to know if there really was a best practice for writing tests, 
> or if it really comes down to black/white box styles.
>
>
>

-- 
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: How to check that a Go package has not been modified?

[Hotei]

The fact that collisions are possible does not make them "easy to create" 
especially when you add the compileable requirement.  If you're uneasy 
about md5 you could always use more bits - like SHA1 used by "git" or 
SHA256 (or larger) if you're really paranoid.

On Wednesday, August 3, 2016 at 1:14:53 PM UTC-4, atd...@gmail.com wrote:
>
> Would a md5 hash suffice?
>
> I mean, it is probably easy to create collisions, but the source still 
> needs to compile so...
>
> Or an md5 hash and using go/types to make sure that any object escaping 
> the package boundaries is still present and none other have been added.
>
> Any idea?
>
>
>

-- 
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: Will compiler do optimization here?

[Hotei]

If you create the source as a byte array by converting it ([]byte("abcde") 
then the compiler can NOT optimize it away.  However - I don't think it 
will *use* the capacity information in the source since it's not relevant 
and it's going to copy the data bytes and length in any case. 

If you're worried about speed impacts I'd suggest benchmarking it.  I think 
the second one may be a nanosecond or two slower per copy. If you're 
looking for significant gains from optimizing this I believe you will be 
wasting time looking here.  

In my unsolicited opinion the first version is arguably "better", because 
it's easier to read/understand, not because it's faster.


I am still not clear about your answer, yes or not?
>

-- 
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: Data locality in large slices

[charraster]

Tu cast pola s ktorou pracujes mas v L1/ L2 cache. V momente ked 
pristupujes k inej casti pola ktora je niekolko megabajtov vzdialena tak 
procesor musi natiahnut tie udaje z ram do cache. Neviem presne cisla ale 
trva to zhruba tych 300 strojovych cyklov . Vypadok L2 neviem kolko trva, 
je to v manualoch.

On Wednesday, August 3, 2016 at 4:24:08 PM UTC+2, ondrej...@gmail.com wrote:
>
> Downgrading to 1.6.3, I'm also getting consistent benchmark results. I'll 
> try 1.7 on my Mac at home later today, to see if it's a 1.7 thing or a 
> Windows thing or...?
>
> On Wednesday, 3 August 2016 14:55:20 UTC+1, C Banning wrote:
>>
>> PS - that's with Go v1.6.
>>
>> On Wednesday, August 3, 2016 at 7:49:49 AM UTC-6, C Banning wrote:
>>>
>>> On MacBook Pro, 2.6 GHz Intel Core i7, 8 GB 1600 MHz memory, running OS 
>>> X 10.11.6, your benchmarks look pretty consistent:
>>>
>>>
>>> BenchmarkStart-4  20 1.45 ns/op
>>>
>>> BenchmarkEnd-420 1.47 ns/op
>>>
>>> BenchmarkHereThere-4  20 1.46 ns/op
>>>
>>> BenchmarkStartEnd-4   20 1.46 ns/op
>>>
>>> BenchmarkEndStart-4   20 1.46 ns/op
>>>
>>> BenchmarkFirst-4  20 0.59 ns/op
>>>
>>> BenchmarkSecond-4 20 0.59 ns/op
>>>
>>> BenchmarkLast-4   20 0.59 ns/op
>>>
>>> BenchmarkPenultimate-4 20 0.58 ns/op
>>>
>>> On Wednesday, August 3, 2016 at 5:56:32 AM UTC-6, Ondrej wrote:

 I wanted to see if there was a difference when loading values from a 
 large-ish slice (1 elements) - to see if caches, locality and other 
 things had any meaningful impacts. Whilst individual value loading (just a 
 single element) seemed to be equally fast regardless of element position 
 (see bench of First, Second, Last, Penultimate), when combining loading of 
 various values, there seem to be almost a 2.5x difference between loading 
 first four values and loading last four values (first two benchmarks).
 Loading the same values, just in different order, also yields different 
 execution times. But alternating loading (0, n, 1, n-1) seems to be faster 
 than loading first two values and last two values.

 (Setting the test slice to be an array instead wipes all differences 
 between benchmarks.)

 Can anyone point me to a resource - be it Go specific or on computer 
 science principles - that would explain these large differences?

 Thanks!

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

>>>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[charraster]

On Wednesday, August 3, 2016 at 6:16:37 PM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Aug 3, 2016 at 9:12 AM, T L  
> wrote: 
> > 
> > On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote: 
> >> 
> >> True, but it would still be just the same loop, it wouldn't actually be 
> >> significantly faster. And you'd need to put quite some machinery into a 
> >> pretty rarely used functionality, which means it also wouldn't be 
> cleaner. 
> >> 
> >> The thing is, that the memory representation of []T and []J, with J 
> being 
> >> an interface type, is very different form each other and differs also 
> for 
> >> each (T, J) pair, AIUI. So you can't really efficiently generalize 
> this. The 
> >> only thing it could possibly safe you, is writing the actual loop and 
> in 
> >> general go doesn't really do this kind of tradeoff (saving small 
> amounts of 
> >> trivial work by complicating the language and -implementation). 
> > 
> > 
> > so the copy buitlin function is not essential? 
>
> Correct. 
>
> Although it is worth noting that, in the absence of significant 
> compiler optimizations that the gc compiler does not currently 
> implement, the copy builtin can be much more efficient than the 
> ordinary user written loop; see 
> https://golang.org/src/runtime/memmove_amd64.s.  That is not true of a 
> function that converts from []T to []interface. 
>
> Ian 
>


Enabling user to do conversion from []*Tto[]*U   (the slices 
contain pointers) would be easy, doing a slight modification in the 
compilers.
We did tricks like this already in modified versions of go


Enabling user to do conversion from []T  (T is arbitrary not just fixed 
size type)   to   []interface would be possible with a deep modification 
involving linkers and other stuff (that I don't understand very well).

Dealing with []T when T is an interface would be nightmare difficult and I 
don't even know where would I begin

i believe in go experts they are more than capable to deal with this

-- 
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] checking for connection error?

[Michael Banzon]

Hi Victor,

There are no "constant" errors in the sql package if thats what you are
looking for.

Generally if .Ping() returns an error there is no connection - afaik the
error string might give some indication but it is totally up to the
driver/database.

If you want to sleep and try again later you can do it this way - but the
reason why .Ping() didn't succeed is unknown.

On Wed, Aug 3, 2016 at 4:34 PM Victor L  wrote:

> Any idea how to check for connection error in database/sql?
>
> err := db.Ping()
> if err == CONNECTION_REFUSED (?) {
> time.Sleep
> }
>
> --
> 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: How to check that a Go package has not been modified?

[atd...@gmail.com]

I'm a bit uneasy about this. Since checksumming is not collision-resistant, 
I would be careful just relying on this.
The goal was to avoid diffing files but I don't know what is the fastest 
way.

In any case, I guess a checksum is not enough to guarantee file integrity 
(against malice). Maybe adding file size would do.

On Wednesday, August 3, 2016 at 7:36:36 PM UTC+2, Daniel Theophanes wrote:
>
> What is the purpose of this? For instance, In govendor the hash of the 
> files, file names, and path is computed and recorded. That way if they are 
> modified it is detected. So yeah, md5 or blake2 would work just fine.
>
> On Wednesday, August 3, 2016 at 10:14:53 AM UTC-7, atd...@gmail.com wrote:
>>
>> Would a md5 hash suffice?
>>
>> I mean, it is probably easy to create collisions, but the source still 
>> needs to compile so...
>>
>> Or an md5 hash and using go/types to make sure that any object escaping 
>> the package boundaries is still present and none other have been added.
>>
>> Any idea?
>>
>>
>>

-- 
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: How to check that a Go package has not been modified?

[Daniel Theophanes]

What is the purpose of this? For instance, In govendor the hash of the 
files, file names, and path is computed and recorded. That way if they are 
modified it is detected. So yeah, md5 or blake2 would work just fine.

On Wednesday, August 3, 2016 at 10:14:53 AM UTC-7, atd...@gmail.com wrote:
>
> Would a md5 hash suffice?
>
> I mean, it is probably easy to create collisions, but the source still 
> needs to compile so...
>
> Or an md5 hash and using go/types to make sure that any object escaping 
> the package boundaries is still present and none other have been added.
>
> Any idea?
>
>
>

-- 
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: Will compiler do optimization here?

[T L]

On Thursday, August 4, 2016 at 12:40:41 AM UTC+8, Hotei wrote:
>
> Looking at the asm it appears that there is a conversion func called in 
> the second version - right before the copy with memmove.
>
> Based on this I'd say what happens AFTER the conversion is the same in 
> both version since the destination is the same and the content is the same. 
>  The only optimization I see is  not doing an unnecessary explicit 
> conversion.  I'm not sure this helps.  Am I answering the right question?  
>

I am still not clear about your answer, yes or not?
 

>
> On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>>
>>
>> I know a string value can be used as []byte if the first parameter if the 
>> builtin copy/append function is a []byte value:
>>
>>> var bs []byte = make([]byte, 10)
>>> copy(bs, "abcde")
>>
>>
>> but if do explicit conversion anyway on the second string value  
>>
>>> var bs []byte = make([]byte, 10)
>>> copy(bs, []byte("abcde"))
>>>
>> will compiler do optimization here to avoid copying the underline byte 
>> array of the string? 
>>
>>

-- 
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: Will compiler do optimization here?

[Hotei]

Looking at the asm it appears that there is a conversion func called in the 
second version - right before the copy with memmove.

Based on this I'd say what happens AFTER the conversion is the same in both 
version since the destination is the same and the content is the same.  The 
only optimization I see is  not doing an unnecessary explicit conversion. 
 I'm not sure this helps.  Am I answering the right question?  

On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>
>
> I know a string value can be used as []byte if the first parameter if the 
> builtin copy/append function is a []byte value:
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, "abcde")
>
>
> but if do explicit conversion anyway on the second string value  
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, []byte("abcde"))
>>
> will compiler do optimization here to avoid copying the underline byte 
> array of the string? 
>
>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[T L]

On Wednesday, August 3, 2016 at 11:46:43 PM UTC+8, Axel Wagner wrote:
>
> True, but it would still be just the same loop, it wouldn't actually be 
> significantly faster. And you'd need to put quite some machinery into a 
> pretty rarely used functionality, which means it also wouldn't be cleaner.
>
> The thing is, that the memory representation of []T and []J, with J being 
> an interface type, is very different form each other and differs also for 
> each (T, J) pair, AIUI. So you can't really efficiently generalize this. 
> The only thing it could possibly safe you, is writing the actual loop and 
> in general go doesn't really do this kind of tradeoff (saving small amounts 
> of trivial work by complicating the language and -implementation).
>

so the copy buitlin function is not essential?
 

>
> On Wed, Aug 3, 2016 at 5:19 PM, T L  
> wrote:
>
>>
>>
>> On Wednesday, August 3, 2016 at 10:54:29 PM UTC+8, Axel Wagner wrote:
>>>
>>> Why is converting it in a loop "neither clean nor efficient"? It seems 
>>> to be both to me: a) It's clean, as it's type-safe, so much less can go 
>>> wrong and it's obvious what it does and b) it's efficient, becaue a 
>>> func([]T) []interface{} would need to use reflection, just to also have the 
>>> same loop (but a less efficient one, as every operation would need to 
>>> reflect). So, writing a loop would, in fact, be *more* efficient and clean 
>>> than a function.
>>>
>>
>> If the functionality is provided by builltin package, the reflection is 
>> not needed, just like the copy builtin function.
>>  
>>
>>>
>>> On Wed, Aug 3, 2016 at 4:35 PM, T L  wrote:
>>>
 Often, I need converting a []T to []interface{} to use the []interface 
 as a variable length parameter.
 But converting a []T for []interface{} in a for loop is neither clean 
 nor efficient.

 So is there a function in standard lib to convert []T to a 
 []interface{}?

 -- 
 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...@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] protobuf go and pointers

[Sankar P]

Thanks for the explanation. It does look much better in proto3. I will
see if it will be possible to switch to proto3.

2016-08-03 21:37 GMT+05:30 Ian Lance Taylor :
> On Wed, Aug 3, 2016 at 8:58 AM, Sankar  wrote:
>>
>> I have a .proto2 file, like:
>>
>> message s {
>> optional double a = 1;
>> }
>>
>> When I run protoc and generate the .pb.go file, it contains code like:
>>
>> type S struct {
>> A*float64 `protobuf:"fixed64,1,opt,name=a"
>> json:"a,omitempty"`
>> XXX_unrecognized []byte   `json:"-"`
>> }
>>
>> Why is the A field here a pointer instead of a normal float64 ?
>
> Because proto2 records not only the value of each field, but also
> whether the field is present or not.  Using a pointer is how the Go
> implementations indicates whether the field is present.
>
> This is better in proto3.  If you can switch to proto3, do so.
>
> Ian



-- 
Sankar P
http://psankar.blogspot.com

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

Re: [go-nuts] protobuf go and pointers

[Ian Lance Taylor]

On Wed, Aug 3, 2016 at 8:58 AM, Sankar  wrote:
>
> I have a .proto2 file, like:
>
> message s {
> optional double a = 1;
> }
>
> When I run protoc and generate the .pb.go file, it contains code like:
>
> type S struct {
> A*float64 `protobuf:"fixed64,1,opt,name=a"
> json:"a,omitempty"`
> XXX_unrecognized []byte   `json:"-"`
> }
>
> Why is the A field here a pointer instead of a normal float64 ?

Because proto2 records not only the value of each field, but also
whether the field is present or not.  Using a pointer is how the Go
implementations indicates whether the field is present.

This is better in proto3.  If you can switch to proto3, do so.

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: Will compiler do optimization here?

[T L]

On Wednesday, August 3, 2016 at 11:59:27 PM UTC+8, Hotei wrote:
>
> Have you tried examining the assembler output?  go build -gcflags="-S" 
> program.go if I recall correctly. 
>

yes, the output is different, looks like optimization is not made here, but 
I can't make sure.
 

>
>
> On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>>
>>
>> I know a string value can be used as []byte if the first parameter if the 
>> builtin copy/append function is a []byte value:
>>
>>> var bs []byte = make([]byte, 10)
>>> copy(bs, "abcde")
>>
>>
>> but if do explicit conversion anyway on the second string value  
>>
>>> var bs []byte = make([]byte, 10)
>>> copy(bs, []byte("abcde"))
>>>
>> will compiler do optimization here to avoid copying the underline byte 
>> array of the string? 
>>
>>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[James Bardin]

https://github.com/golang/go/issues/15209

On Wednesday, August 3, 2016 at 11:20:01 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>>
>> On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>> >
>> > Often, I need converting a []T to []interface{} to use the []interface 
>> as a variable length parameter.
>> > But converting a []T for []interface{} in a for loop is neither clean 
>> nor efficient.
>> >
>> > So is there a function in standard lib to convert []T to a 
>> []interface{}?
>> >
>>
>> There is no function and it's not possible to define one in Go.
>>
>> Define your own function for your specific type or avoid []interface{} if 
>> you can. Usually what you want is to put a []T in an interface{} and use 
>> reflect instead.
>>
>
> fmt.Println needs a []interface{} parameter.
>  
>

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

['Axel Wagner' via golang-nuts]

You probably don't want to actually call
fmt.Println(s...)
with s an []interface{}. Just do
fmt.Print(s)
instead.

On Wed, Aug 3, 2016 at 5:20 PM, T L  wrote:

>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>>
>> On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>> >
>> > Often, I need converting a []T to []interface{} to use the []interface
>> as a variable length parameter.
>> > But converting a []T for []interface{} in a for loop is neither clean
>> nor efficient.
>> >
>> > So is there a function in standard lib to convert []T to a
>> []interface{}?
>> >
>>
>> There is no function and it's not possible to define one in Go.
>>
>> Define your own function for your specific type or avoid []interface{} if
>> you can. Usually what you want is to put a []T in an interface{} and use
>> reflect instead.
>>
>
> fmt.Println needs a []interface{} parameter.
>
>
> --
> 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: Will compiler do optimization here?

[Hotei]

Have you tried examining the assembler output?  go build -gcflags="-S" 
program.go if I recall correctly. 


On Wednesday, August 3, 2016 at 11:27:36 AM UTC-4, T L wrote:
>
>
> I know a string value can be used as []byte if the first parameter if the 
> builtin copy/append function is a []byte value:
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, "abcde")
>
>
> but if do explicit conversion anyway on the second string value  
>
>> var bs []byte = make([]byte, 10)
>> copy(bs, []byte("abcde"))
>>
> will compiler do optimization here to avoid copying the underline byte 
> array of the string? 
>
>

-- 
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] protobuf go and pointers

[Sankar]

Hi

I have a .proto2 file, like:

message s {
optional double a = 1;
}

When I run protoc and generate the .pb.go file, it contains code like:

type S struct {
A*float64 `protobuf:"fixed64,1,opt,name=a" 
json:"a,omitempty"`
XXX_unrecognized []byte   `json:"-"`
}

Why is the A field here a pointer instead of a normal float64 ? Is there 
any way to get it a float64 ?

I ask this because, the code becomes too verbose. If it was just a float, I 
would have written code like:

var s pb.S
s.A, err = strconv.ParseFloat(strings.Replace(lines[0], ",", "", -1), 64)

whereas now I am forced to write:

f, err = strpconv.ParseFloat(strings.Replace(lines[0], ",", "", -1), 64)
if err != nil {
}
s.A = protobuf.Float64(f)


This is one extra line everywhere s.A is used. Also, in case of float64 it 
may be just one line. But if I have other structs as member elements in my 
structs, this code becomes even more complicated. Is there any way to 
generate code such that actual struct instances and datatype instances will 
be used instead of pointers ?

Thanks.

Sankar



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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Aug 3, 2016 at 7:36 AM T L  wrote:

> Often, I need converting a []T to []interface{} to use the []interface as
> a variable length parameter.
> But converting a []T for []interface{} in a for loop is neither clean nor
> efficient.
>

If there was a builtin that did it, it would simply need to do the same
loop. The memory representation is not the same.

Thomas

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

['Thomas Bushnell, BSG' via golang-nuts]

Don't confuse variadic arguments with slice arguments, by the way.

On Wed, Aug 3, 2016 at 8:20 AM T L  wrote:

>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>
>> On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>> >
>> > Often, I need converting a []T to []interface{} to use the []interface
>> as a variable length parameter.
>> > But converting a []T for []interface{} in a for loop is neither clean
>> nor efficient.
>> >
>> > So is there a function in standard lib to convert []T to a
>> []interface{}?
>> >
>>
>> There is no function and it's not possible to define one in Go.
>>
>> Define your own function for your specific type or avoid []interface{} if
>> you can. Usually what you want is to put a []T in an interface{} and use
>> reflect instead.
>>
>
> fmt.Println needs a []interface{} parameter.
>
>
> --
> 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] Is there a function in standard lib to convert []T to a []interface{}?

['Axel Wagner' via golang-nuts]

True, but it would still be just the same loop, it wouldn't actually be
significantly faster. And you'd need to put quite some machinery into a
pretty rarely used functionality, which means it also wouldn't be cleaner.

The thing is, that the memory representation of []T and []J, with J being
an interface type, is very different form each other and differs also for
each (T, J) pair, AIUI. So you can't really efficiently generalize this.
The only thing it could possibly safe you, is writing the actual loop and
in general go doesn't really do this kind of tradeoff (saving small amounts
of trivial work by complicating the language and -implementation).

On Wed, Aug 3, 2016 at 5:19 PM, T L  wrote:

>
>
> On Wednesday, August 3, 2016 at 10:54:29 PM UTC+8, Axel Wagner wrote:
>>
>> Why is converting it in a loop "neither clean nor efficient"? It seems to
>> be both to me: a) It's clean, as it's type-safe, so much less can go wrong
>> and it's obvious what it does and b) it's efficient, becaue a func([]T)
>> []interface{} would need to use reflection, just to also have the same loop
>> (but a less efficient one, as every operation would need to reflect). So,
>> writing a loop would, in fact, be *more* efficient and clean than a
>> function.
>>
>
> If the functionality is provided by builltin package, the reflection is
> not needed, just like the copy builtin function.
>
>
>>
>> On Wed, Aug 3, 2016 at 4:35 PM, T L  wrote:
>>
>>> Often, I need converting a []T to []interface{} to use the []interface
>>> as a variable length parameter.
>>> But converting a []T for []interface{} in a for loop is neither clean
>>> nor efficient.
>>>
>>> So is there a function in standard lib to convert []T to a []interface{}?
>>>
>>> --
>>> 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.
>

-- 
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] Will compiler do optimization here?

[T L]

I know a string value can be used as []byte if the first parameter if the 
builtin copy/append function is a []byte value:

> var bs []byte = make([]byte, 10)
> copy(bs, "abcde")


but if do explicit conversion anyway on the second string value  

> var bs []byte = make([]byte, 10)
> copy(bs, []byte("abcde"))
>
will compiler do optimization here to avoid copying the underline byte 
array of the string? 

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

Re: [go-nuts] Is there a function in standard lib to convert []T to a []interface{}?

[Jesse McNelis]

On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>
> Often, I need converting a []T to []interface{} to use the []interface as
a variable length parameter.
> But converting a []T for []interface{} in a for loop is neither clean nor
efficient.
>
> So is there a function in standard lib to convert []T to a []interface{}?
>

There is no function and it's not possible to define one in Go.

Define your own function for your specific type or avoid []interface{} if
you can. Usually what you want is to put a []T in an interface{} and use
reflect instead.

-- 
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] Is there a function in standard lib to convert []T to a []interface{}?

[T L]

Often, I need converting a []T to []interface{} to use the []interface as a 
variable length parameter.
But converting a []T for []interface{} in a for loop is neither clean nor 
efficient.

So is there a function in standard lib to convert []T to a []interface{}?

-- 
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: Data locality in large slices

[ondrej . kokes]

Downgrading to 1.6.3, I'm also getting consistent benchmark results. I'll 
try 1.7 on my Mac at home later today, to see if it's a 1.7 thing or a 
Windows thing or...?

On Wednesday, 3 August 2016 14:55:20 UTC+1, C Banning wrote:
>
> PS - that's with Go v1.6.
>
> On Wednesday, August 3, 2016 at 7:49:49 AM UTC-6, C Banning wrote:
>>
>> On MacBook Pro, 2.6 GHz Intel Core i7, 8 GB 1600 MHz memory, running OS X 
>> 10.11.6, your benchmarks look pretty consistent:
>>
>>
>> BenchmarkStart-4  20 1.45 ns/op
>>
>> BenchmarkEnd-420 1.47 ns/op
>>
>> BenchmarkHereThere-4  20 1.46 ns/op
>>
>> BenchmarkStartEnd-4   20 1.46 ns/op
>>
>> BenchmarkEndStart-4   20 1.46 ns/op
>>
>> BenchmarkFirst-4  20 0.59 ns/op
>>
>> BenchmarkSecond-4 20 0.59 ns/op
>>
>> BenchmarkLast-4   20 0.59 ns/op
>>
>> BenchmarkPenultimate-4 20 0.58 ns/op
>>
>> On Wednesday, August 3, 2016 at 5:56:32 AM UTC-6, Ondrej wrote:
>>>
>>> I wanted to see if there was a difference when loading values from a 
>>> large-ish slice (1 elements) - to see if caches, locality and other 
>>> things had any meaningful impacts. Whilst individual value loading (just a 
>>> single element) seemed to be equally fast regardless of element position 
>>> (see bench of First, Second, Last, Penultimate), when combining loading of 
>>> various values, there seem to be almost a 2.5x difference between loading 
>>> first four values and loading last four values (first two benchmarks).
>>> Loading the same values, just in different order, also yields different 
>>> execution times. But alternating loading (0, n, 1, n-1) seems to be faster 
>>> than loading first two values and last two values.
>>>
>>> (Setting the test slice to be an array instead wipes all differences 
>>> between benchmarks.)
>>>
>>> Can anyone point me to a resource - be it Go specific or on computer 
>>> science principles - that would explain these large differences?
>>>
>>> Thanks!
>>>
>>> https://play.golang.org/p/oMqDvXI9YW
>>>
>>

-- 
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] building an exe that will embed import in the .exe

[Zlatko Čalušić]

Hello,

When you compile go program, all your source and source from all 
imported packages is compiled together in the same binary (.exe). You 
don't need to worry about it. That's actually one of the go strengths, 
no dll hell.



On 03.08.2016 07:57, ov35...@gmail.com wrote:

Hi,

i have a program that imports a package from github.com/abc...
when i build the .exe how can i have the package/dependency included 
in the .exe ?


thanks,
Al


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


--
Zlatko

--
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: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?

[James Bardin]

The issue here in essence is that an http.Server doesn't store a 
new.Listener to expose, it only operates on one provided to the Serve 
method. Without changing the api, there's no way to expose a listener in an 
http.Server in a way that doesn't interfere with the other methods.

However, I also don't like that it's not completely trivial to create your 
own listener identical to that used by the http.Server. The basic http 
server isn't so bad, but does make use of a small tcpKeepAliveListener 
wrapper. The https method is a little more complicated, since it may modify 
the tls.Config. 

Maybe we could propose helper functions or methods for Listen and 
ListenTLS, which return a net.Listener? (I feel like there were related 
issues files, but I'm not finding them at the moment)



On Wednesday, August 3, 2016 at 8:03:03 AM UTC-4, David Marceau wrote:
>
> I can understand at first glance we may perceive ListenAndServeTLS as a 
> convenience helper, but if enough people to copy and paste its contents to 
> modify it, then the sublety is
> the function is actually assumed to be part of a Foundation/Framework that 
> people build on top of. It is under the golang/net after all.  It was meant 
> simply to be used and extended, NOT rewritten.
>
> A framework usually has a manner in which to access all its 
> class/duck-type's attributes and services.  In this case the package net 
> has a number of duck-types, Client, Server.
> Most of the Server's attributes are accessible, but stunningly the 
> listener itself does not belong to the Server duck-type when I believe it 
> should.  Otherwise the other suggestion would be to make it available by 
> making it a return variable if other framework devs feel it shouldn't be 
> part of the Server duck-type.  For those that don't want to tweak the 
> listener, they can simply use the _ standard to ignore that return variable.
>
> That said, I believe the listener is core and should be available from 
> this one service.  I'm sure there are other developers that rely on 
> ListenAndServeTLS and implicit understand exactly what it does.  I'm not 
> asking to change anything in their understanding about its behaviour.  I 
> asking the golang team to change something to in its characteristics which 
> fundamentally belongs to the Server duck-type which extends its original 
> meaning to something developers assume to be there in the first place.  I'm 
> surprised 
>
> LimitListener(srv.tlsListener, connectionCount) is not part of the Server 
> duck-type's api.  It makes sense to be there.  I'm stunned it's not there.
> That's why I came to the forum to ask why it wasn't there the first place.
>
>

-- 
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: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?

[Nathan Kerr]

Your research revealed the essential lines from ListenAndServeTLS that 
basically say:

1. create a tls listener
2. have the server serve using that listener

The LimitListener example follows this same pattern, just with net.Listener 
instead of a tls.Listener. A careful reading reveals that ListenAndServeTLS 
does not do anything to http.Server that you cannot do from outside the http 
package. This means that you can implement it in your own code; changing it to 
fit your needs. Your code will probably flow something like:

1. get a listener
2. limit that listener
3. create a tls.Config
4. tlslistener on LimitedListener with config
5. Server.Serve(tlsListener)

I am not sure if it would be better to limit before or after the tls listener.

I call this trick expanding convenience functions and explain it in regards to 
another problem at http://pocketgophers.com/expanding-convenience-functions/ 
(http://pocketgophers.com/expanding-convenience-functions/).

To answer your other questions:

I think that tlsListener is not part of the Server structure (so that you could 
easily fetch it and limit it) is for two reasons. First, it keeps the server 
and the listener separate. There is no fundamental reason that a single server 
could not serve on multiple listeners.

Second, Serve is basically an infinite loop waiting on Listener.Accept. What 
would it mean to change the server's listener while it is blocked accepting a 
new connection? The old listener would be blocking. If a connection was never 
made to it, the new listener would never accept any connections.

The API does give the control you need, just not in the way you looked for it.

For that last question, controlling connections is usually done as a way to 
control the use of some other resource such as cpu, memory, database access, 
etc. Managing resources must be done at both the OS and server level. What 
needs to be done depends on what the server needs to do, what hardware it is 
running on, service level agreements, etc. Sometimes limiting, sometimes 
expanding limits, sometime increasing performance.

Hope this helps.

-- 
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] building an exe that will embed import in the .exe

[ov35711]

Hi,

i have a program that imports a package from github.com/abc... 
when i build the .exe how can i have the package/dependency included in the 
.exe ? 

thanks,
Al


-- 
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: SWIG: typemap for std::string* arguments in std_string.i?

[s2323]

Please give me your typemap. 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: How to get struct of function

[Bruno Luis Panuto Silva]

I suggest you also take a look at the Go spec that describes method values: 
https://golang.org/ref/spec#Method_values
It seems to click on what you want to do.
Also, take a look at this article from Alex Edwards: 
http://www.alexedwards.net/blog/organising-database-access more 
specifically, the "Dependency Injection" part. Look at how he takes the 
method booksIndex from a struct and is still able to reference to *Env in 
the handler.

Regards,
Bruno

Em terça-feira, 26 de julho de 2016 21:37:13 UTC-3, nakot...@gmail.com 
escreveu:
>
> Lets say an example function like this
>
> func (r *Router) Get(path string, controller interface{}) {}
>
> And I am calling it this way
>
> Route.Get("/", controllers.Test.IsWorking)
>
>
>
> Refering to this function
>
> type Test struct {
>  Name string
> }
>
>
> func (t Test) IsWorking() {
>  log.Println("hello")
> }
>
> How can I get what struct is the function using? I mean on this example 
> the struct would be Test and the function IsWorking... I have no idea how 
> to achieve this
>
> Running a reflect TypeOf to controller returns this
>
> func(controllers.Test)
>
> But I am not sure how to create a reflect.New of the type of 
> controller.Test (without knowing about 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: Data locality in large slices

[Hotei]

With times under one nanosecond I'm wondering what you're actually 
measuring.  Aggressive optimization could make this an "empty" loop. 
 Synthetic benchmarks like this can be tricky to interpret.


On Wednesday, August 3, 2016 at 7:56:32 AM UTC-4, Ondrej wrote:
>
> I wanted to see if there was a difference when loading values from a 
> large-ish slice (1 elements) - to see if caches, locality and other 
> things had any meaningful impacts. Whilst individual value loading (just a 
> single element) seemed to be equally fast regardless of element position 
> (see bench of First, Second, Last, Penultimate), when combining loading of 
> various values, there seem to be almost a 2.5x difference between loading 
> first four values and loading last four values (first two benchmarks).
> Loading the same values, just in different order, also yields different 
> execution times. But alternating loading (0, n, 1, n-1) seems to be faster 
> than loading first two values and last two values.
>
> (Setting the test slice to be an array instead wipes all differences 
> between benchmarks.)
>
> Can anyone point me to a resource - be it Go specific or on computer 
> science principles - that would explain these large differences?
>
> Thanks!
>
> https://play.golang.org/p/oMqDvXI9YW
>

-- 
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] Data locality in large slices

[Ondrej]

I wanted to see if there was a difference when loading values from a 
large-ish slice (1 elements) - to see if caches, locality and other 
things had any meaningful impacts. Whilst individual value loading (just a 
single element) seemed to be equally fast regardless of element position 
(see bench of First, Second, Last, Penultimate), when combining loading of 
various values, there seem to be almost a 2.5x difference between loading 
first four values and loading last four values (first two benchmarks).
Loading the same values, just in different order, also yields different 
execution times. But alternating loading (0, n, 1, n-1) seems to be faster 
than loading first two values and last two values.

(Setting the test slice to be an array instead wipes all differences 
between benchmarks.)

Can anyone point me to a resource - be it Go specific or on computer 
science principles - that would explain these large differences?

Thanks!

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

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