newConnUpgrader - не экспортируется

ну из внешнего пакета, который импортирует это код

нэт)

так поменяйте

сделайте его экспортируемым

так поменяйте

тогда добавится внешняя зависимость на gorilla/websocket

c чего вы взяли?

можно конечно оставить и копию, ибо там критичного кода нет и меняться он не будет

тогда оставить

тогда оставить

я что-то путаю или если сделать публичным newConnUpgrader в коде https://github.com/qbeon/webwire-go/blob/master/socketImpl.go, то для внешних пакетов - "github.com/gorilla/websocket" не будет требовать импорта

c чего бы это он требовал

тогда оставить

ну вот и я так думаю

не будет, конечно

он используется только внутри

c чего вы взяли?

func newSocket(conn *websocket.Conn) *socket

вообще, есть такой фокус, с функцией, которая возвращает неэкспортируемый тип

тогда за пределами пакета его нельзя получить иначе, чем через эту функцию

func newSocket(conn *websocket.Conn) *socket

вообще то она вызывается только из newConnUpgrader

но и параметром нельзя передать никуда

насколько я понимаю

тогда добавится внешняя зависимость на gorilla/websocket

вы их руками, что ли, менеджите?

вы их руками, что ли, менеджите?

честно говоря я ещё не работал с godep, просто не было времени изучить, поэтому пока ещё не понятно что делать с этим issue: https://github.com/qbeon/webwire-go/issues/2

я надеялся на то, что если gorilla/websocket будет в vendor'е внутри webwire-go тогда ничего вообще делать не нужно и webwire будет работать в любой среде свыше Go 1.5 без каких либо зависимостей

но возможно это не так, я ещё не знаю

я сейчас про goimport

я-ж правильно понимаю что вложенный vendor ни одна система зависимотей включая godep не трогает?

она как раз на нем и живет

ну и если вы передаете в функцию вебсокет - его придется сделать, а для этого придется пакет импортнуть палюбэ

я-ж правильно понимаю что вложенный vendor ни одна система зависимотей включая godep не трогает?

dep объединяет все вложенные вендоры в один

я-ж правильно понимаю что вложенный vendor ни одна система зависимотей включая godep не трогает?

если вам жизненно необходимо юзать newSocket то сделайте над ним обертку

которая бы в этом же пакете создавал соедиенние

тогда не придется ничего тянуть

ну и если вы передаете в функцию вебсокет - его придется сделать, а для этого придется пакет импортнуть палюбэ

вот именно, а на данный момент этого делать не нужно, ибо API webwire не экспортирует зависимость gorilla/websocket, она хранить её в недрах библиотеки и как хард-копию в vendor'е

dep объединяет все вложенные вендоры в один

короче нет никакой неприкосновенности вложенных vendor'ов?

нет, конечно

вот именно, а на данный момент этого делать не нужно, ибо API webwire не экспортирует зависимость gorilla/websocket, она хранить её в недрах библиотеки и как хард-копию в vendor'е

ну так экспортируйте то, что не использует websocket напрямую

понял, значит я в этом кардинально ошибался, я думал если в проекте есть сложенный vendor то его никто трогать не будет из вне

вообще то она вызывается только из newConnUpgrader

нет, она ещё используется в клиенте https://github.com/qbeon/webwire-go/blob/master/client/client.go#L116

c аргументом nil? ?

тогда вам не нужно экспортировать тот пакет

c аргументом nil? ?

нил, не нил, экспортировать придётся: func NewSocket(conn *"github.com/gorilla/websocket".Conn) *socket

не придется

не придется

нил, не нил, экспортировать придётся: func NewSocket(conn *"github.com/gorilla/websocket".Conn) *socket

не важно какая сигнатура, важно что вы передаете со стороны пакета

если вы передаете nil это стандартный тип

если он допустим то все ок

хмм

понял

У меня есть функция rand.Intn(10)) при выполнении программы выдает одно и тоже число. Мне нужен генератор случайных rand.Seed. Как правильно написать функцию помогите

