а файлы в разных директориях но с "одинаковым" пакетом будут иметь пакетную область видимости?

нет. а тимлид даст пизды за это на ревью

за одинаковые пакеты?

а есть у кого малюсенький проектик открытый, чтобы посмотреть на "кошерную" структуру?

за одинаковые пакеты в разных директориях (одного уровня)

а есть у кого малюсенький проектик открытый, чтобы посмотреть на "кошерную" структуру?

+

так если они не одного уровня?

не одного - ок

ну а область видимости у них же будет пакетная, не?

нет

область видимости - одна директория

а, ок

еще раз

спасибо, что разъяснил

пакет существует только в контексте полного пути

окей

просто после жавы когнитивно диссонирую, когда вижу в файле пакет одним словом

без точек, полного пути

тогда вообще не понятно, зачем в файле указывается пакет

Видимо, для совместимости

просто после жавы когнитивно диссонирую, когда вижу в файле пакет одним словом

так импортятся только стандартные. те, что в GOROOT лежат

Видимо, для совместимости

совместимости с чем?

Так. А вот в runtime StackHeap и HeapInuse достаточно, чтобы в перспективе понять, что внутри не течет?

совместимости с чем?

С ранними версиями go

так импортятся только стандартные. те, что в GOROOT лежат

а, я понял

Так в итоге можно пакет держать в подкаталоге проекта или это моветон и все должно лежать в src/ ?

за одинаковые пакеты в разных директориях (одного уровня)

так если они не одного уровня?

не одного - ок

по сути, на пакеты можно забить и считать пакетом полный путь к go файлу?

> Писать import "../A" всегда импортить по полному пути import "myServer.loc/myAccountOnServer/MyProject/myPackage" tckb так не видно - больше ничем помочь не могу, тут шрифт по -больше не сделаешь

А если myPackage лежит в директории MyProject/src/dir1/dir2/myPackage, тогда надо писать: import "myServer.loc/myAccountOnServer/MyProject/dir1/dir2/myPackage" ?

а есть у кого малюсенький проектик открытый, чтобы посмотреть на "кошерную" структуру?

кто нибудь, покажите готовый проект если есть в паблике, ну очень хочется увидеть как правильно строить архитектуру приложения.

кто нибудь, покажите готовый проект если есть в паблике, ну очень хочется увидеть как правильно строить архитектуру приложения.

https://golang.org/doc/code.html

А, уже кидали, сори

https://golang.org/doc/code.html

да этож смешно

Доброго времени суток ))

а блин, всё, до меня дошло :) Т.е. надо указывать полный путь к пакету, относительно каталога src, а не писать путь до каталога "../../myPackage". Всем спасибо.

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

Мы друг друга не поняли. Проблем в той репе в том, что у него пакет называется просто "domain", а надо было назвать "cleanarchitecture/domain" и положить в каталог "src/cleanarchitecture/domain", и обращаться по полному имени пакета import "cleanarchitecture/domain". А когда вы сказали что писать имя пакета это плохо - я зачем то подумал что надо писать путь до каталога, т.е. import "../domain" - и вот это меня смущало.

> import "cleanarchitecture/domain" так можно импортить только стандартные пакеты. те, что в GOROOT все остальные - только по полному пути. больше повторять не буду

я тогда не понимаю, а что есть полный путь?

/Users/userName/projects/go-cleanarchitecture/src/cleanarchitecture/domain ?

Вот структура проекта: ./go-cleanarchitecture/ --main.go --/src/ ----/cleanarchitecture ------/domain/ --------domain.go ------/usecase/ --------usecase.go Как в файле usecase.go правильно обратится к методам из domain.go?

> import "cleanarchitecture/domain" так можно импортить только стандартные пакеты. те, что в GOROOT все остальные - только по полному пути. больше повторять не буду

export GOPATH=$GOPATH:/path/to/project/packages И свои пакеты складывать по этому пути...

"github.com/Djarvur/parsewords" - вот так выглядить полный путь

export GOPATH=$GOPATH:/path/to/project/packages И свои пакеты складывать по этому пути...

а что сделает go get?

Вот структура проекта: ./go-cleanarchitecture/ --main.go --/src/ ----/cleanarchitecture ------/domain/ --------domain.go ------/usecase/ --------usecase.go Как в файле usecase.go правильно обратится к методам из domain.go?

import "cleanarchitecture/domain" func test() { domain.Hello }

import "cleanarchitecture/domain" func test() { domain.Hello }

коллеги, вы читать умеете?

а что сделает go get?

Да, если забирать с удаленного репо

"github.com/Djarvur/parsewords" - вот так выглядить полный путь

Т.е. проблема в том, что файло проекта должно лежать не в src/cleanarchitecture/, а в src/github/username/cleanarchitecture/ ?

Но, полный паз указывать в импорте эт верно

Т.е. проблема в том, что файло проекта должно лежать не в src/cleanarchitecture/, а в src/github/username/cleanarchitecture/ ?

два

да

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

а ты обязан

да

Note that you don't need to publish your code to a remote repository before you can build it. It's just a good habit to organize your code as if you will publish it someday. In practice you can choose any arbitrary path name, as long as it is unique to the standard library and greater Go ecosystem.

так там же в настройках есть

project path

Пакет это краткое обозначение набора файлов в папке

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

