» FreeArc (часть 4)

Bulat_Ziganshin
c i/o можно будет ли в будущем работать? а то на последней FreeArc-LZMA.exe жуткие лаги

Fossius,
консоль рулит.

Цитата:

Возможно ли такое реализовать?

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


Цитата:

Причем, насколько я понимаю, причина не в основном методе rep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128
- он "сравнительно" быстр, а в сжатии текстовых файлов

ты не можешь проверить это предположение? разбить свои файлы на текстовые и бинарные и сжать эти группы по отдельности

скорость бинарного сжатия для mex5 и выше (как и для линейки m5 и выше) практически одинакова - разница между ними только в размере словаря


Цитата:

на других файлах тоже бывает выскакивает ошибка - я выкладывал логи.

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

Цитата:

рискуешь не дожить до пенсионного возраста

Это же очень хорошо! какая жизнь то на пенсии, от этого унылого государства, быть может?

Добавлено:

Цитата:

но ехидствовать

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

Bulat_Ziganshin

Цитата:

настройки программы

В ПМ.

Цитата:

у тебя аплоад ограничен?

Нет. В архиве файлы ~8гб занимают - могу выложить, порезав на куски, на обменник (займёт какое-то время...) или если есть фтп, то залью на него (если канал широкий, то залью быстро).

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

