An online book focusing on Go syntax/semantics and runtime related things

https://github.com/go101/go101/blob/a08fc0c3c37a4a8b326fdfcdf83f8552950d68f4/articles/channel.html#L1097

solutuon

I'll collect typos here and submit them in a single commit.

Inspired by your article https://go101.org/article/channel-closing.html , I wrote this one https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2

I wanted to let you know

Hi @TapirLiu - as I like Your content, I started reading it in my editor, and could not resist to adjust some wordings in order to allow more lucid reading. If You like it, I may be motivated to do more like this.

@bcmills's opinion is right in this thread.

func String2ByteSlice(str string) (bs []byte) {
	strHdr := (*reflect.StringHeader)(unsafe.Pointer(&str))
	sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer(&bs))
	sliceHdr.Data = strHdr.Data
	sliceHdr.Cap = strHdr.Len
	sliceHdr.Len = strHdr.Len
	// This KeepAlive line is essential to make the
	// String2ByteSlice function be always valid
	// when it is used in other custom packages.
	runtime.KeepAlive(&str)
	return
}

Bryan C. Mills said The GC tracks pointers through their original allocations — the pointer scan does not care about lexical types, only allocation types.

@tliron, as that old thread is frozen, so I created this thread to let you get acknowledged.

hi, go101 is very helpful for me. 👍

but when reading panic-and-recover of go101, i found someting wrong in the last example :

// This program exits without panic 1 being recovered.
package main

func demo() {
	defer func() {
		defer func() {
			recover() // this one recovers panic 2
		}()

		defer recover() // no-op

		panic(2)
	}()
	panic(1)
}

func main() {
	demo()
}

it says

In fact, the current Go specification also doesn't explain well why the second recover call, which is expected to recover panic 1, in the following example doesn't take effect.

and

What Go specification doesn't mention is that, at any given time, only the newest unrecovered panic in a goroutine is recoverable. In other words, each recover call is viewed as an attempt to recover the newest unrecovered panic in the currrent goroutine. This is why the second recover call in the above example is a no-op.

i do not think so. the current verson of Go specification says :

The return value of recover is nil if any of the following conditions holds:

1. panic's argument was nil;
2. the goroutine is not panicking;
3. recover was not called directly by a deferred function.

the third condition that is the reason why the second recover call, which is expected to recover panic 1, in the following example doesn't take effect.

then i found something interesting:

example 1 ：

// This program exits without panic 1 being recovered.
package main

func demo() {
	defer func() {
		defer func() {
			recover() // this one recovers panic 2
		}()

		defer recover() // no-op

		panic(2)
	}()
	panic(1)
}

func main() {
	demo()
}

example 2 ：

// This program exits with no panic.
package main

func demo() {
	defer func() {
		defer func() {
			recover() // this one recovers panic 2
		}()

		defer fmt.Println(recover()) // this one recover panic 1

		panic(2)
	}()
	panic(1)
}

func main() {
	demo()
}

example 3 ：

// This program exits without panic 1 being recovered.
package main

func demo() {
	defer func() {
		defer func() {
			recover() // this one recovers panic 2
		}()

		defer func() {
			fmt.Println(recover()) //no-ops
		}()

		panic(2)
	}()
	panic(1)
}

func main() {
	demo()
}

now i know the reason why example 1 exit whit panic , but i don't know why example 2 and example 3 play different.

https://www.gitbook.com/ or something along those lines (such as a static site generator like hugo) so that content can be mostly separated from the HTML

Hello,

This is to avoid the first notification is missed when it is sent before the moderator goroutine gets ready to receive notification from toStop.

When reading this path, I misunderstood the meaning, I thought that Go will ignore the message if the channel is not ready. So I made this explanation. I hope it will have a clearer meaning.

Regards, Huy Dang

I think you meant the receive happens before the following send. It doesn't make sense otherwise. (Also, it violates rule 1). TBH, the second assumption can be removed as it's not really an assumption since it can be derived from the first one.

Maybe you can summarize them together to something along those lines: A send on a channel happens before the corresponding receive from that channel completes. If the channel is buffered with a capacity of m, then the n-th receive where n<m has to complete before the n+m send.

go run main.go .\main.go:29:8: undefined: openBrowser .\main.go:34:5: undefined: go101

go run *.go CreateFile *.go: The filename, directory name, or volume label syntax is incorrect.

go version go1.12.4 windows/amd64

what might be the problem?

Ever since the release of the go2go tool which allows for the usage of generics in Golang, you haven't included it in your great and awesome book "Go101". I think I speak for some when I say that you should add a few topics in your book that include Golang generics usage, installation.

For many people it will be easier to read, especially in a low light environment.

You can read this property of useragent https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

https://go101.org/article/packages-and-imports.html states:

Similar to package dependencies, a module might also depend on some other modules.

However, the term "module" has not yet been defined on this page or, AFAICT, on any page in the ordered sequence leading up to this page. It would be easier for the reader if some definition (or a link to a subsequent definition) was provided first.

3.9 Use value cache pool to avoid some allocations

You write:

Personally, I find the design of sync.Pool seldom satisfies the needs in practice. So I often use custom value cache pool implementations in my Go projects.

Could you give some examples of your custom value cache pool?

Hey! Thanks for writing such an awesome book but I had noticed that you have used print and println for printing to stdout. These function use should be discouraged as its for bootstrapping and it can be removed whenever Go Team wants to.

I prefer we should switch to fmt.Println() and fmt.Print().

EDIT: I saw the opening pages which has a note about it but this should be scrapped and can be given in Some Special Topic.