LINUX.ORG.RU

Pijul 0.11

 , , ,


3

6

Вышла новая версия Pijul — свободной системы управления версиями, основанной на теории патчей и написанной на языке Rust.

Pijul развивает идеи Darcs — Pijul быстрее, лучше, в нём решена проблема экспоненциальной сложности слияния и поддерживаются ветки (для всех, кто спросил и еще спросит «чем оно лучше Git» - ссылка на FAQ)

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

Улучшения в версии 0.11:

  • Добавлено частичное клонирование подкаталогов: pijul clone --path и pijul pull --path. При этом скачиваются только те патчи, которые затрагивают указанный подкаталог.
  • Добавлен парсер ~/.ssh/config — теперь Pijul будет автоматически использовать настройки псевдонимов хостов, SSH-прокси, ключей и т. д.
  • Внутренняя архитектура переведена на использование библиотеки Tokio — де-факто стандарта для асинхронного программирования на языке Rust. Минус велосипеды, новичкам будет проще разобраться в коде Pijul.
  • Исправлено много мелких и две крупные ошибки. Одна из них приводила к падению производительности при использовании pijul record, другая в некоторых случаях приводила к изменении содержимого патчей и файлов после клонирования.

Для нужд Pijul автором также развиваются вспомогательные библиотеки:

  • Thrussh — реализация клиента и сервера SSH на языке Rust.
  • Pleingres — клиентская библиотека, реализующая сетевой протокол PostgreSQL на языке Rust.
  • Sanakirja — хранилище «ключ-значение» на языке Rust, основанное на B-деревьях и поддерживающее транзации (аналог LMDB). «Sanakirja» по-фински означает «словарь».

Автор также разрабатывает Pijul Nest — аналог GitHub на основе Pijul и Rust. К сожалению, Nest пока не является свободным проектом.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: tailgunner (всего исправлений: 4)

Ответ на: комментарий от tailgunner

А кот-то спорит с ненужностью индекса?

anonymous
()
Ответ на: комментарий от anonymous

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

Наоборот, всегда можно сделать --amend. А ещё лучше — накатить поверх ещё один коммит, а потом, когда всё хорошо, squash-нуть их вместе.

Индекс хорош хотя бы тем, что заставляет остановиться и еще раз рассмотреть что же ты собрался коммитить.

Так при коммите в любом случае смотришь, что коммитишь.

Да и странно это — заставлять всех совершать лишнюю работу только для того, чтобы дурак остановился и подумал... А то так можно и до абсурда дойти: сделать 7 индексов, и у каждого свои команды, чтобы наверняка остановиться и 7 раз подумать...

Нормальные разрабы наоборот индекс оценили. А где сейчас остальные VCS мы все видим (хинт: в районе помойки).

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

Если бы индекс был так нужен, то он был бы и во всех остальных VCS. Вместо этого что-то похожее есть только в меркуриал (mq, это даже круче, чем индекс). Но и там это опциональное расширение из серии «универсальный костыль на все случаи жизни», а каждая конкретная задача там решается без mq.

Так что, да, другие разрабы индекс оценили, и оценку поставили невысокую.

anonymous
()
Ответ на: комментарий от dave

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

Наконец-то кто-то высказал здравую мысль, а не простую копипасту про ненужность.

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

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

Как ни странно, на одиннадцатой странице треда про Rust и VCS по-прежнему обсуждаются Rust и VCS!

Неужели лор повзрослел?

Вряд ли, скорее слепой рэндом.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Partisan

Что-то работающее, а именно Hello World написать одинаково легко. Что-то полезное на Haskell написать трудно. До сих пор никому это не удалось.

xmonad это привет миру?

NextGenenration ★★
()
Ответ на: комментарий от dave

Приму за факт, что неизвестно у кого, в неизвестно каком году, на неизвестно каком железе, языке и платформе, были какие-то страшные проблемы с GC... Постой-ка, а где же тут наскрести информации на факт, собственно? Ну ладно, не отвечай :)

Crocodoom ★★★★★
()
Ответ на: комментарий от anonymous

Так что, да, другие разрабы индекс оценили, и оценку поставили невысокую.

Git-индекс - идея убогая, но коммит частями - идея отличная.

tailgunner ★★★★★
()
Ответ на: комментарий от NextGenenration

Ну сравнил. Забыть free или синхронизацию против покопать в доках и найти единственную опасную функцию и ее вызвать

vertexua ★★★★★
()
Ответ на: комментарий от tailgunner

Git-индекс - идея убогая, но коммит частями - идея отличная.

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

O02eg ★★★★★
()
Ответ на: комментарий от dave

