[go-nuts] Re: Go as your first language

[christophberger . com]

Author of the Master Go course here. I am exited to see my course being 
recommended in this group, thank you Kevin!

I am positively surprised to see that you consider the course suitable for 
learning programming from scratch. The course was designed for people who 
already know another language, to keep its size manageable. The course 
definitely does not teach basic programming concepts. However, the course 
does not require deep programming expertise either. One of my students, a 
newcomer to programming, took an online CS introduction course (CS50x from 
Harvard University via edx.org) before taking the Master Go course, and 
recommends this combination. Which makes me think the course could indeed 
be suited for a certain group of beginners who are willing to fill the gaps 
through other means.

So to anyone who reads these lines and seeks to learn Go with no or very 
little prior knowledge about programming: 

I would suggest looking at the curriculum (it's on the landing page 
) and viewing the lectures that are open 
for preview before you buy. If the content you read and see there seems too 
unfamiliar, too advanced, or if the lectures seem to fast-paced, don't 
buy.  You can also ping me at any time, I am happy to answer any question 
about the course. (Find the email address in the FAQ on the landing page.) 
The last thing I want to do is to sell you a course that is not for you.

Best,
Christoph


On Tuesday, January 16, 2018 at 3:13:13 PM UTC+1, Kevin Powick wrote:
>
> I've had good feedback from colleagues on the following course.
>
> https://appliedgo.com/p/mastergo
>
> There are also the usual reference at golang.org such as "Effective Go", 
> the on-line introduction,  and the language spec itself.
>
> --
> Kevin Powick
>
> On Tuesday, 16 January 2018 02:10:48 UTC-5, James Pettyjohn wrote:
>>
>> I've had multiple occasions where I've needed to train someone to be a 
>> programmer from scratch in a Go environment.
>>
>> Trouble I've found is while the go texts are simple and straightforward, 
>> relatively speaking, they often written by someone who sought a better life 
>> in go, fleeing Java/C/C++. They will routinely reference these other 
>> languages in examples, touting the benefits of go is comparison to the old 
>> language. Much like reading GOF design patterns without a background in 
>> smalltalk, it is hard for new developers to pick up when they don't know 
>> other languages first. Commonly they cut it back and learn JS first.
>>
>> Assuming they eventually picked up the language they now need to learn 
>> how to be a software engineer and write code that doesn't suck. Especially 
>> present with those who just learned how to program using JS. And what I've 
>> seen on the subject often expects a knowledge of another language.
>>
>> Are there tracks of knowledge to take someone from 0 to understanding 
>> baseline knowledge?  
>>
>> And from there through taking them to a professional grade standard?
>>
>> Best,
>> James
>>
>

-- 
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] Avoiding duplication in parallel tests

[Kevin Burke]

I have a bunch of tests I would like to run in parallel; I think this is a 
common situation for database backed tests where you might need to 
establish a connection or a transaction, run a bunch of queries, and then 
truncate the database. Right now I have something like this:

func testA(t *testing.T) { t.Parallel(); ... }

func testB(t *testing.T) { t.Parallel(); ... }

func testC(t *testing.T) { t.Parallel(); ... }

func testD(t *testing.T) { t.Parallel(); ... }

func TestAll(t *testing.T) {
setUp(t)
defer tearDown(t)
t.Run("parallel", func(t *testing.T) {
t.Run("TestA", testA)
t.Run("TestB", testB)
t.Run("TestC", testC)
t.Run("TestD", testD)
})
}

However there's some duplication there. 

- Is there a way to avoid the extra level of Run() nesting? It's a little 
annoying when specifying a command to `go test -run`.

- Is there any way to automatically populate the test name from the 
function name? I could probably hack up something with the reflect package 
based on the function name but that would also be pretty ugly, I'm guessing.

-- 
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: Having a Model Package

[Keith Brown]

is there a page such as "https://github.com/yksz/go-design-patterns; I can 
refer to for golang design-patterns? I wish there were some official ones, 
which can help language newbies and give them confidence that what they are 
doing is the "right way". I understand it depends on the problem but would 
be great if something was there.


On Saturday, December 16, 2017 at 2:52:14 AM UTC-5, dc0d wrote:
>
> I've been reading the other day: "having a model package, is considered a 
> code smell, in Go".
>
> 1 - Why?
> 2 - If so, what approach should be chosen? 
> 3 - And how? (In Go code, Go features to employ, Patterns (small/big 
> projects), etc)
>

