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

Я пытался указать в флаге компилятора gccgo а мне в ответ "Нет такого компилятора"

я взял да и установил как обычно ?

У меня можно какой-то один указать или Any... ну хз, провентилирую вопрос.

Как я понял GSSGO написан на С++, а GC с версии 1.5 на го, а раньше вроде на Си. Нужно запробовать, и посмотреть какая разница.

я взял да и установил как обычно ?

Я разницы не заметил, у мну проект может махонький, а так вот что нарыл https://habrahabr.ru/company/intel/blog/348230/

я взял да и установил как обычно ?

Вот интересные способы по уменьшению бинарника, ща запробую ещё и упаковать. http://qaru.site/questions/98570/how-to-reduce-compiled-file-size

Я пытался указать в флаге компилятора gccgo а мне в ответ "Нет такого компилятора"

Во, ужал, почти с 7 MB до 2 с половиной File size Ratio Format Name -------------------- ------ ----------- ----------- 6889376 -> 2588452 37.57% linux/ElfAMD app

Я разницы не заметил, у мну проект может махонький, а так вот что нарыл https://habrahabr.ru/company/intel/blog/348230/

Да я тоже эт читал

Щас вот ковыряю как мне в мэйкфайл goupx прописать, шоб автоматом паковалось...

Во, ужал, почти с 7 MB до 2 с половиной File size Ratio Format Name -------------------- ------ ----------- ----------- 6889376 -> 2588452 37.57% linux/ElfAMD app

ну это же для линуха

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

Дык венда отстой, на ней только в игрушки играть...

один гуи только да бесит

Товарищи, дозвольте вопрос, как правильно располагать файлы тестов? В тех же каталогах, что и основной код?

да

благодарю!

Доброе утро, коллеги. Посоветуйте пожалуйста, как лучше организовать репозитории. Есть проблема в том, что сейчас все находится в монорепе, но там слишком много всего и мержить все это - это проблема. При коммите там, происходит сборка всего разного. Вижу как решение все таки, это разделение процесса сборки в CI по разным веткам на разные компоненты. Однако потом встанет вопрос о разделении прав доступа различных разработчиков к различным кускам кода. Хочется все разбить на отдельные репозитории, однако столкнулись с не очень приятной вещью. Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. Также было бы удобно, если все это хорошо показывалось в Goland. Разделением на репозитории, хотим решить проблему различного по времени деплоя различных проектов и разделения по правам доступа. Хотелось бы услышить какие нибудь советы и рекомендации, или аргументы почему нам не стоит так делать и как лучше тогда сорганизовать монорепозиторий. Спасибо.

Доброе утро, коллеги. Посоветуйте пожалуйста, как лучше организовать репозитории. Есть проблема в том, что сейчас все находится в монорепе, но там слишком много всего и мержить все это - это проблема. При коммите там, происходит сборка всего разного. Вижу как решение все таки, это разделение процесса сборки в CI по разным веткам на разные компоненты. Однако потом встанет вопрос о разделении прав доступа различных разработчиков к различным кускам кода. Хочется все разбить на отдельные репозитории, однако столкнулись с не очень приятной вещью. Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. Также было бы удобно, если все это хорошо показывалось в Goland. Разделением на репозитории, хотим решить проблему различного по времени деплоя различных проектов и разделения по правам доступа. Хотелось бы услышить какие нибудь советы и рекомендации, или аргументы почему нам не стоит так делать и как лучше тогда сорганизовать монорепозиторий. Спасибо.

Добавить эти пакеты в исключения, чтобы не импортировались в вендор.

Добавить эти пакеты в исключения, чтобы не импортировались в вендор.

А как же сборка в CI? Их же нужно импортить при сборке.

А как же сборка в CI? Их же нужно импортить при сборке.

По идее должны тогда импортироваться из обычных путей в src. Но надо смотреть. Я не делал. Попробуйте.

По идее должны тогда импортироваться из обычных путей в src. Но надо смотреть. Я не делал. Попробуйте.

Хм, но внутри контейнера сборки в src пусто.

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

yaml.v2 + самопис :)

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

Я все в переменные среды складываю

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

да viper на пике, но его надо вкурить =) в awecome-go еще configor есть, но немного недоделанный

Доброе утро, коллеги. Посоветуйте пожалуйста, как лучше организовать репозитории. Есть проблема в том, что сейчас все находится в монорепе, но там слишком много всего и мержить все это - это проблема. При коммите там, происходит сборка всего разного. Вижу как решение все таки, это разделение процесса сборки в CI по разным веткам на разные компоненты. Однако потом встанет вопрос о разделении прав доступа различных разработчиков к различным кускам кода. Хочется все разбить на отдельные репозитории, однако столкнулись с не очень приятной вещью. Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. Также было бы удобно, если все это хорошо показывалось в Goland. Разделением на репозитории, хотим решить проблему различного по времени деплоя различных проектов и разделения по правам доступа. Хотелось бы услышить какие нибудь советы и рекомендации, или аргументы почему нам не стоит так делать и как лучше тогда сорганизовать монорепозиторий. Спасибо.

