Re: [go-nuts] image Gray16 endianness

[Pablo Rozas Larraondo]

Thanks Dan. I'm just surprised that Gray16 uses big endian when, for
example, Go's uint16 type uses the little endian convention.

I guess I find this weird and I want to know if there is a reason for
implementing Gray16 this way.

On Wed, Jan 11, 2017 at 4:40 PM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:

> On Wed, 2017-01-11 at 16:21 +1100, Pablo Rozas Larraondo wrote:
> > I'm confused with image.Gray16 having pixel values represented in the
> > wrong order. It seems to me that image.Gray16 considers numbers to be
> > big endian instead of little endian.
>
> Why do you think that is the wrong order?
>
> Here is where the order is defined (yes, big endian):
>
> https://golang.org/src/image/image.go?s=21077:21277#L756
>
>
> > I've created a small playground example to illustrate this:
> > https://play.golang.org/p/bhYbuIkkOz
> >
> > Is there something that I'm not doing right?
>
>
> Why do you need to know the byte ordering?
>
>

-- 
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] image Gray16 endianness

[Dan Kortschak]

On Wed, 2017-01-11 at 16:21 +1100, Pablo Rozas Larraondo wrote:
> I'm confused with image.Gray16 having pixel values represented in the
> wrong order. It seems to me that image.Gray16 considers numbers to be
> big endian instead of little endian.

Why do you think that is the wrong order?

Here is where the order is defined (yes, big endian):

https://golang.org/src/image/image.go?s=21077:21277#L756


> I've created a small playground example to illustrate this:
> https://play.golang.org/p/bhYbuIkkOz
> 
> Is there something that I'm not doing right?


Why do you need to know the byte ordering?

-- 
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] image Gray16 endianness

[Pablo Rozas Larraondo]

Hi,

I'm confused with image.Gray16 having pixel values represented in the wrong
order. It seems to me that image.Gray16 considers numbers to be big endian
instead of little endian.

I've created a small playground example to illustrate this:
https://play.golang.org/p/bhYbuIkkOz

Is there something that I'm not doing right?

Thanks for your help,
Pablo

-- 
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 1.8 Release Candidate 1 is released

[João Henrique Machado Silva]

Awesome! Thanks!!

Em terça-feira, 10 de janeiro de 2017 18:38:03 UTC-2, Chris Broadfoot 
escreveu:
>
> Hello gophers,
>
> We have just released go1.8rc1, a release candidate of Go 1.8.
> It is cut from release-branch.go1.8 at the revision tagged go1.8rc1.
>
> Thank you to everyone who has helped to test Go 1.8 so far.
> We still need more people to test, especially on production workloads.
> Your help is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.8rc1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.8rc1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.8rc1
>
> To find out what has changed in Go 1.8, read the draft release notes:
> https://beta.golang.org/doc/go1.8
>
> Documentation for Go 1.8 is available at:
> https://beta.golang.org/
>
> Our goal is to release the final version of Go 1.8 on February 1st.
>
> 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.

Re: [go-nuts] Compiling a really really large package

[chad . retz]

Good deal. Issue opened at https://github.com/golang/go/issues/18602 and I 
attached code to replicate.

On Tuesday, January 10, 2017 at 3:31:11 PM UTC-6, Ian Lance Taylor wrote:
>
> On Tue, Jan 10, 2017 at 9:47 AM,   
> wrote: 
> > 
> > Is there any value in me reporting it? If helpful, I may be able to toss 
> a 
> > large tarball up on Dropbox or something. It's not really high priority 
> for 
> > me either tbh because I know it would be difficult to stream the 
> compilation 
> > inside the same package w/ circular refs and therefore may not be fixed 
> for 
> > years. Thanks for your help. 
>
> Yes, it's useful to report it at https://golang.org/issue.  It's 
> useful to have real test cases.  Thanks. 
>
> 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] []struct{} vs. []*struct{}

[Steve Roth]

Suppose you are reading a list of structures, and you do not know in 
advance how many there will be.  I'm trying to figure out when it's better 
to append them to a slice of structures, and when it's better to append 
pointers to them to a slice of pointers.  It's easy enough to to the math 
on how many allocations are done, how much data is copied, etc. But what I 
don't know is how to gauge the tradeoff between allocations and data 
copies.  How much extra data copying is it worth accepting in order to do 
fewer allocations?