-- 
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: iconvg: a compact, binary format for simple vector graphics

[Nigel Tao]

On Thu, Jan 18, 2018 at 1:53 AM,   wrote:
> I'm wondering if you know any c/cpp implementation of your renderer

I don't know of a C/C++ implementation, sorry. If you find (or write)
one, let me know!

-- 
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: Race detector for Windows GUI apps. "go build -race" asks for gcc. Why?

[Tad Vizbaras]

Summary: adding *.syso file to main packages directory stops normal race 
detector enabled build on windows/amd64.

This in essence prevents race detection on Windows apps with GUI interface 
that use binary resources (icons, etc.).


-- 
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] Race detector for Windows GUI apps. "go build -race" asks for gcc. Why?

[Tad Vizbaras]

This is windows/amd64 setup.

go build -race works in other scenarios. Example: building console apps.
It also works if *.syso file with binary resources (icons, etc.) is NOT in 
the build directory.

Once you place rsrc.syso or any *.syso "go build -race" stops working.

There is the output:

go build -race
# xtrans/prod/xtrunwui
C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exec: "gcc": 
executable file not found in %PATH%

None of the source files uses import "C" and I do not want to install C for 
this since if there is no *.syso file
then build -race works. Unfortunately there are icons in rsrc.syso and GUI 
app simply does not run without them.


-- 
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: Slice of structs element swap performance

[lemire]

> My understanding is that when something is assigned to an interface the 
> thing is copied. 
>

In the context of the code in question, the interface refers to pointers.

-- 
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: iconvg: a compact, binary format for simple vector graphics

[rxboucher]

Hi Nigel,

I'm looking for a compact vg format and I found your iconvg format.
This seems to be exactly what I'm looking for. 
I'm wondering if you know any c/cpp implementation of your renderer (into 
image buffer). This is to be used in a small embedded system.

Great job.
Regards
Eric


Le lundi 24 octobre 2016 08:52:48 UTC+2, Nigel Tao a écrit :
>
> I was looking for a compact, binary format for simple vector graphics. 
> I didn't find one that did all I wanted. 
>
> SVG is the de facto standard for vector graphics, in the open source 
> world. Unfortunately, https://www.w3.org/TR/SVG/single-page.html 
> prints as 400 pages, not including the XML, CSS or XSLT 
> specifications. The S in SVG doesn't stand for simple. 
>
> The Haiku Vector Icon Format is pretty close. Unfortunately, I didn't 
> find a written specification, only a single C implementation, tightly 
> coupled, as far as I could tell, to the Haiku operating system. Also, 
>
> https://www.haiku-os.org/articles/2009-09-14_why_haiku_vector_icons_are_so_small
>  
> says that "you wouldn't really want to use HVIF to store generic 
> vector graphics". 
>
> OpenType fonts contain vector graphics (glyphs), and people use it for 
> icon and emoji fonts. Unfortunately, there doesn't appear to be a 
> clear standard for colored or partially transparent glyphs. 
> https://en.wikipedia.org/wiki/OpenType#Color lists three competing 
> approaches, built on PNG, SVG or neither. 
>
> So, as an experiment, I invented a new format: IconVG. The format 
> itself is documented at 
> https://godoc.org/golang.org/x/exp/shiny/iconvg and there are some 
> examples at https://go.googlesource.com/exp/+/master/shiny/iconvg/testdata 
>
> The Material Design icon set (https://design.google.com/icons/) 
> consists of 961 vector icons. As SVG files, this totals 312,887 bytes. 
> As 24*24 pixel PNGs, 190,840 bytes. As 48*48 pixel PNGs, 318,219 
> bytes. As IconVGs, 122,012 bytes. 
>
> Like all of the golang.org/x/exp/shiny code, this is experimental, but 
> I think that IconVG is at an interesting enough point now to share. 
>
> The vector rasterizer at golang.org/x/image/vector is also a nice Go 
> package, in my biased opinion, based on the algorithm described at 
>
> https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445#.ja3y3m6z2,
>  
>
> but that's probably a different topic for a different time. 
>
> Comments welcome. 
>

-- 
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.net/websocket framing problem

[adumandix]

Oh,It helps me a lot,thanks

在 2012年11月9日星期五 UTC+8下午5:03:56，Timo Savola写道：
>
> Hello
>
> I would like to receive intact WebSocket frames with controlled buffer 
> sizes (to prevent excessive memory usage caused by bad peers).  The 
> websocket.Message codec doesn't seem to allow that, but according to the 
> websocket.Conn.Read function documentation I could use it directly to read 
> the whole frame to my pre-allocated array if I provide one large enough. 
> (Even then I can't always tell if the whole frame was read, but I could 
> live with providing an array of maxsize+1 bytes and disconnecting if I read 
> over maxsize bytes.)
>
> The problem is that Conn.Read doesn't work as advertised; the 
> documentation says: "if msg is not large enough for the frame data, it 
> fills the msg and next Read will read the rest of the frame data."  When 
> reading frames of over 4088 bytes into larger buffers, it consistently 
> returns data in 4088-byte chunks.  The implementation relies on 
> io.LimitedReader to fill the array in one go, which it apparently doesn't 
> do.  This behavior of course conforms to the io.Reader interface, and that 
> might be what the implementer had in mind, but then the documentation 
> should be fixed.
>
> But changing the documentation wouldn't help me, because if I have to call 
> Conn.Read in a loop to get the whole frame, I wouldn't know where the frame 
> boundaries are.  I see two alternatives which would make me happy:
>
> 1. If the Conn.Read implementation is considered buggy, apply the patch 
> I've attached.  (I'll go through the official review channel if this is 
> indeed the real bug that needs to be fixed.)
>
> 2. Provide an API for asking the size of the frame before receiving it. 
>  (This would be great regardless of alternative 1.)
>
> timo
>
>

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

