Продолжение идей libbash: технический аспект и степень ненужности

Ведется ли какая-то разработка в этом направлении или все затухло тогда в 2011?

qiaomuf что-то пилил еще потом, но в 2013 году он из состава разработчиков вышел

Какой потенциал у libbash, кроме ускорения портаж, нужно ли оно?

В принципе если кому-то нужен «встраиваемый» интерпретатор bash - может и нужно.

Наиболее интересна штука должна быть гентушникам, так как позволила бы на порядок ускорить работу portage засчет замены кучи вызовов bash на вызовы сишного апи libbash с соответствующим кэшированием абстрактных синтаксических деревьев.

Ты её бенчил?

Ты вначале попробуй увеличить кол-во вызовов этого самого bash в portage. Что там мешает заспавнить сразу 100500 башей одновременно? Сейчас оно у меня запускает только один баш одновременно. Почему их надо вызвать последовательно?

Какой потенциал у libbash, кроме ускорения портаж, нужно ли оно?

Никакой. В любом случае это будет дерьмо. Какой мне профит с того, что тупить оно будет не пять минут, а в лучшем случае 2? Вот если бы оно работало нормально - был бы профит, но этого никогда не будет. Поэтому все забили.

По-моему, libbash - тупняковое направление развития. Реализовывать полный баш - это убиться проще. Проще перевести ебилды на dash какой-нибудь или выбрать своё компактное подмножество баша и написать свой интерпретатор. (А ещё лучше было не использовать говношелл с самого начала, а юзать что-то полудекларативное типа qml. Которого тогда и в проекте не было, но всё-таки. Ну да уже поздняк пить таблетки, проще новый дистрибутив запилить.

Какой потенциал у libbash, кроме ускорения портаж, нужно ли оно?

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

Ты её бенчил?

Ее бенчил qiaomuf, а я смотрел его сорцы: оптимизация там оставляла желать лучшего.
Тем не менее, портажевские утилиты с принрученным libbash действительно работали на несколько порядков быстрее. По ссылке выше есть пруфы.

Ты вначале попробуй увеличить кол-во вызовов этого самого bash в portage.

По моему, как раз это — тупиковая ветвь развития.
Усложнит семантику кода, но зачем — ради увеличения производительности всего в %количество ядер процессора% раз?
Разбор адекватным парсером, вместо регэкспов в баше — уже профит + кэш AST.

В любом случае это будет дерьмо

Очень аргументированно)

Проще перевести ебилды на dash какой-нибудь или выбрать своё компактное подмножество баша и написать свой интерпретатор.

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

Ее бенчил qiaomuf, а я смотрел его сорцы: оптимизация там оставляла желать лучшего.

А их кто-нибудь видел?

Тем не менее, реализованные с помощью libbash утилиты действительно работали на несколько порядков быстрее. По ссылке выше есть пруфы.

Там какая-то неведомая херня.

#time egencache --jobs=1 --update --repo gentoo
real    0m16.982s
user    0m15.690s
sys     0m1.270s

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

Ну хорошо, предположим идея говно + есть хт.

Разбор адекватным парсером, вместо регэкспов в баше — уже профит + кэш AST.

А что вообще ты хочешь прекрутить на либбаш? Разбор ебилдов? Расскажи конкретней.

Ебилды до сих пор не вынесли в отдельного однофайловое хранилище/фс - это фейл. В какой-то из твоих тем я ваял читалку всех ебилдов и бенчил холодный и горячий её старт - холодный старт был полчаса, а горячий доли секунды.

Сейчас я запустил этот egencache и на холодную он у меня так же полчаса пилил.

Очень аргументированно)

Ну вот смотри - какая мне разница - будет ли оно тупить 5, либо 10минут? Всё это не имеет значение, если это не мгновенно. Я же не буду сидеть и глядеть в консольку 5минут в ожидании? Я её сверну и пойду делать что-то иное.

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

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

У самого руки никак не дойдут провести адекватные замеры портажа и понять в чем конкретно проблема. Все вопли по-поводу сложности расчёта зависимостей не имеют никаких оснований и оправданий.

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

А зачем их терять?

Ты делаешь свой куллформат и транслятор в него - всё. Он ставится вместо emerge --sync, а в самом репе и у консерваторов пусть стоит портеж, если им так хочется.

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

Ну делать костыли для самого себя любимого — не есть самоцель.

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

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

Почему кастыли? Почему для самого себя? Зачем пытаться реализовать дерьмо, если проще написать транслятор из дерьма в своё и не париться? Никаких проблем не вызывает.