A couple of examples.  Suppose my structure size is 128 bytes, and it turns 
out I read 32 of them.  That's 4kB of raw data.
 read into []struct{}:  6 allocations totalling 8064 bytes, with 7296 
bytes of data copies
 read into []*struct{}:  69 allocations totalling 8568 bytes, with 248 
bytes of pointer copies
So, how does 7kB more data copies balance with 73 more allocations?  Is one 
clearly better than the other?

Or suppose a 32 byte structure, and it turns out I read 128 of them. 
 Again, 4kB of raw data.
 read into []struct{}:  8 allocations totalling 8169 bytes, with 7904 
bytes of data copies
 read into []*struct{}: 263 allocations totalling 10,200 bytes, with 
1016 bytes of pointer copies
How does 250 more allocations balance with 7kB more copies?

Of course it would be nice to answer these questions by benchmarking, but 
the problem tends to be embedded in highly complex systems that defy 
deterministic benchmarking.  So all I'm really looking for is the gut feel 
of those Go experts who have focused on these sort of optimizations in the 
past.  Thanks in advance...

-- 
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: bit twiddling API survey

[notcarl via golang-nuts]

Are bit rotations complied to single instructions?  Specifically things 
like:

var a uint32
(a << 5) | (a >> (32 - 5)



On Monday, January 9, 2017 at 3:46:45 PM UTC-8, mo...@google.com wrote:
>
> Hello!
>
> I'm working on a proposal for a compiler/hardware supported bittwidling 
> API. See discussion at https://github.com/golang/go/issues/17373. The 
> current set of functions I have in mind are: count trailing zeros, count 
> leading zeros, byte swap and population count for 32 and 64 bits integers. 
> Which other functions do you thing should be in this API? What are the 
> popular packages that implement (even without exporting) a subset of these 
> functions?
>
> Regards,
>
>
>

-- 
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: Go 1.8 Release Candidate 1 is released

[Brad Fitzpatrick]

App Engine has its own release cycle, but they're working on it.


On Tue, Jan 10, 2017 at 3:06 PM, go-guy 
wrote:

> Awesome!
>
> Is there any way that 1.8 can be made available to AppEngine when it's
> released?
>
> On Tuesday, January 10, 2017 at 3:38:03 PM UTC-5, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We have just released go1.8rc1, a release candidate of Go 1.8.
>> It is cut from release-branch.go1.8 at the revision tagged go1.8rc1.
>>
>> Thank you to everyone who has helped to test Go 1.8 so far.
>> We still need more people to test, especially on production workloads.
>> Your help is invaluable.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.8rc1
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.8rc1
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.8rc1
>>
>> To find out what has changed in Go 1.8, read the draft release notes:
>> https://beta.golang.org/doc/go1.8
>>
>> Documentation for Go 1.8 is available at:
>> https://beta.golang.org/
>>
>> Our goal is to release the final version of Go 1.8 on February 1st.
>>
>> 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.
>

-- 
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 1.8 Release Candidate 1 is released

[go-guy]

Awesome!

Is there any way that 1.8 can be made available to AppEngine when it's 
released?

On Tuesday, January 10, 2017 at 3:38:03 PM UTC-5, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.8rc1, a release candidate of Go 1.8.
> It is cut from release-branch.go1.8 at the revision tagged go1.8rc1.
>
> Thank you to everyone who has helped to test Go 1.8 so far.
> We still need more people to test, especially on production workloads.
> Your help is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.8rc1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.8rc1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.8rc1
>
> To find out what has changed in Go 1.8, read the draft release notes:
> https://beta.golang.org/doc/go1.8
>
> Documentation for Go 1.8 is available at:
> https://beta.golang.org/
>
> Our goal is to release the final version of Go 1.8 on February 1st.
>
> 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] Re: bit twiddling API survey

[Scott Pakin]

On Monday, January 9, 2017 at 6:07:19 PM UTC-7, ma...@influxdb.com wrote:
>
> I haven't personally experienced a need for a bit twiddling API, but if 
> you're looking for other interesting operations, you might want to check 
> out the awesome-bits curated list of bitwise operations [1].
>
> [1] https://github.com/keonkim/awesome-bits
>