[go-nuts] Re: [golang-dev] Go 1.10 Beta 2 is released

[bob . hiestand]

On Thursday, January 11, 2018 at 2:28:36 PM UTC-6, Ian Lance Taylor wrote:
>
>
> Please do test this if you can.  There are significant changes to the 
> go tool.  Please report bugs now, so that we can fix them before the 
> final release. 
>
> In particular, there are significant changes to the go tool caching 
> and `go test`; see the release notes.  As a consequence, I encourage 
> anybody who uses the go tool's -buildmode option to test the new 
> release, as those options are less used and less tested. 
>
>
I apologize for a poor error report, but using 1.10 beta 2  on windows I 
received an error running 'go test' that I haven't encountered before:

>go test -c
open C:\Users\...\api.test.exe: The process cannot access the file because 
it is being used by another process. 

It has only occurred once in many (dozens, at least) invocations in the 
last few days.

Thank you,

Bob

-- 
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: Slice of structs element swap performance

[matthewjuran]

My understanding is that when something is assigned to an interface the 
thing is copied. Maybe the swap is causing a copy of the interface contents?

I'm not sure what Xcode does but pprof and package testing benchmark are 
more common. For benchmarking be sure to disable power management features 
that may affect consistent performance.

(for others taking a look Swap is in parallel.go and container is in 
roaringarray.go)

Matt

On Wednesday, January 17, 2018 at 7:24:56 AM UTC-6, Maciej Biłas wrote:
>
> Hi,
>
> I've ran into an interesting performance problem.
>
> I've made a small change in the struct that I'm swapping (like in heap 
> Swap function example: h[i], h[j] = h[j], h[i]), namely I've removed a 
> reference to a interface object. After this change the swap operation speed 
> increased by 10x (at least according to Xcode, which I used to instrument 
> the benchmark):
>
> Below is the instrumentation report. The function in question is 
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Swap
>
> With struct containing an interface:
>
> 12242 12242.0ms9.2%   450.0  
> github.com/RoaringBitmap/roaring.ParOr
> 11729 11729.0ms8.8%   2476.0  
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).PopNextContainers
> 8526  8526.0ms6.4%657.0
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).PopIncrementing
> 7782  7782.0ms5.8%3239.0container/heap.Fix
> 4543  4543.0ms3.4%2658.0 container/heap.down
> 1885  1885.0ms1.4%1127.0  
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Swap
> 758   758.0ms0.5% 166.0runtime.typedmemmove
> 592   592.0ms0.4% 295.0 
> runtime.bulkBarrierPreWrite
> 7979.0ms0.0%  13.0  runtime.typedmemmove
> 6666.0ms0.0%  36.0   runtime.bulkBarrierPreWrite
>
>
> without:
>
> 6249  6249.0ms8.2%181.0  
> github.com/RoaringBitmap/roaring.ParOr
> 5943  5943.0ms7.8%1473.0  
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Next
> 4450  4450.0ms5.8%146.0
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).popIncrementing
> 4300  4300.0ms5.6%2129.0container/heap.Fix
> 2171  2171.0ms2.8%2021.0 container/heap.down
> 150   150.0ms0.1% 4.0 
> github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Swap
> 146   146.0ms0.1% 41.0 runtime.writebarrierptr
>
> The second column is the total time of a function, the 3rd is the 
> percentage of time spent in that function relative to the total execution 
> time.
>
> The code commit can be found here: 
> https://github.com/RoaringBitmap/roaring/pull/133/commits/970e4f698d69e14a79c685c986b0062d8aec1877,
>  
> here is a link to the pull request containing the commit 
> https://github.com/RoaringBitmap/roaring/pull/133 (if your curious)
>
> I'm using Go 1.9.2, MacOS 10.13.2 on an i7 quad-core Intel Haswell 
> processor.
>
> I hope the benchmarks are correct. Please correct me if I got something 
> wrong.
>
> Is that to be expected? What are the reasons why performance seems to be 
> impacted the such a seemingly small change?
>
> Bests,
> -Maciej
>

