Создание sharde object с помощью gccgo

Какие проблемы сулит создание и использование таких библиотек?

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

Есть ли способ сгенерировать на ее основе «header» для go по ее исходникам?

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

Да уж, а когда у низ намечается поддержка динамически загружаемых библиотек? С переездом на github я потерял их роадмап (и то, он был кривой какой-то).

А как вообще обстоят дела с gccgo? Я слышал, что он по оптимизациям обгоняет родной компилятор.

Да уж, а когда у низ намечается поддержка динамически загружаемых библиотек?

У оригинального gc? Авторы принципиально считают, что динамические библиотеки не нужны.

А как вообще обстоят дела с gccgo? Я слышал, что он по оптимизациям обгоняет родной компилятор.

Да, это правда, он же фронтенд к gcc. Хорошо обстоят дела, но поддерживается только Go 1.2, поддержка Go 1.4 запланирована в GCC 5.

Чрт, ну я авторам хочу сказать, что они не правы...

Это глупо пытаться сломать устоявшиеся положения...

Чрт, ну я авторам хочу сказать, что они не правы...

https://groups.google.com/forum/#!forum/golang-nuts

Только ты будешь не первый.

Это глупо пытаться сломать устоявшиеся положения

Это в ваших Линуксах, может быть, устоявшееся положение. Вам бы ещё их переименовать из .so в .dll, чтобы более соответствовать популярным трендам. В православной Plan 9 никаких разделяемых библиотек нет.

(хочу добавить, что это был сарказм)

А как они это решают тогда там?

Мне интересен был когда-то plan9...

Авторы принципиально считают, что динамические библиотеки не нужны.

4.2 же. Даже proposal был от Ian Lance Taylor: https://docs.google.com/a/golang.org/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDel...

А как они это решают тогда там?

Что «это»? Где «там»? Если ты про динамическое связывание в Plan 9, то так и так.

Я непонял. Оно там решается тем, что все проги сами себе либы?

4.2 же. Даже proposal был от Ian Lance Taylor

Ну и что же? Главный разработчик gccgo предложил разработчикам gc разупориться и даже план разупарывания написал. Но только чем кончилось, я не знаю.

Держи те меня в курсе пожалуйста. Именно этот момент меня отпугивает от Go сейчас.

Кстати, есть какой-нибудь транслятор C++ заголовочников либ в Go?

а go package создать ?

Зачем? В чем суть если я хочу предоставить именно скомпилированный объект.

Т.е. исходники одно, а готовая для использования либа - другое.

В общем пока эта штука не научиться в либы мне е не особо хочется...

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

Тогда не пользуйтесь Go.

Ну я так и делаю, зачем говорить очевидное. Однако мне нравиться revel и его я юзаю. Т.е. я не юзаю его там где мне нужны ибы, а хотелось бы...

Я непонял. Оно там решается тем, что все проги сами себе либы?

Эээ... Нет, если нужно просто как-то выделить общий код, он выделяется в библиотеку, которая потом связывается с программами статически. Если нужно выделить общий «сервис», то пишется 9P-сервер.

Зачем? В чем суть если я хочу предоставить именно скомпилированный объект.

Т.е. исходники одно, а готовая для использования либа - другое.

Логика здесь такова, что твоя библиотека по определению не может быть готовым для использования скомпилированным объектом. Готовый объект — это программа. А у тебя только компонент программы.

Ну я бы хотел предоставить в результате не только исходники, но и скомпилированную либу. Которую смогут юзать не только go'ленгисты, но и плюсовики и все те, кто может дергать сишные либы.

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

Вот это вообще отдельная тема, которая, насколько я знаю, вообще не работает.

Ну как бы ты понимаешь, что это жопа?

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

Странно, что Роб Пайк так мало уделяет внимание этом вопросу...

Насколько я знаю, Роб Пайк считает динамические библиотеки злом, и что взаимодействие между разными инфраструктурами лучше делать более универсальными, платформонезависимыми протоколами.

Ну если бы он придумал адекватную альтернативу...

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

Дык этих альтернатив понапридумано море, зачем еще одну?

Можно подробнее про альтернативы?

Я что-то не в курсах...

Господи, чё-то лор совсем скатывается...
http://stackoverflow.com/questions/6125683/call-go-functions-from-c

package foo

// extern int goCallbackHandler(int, int);
//
// static int doAdd(int a, int b) {
//     return goCallbackHandler(a, b);
// }
import "C"

//export goCallbackHandler
func goCallbackHandler(a, b C.int) C.int {
    return a + b
}