Sean Eron Anderson's Bit Twiddling Hacks 
 is another good 
reference source.

— Scott

-- 
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: Poor performance of net.Dial() & friends

[sjn via golang-nuts]

On Tuesday, January 10, 2017 at 1:24:51 PM UTC-8, Dave Cheney wrote:

> Dumb question, what about your design prevents you from pooling and 
reusing connected sockets?

The requirements call for a new TCP connection each time. I proposed 
reusing connections but the customer isn't happy with that solution long 
term.

> Second dumb question, if your messages are 100 bytes long, why not use 
UDP?

The protocol is unfortunately not under my control. What's in the gist is 
not the actual protocol but an approximation. 

Simon

-- 
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] Compiling a really really large package

[Ian Lance Taylor]

On Tue, Jan 10, 2017 at 9:47 AM,   wrote:
>
> Is there any value in me reporting it? If helpful, I may be able to toss a
> large tarball up on Dropbox or something. It's not really high priority for
> me either tbh because I know it would be difficult to stream the compilation
> inside the same package w/ circular refs and therefore may not be fixed for
> years. Thanks for your help.

Yes, it's useful to report it at https://golang.org/issue.  It's
useful to have real test cases.  Thanks.

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] Poor performance of net.Dial() & friends

[Dave Cheney]

Second dumb question, if your messages are 100 bytes long, why not use UDP?

-- 
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 profiling in CGO

[Ian Lance Taylor]

On Tue, Jan 10, 2017 at 12:52 PM, Yucong Sun  wrote:
>
> I've successfully compile and staticlly linked my C++ project and CGO , I
> was trying to get on demand CPU profling to work, but it keeps generating
> empty outputs.
>
> The CPU profiling page mentioned that if code built in C mode, i need to do
> something with SIGPROF , but no examples were given, could anyone enlighten
> me?

What operating system?

What version of Go?

What is the "CPU profiling page"?  Do you mean
https://golang.org/pkg/runtime/pprof?  The references there to SIGPROF
are specific to using -buildmode=c-archive or -buildmode=c-shared.
Are you using one of those build modes?

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] Poor performance of net.Dial() & friends

[Dave Cheney]

Dumb question, what about your design prevents you from pooling and reusing 
connected sockets?

-- 
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 profiling in CGO

[Yucong Sun]

Hi,

I've successfully compile and staticlly linked my C++ project and CGO , I 
was trying to get on demand CPU profling to work, but it keeps generating 
empty outputs.

The CPU profiling page mentioned that if code built in C mode, i need to do 
something with SIGPROF , but no examples were given, could anyone enlighten 
me?

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] best way to write a file handler to serve gzipped files

['Anmol Sethi' via golang-nuts]

Hello, I'm trying to write a http handler to serve gzipped files but if the
client does not accept the gzip content-encoding, it falls back to identity.

I see three ways to do this.

First is dynamic gzipping. If a client supports it and a file is gzippable,
I gzip the file on the fly and then serve it. Interestingly, I noticed that
google does the opposite. They have the gzipped versions of the files
stored, but when a client does not accept the gzip content-encoding, the
server decompresses the gzipped file on the fly and serves that. This first
method is attractive because it is simple to implement but it can be CPU
intensive.

Second is static gzipping on the file system, e.g. storing .gz files next
to regular files. Another variation on this might be to have a second root
folder, one which contains the gzipped files. This is attractive because
you can gzip files at the highest compression level to save the most on
bandwidth but it requires some setup.

Third is a combination of the first two, gzipping files as they are
requested and storing them in an in memory cache and serving subsequent
requests to clients that accept the gzip content-encoding from there. This
combines the simplicity of the first option with the performance benefits
of the second option but it is significantly more complex to write the code.

Which do you think is the best option?

-- 
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] Compiling a really really large package

[chad . retz]

Is there any value in me reporting it? If helpful, I may be able to toss a 
large tarball up on Dropbox or something. It's not really high priority for 
me either tbh because I know it would be difficult to stream the 
compilation inside the same package w/ circular refs and therefore may not 
be fixed for years. Thanks for your help.