-- 
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: Writing correct response writer wrappers

[matthewjuran]

If you use struct embedding I think you may get what you are looking for:

type retryResponseWriter struct {
http.ResponseWriter
attemptsExhausted bool
}

Now retryResponseWriter has all of the methods of the http.ResponseWriter 
you assign to it and can be cast to those http interfaces without having to 
define stub methods or separate types.

Also since http.Handler is an interface I don’t think you need a pointer to 
it in type retry.

Matt

On Wednesday, January 17, 2018 at 2:57:22 AM UTC-6, Marco Jantke wrote:
>
> Thanks for the response Matt. Some examples to explain my use-case better. 
> First of all, it's important to know that the proxy I am working on uses 
> HTTP handler wrapper to provide additional functionality. The retry handler 
> + response writer wrapper look like the following (code examples are 
> simplified):
>
>
> type retry struct {
>   next *http.Handler
> }
>
> func (retry *Retry) ServeHTTP(rw http.ResponseWriter, r *http.Request) {
> attempts := 1
> for {
> retryResponseWriter := newRetryResponseWriter(rw, attempts >= 
> retry.attempts, ...)
>
> retry.next.ServeHTTP(retryResponseWriter, r.WithContext(newCtx))
> if !retryResponseWriter.ShouldRetry() {
> break
> }
>
> attempts++
> log.Debugf("New attempt %d for request: %v", attempts, r.URL)
> retry.listener.Retried(r, attempts)
> }
> }
>
> type retryResponseWriter struct {
> responseWriterhttp.ResponseWriter
> attemptsExhausted bool
>   ...
> }
>
> // Only responses that should not be retried
> // should be written into the original response writer.
> func (rr *retryResponseWriter) ShouldRetry() bool {
> return netErrorOccured() && !rr.attemptsExhausted
> }
>
> func (rr *retryResponseWriter) Header() http.Header {
> if rr.ShouldRetry() {
> return make(http.Header)
> }
> return rr.responseWriter.Header()
> }
>
> func (rr *retryResponseWriter) Write(buf []byte) (int, error) {
> if rr.ShouldRetry() {
> return 0, nil
> }
> return rr.responseWriter.Write(buf)
> }
>
> func (rr *retryResponseWriter) WriteHeader(code int) {
> if rr.ShouldRetry() {
> return
> }
> rr.responseWriter.WriteHeader(code)
> }
>
> func (rr *retryResponseWriter) Hijack() (net.Conn, *bufio.ReadWriter, 
> error) {
> return rr.responseWriter.(http.Hijacker).Hijack()
> }
>
> func (rr *retryResponseWriter) CloseNotify() <-chan bool {
> return rr.responseWriter.(http.CloseNotifier).CloseNotify()
> }
>
> func (rr *retryResponseWriter) Flush() {
> if flusher, ok := rr.responseWriter.(http.Flusher); ok {
> flusher.Flush()
> }
> -}
>
> My problem is now that the retryResponseWriter always implements the 
> interfaces like Flusher or Hijacker. But actually what I want is that it 
> has the same capabilities as the http.ResponseWriter I am wrapping. An 
> idiomatic usage, to my understanding, of a response writer would look like 
> the following:
>
> if hijacker, ok := responseWriter.(Hijacker); ok {
>   conn, rw, err := hijacker.Hijack()
>   if err != nil {
> // error handling, I even saw sometimes panic() used in this cases
>   }
>   // handle connections
> }
>
> So implementing the interface is definitely something different than 
> returning stub values. However, after having a closer look it looks like 
> that it's safe to implement stub methods for Flush() (as a no-op) and 
> CloseNotify() (returning a new closed channel). If that assumption is right 
> I would only have to create two different retryResponseWriter types, one 
> with Hijack and one without and do a type assertion on the 
> http.ResponseWriter to choose which one. I would favor a more generic way 
> in case someone has a better idea, though.
>
>
> On Tuesday, 16 January 2018 16:10:16 UTC+1, matthe...@gmail.com wrote:
>>
>> The type switch may not work since these http types are interfaces that 
>> may all be satisfied by the ResponseWriter. Instead of a type switch you 
>> would need to do a type assertion for each possible http interface.
>>
>> Matt
>>
>> On Tuesday, January 16, 2018 at 9:01:28 AM UTC-6, matthe...@gmail.com 
>> wrote:
>>>
>>> Can you provide some example code showing the problem?
>>>
>>> I don’t understand why you are wrapping the ResponseWriter. If you need 
>>> to pass along metadata then wrapping makes sense, but why not just pass the 
>>> original interface and do the type switch in each handler?
>>>
>>> type RetryResponseWriter struct {
>>> http.ResponseWriter
>>> Count uint
>>> …
>>> }
>>>
>>> func handler1(w http.ResponseWriter, r *http.Request) {
>>> rrw := w.(RetryResponseWriter)
>>> switch v := rrw.ResponseWriter.(type) {
>>> case http.Hijacker:
>>> …
>>> case http.Flusher:
>>> …
>>> case http.CloseNotifier:
>>> …
>>> }
>>> …
>>>
>>> Matt
>>>
>>> On Tuesday, January 16, 2018 at 7:53:40 AM UTC-6, Marco Jantke wrote:

 Hi everyone, 

 I am currently working on a retry middleware for an http proxy. It is 
 wrapping the original response writer and only in case the forwarded 
 

Re: [go-nuts] Effective Go recommends reading the language specification first

[Matt McClure]

Cool!
On Wed, Jan 17, 2018 at 08:27 Ian Lance Taylor  wrote:

> On Wed, Jan 17, 2018 at 3:30 AM, Matt McClure
>  wrote:
> >
> > Hard to say until I read both. My original message is based on my
> experience
> > with other languages and their specs.
>
> The Go spec is intended to be as readable as possible.
>
> Ian
>
>
> > On Wed, Jan 17, 2018 at 01:09 Ian Lance Taylor  wrote:
> >>
> >> On Tue, Jan 16, 2018 at 6:40 PM,   wrote:
> >> >
> >> > It strikes me as odd that Effective Go recommends reading the language
> >> > specification first.
> >> >
> >> > "This document gives tips for writing clear, idiomatic Go code. It
> >> > augments
> >> > the language specification, the Tour of Go, and How to Write Go Code,
> >> > all of
> >> > which you should read first."
> >> >
> >> > Is that really good advice for Go learners?
> >>
> >> I think so.  Do you disagree?
> >>
> >> Ian
> >
> > --
> > http://matthewlmcclure.com/
> > +1 617 329 1189
>
-- 
http://matthewlmcclure.com/
+1 617 329 1189

-- 
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] Effective Go recommends reading the language specification first

