» FreeArc (часть 4)

Цитата:

m7rep

на этот параметр ругается чего-то арк...

Цитата:

У меня при подключении lzma x64 перестал работать метод 4x4:lzma

ага, я знаю об этой проблеме


Цитата:

rep больше 2047mb не ставится. Пишет про нехватку памяти. Это потолок

ага


Цитата:

После подключения lzma64 в свойствах созданных архивов пишет: память для распаковки 8Мб, память бля упаковки 8 мб.

это особенность всех внешних архиваторов, но кому в голову придёт читать документацию?


Цитата:

ФА часто начал падать с такой ошибкой

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


Цитата:

precompz     = precompj:t+z

подтверждаю что не работает, щас разберусь

-m7rep
?

Довольно давно пользуюсь ФА. И все это время меня смущала закладка "сжатия", а именно то что она в основном дублировала функции из других закладок. Я решил ее немного усовершенствовать, подогнать под свои нужды. Строго не судите потому что рисовал в Paintи.

Что скажете? Не лучше оригинала?

Цитата:

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

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


Цитата:

это особенность всех внешних архиваторов, но кому в голову придёт читать документацию?

но предыдущая версия программы показывала нормальные данные!

alexseb2007
читай внимательно:

Цитата:

-m7rep+xlzma:16m:h64m:max (что полностью записывается как
-mrep:512mb+4x4:lzma:16mb:h64m:normal:bt4:128)

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



Цитата:

В стандартном варианете –mex7 деление на группы при сжатии, видимо уменьшает эффективность использования rep! Мне кажется, что деление на группы эффективно только на очень больших объемах данных?!

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

методы -mex5..9 сделаны как раз для разных объёмов памяти. т.е. если тебе не нравится mex7 - используй mex8 и т.д.

Добавлено:
vasulpr
только ручными настройками. после чего тебе для распаковки нужен будет srep в путях и достаточное место под временные файлы

vasulpr
ну тогда сам разбирайся - какие опции/методы сжатия приводят к ошибке, что происходит при повторении той же команды с которой был сбой

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

Цитата:

я не психотерапевт, но вам то зачем "увеличения числа машин, на которых можно распаковать .arc" ?

ну, большой автомобиль я пока не могу себе позволить

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


Цитата:

Юзеров фраза "поддерживает 49 форматов" вводят в состояние мистического транса.

ну напишем 58.5, трудно что ли. одних только переименованных zip, я уверен, не меньше


Цитата:

Unicode для архивов, многотомность

а в 7z.dll чего-то из этого нет?

vasulpr
глас народа - глас божий. ты нарисовал чего тебе не хватает, если другие считают также - добавлю

высказывайтесь

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

а как фриарк включить в скрипт?

В последней версии от 12 августа обнаружил следующее.
Если из проводника выделить архив и из контекстного меню выбрать "Протестировать", то после окончания ничего не выводиться. То ли нет ошибок, то ли завис на 100%.

Цитата:

vasulpr
ты нарисовал чего тебе не хватает, если другие считают также - добавлю

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

xanloz
На шапку взгляните:
Цитата:

Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах

Цитата:

предыдущая версия программы показывала нормальные данные!

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

Bulat_Ziganshin
а что мешает в 7z Павлова добавить поддержку формата arc (просто открытие и распаковка, как rar)

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

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

freearc по-умолчанию пытается сжимать файлы открытые уже для записи
в 7z z для этого есть опция -ssw
если пытаться сжимать так:
arc a -t7z -m1 archive files
то сжимаются не все файлы
когда как без опции -t все ок
что можно сделать для решения этой проблемы?
использовать 7z?

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

Bulat_Ziganshin

Цитата:

методы -mex5..9 сделаны как раз для разных объёмов памяти. т.е. если тебе не нравится mex7 - используй mex8 и т.д.

Хотел выяснить Ваше отношение к возникающей здесь проблеме.

Во времена 32-разрядных ОС и одноядерных процессоров все было просто - больше словарь - лучше сжатие.
Но сейчас времена изменились - широко используются многоядерные процессоры.
А доступный объем памяти в 32-разрядных ОС остался на уровне 2 ГБ (Ну 3 ГБ, в специфических случаях).
Поэтому эффективное использование, скажем 4-х ядерных (поточных) процессоров возможно только до предела, когда каждый поток занимает 400 МБ (=2 ГБ - нужды системы/4). При дальнейшем увеличении словаря, для потока нужно больше памяти и приходится уменьшать число потоков до 2 (или 1).

Вот она дилемма:
Или многопоточность (эффективность) <-> или сильное сжатие, но при слабом использовании процессора!!!
В том же -mex9 идет уже только 2 потока! И время резко увеличивается.

Может ли эта проблема быть решена в 64-разрядных ОС? Там для одной задачи все равно ограничение памяти 2 ГБ.
Слышал, что в 64-разрядной 7zip размер словаря увеличен по сравнению с 32-х разрядной.

Цитата:

ФА часто начал падать с такой ошибкой: read: invalid argument (Bud file descriptor), после чего выскакивает окно виндовс о завершении работы программы

Подтверждаю. Вот видео и сам набор файлов: http://rghost.ru/39804078

Цитата:

а что мешает в 7z Павлова добавить поддержку формата arc (просто открытие и распаковка, как rar)

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