О паузах stop-the-world, которые порой длятся десятками секунд.

Очень специфические обстоятельства. Далеко не всегда так.

NextGenenration ★★
()
Ответ на: комментарий от anonymous

Это, как mldonkey, исключение, подтверждающее правило.

И сколько нужно исключений, чтобы отказаться от правила?

NextGenenration ★★
()
Ответ на: комментарий от vertexua

Ну сравнил. Забыть free или синхронизацию против покопать в доках и найти единственную опасную функцию и ее вызвать

Это не единственная функция. Так же в статье упоминались указатели с подсчётом ссылок. А если есть подсчёт ссылок, то это либо необходимость работать со слабыми умными указателями, не участвующими в подсчёте ссылок, постоянно проверяя не сломается ли где-то логика, либо объекты становятся неизменяемыми и при каждой необходимости пересоздаются.

Абстрактный пример. Есть у меня какое-то дерево, к примеру ast. Или не дерево. И мне его нужно поменять. Я не могу в безопасном коде одновременно иметь несколько изменяемых переменных. Насколько я знаю нет возможности забрать владение данными прямо из существующего листа, чтобы потом спустя некоторое время заменить этот лист.

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

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

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

Твои представления о «безопасном коде» - нечто среднее между мифом и фантазией.

а чем создание дерева с нуля каждый раз лучше языков со сборкой мусора?

В контексте Rust этот вопрос не имеет смыла. Никто не пересоздает деревья при каждом изменении.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Твои представления о «безопасном коде» - нечто среднее между мифом и фантазией.

И как будет это выглядеть в реальности? Разумеется речь идёт о rust

NextGenenration ★★
()
Последнее исправление: NextGenenration (всего исправлений: 1)
Ответ на: комментарий от tailgunner

В контексте Rust этот вопрос не имеет смыла. Никто не пересоздает деревья при каждом изменении.

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

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

И как будет это выглядеть в реальности?

За тебя набрать в гугле «rust tree example»? Вот как оно выглядит в лоб: https://rust-leipzig.github.io/architecture/2016/12/20/idiomatic-trees-in-rust/

Но похоже, что в последнее время народ склоняется к GenerationalIndexes: https://kyren.github.io/rustconf_2018_slides/index.html

а чем создание дерева с нуля каждый раз лучше языков со сборкой мусора?

В контексте Rust этот вопрос не имеет смыла.

Это имеет смысл в случае неизменяемых объектов.

Может быть. Но ты спрашивал именно об изменяемом.

tailgunner ★★★★★
()
Ответ на: комментарий от NextGenenration

И объект висит в памяти до конца времён программы. Идеально.

Почему вдруг?

https://habr.com/post/281370/

Это как раз не ответ на вопрос совсем. Тебе говорят что сборщик мусора во время компиляции работает. Мусор освобождается статически. Ты написал что нет. На требование обосновать ты приводишь статью в которой программист явно указывает не освобождать что-то.

Давай другой аргумент, или признавай что «И объект висит в памяти до конца времён программы. Идеально.» - чушь.

vlad9486
()
Ответ на: комментарий от NextGenenration

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

Можешь. Ты не можешь иметь несколько «хардварных» быстрых изменяемых ссылок на те самые данные.

Наверное я не понял пример. Но зачем тебе несколько меняя ветку дерева?

vlad9486
()
Ответ на: комментарий от vlad9486

Тебе говорят что сборщик мусора во время компиляции работает. Мусор освобождается статически. Ты написал что нет.

Правильно написал. Что такое вообще «сборщик мусора во время компиляции»? Нет никакого сборщика мусора, ни во время компиляции, ни после. Компилятор всего лишь проверяет (когда может, а может он не всегда), что память освобождается.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Спасибо за замечания, но я более-менее знаю это. Мои слова - вольный пересказ того, что было написано еще выше. Если бы я писал тебе, то подобрал бы более точные формулировки.

vlad9486
()
Ответ на: комментарий от vlad9486

Наверное я не понял пример. Но зачем тебе несколько меняя ветку дерева?

Поворот дерева, например.

kirk_johnson ★☆
()
Ответ на: комментарий от tailgunner

Вот как оно выглядит в лоб: https://rust-leipzig.github.io/architecture/2016/12/20/idiomatic-trees-in-rust/

previous: Rc<RefCell<Box<Node<T>>>>

Не спасибо за очевидное

pub struct Arena<T> {
    nodes: Vec<Node<T>>,
}

pub struct Node<T> {
    parent: Option<NodeId>,
    previous_sibling: Option<NodeId>,
    next_sibling: Option<NodeId>,
    first_child: Option<NodeId>,
    last_child: Option<NodeId>,