[Ian Lance Taylor]

On Wed, Jan 17, 2018 at 3:30 AM, Matt McClure
 wrote:
>
> Hard to say until I read both. My original message is based on my experience
> with other languages and their specs.

The Go spec is intended to be as readable as possible.

Ian


> On Wed, Jan 17, 2018 at 01:09 Ian Lance Taylor  wrote:
>>
>> On Tue, Jan 16, 2018 at 6:40 PM,   wrote:
>> >
>> > It strikes me as odd that Effective Go recommends reading the language
>> > specification first.
>> >
>> > "This document gives tips for writing clear, idiomatic Go code. It
>> > augments
>> > the language specification, the Tour of Go, and How to Write Go Code,
>> > all of
>> > which you should read first."
>> >
>> > Is that really good advice for Go learners?
>>
>> I think so.  Do you disagree?
>>
>> Ian
>
> --
> http://matthewlmcclure.com/
> +1 617 329 1189

-- 
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] Slice of structs element swap performance

[Maciej Biłas]

Hi,

I've ran into an interesting performance problem.

I've made a small change in the struct that I'm swapping (like in heap Swap 
function example: h[i], h[j] = h[j], h[i]), namely I've removed a reference 
to a interface object. After this change the swap operation speed increased 
by 10x (at least according to Xcode, which I used to instrument the 
benchmark):