а стратегически - да. поддержка fa через 7z.dll сделает элементарным его добавление в winrar, winzip и т.д. а в прогах типа haozip он просто автоматом появится. возможно, мне следует перенести приоритеты в эту сторону

Цитата:

Подтверждаю

у меня этот каталог нормально сжимается с -m=lzma. посмотри, может у тебя ещё какие опции стоят или arc.ini не дефолтный


Цитата:

что можно сделать для решения этой проблемы?
использовать 7z?

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

я не знаю как фриарк включить в скрипт мож кто-нибудь поможет?

во исполнение идеи vasulpr сделал пока следующее:



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

что туда ещё добавить? мои мысли:

- галочка "расшифровать метод сжатия", превращающая -m4 в -mrep.../$obj=..... - ну в общем ясно
- lc/-ld
- галочки для включения srep, precomp (с подгалочками для -t-j и slow) и dispack
- на этом мысль останавливается...

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

Цитата:

--- Disable filter/group
1509 rep=Finds repetitions on distances up to 1gb, improving compression ratio on multi-gigabyte datasets up to 10-30%
1510 exe=Improves compression of x86 executables up to 10%
1511 delta=Transforms binary data tables, improving compression ratio on executables up to 2-4%, on databases/mailbases - up to 10%
1512 dict=Replaces highly-repeatable words with short codes, improving compression ratio on texts
1513 lzp=Collapses repetitions, improving compression ratio on texts and especially logfiles
1514 $text=Advanced compression for plain text files
1515 $wav=Advanced compression for uncompressed audio wave files
1516 $bmp=Advanced compression for uncompressed bitmap graphic files
1517 $compressed=Quick-and-dirty compression for already compressed files, improving overall speed/compression ratio

Жду от вас предложений по улучшению этих тултипов

Bulat_Ziganshin
понятно. а вот например в arc можно передавать еще такие типы:
xz/wim/gzip/bzip2/tar
они видимо как-то 7z.dll отлавливаются
(ну соответственно и свои ограничения для xz/gzip/bzip2 в 1 файл)
это вообще кто либо замечал? ))

Bulat_Ziganshin

Цитата:

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

Идея понятна.
Но у меня, что на работе, что дома, ВСЕГДА без деления на группы получается лучше. И пока ни разу - наоборот! Что меня очень удивляет!
Вы не пробовали проверить и сравнить мой альтернативный вариант на своих данных?

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

Bulat_Ziganshin
несколько вопросов по GUI:
1. В окне Freearc выделяю файл, например, price.xls --> Упаковать - в строке "Выходной архив": price.arc

Отмечаю опцию "Сделать ЕХЕ" --> "Выходной архив" так и остается price.arc
Это возможно исправить?
(7-zip и WinRAR меняют расширение 7z -->exe и rar-->exe корректно)

2. При создании нового архива и нажатии в строке "Сжатие" на кнопку "..." выставляем, например, "Уровень сажатия" - Максимальное , отмечаем галочку "precomp" и нажимаем "Ок". ---- Строка сжатия поменялась на Максимальное: -mx -mc$default,$obj:+precomp.
Если, не начиная Упаковки (не нажать на Ок. диалога упаковки), снова зайти по кнопке "..." ) - видим что "Уровень сжатия" - Нормальное и галочка "precomp" не отмечена ------> нажимаем Ок - но Строка сжатия так и осталась Максимальное: -mx -mc$default,$obj:+precomp

Почему первый вариант установок имеет приоритет над вторым или почему не применились опции второго варианта и не поменялась срока сжатия?

Bulat_Ziganshin
незнаю
GUI конечно круто
но лично я вообще просто вбиваю нужный тип цепочки методов в поле сжатие и все (когда CUI не пользуюсь)
если для каждой утилиты делать галочки, то может для утилит с большим разнообразием опций просто сделать поле ввода этих параметров

кстати а можно для CUI сделать в заголовке или где то еще чтобы также как в GUI скорость сжатия отображалась

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

Цитата:

arc.ini не дефолтный

Ну да. Добавлено содержание arc-lzma-x64-filter.ini. На lzma x32 таких выкрутасов никогда не замечал. Такую ошибку выдает только lzma x64. Но т.к. методом -m=lzma я не пакую, а -mx сжимает этот каталог без проблем, то для меня эта ошибка не критична.

Добавлено:
ruduk

Цитата:

Отмечаю опцию "Сделать ЕХЕ" --> "Выходной архив" так и остается price.arc

Какой в этом смысл, главное результат. После упаковки архив всегда будет exe а не arc если поставил галочку "Сделать ЕХЕ"

kalpak

Цитата:

можно для CUI сделать в заголовке или где то еще чтобы также как в GUI скорость сжатия отображалась

Не только в CLI, но и вообще, нет насущного смыла в отображении моментальной "скорости сжатия": для разных файлов , разных размеров будет разная скорость сжатия.
От наличия "отображения скорости" мало что изменится. А уж если просить, так просите ещё и отображение потребляемой памяти, процессорного времени, отображении дисковой активности как на память так и на запись.
Для этого есть "монитор ресурсов" и Process Explorer.

В прогресс-баре есть смысл (обратная связь (в частности с пользователем ) зачастую полезна), но его бессмысленно просить - он уже есть.

Какой исходный объем и сжатый?