    /// The actual data which will be stored within the tree
    pub data: T,
}

pub struct NodeId {
    index: usize,
}
Костыль. По сути это переизобретение сборщика мусора одновременно с указателями в лучших традициях си/крестов унаследовавший минусы двух этих подходов. От указателей: придётся самому писать код, который будет чистить этот вектор. Плюс ещё нужно каким-то образом гарантировать доставерность индексов. Заодно теперь этот вектор становится чуть глобальной переменной в лучших традициях языков типа php. От сборщика мусора: теперь интеграция с другим языком будет не такой-то уж и простой. Придётся останавливать мир на время сборки мусора.

Так же надо будет подумать о дефрагменатции индексов, если предполагается удаление элементов. Красота.

Но похоже, что в последнее время народ склоняется к GenerationalIndexes: https://kyren.github.io/rustconf_2018_slides/index.html

Кто-то собрал библиотеку по данному принципу?

NextGenenration ★★
()
Ответ на: комментарий от vlad9486

Тебе говорят что сборщик мусора во время компиляции работает.

Во время компиляции собирать ещё нечего.

На требование обосновать ты приводишь статью в которой программист явно указывает не освобождать что-то.

Использование случайно зациклившегося указателя с подсчётом ссылки - явно? Случайная блокировка потоков - явно?

NextGenenration ★★
()
Ответ на: комментарий от kirk_johnson

Можешь, в Rust есть Arc и Rc.

Про подсчёт ссылок я писал отдельно. Можно случайно зациклить. И героические усилия для предотвращения этого.

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

По сути это переизобретение сборщика мусора одновременно с указателями в лучших традициях си/крестов унаследовавший минусы двух этих подходов.

А ты быстрый. Час назад ты вообще не знал, как это делается, но уже всё понял, проанализировал и вынес вердикт.

Кто-то собрал библиотеку по данному принципу?

Да какая разница. Тоже ведь «по сути переизобретение сборщика мусора» (ц).

tailgunner ★★★★★
()
Ответ на: комментарий от vlad9486

Можешь. Ты не можешь иметь несколько «хардварных» быстрых изменяемых ссылок на те самые данные.

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

Наверное я не понял пример. Но зачем тебе несколько меняя ветку дерева?

Одна функция рекурсивно обходит дерево и ищет места которые надо поменять и возвращает их список. Вторая функция меняет эти места.

NextGenenration ★★
()
Ответ на: комментарий от tailgunner

Сложна. Я пока использую RcTree и не парюсь.

Тем более не ясно как оно скажется на производительности, если дерево нужно постоянно менять. Вставка/Удаление в вектор не бесплатные.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от tailgunner

А ты быстрый. Час назад ты вообще не знал, как это делается, но уже всё понял, проанализировал и вынес вердикт.

Долго ли умеючи?

Да какая разница. Тоже ведь «по сути переизобретение сборщика мусора» (ц).

Контраргументы закончились? Мне реально интересно, во сколько строк выльется решение описанных мною проблем.

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

Про подсчёт ссылок я писал отдельно. Можно случайно зациклить. И героические усилия для предотвращения этого.

То есть все-таки можешь?

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от NextGenenration

Долго ли умеючи?

«Умеючи - долго» (ц)

Да какая разница. Тоже ведь «по сути переизобретение сборщика мусора» (ц).

Контраргументы закончились?

Контраргументы - это у тебя. Быстро и много. Мне не угнаться.

tailgunner ★★★★★
()
Ответ на: комментарий от NextGenenration

и возвращает их список

Дорого.

Чем такой код не устраивает (если я правильно понял вопрос):

for mut node in root.descendants() {
    if node.has_attribute("a") {
        node.set_attribute("b", "v");
    }
}

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Насколько я понимаю, GenerationalIndex - это замена Box, обходящая проблему с множественными мутабельными ссылками.

tailgunner ★★★★★
()
Ответ на: комментарий от NextGenenration

Это решает только одну проблему, но не решает других

Это решает проблему с множественными ссылками. Какие еще проблемы есть?

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Тогда релевантная цитата вот:

store objects in a Vec<T> and have them reference each other via their indices. No more borrow checker or ownership problems!

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Дорого.

ИМХО только по памяти

Чем такой код не устраивает (если я правильно понял вопрос):

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

NextGenenration ★★
()
Ответ на: комментарий от kirk_johnson

Это решает проблему с множественными ссылками. Какие еще проблемы есть?

Чуть выше писал про зацикливание. A ссылается на B, B ссылается на A. Что Arc, что Rc считают ссылки.

NextGenenration ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.