Below is the instrumentation report. The function in question is 
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Swap

With struct containing an interface:

12242   12242.0ms9.2%   450.0  
github.com/RoaringBitmap/roaring.ParOr
11729   11729.0ms8.8%   2476.0  
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).PopNextContainers
85268526.0ms6.4%657.0
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).PopIncrementing
77827782.0ms5.8%3239.0container/heap.Fix
45434543.0ms3.4%2658.0 container/heap.down
18851885.0ms1.4%1127.0  
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Swap
758 758.0ms0.5% 166.0runtime.typedmemmove
592 592.0ms0.4% 295.0 
runtime.bulkBarrierPreWrite
79  79.0ms0.0%  13.0  runtime.typedmemmove
66  66.0ms0.0%  36.0   runtime.bulkBarrierPreWrite


without:

62496249.0ms8.2%181.0  
github.com/RoaringBitmap/roaring.ParOr
59435943.0ms7.8%1473.0  
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Next
44504450.0ms5.8%146.0
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).popIncrementing
43004300.0ms5.6%2129.0container/heap.Fix
21712171.0ms2.8%2021.0 container/heap.down
150 150.0ms0.1% 4.0 
github.com/RoaringBitmap/roaring.(*bitmapContainerHeap).Swap
146 146.0ms0.1% 41.0 runtime.writebarrierptr

The second column is the total time of a function, the 3rd is the 
percentage of time spent in that function relative to the total execution 
time.

The code commit can be found here: 
https://github.com/RoaringBitmap/roaring/pull/133/commits/970e4f698d69e14a79c685c986b0062d8aec1877,
 
here is a link to the pull request containing the commit 
https://github.com/RoaringBitmap/roaring/pull/133 (if your curious)

I'm using Go 1.9.2, MacOS 10.13.2 on an i7 quad-core Intel Haswell 
processor.

I hope the benchmarks are correct. Please correct me if I got something 
wrong.

Is that to be expected? What are the reasons why performance seems to be 
impacted the such a seemingly small change?

Bests,
-Maciej

-- 
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] Effective Go recommends reading the language specification first

[Matt McClure]

Hard to say until I read both. My original message is based on my
experience with other languages and their specs.
On Wed, Jan 17, 2018 at 01:09 Ian Lance Taylor  wrote:

> On Tue, Jan 16, 2018 at 6:40 PM,   wrote:
> >
> > It strikes me as odd that Effective Go recommends reading the language
> > specification first.
> >
> > "This document gives tips for writing clear, idiomatic Go code. It
> augments
> > the language specification, the Tour of Go, and How to Write Go Code,
> all of
> > which you should read first."
> >
> > Is that really good advice for Go learners?
>
> I think so.  Do you disagree?
>
> Ian
>
-- 
http://matthewlmcclure.com/
+1 617 329 1189

-- 
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: Writing correct response writer wrappers

[Marco Jantke]

Thanks for the response Matt. Some examples to explain my use-case better. 
First of all, it's important to know that the proxy I am working on uses 
HTTP handler wrapper to provide additional functionality. The retry handler 
+ response writer wrapper look like the following (code examples are 
simplified):


type retry struct {
  next *http.Handler
}

func (retry *Retry) ServeHTTP(rw http.ResponseWriter, r *http.Request) {
attempts := 1
for {
retryResponseWriter := newRetryResponseWriter(rw, attempts >= 
retry.attempts, ...)

retry.next.ServeHTTP(retryResponseWriter, r.WithContext(newCtx))
if !retryResponseWriter.ShouldRetry() {
break
}

attempts++
log.Debugf("New attempt %d for request: %v", attempts, r.URL)
retry.listener.Retried(r, attempts)
}
}