В любом случае - куда деваалсь проблема io? Которая существует из-за убогой архитектуры.

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

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

Я имел ввиду вообще его переписать.

Да, есть паладиус. Но сам факт того, что прога на C++ не быстрее питона, вызывает сильные опасения по-поводу качества кода и подходов/алгоритмов. Да и смысл тогда было переписывать, если итоговый результат не дал никаких плюсов.

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

Увы, но работа по переписыванию portage - это минимум годик для нескольких человек. И это убивает всю затею.

если проще написать транслятор из дерьма в своё

Окей, предположим, я делаю свой офигенный формат, а что дальше?
Патчить портаж? Там такие километры макаронного кода, что я закопаюсь, пока пропатчу.
FUSE, перехватывающая вызовы open? Оверкилл, да и портаж — система сложная, вряд ли так что-то выйдет.

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

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

Патчить портаж? Там такие километры макаронного кода, что я закопаюсь, пока пропатчу.

Я не понимаю что тебе нужно.

Ты хочешь ваять либбаш, чтобы заменить вызов баша на сишные вызовы в том же пистоне.

Какая разница заменять их на вызов либбаш, либо заменять их на либсуперформат?

Вывод — нужна поддержка со стороны разработчиков, а никто мой велосипедный формат поддерживать не станет.

А как ты хочешь впихнуть свой либбаш? Сделать свой баш с кешированием выхлопа аля ccache?

Уже есть кэш через sqlite, казалось бы, мечта, база данных с интексированием и прочими плюшками, но не помогло.

Это не кеш - это дерьмо. С чего вообще кто-то решил, что это что-то даст?

Проблема в организации данных и убогих паттернах обращения к ним.

Опиши как вообще должна работать либбаш и что там баш делает с ебилдами.

Какая разница заменять их на вызов либбаш, либо заменять их на либсуперформат?

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

Сделать свой баш с кешированием выхлопа аля ccache?

Ну или на крайняк так, да, если пошлют девы генты

Да, есть паладиус.

Я ничего не знаю о том - что там в паладусе. Там такие же ебелды, либо что-то своё?

Увы, но работа по переписыванию portage - это минимум годик для нескольких человек. И это убивает всю затею.

Что ты понимаешь под переписыванием portage? Заваять то же самое на крестах? Это гиблая идея.

Даже если ты перепилишь всё, начиная с ебилдов - это то же тупиковый путь, ибо кто научит тонны пакетов собираться нормально? В любом случае там будут тонны кастыли на башике.

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

Хорошо. Ты лучше объясни что там конкретно делает либбаш с ебилдами. Парсит его и выдаёт какой-то набор значений?

Ты можешь просто эмилировать либбаш, только ты будешь не либбаш.

Такое ощущение, что никто из присутствующих pkgcore не пробовал. Он тоже на питоне, но работает реактивной. Вот его лучше и пилите.

Парсит его и выдаёт какой-то набор значений?

Интерпретирует и выдает массив переменных и массив функций

Мне кажется, он реактивный именно потому что нифига не умеет)
Поставил — нет поддержки EABI 6 :C

массив функций

Это что за зверь такой?

Вот у нас есть ебилд: /usr/portage/sys-devel/gcc/gcc-5.3.0.ebuild

Что из него надо выкатить? Тупо набор строка-строка и «функция»? Это в каких-то пистонячих объектах или как?

Он тоже на питоне, но работает реактивной. Вот его лучше и пилите.

А оно не похерит мне систему, если я им что-то поставлю или сделаю pmaint sync?

Он тоже на питоне, но работает реактивной

Ни одного бенчмарка нагуглить не смог.

Его пилят уже лет 10, а толку пока 0.

Как ни крути, но python и high performance разные вещи.

Тупо набор строка-строка и «функция»?

В существующем недопилке строка-массив, функции интерпритируются libbash

В существующем недопилке строка-массив

Это как?

функции интерпритируются libbash

Ну функции же там только для выполнения ебилда, не?

Насколько я понимаю - у всех, как и у меня - жопа болит только от самого emerge, а то как оно тупит во время самого процесса сбора ебилдов меня мало волнует.

В конечном итоге, для начала, тут баш и не нужен. Можно просто сделать кеширование с интерфейсом через libbash, если он уже есть в emerge.

После чего поглядеть на профит и понять - надо ли оно. Быстрее кеширования libbash всё равно работать не будет.

Оно вообще юзабельное - я могу как-то собрать портеж с либбаш и прикрутить к ней что-то своё? Либо оно уже протухло и не работает?

Это как?