тогда делай что хочешь, но сам и тихо :)

тогда делай что хочешь, но сам и тихо :)

ясно понятно)) теперь все стало чуть более понятнее. Всем спасибо

ERROR: S client not available

Вот структура проекта: ./go-cleanarchitecture/ --main.go --/src/ ----/cleanarchitecture ------/domain/ --------domain.go ------/usecase/ --------usecase.go Как в файле usecase.go правильно обратится к методам из domain.go?

Вроде только main.go должен быть в src/cleanarchitecture/

В одном из чатиков рубист не смог пройти /test_IQ три раза подряд

This never gets old

В одном из чатиков рубист не смог пройти /test_IQ три раза подряд

Что это за команда?

Что это за команда?

Тест

Чего?

IQ

Только не это

Тест на знание телеграма, скорее

Всех приветствую! Подскажите новичку. Есть необходимость что-то делать с xml, но на вход приходит либо в utf-8 либо в windows-1251 причем без объявления. Столкнулся с Ридерами и Райтерами. Погуглив про повторные чтения из ридера, написал вот такую функцию. Подскажите, может есть вариант решения без чтения в буффер? и что по коду посоветуете? func foo(data io.Reader, result io.Writer) error { var buf bytes.Buffer body := io.TeeReader(data, &buf) decoder := xml.NewDecoder(body) var resBuf bytes.Buffer resWriter := bufio.NewWriter(&resBuf) err := bar(decoder, resWriter) if err != nil { if strings.Contains(err.Error(), "invalid UTF-8") { decoder2 := xml.NewDecoder(charmap.Windows1251.NewDecoder().Reader(&buf)) return bar(decoder2, result) } return err } resWriter.Flush() resReader := bufio.NewReader(&resbuf) _, err = io.Copy(result, resReader) if err != nil { return err } return nil }

Всех приветствую! Подскажите новичку. Есть необходимость что-то делать с xml, но на вход приходит либо в utf-8 либо в windows-1251 причем без объявления. Столкнулся с Ридерами и Райтерами. Погуглив про повторные чтения из ридера, написал вот такую функцию. Подскажите, может есть вариант решения без чтения в буффер? и что по коду посоветуете? func foo(data io.Reader, result io.Writer) error { var buf bytes.Buffer body := io.TeeReader(data, &buf) decoder := xml.NewDecoder(body) var resBuf bytes.Buffer resWriter := bufio.NewWriter(&resBuf) err := bar(decoder, resWriter) if err != nil { if strings.Contains(err.Error(), "invalid UTF-8") { decoder2 := xml.NewDecoder(charmap.Windows1251.NewDecoder().Reader(&buf)) return bar(decoder2, result) } return err } resWriter.Flush() resReader := bufio.NewReader(&resbuf) _, err = io.Copy(result, resReader) if err != nil { return err } return nil }

может быть любой charset detector заюзать?

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

Прямо только на локальном компе хранишь? Без внешнего репозитория? А ты рисковый.

Прямо только на локальном компе хранишь? Без внешнего репозитория? А ты рисковый.

я этого не говорил)

я этого не говорил)

Ну тогда проще всего путь к нему указать, и будет всё ок.

Ну тогда проще всего путь к нему указать, и будет всё ок.

Это я уже понял, да. Изначально вопрос был не про то, мне дали ответ не на тот вопрос который я задал, и в итоге я запутался. Сейчас вроде все понял.

может быть любой charset detector заюзать?

например?

Вот структура проекта: ./go-cleanarchitecture/ --main.go --/src/ ----/cleanarchitecture ------/domain/ --------domain.go ------/usecase/ --------usecase.go Как в файле usecase.go правильно обратится к методам из domain.go?

/src/ излишний. Его в структуре проектов go опускают, так как в стандартном дереве src есть уровнем выше вашего пакета

например?

любой, в гугле гуглящийся

гугель ничего стОящего не показывает в этой области

гугель ничего стОящего не показывает в этой области

https://github.com/saintfish/chardet

такое например

это я видел, смущает что 5 лет не обновлялось. не в депрекейшене ли оно?

это я видел, смущает что 5 лет не обновлялось. не в депрекейшене ли оно?

ну оно простое. развивать некуда

товарищи, а можете немного по управлению памятью в го просветить? Вот, скажем, я шлю в канал из метода указатель на байтовый буфер, затем буфер этот чищу и функция завершается. Это же race condition получается, верно?

между сборщиком мусора и читалкой из канала

если же я шлю по значению, а не указатель, то все должно быть окей

Всем привет, два дня назад пришел в мир Go. Поделитесь, пожалуйста, ссылками на гайды как правильно структурировать веб приложение? Поискал по сети - информации очень мало и каждый источник делает все по-своему.

в доках искал?

Всем привет, два дня назад пришел в мир Go. Поделитесь, пожалуйста, ссылками на гайды как правильно структурировать веб приложение? Поискал по сети - информации очень мало и каждый источник делает все по-своему.

да у всех этот вопрос ?

Всем привет, два дня назад пришел в мир Go. Поделитесь, пожалуйста, ссылками на гайды как правильно структурировать веб приложение? Поискал по сети - информации очень мало и каждый источник делает все по-своему.

В доках есть структуры, в примерах фреймворков