я бы все-таки подумал насчет монорепо с git-submodules

Не надо сабмодулей

Не надо сабмодулей

А что думаете лучше делать в этом случае?

Мультирепо

Мультирепо

Можно поподробнее? Или есть линк, где почитать можно?

Да че тут подробнее

Каждый сервис - в свою репу

Каждую либу - в свою

Vendor у каждого свой (и закоммиченный)

Ну а что делать с теми проблемами, которые я описал выше?

Если мы хотим править одновременно несколько репозиториев.

Правьте

При закоммиченном вендоре это только в момент обновления важно

То есть решение такое, что в случае если мы хотим работать одновременно, то мы удаляем копию локального проекта из vendor?

> Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. У вас сборка одновременно двух сервисов чтоли?

То есть решение такое, что в случае если мы хотим работать одновременно, то мы удаляем копию локального проекта из vendor?

Зачем удаляем?

Зачем удаляем?

из за вот этого. сли у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg.

> Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. У вас сборка одновременно двух сервисов чтоли?

не понял вопроса.

А я - ответа

переходите с glide на dep тогда, если он не умеет собирать проекты по отдельности

Умеет

тогда я не понимаю их проблемы

Переходить все равно пора, но - умеет

тогда я не понимаю их проблемы

В монорепе возможно всякое

тогда проблема исчезнет при уходе от монорепо

Появится другая :)

ну, это как повезёт :)

Понадобится коммит изменений в своих же либах и апдейт вендора после него

проблема видимо в том, что тебе надо поправить параллельно основной проект и зависимую либу

Но это лучше, чем месиво монорепы

Glide все умеет. Смотрите. Я редактирую проект A, который зависит от проекта B. A и B зависят от viper к примеру. Я хочу, работая на проектом A, изменять проект B. Для этого, я должен удалить проект B из vendor-а проекта A, в том случае будет использоваться проект B в GOPATH, но у него есть свой vendor. И оба проекта зависят от viper, но каждый проект ходит в свой vendor за viper. А компилятор считает, что это разные viper.

Соответственно решение - удалить viper из обоих vendor-ов, и оставить его в GOPATH.

Погодите

Dep объединяет вендоры в один

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

А glide?

Проблема возникает только в том случае, когда я хочу редактировать 2 проекта одновременно. Иначе мне придется гонять изменения через git.

glide для каждого проекта свой GOPATH держит? Тогда печально

Их и надо гонять через гит

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

> Иначе мне придется гонять изменения через git. Так и надо, да. Делайте отдельные бранчи для этого.

Выглядит сложно конечно. Просто если 1-2 проекта, может быть еще сработает, а вот если множество, не очень удобно конечно.

Спасибо за советы

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

я бы на вашем месте рассмотрел причины, по которым вам приходится делать правки одновременно в нескольких проектах и попытался от них избавиться

Каким VPN-ом будем обходить блокировку телеги? FreeOpenVPN, CyberGhost, Hola - что лучше?

ssh порт форвардинг

Alexey Venediktov, [12.04.18 12:28] [Forwarded from Сайберсекьюрити и Ко. (Alex V. Litreev)] Дорогие подписчики. Прочитайте это внимательно, это важно, черт возьми. Вероятно, что уже сегодня Telegram может быть заблокирован в России. Наша миссия заключается в сохранении работоспособности мессенджера на территории РФ. Наша команда @VeeSecurity разработала бесплатный сервис Connecto Proxy для Telegram. С ним никакие ограничения Роскомнадзора не страшны. Пожалуйста, распространите эти ссылки максимально широко: http://opentg.us http://fuckrkn.us http://telegram.veesecurity.com Также можно распространить ссылки мгновенной настройки, тогда вся процедура займёт ровно один клик: http://12345.opentg.us http://12345.fuckrkn.us

Суд постановил заблокировать Telegram в России.

@tomiccio

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

не заблокируют

Жесть!

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

Welp.

Ну технически пока не заблокировали

Ну технически пока не заблокировали

а, ну понятно с тобой все)

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

а, ну понятно с тобой все)

Что именно? Люблю когда в чатике телепат штатный есть

Что именно? Люблю когда в чатике телепат штатный есть

ну вот это не ты. потому что ни телепатия ни логика не отработала

Не я. Я же говорю, приятно когда телепат в чате есть

ЧТО ДЕЛАТЬ Поставить прокси через @socks5_bot или воспользоваться одним из этих сервисов: — http://opentg.us — http://fuckrkn.us — http://telegram.veesecurity.com — https://tgvpn.com/ru

посоны я буду скучать по Вам)

xD

посоны я буду скучать по Вам)

щас забаню превентивно

я уже через прокси с пятницы

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

а я из Минска)

Может лучше в icq перейдем?

на юр лиц ркн вроде как не действует.