Pull to refresh

Comments 13

Можно вопрос не по теме топика, но по теме Go.

Вопрос по организации кода.
У меня на машине такая структура:
Projects
---ASP.NET
   ---Proj1
   ---Proj2
---PHP
   ---Proj1
   ---Proj2
---GO
   --- ???

Как должна быть организована структуру кода на Go? Я читал официальную и не официальную документацию.
В Go Есть понятие Workspaces. Которые содержат в себе следующую структуру
— src
— pkg
— bin
Что это такое? Каждый Workspace это отдельный проект на Go и в каждом проекте должна быть структура как выше? Для каждого проекта на Go путь до него обязательно добавлять в $PATH?

Такая банальная вещь, но в доках и других туториалах на этот вопрос нет очевидного ответа.
Буду признателен за ответ.
Ну как же нет? golang.org/doc/code.html#Workspaces

В 90% случаев вы один раз в жизни устанавливаете свой рабочий workspace — GOPATH=C:\Projects\GO (в вашем примере) и работаете в этой директории. К примеру, ваши проекты могут быть в:
C:\Projects\GO\src\test\mytestprj\
C:\Projects\GO\src\github.com\paco\mycoolprj\

Можно писать код и вне GOPATH, но все сторонние пакеты которые вы будете использовать (и ставить через go get) — будут сохраняться именно в GOPATH\src и оттуда браться компилятором.

В src хранятся исходные коды. В pkg — скомпилированные бинарные версии пакетов, которые предназначены для линковки (библиотеки, другими словами). В bin — скомпилированные файлы для исполнения (бинарники). $GOPATH/bin удобно добавить в PATH, потому как тогда легко инсталлировать внешние Go-программы (ту же go-bindata) одним телодвижением — go install — и оно готово к использованию в вашей системе.
Благодарю за ответ. Разбитие namespace по папкам внутри src конечно не привычно.
Непривычно?

Это же классический java-style, а в PHP подобное поведение описывается в PSR4, не знаю правда что там с ASP.NET, но больее чем уверен что такая организация кода вполне возможна, и всякие гуру-папки активно ее используют, потому что не надо лишних слов — просто заставь имена пакетов и папок на диске кореллировать между собой.
Но тут возникает следующий момент — раз кросс-компиляция и деплой становятся такими простыми и быстрыми, появляется стимул все зависимости от файлов — будь-то конфиги, сертификаты или что угодно еще — встраивать в бинарник тоже

+100500
У Меня тоже возник такой соблазн
Более того я это соблазну подался!!! И веб-морду (index.html) воткнул в виде зашифрованной в base64 строки
const indexPageD = "PCFkb2N0eXBlIGh0bWw+DQo8aHRtbD4NCg0KPGhlYWQ+DQoJPHRpdGxlPldlYlRvcDwvdGl0bGU+DQoJP
......
func (service *TopJsonService) ServePage(responseWriter http.ResponseWriter, request *http.Request) {
	responseWriter.Header().Set("Content-Type: text/html", "*")
	content, err := ioutil.ReadFile("index.html")
	if err != nil {
		val, _ := base64.StdEncoding.DecodeString(indexPageD)
		responseWriter.Write(val)
		return
	}
	responseWriter.Write(content)
}

github.com/Loafter/WebTop/blob/master/WebService.go

Вообще очень полезные вы статии пишите.

Кстати я не понимаю как еще полностью статически слинокованный дистрибутив линукс еще не вышел
Если вам нравится всё встраивать в бинарник, посмотрите проект go.rice, очень удобная штука :)
Можно целые папки автоматически встраивать, а во время разработки — читать из файла.
JFYI ещё одна либа для встраивания всякой внешней статики в бинарник github.com/rakyll/statik
Больше либ хороших и разных.
Спасибо)

Ну, в base64 засовывать — это не очень продуктивно в общем случае. Лучше таки или go-bindata (+go-bindata-assetfs) или go-rice использовать.Тем более, что c go generate их еще удобнее стало использовать.
UFO landed and left these words here
Может кто сможет заставить работать influxdb под windows? Смог скомпилировать, даже запускается, но не делает того что надо.
github.com/influxdb/influxdb/blob/master/docs/contributing.md
Тоже написано на Go. Но почему-то их команда упорно игнорирует windows.
InfluxDB — отличная вещь. А в чем там проблема? Не вижу открытых issue по теме windows…
Про GO386 забыли
Иначе вроде i386 а на athlon xp без sse2 не запустится!
В нете очень много i386 или x86 скомпилированных под >=sse2 и *i386*.deb в том числе.

$GO386 (for 386 only, default is auto-detected if built on either 386 or amd64, 387 otherwise)
This controls the code generated by gc to use either the 387 floating-point unit (set to 387) or SSE2 instructions (set to sse2) for floating point computations.

GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).
GO386=sse2: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.
SSE2 Не поддерживают:
Поскольку SSE2 — расширение IA-32, процессоры, не поддерживающие IA-32, не поддерживают SSE2. Все известные процессоры x86-64 также поддерживают SSE2.

Кроме того, не поддерживают IA-32-совместимые процессоры, появившиеся до SSE2:

Все AMD до Athlon 64
Все Intel до Pentium 4
VIA C3
Transmeta Crusoe

PS т.е. i386 точно работает на x86-64.
Sign up to leave a comment.

Articles