всем привет. учу Go. прохожу A Tour of Go. вот такой код func Crawl(url string, depth int, fetcher Fetcher, cache *Cache, ch chan string) { // TODO: Fetch URLs in parallel. // TODO: Don't fetch the same URL twice. // This implementation doesn't do either: defer close(ch) if depth <= 0 { return } cache.mux.Lock() if cache.visited[url] { cache.mux.Unlock() return } cache.visited[url] = true cache.mux.Unlock() body, urls, err := fetcher.Fetch(url) if err != nil { ch <- err.Error() return } ch <- fmt.Sprintf("found: %s %q\n", url, body) result := make([]chan string, len(urls)) for i, u := range urls { go func(u string) { result[i] = make(chan string) Crawl(u, depth-1, fetcher, cache, result[i]) }(u) } for i := range result { for res := range result[i] { ch <- res } } return } func main() { cache := &Cache{visited: make(map[string]bool)} ch := make(chan string) Crawl("https://golang.org/", 4, fetcher, cache, ch) for res := range ch { fmt.Println(res) } }

выполняется с ошибкой "fatal error: all goroutines are asleep - deadlock!"

никак не могу понять причину. может, кто посмотреть?

оформите его в play

хмм

так что выносите все в отдельный пакет

всем привет. учу Go. прохожу A Tour of Go. вот такой код func Crawl(url string, depth int, fetcher Fetcher, cache *Cache, ch chan string) { // TODO: Fetch URLs in parallel. // TODO: Don't fetch the same URL twice. // This implementation doesn't do either: defer close(ch) if depth <= 0 { return } cache.mux.Lock() if cache.visited[url] { cache.mux.Unlock() return } cache.visited[url] = true cache.mux.Unlock() body, urls, err := fetcher.Fetch(url) if err != nil { ch <- err.Error() return } ch <- fmt.Sprintf("found: %s %q\n", url, body) result := make([]chan string, len(urls)) for i, u := range urls { go func(u string) { result[i] = make(chan string) Crawl(u, depth-1, fetcher, cache, result[i]) }(u) } for i := range result { for res := range result[i] { ch <- res } } return } func main() { cache := &Cache{visited: make(map[string]bool)} ch := make(chan string) Crawl("https://golang.org/", 4, fetcher, cache, ch) for res := range ch { fmt.Println(res) } }

вам нужно использовать waitgroup

если вы просто позапускаете гоурутины из main без ожидания

то основной процесс схлопнется до того как они успеют отработать

это и есть "all goroutines are asleep - deadlock!"

оформите его в play

https://play.golang.org/p/6eFIzNnAYwK

https://play.golang.org/p/6eFIzNnAYwK

func main() { go test() go test() }

попробуйте такой просто код

тест может быть любым

получите такую же ошибку

то основной процесс схлопнется до того как они успеют отработать

range по channel не ждет действий?

ждет

только чего вы ждете то?

только чего вы ждете то?

завершения вот этого участка, потом defer close(ch) for i := range result { for res := range result[i] { ch <- res } }

стоит переосмыслить подход

ERROR: S client not available

result[i] = make(chan string) Crawl(u, depth-1, fetcher, cache, result[i])

вот это зачем?

вы же можете один раз создать ch в main и кормить его до посинения

я не знаю, в какой момент его закрыть, если делать 1 канал

fixed не тот кусок скопировал

а зачем вам его закрывать?

что бы приложение завершилось?

да, в данном случае. чтобы завершить range

вам нужно обработку канала вынести в отдельную гоурутину тоже

и сделать waitgroup

прочитайте про это

тогда не надо будет переживать по поводу закрылся ли канал

т.е. в отдельной горутине объявить переменную, которая будет обеспечивать waitgroup?

waitgroup нужен там, где нет канала

если у нас уже есть канал - его надо просто закрыть в тот момент, когда вам поажется, что пора валить

звучит прозрачно

а вот когда этот момент наступит, и как его дождаться, не завершив main - это вопрос к вам уже

хорошо. много каналов - плохо?

вы сами себя запутали с этими каналами

каналов нужно ровно столько, сколько вам нужно

я открываю канал на каждый рекурсивный вызов, внутри которого я точно знаю, когда закрыть его. потом все сливаю в 1 канал и уже его жду в мэйне

мне кажется, нормальный подход

а?!

для начала - рекурсия это плохо

Daniel передаю пациента вам ?

я простой парень

я сначала попрошу кода в play

я сначала попрошу кода в play

https://play.golang.org/p/6eFIzNnAYwK

Daniel передаю пациента вам ?

спасибо, Александр ?

Daniel передаю пациента вам ?

а как ты это сделал?

https://play.golang.org/p/6eFIzNnAYwK

как ни странно - тут поможет именно waitgroup. перед стартом горутины надо делать Add(1)