Ключ — строка, значение — массив строк.
Там редкостный говнокод.

я могу как-то собрать портеж с либбаш и прикрутить к ней что-то своё?

Оно не готово, это недопилок.
Не умеет в синтаксис даже bash 3.2 полностью, а на дворе уже 4.*
На тот момент, в 2012 году libbash кряхтя обрабатывал около 60% ебилдов, собственно, все понятно, да?

Я написал мейнтейнеру либбаша на предмет нужно ли оно.
Жду в тред активных разработчиков портажей чтобы пояснили за кэширование и обработку ебилдов, если кто знает — кастаните пожалуйста.

А ещё лучше было не использовать говношелл с самого начала, а юзать что-то полудекларативное типа qml

тогда уже сразу брать nix.

А я и не искал бенчмарки, просто поставил и сравнил.

Мне нужно я извращенец любитель в сишном коде system() на лево и на право дёргать. Но с другой стороны я же дёргаю внешние программы которые что-то делают и валят в топку, а С код чисто для управляющих конструкцийиз лапши if else. Если только всякие переменные окружения менять, но вроде как и так можно без всяких С API. А использовать конструкции баша для обработки данных и встраивать их в скажем сишный код эммм я не представляю зачем.

Я наверно чего-то не понимаю, ты бы примеры кода в шапке привёл где будет видно как оно приносит профит. Или просто пример работы оного.

Ты не понял сути
Она именно в том, чтобы не дергать лишний раз системные вызовы, когда надо, например, распарсить конфиг на баше и сделать простенькую интерпретацию.
Один-два вызова system() еще можно пережить, но если их тысячи — это серьезная проблема.

Ааа. Тоесть например есть такая кукарача

URL="http://example.com/"
PAGE="index.html"

#тут блалала много всякого gpep/pdw/curl/get/etc

GRAND_URL=$URL+$PAGE+$PARAMPAMPAM
DATA=`GET $GRAND_URL`

А там можно будет например получить значение DATA в char[] Типа

char * str;

//тут загружаем и интерпритируем бла бла

str = get_val_string("$DATA"); //а тут получаем значение одной из переменных в выполненном скрипте в виде указателя на строку к примеру

Ключ — строка, значение — массив строк.

А как переменная может быть массивом строк? Или что-то типа «x86 amd64 mips ppc ppc64 arm ia64» - оно переделывает в массив строк?

На тот момент, в 2012 году libbash кряхтя обрабатывал около 60% ебилдов, собственно, все понятно, да?

Мне и не надо, чтобы оно обрабатывало.

Насколько я понимаю оно работает как-то так: где-то в портеже вставлен вызов этого либбаш libbash(file.ebuild), а после либбаш выдаёт этот самый список {строка, массив строк}.

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

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

Да, вроде того

А как переменная может быть массивом строк?

Это не ко мне вопрос, я бы вообще делал через discriminated unions

где-то в портеже вставлен вызов этого либбаш

В портеже ничего нигде еще не вставлено, он не использует libbash, именно потому что недопилок

Тогда, нужно.

Bump: Добавил переписку с девом генты

Его пилят уже лет 10, а толку пока 0.

Потому что пилят его 2 человека и те - только когда оно им надо. Но к слову именно разработки pkgcore в плане расчета зависимостей были включены в portage ВМЕСТО того ада, что там был, что сильно повысило скорость расчета зависимостей в определенных случаях.

Было еще хуже, когда это?

В общем еще одна из проблем форка portage/опенсорца - поддерживать некому.

Вот реально - проще мучатся с portage, чем переписать его...

Я б сперва провел таки подробные бенчмарки и выяснил что именно «тормозит».

Проще допилить pkgcore.

тогда уже сразу брать nix.

И он тоже «реактивный, потому что нифига не умеет».

Проще допилить pkgcore.

Проще учесть текущие недостатки а главное их причины и с оглядкой на них дропнув всякую совместимость с текущими ebuild-ами сделать всё по новой.

Так ведь давно выяснили, что портаж тормозит не из-за I/O или вызовов баша, а из-за алгоритма разрешения зависимостей, который, во-первых, не параллелится, во-вторых, учитывает очень много нюансов из новых EAPI.

из-за алгоритма разрешения зависимостей

А почему этот самый алгоритм из прототипа на пистоне не превратят во что-то вменяемое на нормальном ЯП?

А почему этот самый алгоритм из прототипа на пистоне не превратят во что-то вменяемое на нормальном ЯП?

А зачем?

Было мне откровение, что portage не нужно, а будущее за NixOS.