Бесконечно благодарен автору, и желаю многоуважаемому Булату Зиганшину личного творческого долголетия и всяческих успехов в развитии FreeArc`а в удовольствие пользователям!

Bulat_Ziganshin

Цитата:

ты не можешь проверить это предположение? разбить свои файлы на текстовые и бинарные и сжать эти группы по отдельности

Удобнее было бы выкладывать данные (xls) не в форуме, а по e-mail.
Мне много что есть написать.

Добавлено:
Bulat_Ziganshin

Взял enwik8 (100 000 000 байт):
Метод Сжатие текста Размер Время, с

Snoopak96
какое i/o, какие лаги???

завтра надеюсь сделать ftp-аплоад на своём сервере

Добавлено:
Shuld
и какие выводы?

Добавлено:
WildGoblin
а ещё можно через uTorrent 3.x передать. там специальный дропбокс есть. у меня белый адрес

нужен точный набор файлов, на котором обнаруживается сбой, и твой каталог "program files\freearc" - чтоб уж точно воспроизвести условия сжатия

Bulat_Ziganshin
Если допустим в arc.ini lzma прицеплен так:

Код:
[External compressor:lzma]
header = 0
packcmd = FreeArc-LZMA-x64 e lzma{:option} <stdin> <stdout>
unpackcmd = FreeArc-LZMA-x64 d lzma{:option} <stdin> <stdout>

Bulat_Ziganshin

Цитата:

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

рад это слышать!
если можно то поделитесь более подробной информацией по этому поводу.
это будет абсолютно новый формат не совместим с предыдущим? в какой версии мы сможем увидеть эти изменения?
также хочется узнать как дела с 0.70 финал, что еще планируется сделать?

Цитата:

А меня, например, ни чуть не смущает условная нумерация версий этого замечательного архиватора.

Дело не в нумерации, а в функционале. Был бы нормальный гуи с drag'n'drop, уже было бы значительно лучше, и кстати способствовало бы широкому распостранению архиватора. Булат, может напишешь в чём загвоздка? А мы чем сможем тем поможем.

Bulat_Ziganshin
Завтра могу всё выложить.

Цитата:

а ещё можно через uTorrent 3.x передать. там специальный дропбокс есть. у меня белый адрес

Можно и так.

Bulat_Ziganshin

Цитата:

и какие выводы?

При сжатии текстовых файлов, при переходе от -m4 к -mex5 наблюдается большой скачек в затрачиваемом времени, и далее до -mex9 одинаковый результат.
Нет плавного изменения времени и сжатия, как для методов -m1...-m4.

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

Добавлено:
а при методе -lc- -max: ОШИБКА: ошибка (рас)паковки в pmm:24:1600mb

1. Скачиваем архив - 20 Мб
2. Распаковываем.
3. Выделяем все архивы и выбираем Extract Here.
4. Появляется окошко о подтверждении перезаписи существующего файла, жму Yes to All
5. Окошко продолжает появляться на всех файлах.

Ежели выбрать Extract... и указать Overwrite without prompt то больее никаких подтверждений не требуется.
7z срабатывает коректно.

Детектив
С ног на голову
В котором принять участие может каждый.

Глава 1. Введение
Ранее я предлагал методы –m81 и –m82 для быстрого сжатия большого объема информации: http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1100#10
Можно было продолжить работу и сделать методы –m83 и далее, но мне казалась, что в этом мало смысла. Скорее «для галочки», чем для дела я все-таки довел линейку до –m88. В этой нумерации первая цифра 8 означает использование 8rep или rep:1g, а вторая – примерное соответствие «стандартному» методу с моей поправкой на «оптимизацию». Т.е. метод –m86 является примерным аналогом –mex6. Скачать файл arc.ini с методами –m81…-m88 в архиве можно здесь: Скачать arc2012-01-25.zip с WebFile.RU, и заменить стандартный в папке с arc.exe. (Все методы проверялись на компьютере с 4-поточным процессором, часть – на 2-х ядерном, как поведет себя на 8-ми ядерном – не знаю).

Глава 2. Завязка
Важным моментом является то, что в методах –m81…-m88 нет деления на группы файлов. Казалось, что это должно привести к ухудшению по сравнению со «стандартными» методами, использующими специализированные методы для различных групп файлов. И вот тут-то начинаются чудеса!

Глава 3. Что лучше?
Наиболее корректно проводить сравнение на методах –m88 и –mex8, поскольку у них одинаковый rep и одинаковый основной метод сжатия lzma:32m. Разница именно в отсутствии/наличии деления на группы файлов.
Я протестировал многие папки на своем компьютере и результаты (без купюр!) выкладываю далее, в порядке увеличения размера испытуемой папки. Все папки не какие-то условные, а мои рабочие, для которых я делаю резервные копии.
Метод Размер, байт Время, с

Цитата:

а при методе -lc- -max: ОШИБКА: ошибка (рас)паковки в pmm:24:1600mb

а что означает опция -lc-?


Цитата:

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

так он в конце концов их пакует?


Цитата:

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

и для бинарных та же фигня. у тебя есть идеи как сделать лучше?


Цитата:

это будет абсолютно новый формат не совместим с предыдущим? в какой версии мы сможем увидеть эти изменения?

да, несовместимый. возможно, 0.80. я собираюсь интегрировать exe или даже dispack+bcj2 в rep

Bulat_Ziganshin

Цитата:

а что означает опция -lc-?

использовать всю оперативку при упаковке.

Цитата:

так он в конце концов их пакует?

нет. специально ждал минут 40. остановился на 2.3%, скорость 0.
ради интереса попробовал упаковать 2 текстовых файла 1 и 5 мб параметром -max, снова скорость 0. по одиночке упаковываются сразу.

Цитата:

использовать всю оперативку при упаковке.

в документации посмотри


Цитата:

ради интереса попробовал упаковать 2 текстовых файла 1 и 5 мб параметром -max, снова скорость 0.

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

забавно. ну опять же - архивируй целиком папку с архиватором и присылай мне

Bulat_Ziganshin

Цитата:

архивируй целиком папку с архиватором и присылай мне

http://upwap.ru/1983711
вопрос снимаю, переустановил и проблема изчезла.

Paramon111
я тебе советую ещё и power pack поставить - без него -max аналогичен -mx. кстати, он будет нужен и при распаковке

Цитата:

да, несовместимый. возможно, 0.80. я собираюсь интегрировать exe или даже dispack+bcj2 в rep

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

Будете ли вы интегрировать в основной алгоритм PackJPG и TTA 2.0? И будет ли возможность создавать многотомные архивы?

также хочется узнать как дела с 0.70 финал, что еще планируется сделать, в чем задержка?

Bulat_Ziganshin

Цитата:

я тебе советую ещё и power pack поставить

где его скачать и как правильно установить?

Bulat_Ziganshin

Цитата:

нужен точный набор файлов, на котором обнаруживается сбой, и твой каталог "program files\freearc" - чтоб уж точно воспроизвести условия сжатия

Файлы ещё нужны? Они у меня висят на раздаче.
Скачались? Убираю раздачу?

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

Цитата:

3. Выделяем все архивы и выбираем Extract Here.
4. Появляется окошко о подтверждении перезаписи существующего файла, жму Yes to  All
5. Окошко продолжает появляться на всех файлах.

при этом выполняется команда "arc x 1.zip ; x 2.zip ...", а fa "yes to all" трактует All только до конца текущей подкоманды. согласен, что здесь это неправильно. вопрос в том, как это лучше поправить

Bulat_Ziganshin
поторопился я. версия 0.666 упаковывакт с параметром -max, а версия 0.67 не хочет по прежнему. ну на нет и суда нет, буду паковать -mx.

Paramon111

Цитата:

где его скачать и как правильно установить?

http://freearc.org/ru/Download.aspx
Последний в табличке.
-max пакует, используя этот ПауэрПак.

Добавлено:
Bulat_Ziganshin

Цитата:

и для бинарных та же фигня. у тебя есть идеи как сделать лучше?

Вариантов много. Смотря какие цели ставить.
Например:
Метод Основной Текст

Shuld
я понял в чем дело. если упаковка архива останавливается, заходим в диспетчер задач и завершаем процесс precomp04.exe после этого архив сдвигается с мертвой точки и упаковка возобновляется. вот видеоскрин: http://upwap.ru/1984357

Цитата:

Скачались? Убираю раздачу?

убирай


Цитата:

также хочется узнать как дела с 0.70 финал, что еще планируется сделать, в чем задержка?

xlzma requires 2.5 gb on 2gb box: let limit_memory num method = return method -- ограничение памяти для метода используется только при сжатии
не установлена галка "ассоциировать с другими архивами", он все равно ассоциирует (при установке с нуля отключены оба ассоциирования!)
zipx compression
rep+tor => Decompression error -9! (fix in multi_de_compress?) - может проявиться в unarc.exe/sfxes!
"a a.zip" и "a a -tzip" должны работать как "a a.zip -tzip"
при прерывании сжатия в zip остаётся временный архив
при открытии zip с 250 тысячами файлов тормозит 10 минут
lzma.exe - проверить что решены проблемы с неполным чтением/записью буфера
external compressors stdin+stdout: http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=500#7
fread/fwrite => FullRead/Write (в lzma и Example-C)
CreateProcess with STARTUPINFO with hStdInput, hStdOutput and hStdError handles set to file handles you opened (either real files or memory mapped files should work).
stdinout.cpp
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499(v=VS.85).aspx
4x4:lzma-x64: может, проблема в compress_all_at_once?
английский unarc-dll\readme.txt
improved tooltips 1125, 1227, 1176
* "Open .tar.gz and similar archives in one step" is broken (tested on .tar.bz2 and .tar.gz).
* "Up" button in filelist could have some icon (something like: )
выбираем несколько архивов - Extract Here - Overwrite? - Yes to All



Цитата:

Будете ли вы интегрировать в основной алгоритм PackJPG и TTA 2.0? И будет ли возможность создавать многотомные архивы?

tta уже есть. PackJPG пока особо не стремлюсь, может кто другой сделает. многотомные - в 0.80 запланированы


Цитата:

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

дело в том, что srep имеет недостатки в сравнении с rep, поэтому я хочу оставить текущее положение дел, когда он цепляется только как внешний алгоритм для nt[> кому очень нужно, а внутри fa заменить rep на его продвинутый вариант, имеющий некоторые преимущества srep, но ни одного из его недостатков

Bulat_Ziganshin
спасибо за ответ!
судя по запланированному 0.70 мы до конца зимы не увидим.