@gogolang

Страница 999 из 1630
Marlik
13.04.2018
01:18:42
Честно говоря, только щас задумался кто у меня компилит, ибо в голэнде стоит любой а каким он компилит даж не в курсах.

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

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

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

Google
Marlik
13.04.2018
01:23:33
Как я понял 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

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

Marlik
13.04.2018
02:43:09
Дык венда отстой, на ней только в игрушки играть...

Makkusu
13.04.2018
02:43:39
один гуи только да бесит

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

Slava
13.04.2018
04:13:20
да

Sergey
13.04.2018
04:14:17
благодарю!

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

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

Vsevolod
13.04.2018
05:52:47
Добавить эти пакеты в исключения, чтобы не импортировались в вендор.
А как же сборка в CI? Их же нужно импортить при сборке.

Zver
13.04.2018
05:54:02
А как же сборка в CI? Их же нужно импортить при сборке.
По идее должны тогда импортироваться из обычных путей в src. Но надо смотреть. Я не делал. Попробуйте.

Sergey
13.04.2018
06:24:28
Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

Mykyta
13.04.2018
07:16:22
Slach
13.04.2018
07:21:21
Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?
да viper на пике, но его надо вкурить =) в awecome-go еще configor есть, но немного недоделанный

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

Daniel
13.04.2018
07:57:36
Не надо сабмодулей

Vsevolod
13.04.2018
07:58:01
Не надо сабмодулей
А что думаете лучше делать в этом случае?

Daniel
13.04.2018
07:59:30
Мультирепо

Vsevolod
13.04.2018
08:04:59
Мультирепо
Можно поподробнее? Или есть линк, где почитать можно?

Daniel
13.04.2018
08:05:22
Да че тут подробнее

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

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

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

Vsevolod
13.04.2018
08:06:28
Ну а что делать с теми проблемами, которые я описал выше?

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

Google
Daniel
13.04.2018
08:06:58
Правьте

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

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

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

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

Daniel
13.04.2018
08:09:49
А я - ответа

Andrey
13.04.2018
08:10:05
переходите с glide на dep тогда, если он не умеет собирать проекты по отдельности

Daniel
13.04.2018
08:10:16
Умеет

Andrey
13.04.2018
08:10:27
тогда я не понимаю их проблемы

Daniel
13.04.2018
08:10:33
Переходить все равно пора, но - умеет

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

Andrey
13.04.2018
08:11:04
тогда проблема исчезнет при уходе от монорепо

Daniel
13.04.2018
08:11:21
Появится другая :)

Andrey
13.04.2018
08:11:37
ну, это как повезёт :)

Daniel
13.04.2018
08:12:07
Понадобится коммит изменений в своих же либах и апдейт вендора после него

Dmitriy
13.04.2018
08:12:24
проблема видимо в том, что тебе надо поправить параллельно основной проект и зависимую либу

Daniel
13.04.2018
08:12:35
Но это лучше, чем месиво монорепы

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

Google
Vsevolod
13.04.2018
08:13:14
Соответственно решение - удалить viper из обоих vendor-ов, и оставить его в GOPATH.

Daniel
13.04.2018
08:13:51
Погодите

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

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

Daniel
13.04.2018
08:14:21
А glide?

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

Andrey
13.04.2018
08:15:11
glide для каждого проекта свой GOPATH держит? Тогда печально

Daniel
13.04.2018
08:15:25
Их и надо гонять через гит

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

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

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

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

Andrey
13.04.2018
08:17:26
если у вас проекты настолько взаимосвязаны - то это само по себе сложно

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

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

Phil
13.04.2018
08:32:44
ssh порт форвардинг

Aleksandr
13.04.2018
08:33:31
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

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

Google
Aleksandr
13.04.2018
08:36:29
не заблокируют

Андрей
13.04.2018
08:37:02
Жесть!

Artem
13.04.2018
08:40:34
Ну технически пока не заблокировали

Aleksandr
13.04.2018
08:41:29
Ну технически пока не заблокировали
а, ну понятно с тобой все)

Artem
13.04.2018
08:41:49
Но конечно маловероятно соо кто-то будет дискредитировать суд

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

Aleksandr
13.04.2018
08:43:41
Что именно? Люблю когда в чатике телепат штатный есть
ну вот это не ты. потому что ни телепатия ни логика не отработала

Artem
13.04.2018
08:44:27
Не я. Я же говорю, приятно когда телепат в чате есть

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

X
13.04.2018
08:46:38
посоны я буду скучать по Вам)

Ivan
13.04.2018
08:46:51
xD

Aleksandr
13.04.2018
08:47:00
посоны я буду скучать по Вам)
щас забаню превентивно

Александр
13.04.2018
08:47:01
я уже через прокси с пятницы

Kirill
13.04.2018
08:47:03
Мне на работе вообще пофигу, мы сами себе провайдер, блокировок нет

X
13.04.2018
08:47:17
а я из Минска)

Ivan
13.04.2018
08:47:38
Может лучше в icq перейдем?

Andrey
13.04.2018
08:47:49
на юр лиц ркн вроде как не действует.

Страница 999 из 1630