On Tuesday, January 10, 2017 at 11:35:32 AM UTC-6, Ian Lance Taylor wrote:
>
> On Tue, Jan 10, 2017 at 9:22 AM,   
> wrote: 
> > 
> > Just as an update, Go 1.8 doesn't help much, and the compile flags do 
> reduce 
> > memory usage which only extends the inevitable time it runs out of 
> memory. I 
> > guess I am at a loss here. I suppose this is not considered a bug, 
> correct? 
> > Just a practical limitation of the compiler to use more memory 
> proportional 
> > to same-package code size? 
>
> Oh, no, it's definitely a bug.  It's just very hard to fix and rare in 
> practice, so it's not high priority. 
>
> 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] Reset Slice with Make Every Time?

[wadekim991 via golang-nuts]

On Tue, 1/10/17, Marvin Renich  wrote:

 Subject: Re: [go-nuts] Reset Slice with Make Every Time?
 To: "golang-nuts" 
 Date: Tuesday, January 10, 2017, 5:29 PM
 
 * Tomi Häsä 
 [170110 02:23]:
 > On Tuesday, January 10,
 2017 at 1:49:37 AM UTC+2, kortschak wrote:
 > > On Mon, 2017-01-09 at 15:12 -0800,
 Tomi Häsä wrote: 
 > > > Is this
 the correct way of resetting a slice? I mean do I always
 > > > need to  use make to reset a
 slice? 
 > > > 
 >
 > >     // initialize slice 
 > > >     onearea Area =
 Area{} 
 > > >     group
 []Area = make( []Area, 0, MAX ) 
 > >
 > 
 > > >     // add
 stuff to slice 
 > > > 
    group = append( group, onearea ) 
 > > > 
 > >
 >     // reset slice 
 >
 > >     group = make( []Area, 0, MAX ) 
 > >
 > > group =
 group[:0] 
 > >
 >
 > > Using nil to reset a slice doesn't seem to be
 wise as the capacity
 > > > does not
 stay with MAX, but it will decrease to 2 in my program. 
 > > > 
 > >
 >     group = nil 
 > >
 > 
 > > > Full code here: https://github.com/tomihasa/unicodetest
 
 > 
 > By the way,
 what happens to the old data I used with the previous make
 
 > command?
 
 I'm not sure if these were mentioned
 earlier in the thread, but both
 https://blog.golang.org/slices and
 https://blog.golang.org/go-slices-usage-and-internals
 give some really
 good info on this.
 
 The abbreviated answer is to
 think of a slice as a view into its backing
 array.  As long as a slice (or other variable)
 refers to the backing
 array or one of its
 elements, the garbage collector will not reclaim any
 of the backing array.  So, even doing
     group = group[1:]
 will
 not allow the GC to reclaim the memory for the old
 group[0].
 
 If the elements
 of the slice (and therefore of the backing array) are
 simple values, such as ints, or structs of
 simple values, doing
     group =
 group[:0]
 will reset the slice to empty
 without changing its current capacity and
 without reallocating the memory for its backing
 array.
 
 If, however, the
 slice elements contain pointers, maps, channels, or
 other slices, then the memory referred to by
 those items will not be
 reclaimed, even
 though group appears to not refer to them.  As you
 append to group the second time around, those
 elements will be
 overwritten, and the memory
 referred to by the old values will be able
 to be reclaimed by the GC.  Example:
 
     type LargeStruct struct
 { /* lots of fields */ }
     func
 NewLargeStruct(i int) (ls *LargeStruct) { /* does what's
 needed */ }
     type SmallStruct struct {
 ls *LargeStruct }
     var small
 []SmallStruct = make([]SmallStruct, 0, 50)
     for i := 0; i < 10; i++ {
         small = append(small,
 SmallStruct{NewLargeStruct(i)})
     }
     small[:0]
 
 small is now an empty slice with capacity 50,
 but none of the memory
 allocated for the ten
 instances of LargeStruct is able to be reclaimed
 by the GC.  This is because the backing array
 still contains the
 pointers to all of the
 LargeStruct's allocated in the loop.  Now do
 
     small = append(small,
 SmallStruct{NewLargeStruct(41)})
     small
 = append(small, SmallStruct{NewLargeStruct(42)})
 
 and the memory allocated by
 NewLargeStruct(0) and NewLargeStruct(1) in
 the earlier loop can be reclaimed (assuming
 they are not referenced
 elsewhere).
 
 On the other hand,
 replacing
     small[:0]
 in
 the above code by
     small =
 make([]SmallStruct, 0, 50)
 will allocate a
 new backing array and will allow the old backing array
 as well as all of the LargeStruct's to be
 reclaimed.  Which is better
 will depend on
 your application.
 
 ...Marvin
 
 -- 
 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.arlamentul de la Bucuresti a suspendat 
