это как с objective-c никто не мешает его использовать под linux, но что-то нормально с ним сделать там все равно не получается так как нет нормальных инструментов. GnuStep убог, чуть более чем полностью.
какая у тебя странная цепочка рассуждений :)
на самом деле LLVM первичен, потом идет clang, и то и то прикрастно работает по linux, но проблема со swift совсем не в этом - он заточен под cacoe и ios.
prompt_command вроде как вызывается на каждую отрисовку этого самого промта, то есть если ты просто нажмешь enter после нужного периода ожидания - получишь нотификацию.
@mihail0v а, ну это не gui называется, просто ui ну или в крайнем случаи cui или tui. Ну понятно - в любом случае тебе не нужен screen - от него вряд ли много пользы будет, это скорее инструмент для человека, нежели для компьютера. Тебе достаточно будет просто умеет перенаправлять ввод у дочерних процессов. Я в node.js слабо разбираюсь, но вот слова которые нужно забить в man 2 и 3 и обязательно почитать (если ты конечно еще этого не сделал :)) fork, execv, dub, dub2, pipe
@mihail0v screen и gui никак не связаны. screen - это просто эмулятор терминала на подобе gnome-terminal (из gnome-а) или kterminal (из kde). Если тебе нужно работать с gui то screen ни как не поможет, можешь смело форкаться и запускать jar из форкнутого процесса, но как ты собираешься работать с gui на сервере - я слабо себе представляю.
вряд ли такие есть, но можно упростить через систему инкрементальных бэкапов (с какой-то версии в убунте есть предустановленая) и соответственно таскать только их дифы, но как там будет решаться проблема с конфликтами - фиг знает.
@h0x0d9 боюсь что не до конца ответил
>нужны ли ему эти вспомогательные маркеры в пришедшем пакете, чтобы восстановить структуру?
При десериализации протобуфу нужен только буфер и его длина откуда брать данные, то есть все эти маркеры нужны скорее тебе, что бы достать нужного размера буфер из входного пакета.
@h0x0d9 ага теперь понял
>Сериализуя структуры, вносит ли protoBuf какие-то вспомогательные байты в выходной поток
Протобуф ничего дополнительного в сообщение не вставляет и да, это распространенная практика оборачивать сообщения протобуфа вот такой структурой, которую ты описал.
>нужны ли ему эти вспомогательные маркеры в пришедшем пакете, чтобы восстановить структуру?
И да и нет. У протобуфа бинарный формат очень хитро устроен, он вообще говоря, может несколько входных сообщений при десериализации объединить в одно, тут надо смотреть когда это может понадобиться. Но, как уже выше писал, обычно протобуфное сообщение оборачивают чем-то похожим на то, что ты описал и таким образом получают в точности то что послали.
и еще вот эта строчка как-то смущает
client_ = new buzz::XmppClient(this); // NOTE: deleted by TaskRunner
точнее ее коментарий, как это TaskRunner убивает клиента?