// This is the public function, callable from outside this package.
// It forwards the parameters to C.doAdd(), which in turn forwards
// them back to goCallbackHandler(). This one performs the addition
// and yields the result.
func MyAdd(a, b int) int {
   return int( C.doAdd( C.int(a), C.int(b)) )
}

Можно подробнее про альтернативы?

Банально 9P, например. Любой протокол межпроцессного взаимодействия, TCP/IP и т.д. и т.п.

Разве оно не даст просадки по скорости? Как быть например в играх?

Разве оно не даст просадки по скорости?

Не такие большие. Зато можно, например, расшарить код по сети, запустить его на другой машине с другой архитектурой.

Как быть например в играх?

А сколько библиотеки DirectX весят? Я че-т не смог найти в винде, где они лежат, нашел только какие-то DirectX for Managed Code, там всего 2МБ, так что наверное не то. Да и игроделы когда-то и DX не принимали, в т.ч. и из-за того, что он снижал производительность, но в итоге «фичи» и избавление от необходимости собственноручно поддерживать драйвера для всё быстрее растущего и усложняющегося зоопарка железа превозобладали.

Господи, чё-то лор совсем скатывается...

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

Ну как бы ты понимаешь, что это жопа?

А сколько ты знаешь современных языков, которые можно вот так просто вызывать из Си? Кроме Си, C++ (и то с правильными заголовками) и ассемблера (и то может быть несогласование конвенций вызовов)? Ну, может быть, ещё Rust, но я его не щупал. Особенно со сборкой мусора и собственным управлением потоками.

Можешь ли ты, например, написать библиотеку на Java, которую можно дёргать из Си? Или на Python? Или на Haskell?

Некоторые языки — в том числе Go — позволяют дёргать код на Си и организовывать коллбэки, при условии, что main() написан на этом языке, а вызываемая функция «ведёт себя хорошо» и не лезет, например, менять память в непредсказуемых (с точки зрения рантайма и компилятора) местах или манипулировать потоками. Насколько я знаю, некоторые реализации Haskell позволяют писать main() на Си при условии, что оно будет компилироваться специальным компилятором.

Но возможность писать библиотеки, которые можно безо всяких костылей и оговорок дёргать из любого языка, — это отнюдь не тривиальная вещь. Она накладывает сильные ограничения на свободу в дизайне языка. Поэтому её отсутствие — это вовсе не такая «жопа», как кажется на первый взгляд. Во многих областях без неё можно прекрасно обойтись. Но не во всех. Это одна из причин популярности Си и Си++.

Ты кстати не знаешь более вменяемого для Go ide, чем liteide? Atom у меня так и не собрался последний, а плагин go-plus к нему в прошлом году не умел gocode.

У нас в отделе один использует Sublime Text, я использую emacs, остальные - vim. Везде работает gocode и другие плюшки.

Ну не знаю, emacs я хотел опять начать юзать, но... Что-то меня останавливает...

Дело хозяйское. А вообще, советую осилить вим. Распечатай себе шпаргалку ( она гуглится). За неделю освоишься. Когда допилят neovim, скорее всего буду на него переползать.

Мне emacs ближе. Т.е. я на elispe пишу если надо и все такое. Слушай, а может подскажешь адекватное решение для go. Хочу с xlib работать, есть что на примете? Или в ручную дергать сишные функции?

Сомневаюсь, что тут что-то готовое есть. Поищи, но скорее всего придется тебе писать обвязку самому. У меня несколько иная предметная область.

Я пользуюсь Eclipse + Goclipse.

Ну я помню он там кривой был... Что-то импорты не подтягивал

Ладно, уговорили. Уж очень соблазнителен тот факт, что по умолчанию есть кроссплатформенность (_linux, _windows и т.д.) + потоки делаются легко и понятно(без лишних проблем и мороки), ну и тесты отлично все это дополняют. Придется правда обвязки писать самому...

Кстати, а зачем второй раз вызывается функция?

    // runtime.GOMAXPROCS() returns previous max_procs
    max_procs := runtime.GOMAXPROCS(MAXPROCS) 
    // second call to get real state
    max_procs = runtime.GOMAXPROCS(MAXPROCS)
    fmt.Println("MaxProcs = ", max_procs)

И да, ребят, у вас есть контакты feofan proud_anon?

Этот код откуда?

http://golang.org/pkg/runtime/#GOMAXPROCS - читай описание и комментарии, всё прозрачно.

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

Код от сюда: http://habrahabr.ru/post/195818/

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

Добавил в профиль

И да, ребят, у вас есть контакты proud_anon

Не, у меня нет контактов :)