activitatea P.C.R.  care sustinuse fatis

-- 
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 know the listener

[Nathan Kerr]

Hi,

You can use RemoteAddr from *http.Request to tell the difference. When the 
request comes through the unix socket, RemoteAddr is "" (i.e., blank).

The source for my test server is at https://play.golang.org/p/m3h_L_ACks

I used curl 127.0.0.1:3001 to test the tcp socket and curl-unix-socket 
unix://`pwd`/tmp_socket: from https://github.com/Soulou/curl-unix-socket to 
test the unix socket.

Hopefully my server is similar to what you had. If not, please post some 
code.

Cheers,

Nathan

On Tuesday, January 10, 2017 at 3:23:30 PM UTC+1, hawk hsieh wrote:
>
> I open a port 80 and a unix socket to listen http request simultaneously.
> I would like to determine where is the request coming from so that the 
> request from unix socket is no need to be authorized.
> Maybe the first problem is to know the listener from  http.ResponseWriter 
> or *http.Request. I guess.
> Is there any workaround or idiomatic manner to find the listener ? 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.

Re: [go-nuts] Re: error message with Go fonts

[Mathieu Lonjaret]

Ah thanks, I had forgotten to try reading that one. Here goes:

$ 9p read 'font/Go Mono/11/font'
 16  13
0x 0x001f x.bit
0x0020 0x003f x0020.bit
...


On 10 January 2017 at 17:13, andrey mirtchovski 
wrote:

> > Sorry, I don't understand what you mean by the textual Plan 9 font file.
>
> do $ 9p read 'font/Go Mono/11/font' instead. the second line should
> point to the glyph file for runes 0x0 to 0xff, something like:
>
> 0x 0x00ff x.bit
>

-- 
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: error message with Go fonts

[andrey mirtchovski]

> Sorry, I don't understand what you mean by the textual Plan 9 font file.

do $ 9p read 'font/Go Mono/11/font' instead. the second line should
point to the glyph file for runes 0x0 to 0xff, something like:

0x 0x00ff x.bit

-- 
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.org/x/crypto/nacl authentication support

[Manlio Perillo]

Hi.

I need an high level crypto package, and x/crypto/nacl seems a good 
solution.
However It only supports authenticated encryption.
What about authentication (http://nacl.cr.yp.to/auth.html) ?

Surely, compared to authenticated encryption, authentication is simple to 
implement.
However I would like to avoid having to implement and maintain my own crypt 
package.


Thanks
Manlio

-- 
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] Reset Slice with Make Every Time?

[Marvin Renich]

* Tomi Häsä  [170110 02:23]:
> On Tuesday, January 10, 2017 at 1:49:37 AM UTC+2, kortschak wrote:
> > On Mon, 2017-01-09 at 15:12 -0800, Tomi Häsä wrote: 
> > > Is this the correct way of resetting a slice? I mean do I always
> > > need to  use make to reset a slice? 
> > > 
> > > // initialize slice 
> > > onearea Area = Area{} 
> > > group []Area = make( []Area, 0, MAX ) 
> > > 
> > > // add stuff to slice 
> > > group = append( group, onearea ) 
> > > 
> > > // reset slice 
> > > group = make( []Area, 0, MAX ) 
> >
> > group = group[:0] 
> >
> > > Using nil to reset a slice doesn't seem to be wise as the capacity
> > > does not stay with MAX, but it will decrease to 2 in my program. 
> > > 
> > > group = nil 
> > > 
> > > Full code here: https://github.com/tomihasa/unicodetest 
> 
> By the way, what happens to the old data I used with the previous make 
> command?

I'm not sure if these were mentioned earlier in the thread, but both
https://blog.golang.org/slices and
https://blog.golang.org/go-slices-usage-and-internals give some really
good info on this.