type retryResponseWriter struct {
responseWriterhttp.ResponseWriter
attemptsExhausted bool
  ...
}

// Only responses that should not be retried
// should be written into the original response writer.
func (rr *retryResponseWriter) ShouldRetry() bool {
return netErrorOccured() && !rr.attemptsExhausted
}

func (rr *retryResponseWriter) Header() http.Header {
if rr.ShouldRetry() {
return make(http.Header)
}
return rr.responseWriter.Header()
}

func (rr *retryResponseWriter) Write(buf []byte) (int, error) {
if rr.ShouldRetry() {
return 0, nil
}
return rr.responseWriter.Write(buf)
}

func (rr *retryResponseWriter) WriteHeader(code int) {
if rr.ShouldRetry() {
return
}
rr.responseWriter.WriteHeader(code)
}

func (rr *retryResponseWriter) Hijack() (net.Conn, *bufio.ReadWriter, 
error) {
return rr.responseWriter.(http.Hijacker).Hijack()
}

func (rr *retryResponseWriter) CloseNotify() <-chan bool {
return rr.responseWriter.(http.CloseNotifier).CloseNotify()
}

func (rr *retryResponseWriter) Flush() {
if flusher, ok := rr.responseWriter.(http.Flusher); ok {
flusher.Flush()
}
-}

My problem is now that the retryResponseWriter always implements the 
interfaces like Flusher or Hijacker. But actually what I want is that it 
has the same capabilities as the http.ResponseWriter I am wrapping. An 
idiomatic usage, to my understanding, of a response writer would look like 
the following:

if hijacker, ok := responseWriter.(Hijacker); ok {
  conn, rw, err := hijacker.Hijack()
  if err != nil {
// error handling, I even saw sometimes panic() used in this cases
  }
  // handle connections
}

So implementing the interface is definitely something different than 
returning stub values. However, after having a closer look it looks like 
that it's safe to implement stub methods for Flush() (as a no-op) and 
CloseNotify() (returning a new closed channel). If that assumption is right 
I would only have to create two different retryResponseWriter types, one 
with Hijack and one without and do a type assertion on the 
http.ResponseWriter to choose which one. I would favor a more generic way 
in case someone has a better idea, though.


On Tuesday, 16 January 2018 16:10:16 UTC+1, matthe...@gmail.com wrote:
>
> The type switch may not work since these http types are interfaces that 
> may all be satisfied by the ResponseWriter. Instead of a type switch you 
> would need to do a type assertion for each possible http interface.
>
> Matt
>
> On Tuesday, January 16, 2018 at 9:01:28 AM UTC-6, matthe...@gmail.com 
> wrote:
>>
>> Can you provide some example code showing the problem?
>>
>> I don’t understand why you are wrapping the ResponseWriter. If you need 
>> to pass along metadata then wrapping makes sense, but why not just pass the 
>> original interface and do the type switch in each handler?
>>
>> type RetryResponseWriter struct {
>> http.ResponseWriter
>> Count uint
>> …
>> }
>>
>> func handler1(w http.ResponseWriter, r *http.Request) {
>> rrw := w.(RetryResponseWriter)
>> switch v := rrw.ResponseWriter.(type) {
>> case http.Hijacker:
>> …
>> case http.Flusher:
>> …
>> case http.CloseNotifier:
>> …
>> }
>> …
>>
>> Matt
>>
>> On Tuesday, January 16, 2018 at 7:53:40 AM UTC-6, Marco Jantke wrote:
>>>
>>> Hi everyone, 
>>>
>>> I am currently working on a retry middleware for an http proxy. It is 
>>> wrapping the original response writer and only in case the forwarded 
>>> request should not be retried, it passes calls to `Write()`, 
>>> `WriteHeader()` etc directly through to the original response writer. Now I 
>>> am struggling with the fact, that response writers have different 
>>> capabilities dependent on their type. Namely they can be `Hijacker`, 
>>> `Flusher` or `CloseNotifier`. The problem is that my wrapper should have 
>>> the same capabilities as the wrapped one, but I don't see any other way 
>>> than creating all different types and using the proper one after doing type 
>>> assertions on the response writer I am wrapping. Those types would be for 
>>> example: `ResponseWriterWrapper`, `ResponseWriterWrapperWithFlush`, 
>>> `ResponseWriterWrapperWithHijack`, 
>>>