книга есть

На Go не делают системное программирование. Его на С делают и на расте (про раст не уверен).

системное программирование на кросплатформе? Вы знаете толк в извращениях ?

на linux

ubuntu / manjaro

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

Что, в вашем понимании, есть системное программирование?

https://www.packtpub.com/networking-and-servers/go-systems-programming

похоже не я один

мне надо demon`ы автоматизировать

их создание и управленние

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

а вы gcc использовали в работе ... или хотите простым синтаксисом GO обойтись в этом деле?

их создание и управленние

Так это не системное программирование. Системное - это когда драйвера пишут, ну или там в ядре что.

gcc да. но хотел именно через го , если верить книге , там можно обойтись без дополнительных форков процессов

Так это не системное программирование. Системное - это когда драйвера пишут, ну или там в ядре что.

я несколько по другому понимаю значит этот термин:)

gcc да. но хотел именно через го , если верить книге , там можно обойтись без дополнительных форков процессов

Алексей вам правду сказал ... создание демонов не системное программирование

системное это уровень kernel

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

уровень ядра.

мне надо demon`ы автоматизировать

А вообще ведь уже есть systemd, а к нему есть биндинги, вот, например: https://github.com/coreos/go-systemd

Уровень ядра это драйверы

ядра ОС , к этому уровню относится разработка драйверов !

А ваш извините прикладной

А ваш извините прикладной

ок, затупил, признаю

не проснулся

со вчера. с кем не бывает

Вы пускаете процесс, пусть и с повышенными правами

А вообще ведь уже есть systemd, а к нему есть биндинги, вот, например: https://github.com/coreos/go-systemd

0_0 я вчера на нее смотрел.. смотрел... ,блин.. пора на пенсию

в мои 26- самое время

Вы пускаете процесс, пусть и с повышенными правами

да,

Вы пускаете процесс, пусть и с повышенными правами

осталось придумать как этот процесс подвязать к rest api на go :)и все будет готово

но то я уже сам, спасибо. буду либу изучать

Может быть стоит подумать про очереди

И асинхронную обработку

Почти любой сценарий крона можно сделать асинхронным

да, там по другому не выйдет,

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

Только тут ещё вариант "-1" должен быть. Потому что Lookups это такой рандом, который превращает тест в фарш

Только тут ещё вариант "-1" должен быть. Потому что Lookups это такой рандом, который превращает тест в фарш

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

Ебануться

Есть пакет main, который объявлен в каталоге ./main/. Если создать в каталоге ./main/ подкаталог ./main/model/ и в нем создать файл и указать пакет main - так делать можно? или это плохая практика, и пакет должен точно соответствовать имени(пути) каталога?

Привет Писал на python, решил попробовать на go

возникла трабла

надо показать содержимое архива

https://pastebin.com/aEZ1r4du

ругается на reader, err

.\main.go:9:2: undefined: reader .\main.go:9:10: undefined: err .\main.go:10:5: undefined: err .\main.go:11:3: too many arguments to return .\main.go:11:10: undefined: err .\main.go:13:23: undefined: reader

reader, err := zip.OpenReader("c:/bin/1.zip") :=

https://pastebin.com/aEZ1r4du

можно код постить на play.golang.org :) там его же можно было бы и запустить

.\main.go:9:2: undefined: reader .\main.go:9:10: undefined: err .\main.go:10:5: undefined: err .\main.go:11:3: too many arguments to return .\main.go:11:10: undefined: err .\main.go:13:23: undefined: reader

https://play.golang.org/p/uIrl1tNBDi

дада. понял

мерси

Я тут пытаюсь своего домена вежливо убивать, и такой вопрос возник - Shutdown() для http.Server ведь пытается ждать, пока все ServeHTTP отработают?

А, всё, прочитал доку. Пытается, кроме тех, которые прокачаны до websocket.

кто юзает ovh? дайте промокод если не жалко

Привет Всем! Есть вопросик по vue+go, плз кто использует эту связку, напишите в личку

Таки в репе оказалось все верно, и чтобы можно было указывать импорт пакета по имени пакета, а не по пути к каталогу, надо в GOPATH добавить путь к каталогу с проектом.

Таки в репе оказалось все верно, и чтобы можно было указывать импорт пакета по имени пакета, а не по пути к каталогу, надо в GOPATH добавить путь к каталогу с проектом.

Вот чуть не отпало желание дальше учить GO, когда думал что надо всегда указывать путь к каталогу с пакетом :) указывать имя пакета же приятнее, чем писать путь к нему.

Таки в репе оказалось все верно, и чтобы можно было указывать импорт пакета по имени пакета, а не по пути к каталогу, надо в GOPATH добавить путь к каталогу с проектом.

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

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

+++

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

Возможно, буду благодарен за парочку примеров(вкратце), почему писать импорт по имени плохо, и чем это может обернуться.

ERROR: S client not available

что такое "писать импор по имени"?

Ну вот если добавить путь к проекту в GOPATH, тогда я могу импорт писать по имени пакета: import "domain". А если не добавлять в GOPATH путь к проекту, тогда для импорта надо писать import "../domain"

смотрите

Ну вот если добавить путь к проекту в GOPATH, тогда я могу импорт писать по имени пакета: import "domain". А если не добавлять в GOPATH путь к проекту, тогда для импорта надо писать import "../domain"

Проект надо создавать в GOPATH и писать полный путь относительно его.

у вас уже есть GOPATH

и вы говорите go get

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

если после go get пает ваш не собирается - это говно, а не пакет

не нужно бороться с GOPATH нужно принять его :)

не нужно бороться с GOPATH нужно принять его :)

не нужно бороться с ВИЧ, нужно принять его

)

Вот у меня есть каталоги A и B, которые лежат в каталоге с моим проектом, т.е. они лежат рядом с файлом main.go. В этих каталогах определены пакеты A и B, соответственно. Как мне из пакета B обратится к методам которые режат в A? Писать import "../A" ? Вот это очень смущает. А вот если добавить в GOPATH каталог в котором лежит мой проект, тогда внутри пакета B, для того чтобы обратится к функциям из A, я могу просто написать impport "A"

Вот у меня есть каталоги A и B, которые лежат в каталоге с моим проектом, т.е. они лежат рядом с файлом main.go. В этих каталогах определены пакеты A и B, соответственно. Как мне из пакета B обратится к методам которые режат в A? Писать import "../A" ? Вот это очень смущает. А вот если добавить в GOPATH каталог в котором лежит мой проект, тогда внутри пакета B, для того чтобы обратится к функциям из A, я могу просто написать impport "A"

А зачем они в каталоге с проектом лежат?

не понял вопроса. это код который относится к этому приложению, это не библиотеки

src/myproject, src/A, src/B

src/myproject, src/A, src/B

а что тогда должно ленжать в src/myproject?

main.go

и все?

один файл?

не нужно бороться с ВИЧ, нужно принять его

А аналогия с Гитлером будет?

Ну и остальные файлы проекта, если они есть

Ну и остальные файлы проекта, если они есть

каталоги A и B - это и есть файлы моего проекта

А аналогия с Гитлером будет?

а надо? не сочтут терроритом?

каталоги A и B - это и есть файлы моего проекта

А зачем они в отдельных каталогах? Почему не в корне?

src/myproject, src/A, src/B

А чем плохо держать файлы пакета в подпапке проекта?

А зачем они в отдельных каталогах? Почему не в корне?

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

я вообще, придя из жавы, "немного" ошалел от того, как устроена структура проекта в ГО

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

Отлично всё устроено

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