The abbreviated answer is to think of a slice as a view into its backing
array.  As long as a slice (or other variable) refers to the backing
array or one of its elements, the garbage collector will not reclaim any
of the backing array.  So, even doing
group = group[1:]
will not allow the GC to reclaim the memory for the old group[0].

If the elements of the slice (and therefore of the backing array) are
simple values, such as ints, or structs of simple values, doing
group = group[:0]
will reset the slice to empty without changing its current capacity and
without reallocating the memory for its backing array.

If, however, the slice elements contain pointers, maps, channels, or
other slices, then the memory referred to by those items will not be
reclaimed, even though group appears to not refer to them.  As you
append to group the second time around, those elements will be
overwritten, and the memory referred to by the old values will be able
to be reclaimed by the GC.  Example:

type LargeStruct struct { /* lots of fields */ }
func NewLargeStruct(i int) (ls *LargeStruct) { /* does what's needed */ }
type SmallStruct struct { ls *LargeStruct }
var small []SmallStruct = make([]SmallStruct, 0, 50)
for i := 0; i < 10; i++ {
small = append(small, SmallStruct{NewLargeStruct(i)})
}
small[:0]

small is now an empty slice with capacity 50, but none of the memory
allocated for the ten instances of LargeStruct is able to be reclaimed
by the GC.  This is because the backing array still contains the
pointers to all of the LargeStruct's allocated in the loop.  Now do

small = append(small, SmallStruct{NewLargeStruct(41)})
small = append(small, SmallStruct{NewLargeStruct(42)})

and the memory allocated by NewLargeStruct(0) and NewLargeStruct(1) in
the earlier loop can be reclaimed (assuming they are not referenced
elsewhere).

On the other hand, replacing
small[:0]
in the above code by
small = make([]SmallStruct, 0, 50)
will allocate a new backing array and will allow the old backing array
as well as all of the LargeStruct's to be reclaimed.  Which is better
will depend on your application.

...Marvin

-- 
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] Sort between bitcoin addresses and number of pages

[Anonymous]

hello i'm a problem with source code of directory.io :

As said in the title I'm on a project (GOLANG language)
I recreated the site directory.io with as a modification the display of the 
final balance of each address (addresses included)
And also put a filter of the kind the addresses beginning with "1Feex" that I 
can modify at will.

Only even by filtering the addresses the number of pages (or bitcoin addresses 
do not decrease).
I would have liked to know if I could get help from members who know the golang 
language?

For info here is the address filter:

if strings.HasPrefix(key.compressed, "1Feex") {
fmt.Fprintf(w, KeyTemplate, key.private, key.private, 
key.number, key.private, key.compressed, key.compressed)


And the number of bitcoins addresses which is in byte:

total = new(big.Int).SetBytes([]byte{
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
})


thanks for 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] How to know the listener

[hawk hsieh]

I open a port 80 and a unix socket to listen http request simultaneously.
I would like to determine where is the request coming from so that the 
request from unix socket is no need to be authorized.
Maybe the first problem is to know the listener from  http.ResponseWriter 
or *http.Request. I guess.
Is there any workaround or idiomatic manner to find the listener ? 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.

Re: [go-nuts] Reset Slice with Make Every Time?

[djadala]

On Tuesday, January 10, 2017 at 9:52:06 AM UTC+2, Chetan Gowda wrote:

Old data remains as it is in the existing allocation. It will be 
> overwritten as you fill up the slice again. 


This happens in case of group = group[:0],
OP asks what happens   in case of group = make( []Area, 0, MAX ),
In that case  old data will be garbage collected when GC runs.

Djadala  

-- 
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: error message with Go fonts

[Mathieu Lonjaret]

Sorry, I don't understand what you mean by the textual Plan 9 font file.

The actual font is installed at /usr/share/fonts/truetype/go/Go-Mono.ttf ,
and I think acme accesses it through fontsrv. If I do

$ 9p ls 'font/Go Mono/11/'

I get:
font
x.bit
x0020.bit
x0040.bit
...
x2660.bit
xf800.bit
xfb00.bit

and it does not seem like any of these are textual representations.
(they're probably the subfont images you're talking about?).


On 9 January 2017 at 20:44, Rob Pike  wrote:

