В логах пусто. Он просто отжирает 100% проца и все. MS Office на более слабом компе работает вообще моментально

На правах оффтопа. К теме линукс для десктопа. LibreOffice у меня намертво виснет при попытке открытия xlsx файла. Ей богу хоть винду на виртуалку ставь т.к. работа стоит

LibreOffice он такой, да. Сам по себе тормоз еще тот, и частенько не ладит с форматами MSO.

LibreOffice он такой, да. Сам по себе тормоз еще тот, и частенько не ладит с форматами MSO.

Ну Майки сами отчасти виноваты. Любят проприетарщину

Так никто не мешал Libre/Open офису сделать удобный продукт, а не делать пародию на MS Office.

См. шутку про 11 конкурирующих стандартов

Ну Майки сами отчасти виноваты. Любят проприетарщину

xlsx - это открытый стандарт Office Open XML

И его то как раз LibreOffic жрет очень неплохо

ну вон человек жалуется что не жрет, давится

Впрочем формат дерьмовый, им нетрудно подавиться

idea обновилась

@ahdenchik ты использовал https://github.com/dcarp/protobuf-d ? или может кто другой пользовал?

он не рабочий ещё вроде

автор пропал

но идея верная, поддерживаю его

он не рабочий ещё вроде

крайне печально

Попробуй, может и заработают те части что тебе нужны

а чем тебе dproto плох кроме моей антирекламы?)

У D есть одновременно и киллер-фича и проклятие - это совместимость с C/C++

С одной стороны доступ к огромной базе кодов накопленной за несколько десятков лет. С другой стороны все эти библиотеки.. Они получается написаны на другом языке. И кроме биндингов ничего особо не поправишь..

с С++ нету

немножко есть

вызовы? ну ок, да

а чем тебе dproto плох кроме моей антирекламы?)

То что было уже написанно было под протобаф3

А да, есть такое. Новый пакет взлетит скорее чем dproto

Потому что он будет проще и удобнее.

И поддержит все нюансы

юзайте MessagePack

юзайте MessagePack

Передаём в основном числа, много, поэтому бинарный формат предпочтительней

Передаём в основном числа, много, поэтому бинарный формат предпочтительней

дык он и есть бинарный

просто он попроще, нет версионирования

Чёт мельком прочитал, он же совместим с json?

нет

чисто бинарная фигня, кодирование похоже на протобуферы

Ну я уже велосипед написал один

Но вот думаю его всё-таки поменять на что-то

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

Ну это да

а для чего нужно? RPC?

Скорее IPC

Внутри системы

межпроцессное?

Ну да

ну тогда протобуфы наверняка излишни

Сейчас на mqtt, тоже задумывался над заменой

Но mqtt не сильно грузит

а чем mqtt не нра?

Поэтому пришёл к выводу, что ок

Посмотрел на чисто linux ipc (разделяемая память, fifo и тд) и понял, что нужно будет городить такую же штуку как mqtt (топики, очереди сообщений)

По сути mqtt устраивает

Кроме того что я его тоже свелосипедил)

Есть реализация через vibe, но она не выдерживала нагрузки, пришлось биндить libmosquito

ну так оставь

работает - нитрогай :)

пока точно не буду)

так есть же очереди сообщений в sysv ipc

и в unix ipc тоже вроде есть queue

или я что-то не так понял?

да, есть это всё

но задача чуть сложнее чем просто из одной программы в другую данные передать

нужны каналы коммуникации, шины

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

двусторонняя связь — программа отсылает запрос, должна получить ответ

получается этих fifo нужно будет создавать пачками (2 на каждую программу + общие шины данных на всех)

при этом я не уверен, что возможна модель шины данных

так что mqtt вообще огонь

ERROR: S client not available

А что про zeromq скажешь?

пока не пробовал, но как-то очень давно читал и вроде там немного другая модель

несколько получателей нельзя делать. я на си пишу когда многопоточные приложения - у меня обертка есть с созданием 2 queue на каждый тред. и уже обмен сообщениями через главный тред, который сам решает кому послать\переслать. только если так)

не оч удобно, да, особенно на си

кафка очень неплох для задач такого типа.

Вместо протобуфа для бинарного IPC вот такая еще приятная штука есть https://code.dlang.org/packages/cerealed

У меня в одном продукте как раз используется для общения процессов.

началось

Ура мы популярны

К Д пришла слава!

век бы такой славы не видать

век бы такой славы не видать

Шта?! Что происходит, о чём речь?

да спамить начали

Вместо протобуфа для бинарного IPC вот такая еще приятная штука есть https://code.dlang.org/packages/cerealed

Ну не знаю. Протобаф лучше, имхо, его много кто поддерживает

Реально как стандарт уже)

а давно указатель вметсо .ptr стал &, как в с++ ?

и еще тупой вопрос два цикла подряд (не вложенные) это сложность 2n, так ведь?

и еще тупой вопрос два цикла подряд (не вложенные) это сложность 2n, так ведь?

ну вроде, да

а давно указатель вметсо .ptr стал &, как в с++ ?

с самого начала. ptr это только для массивов.

а давно указатель вметсо .ptr стал &, как в с++ ?

.ptr это у динамических массивов поле.

и еще тупой вопрос два цикла подряд (не вложенные) это сложность 2n, так ведь?

Не, O(n). Множитель игноируется

Ребят, такой вопрос. Вот мы решили писать логи в logstash. Правильно ли я понимаю, что лучшей практикой будет писать их не туда напрямую, а в stdout и пробрасывать через pipe в logstash нежели брать логер, который сразу в logstash пишет

Оу это спроси в @ru_devops

Но впринципе, а чего бы напрямую не писать? Зачем пайп?

Хорошо, щас там спрошу. А пайп затем, чтобы мы без доп усилий могли его если надо просто в стадаут отправить

А "напрямую" это ты думаешь не через пайп? )

Там как бы все в итоге сводится к файловому дескриптору все равно.

Даже при сетевом обращении?

Единственная рекомендация, делайте не через unix сокет а через TCP, это хоть и помедленнее, но если вдруг придется масштабировать машины то будет проще

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

Ну вот пишу я логи в stdout, дальше мои действия какие?

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