> That's a sign that your .font file is wrong, for instance that it contains
> a loop or hole in its definition. In particular it's about the textual Plan
> 9 font file, not the subfont images.
>
> But it should be easy to figure out: where does rune U+ map to,
> according to the font? I suspect the answer is "nowhere" and that's what's
> wrong.
>
> -rob
>
>
> On Tue, Jan 10, 2017 at 2:05 AM, Mathieu Lonjaret <
> mathieu.lonja...@gmail.com> wrote:
>
>> Hi,
>>
>> I've been using the Go fonts (in p9p acme) for a week now, and so far I
>> kind of like it, so thanks for making it.
>>
>> Anyway, I've just noticed this error message in the terminal from which I
>> launched acme, so I assume acme is the one complaining about it, but I
>> haven't dug any deeper.
>>
>> "stringwidth: bad character set for rune 0x in /mnt/font/Go
>> Mono/11a/font"
>>
>> I don't know what it is I did to make it appear, and it looks more like a
>> warning, but given that I had never seen this message before with other
>> fonts, I figured I'd report it.
>>
>> Do you want me to grep into acme, or report a bug somewhere? Or is that
>> an expected warning you already know about?
>>
>> Regards,
>> Mathieu
>>
>>
>

-- 
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] gtcp - TCP server framework that inherits battle-tested code from net/http(tips

[neat cat]

Hi all,

I love go especially to write any server stuffs and wish if there was a
generic server stuff that inherits battle-tested code from net/http (proper
error handling, heuristic exponential backoff value working well in most
cases and Close/Shutdown operations that will be introduced in 1.8 and
more!).

I made it.

https://github.com/cat2neat/gtcp

gtcp is a TCP server framework not only that inherits battle-tested code
from net/http but can be extended through built-in interfaces and makes it
easy to write a keepalive protocol that cooperates with
server.Close|Shutdown and also makes it easy to write pipelining one.

The below are features.

### Features
- Can be used in the same manner with http.Server(>= 1.8).
  - Make API as much compatible as possible.
  - Make the zero value useful.
- Inherits as much battle tested code from net/http.
- Provides much flexiblity through built-in interfaces.
  - ConnHandler
- ConnHandler
- KeepAliveHandler that makes it easy to implement keepalive.
- PipelineHandler that makes it easy to implement pipelining.
  - ConnTracker
- MapConnTracker that handles force closing active connections also
graceful shutdown.
- WGConnTracker that handles only graceful shutdown using a naive way
with sync.WaitGroup.
  - Conn
- BufferedConn that wraps Conn in bufio.Reader/Writer.
- StatsConn that wraps Conn to measure incoming/outgoing bytes.
- DebugConn that wraps Conn to output debug information.
  - Logger
- BuiltinLogger that logs using standard log package.
  - Retry
- ExponentialRetry that implements exponential backoff algorithm
without jitter.
  - Statistics
- TrafficStatistics that measures incomming/outgoing traffic across a
server.
  - Limiter
- MaxConnLimiter that limits connections based on the maximum number.
- Gets GC pressure as little as possible with sync.Pool.
- Zero 3rd party dependencies.

I'm going to write some servers on top of gtcp so actively keep maintaining
as long as possible.

Any feedback, contributions or questions are appreciated.

cat2neat

-- 
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: database/sql: special interest group

[LMR]

Great!
Thank you.
Much needed feature IMO

On Monday, 9 January 2017 01:48:13 UTC+1, Daniel Theophanes wrote:
>
> In go1.8 I worked on adding a number of features to "database/sql". I hope 
> to address a few more needs in the go1.9 cycle. To that end I want to 
> gather some other voices who both use Go and who use SQL based database 
> servers regularly. Even if you don't use "database/sql" I would still like 
> to hear from you.
>
> I've created a new group 
> https://groups.google.com/forum/#!forum/golang-sql for such discussion 
> and interest. I would like to discuss a few of the issues listed at 
> https://github.com/golang/go/issues/assigned/kardianos with a wider 
> audience instead of the one or two people who happened upon the issue at 
> hand.
>
> In the further future I would like to discuss connection pool and driver 
> optimizations, testing, and a dedicated (non-std lib) package for defining 
> SQL types, common utilities such as table buffers, and interfaces like bulk 
> load. I think it would also be good to vet drivers through a common testing 
> suit and setup CI for drivers without it yet.
>
> Thanks, -Daniel
>
>

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