» FreeArc (часть 4)

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

http://i.imgur.com/3Q8XP.png
http://i.imgur.com/RNy7W.png
http://i.imgur.com/aJMoj.png


1. Возможность скрывать тулбар
2. Отказ от иконок в меню "Файл": в современных приложениях их уже давно нет.
3. Кнопка "Обновить" возде адресс-бара, а не на тулбаре.
4. [..] в качестве "Вверх".
5. Реализация базовых команд проводника: копировать, вставить и т.д.
6. Мы все ждем контекстное меню

Цитата:

я начинаю подготовку к выпуску 0.70.

новость супер! вот ещё бы 64-битную версию под Лин
(необязательно использующую все преимущества 64 бит,
хотя бы просто кросс-сборку, которая запускается )

Shuld
я вставил bsd-лицензированный код, реализующий только режим -c0

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

2. имхо с иконками лучше. какая разница что сейчас модно

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

Time: 0:00:05 of ~0:00:12
Files: 15 of 70
Bytes: 30,000 of 100,000
Compressed: 12,300 of ~40,700

а твои варианты - думаешь, именно они понятней будут нынешних?

a) kB/s написано потому что K вроде означает 1024, а k - 1000
б) keep window on top скрыто потому что оно нафиг не нужно подавляющему большинству юзеров и потому что я планурю туда добавить больше опций, типа "shutdown after operation"
в) насчёт 2px не понял
г) насчёт Combine вместо Join archives - думаешь понятно будет? а по-русски как перевести?

Булат, как насчёт включения в 0.70 тех быстрых пресетов из соседней темы, а также packarc для jpg/mp3 без precomp ?

Цитата:

Булат, как насчёт включения в 0.70 тех быстрых пресетов из соседней темы, а также packarc для jpg/mp3 без precomp ?

Не все сразу! дайте автору привести в порядок то что есть!

1. Folder --> FreeArc --> Add to acrhive --> High: -m7 -md96m -ld192m
2. Пригнал себез по 3G 470 МБ
3. Распоковать так и не смог

Код:
Arc.Extract.hs:154:56:-126:Non-exautsive patterns in lamda

slech
процессор, версия freearc, arc lt?

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

Bulat_Ziganshin
Хотелось бы сделать примечание по sfx модулю.
Немного подглючивает прогрессбар.

Изображаю в лицах:[more]
Извлекаю sfx архив на "юсб-флешку".



















Прогресс-бар всегда на 99%.
"Remaining time" всегда 1 секунда.
На последнем скриншоте видно что процесс извлечения длится минуту.

На свежескачанной альфе происходит то же самое.
[/more]

Опишу словами:
Дефект: При извлечении неверно работает "прогноз оставшегося времени".
Запрос: Пожалуйста подкорректируйте алгоритм вычисления "предполагаемого оставшегося времени", чтобы "Remaining time" походило на реальное.
Причина: ожидание неизвестности очень дискомфортный процесс (психологический дискомфорт).


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

Еще одно применение FreeArc - в качестве бенчмарка (на запись) юсб-флешек

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

[more] Bulat_Ziganshin
Были такие же ошибки, как и у slech: при упаковке -m7 - can't allocate memory required for de(compresison) in ppdm:12:192mb, use -lc/-ld to limit memory usage . При распаковке с -m5: cделанный архив не распаковывается с Arc.Extract.hs:154:56:-126:Non-exautsive patterns in lamda

Core 2 Duo T5800, последняя альфа, -m5, листинг:

FreeArc 0.67 (August 22 2012) listing archive: rest.bin

Archive type: FreeArc
Total bytes: 23,060,382
Compressed bytes: 4,997,812
Ratio: 21.6%

Directory blocks: 1
Directory, bytes: 1,871
Directory, compressed: 820
Solid blocks: 2
Avg. blocksize: 11 mb

Compression memory: 185 mb
Decompression memory: 23 mb
Dictionary: rep:23mb+lzma:16mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 8 storing
31 23,060,382 4,997,812 62 rep:23mb+exe+delta+lzma:16mb:normal:bt4:128
-----------------------------------------------------------------------------
70 files, 23,060,382 bytes, 4,997,812 compressed
All OK


Ответы к предыдущему посту:

>насчёт надписей в окошке прогресса - у меня появилась идея написать так:
Тоже так хотел, но с выравниванием названий и циферок красивый макет не получался - циферки находлись слишком далеко. Но, если делать в виде "Time: 56:56", без пустого места между ними, может, получится даже лучше.

>а твои варианты - думаешь, именно они понятней будут нынешних?
Ну, я, брал пример с других программ

>a) kB/s написано потому что K вроде означает 1024, а k - 1000
Спасибо, не знал


>б) keep window on top скрыто потому что оно нафиг не нужно подавляющему большинству юзеров и потому что я планурю туда добавить больше опций, типа "shutdown after operation"
Тогда все логично

>в) насчёт 2px не понял
Вниз сдвинуть
[/more]

UbiSergei
залейте исходные данные скажем на rghost. плюс arc.ini/arc.groups. ну и ваш архив заодно тоже

Добавлено:
UbiSergei
вы тот архив который с ppmd - пробовали с -mt1 распаковать?

Bulat_Ziganshin
Понимаю что возможно на это нет времени, просто напоминаю, на случай если Вы забыли:
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=560#5

Суть предложения в том, чтобы была возможность
драг-н-дропнуть на sfx любой *.arc и этот *.arc извлёкся.
Т.е. при запуске sfx.exe анализировал аргумент и "извлекал из него содержимое архива", если это *.arc (или *.exe, но )
(по сути при драг-н дропе запускается sfx.exe тот_файл_который_кинули_на_пиктограмму)

Для чего ? "В среднем по палате" sfx-ы встречаются гораздо чаще чем "полнофункциональный архиватор".

Добавлено:
Bulat_Ziganshin

Цитата:

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

Делать поправку раз в 15 секунд (общий размер "распакованных" файлов/скорость) не вариант ?
Нет, Вам виднее, но мне просто интересно.

Цитата:

slech
процессор, версия freearc, arc lt?

i5-2400
FreeArc 0.67 (August 22 2012)
[more=arc lt]production-bad.arc
FreeArc 0.67 (August 22 2012) listing archive: d:\boot-menu\production-bad.arc

Archive type: FreeArc
Total bytes: 481,536,826
Compressed bytes: 468,998,126
Ratio: 97.3%

Directory blocks: 1
Directory, bytes: 2,354
Directory, compressed: 1,229
Solid blocks: 4
Avg. blocksize: 115 mb

Compression memory: 336 mb
Decompression memory: 352 mb
Dictionary: rep:96mb+xtor:16mb rep:10mb+xlzma:10mb grzip:41kb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 14 storing
31 40,280 10,249 15 grzip:41kb:m1:l32:h15
10,280 471,835,437 464,186,719 13 rep:96mb:96:d4mb:s32+4x4:tor:16mb:c3
464,196,999 9,661,109 4,801,158 30 rep:10mb:96:d4mb:s32+exe+delta+4x4:lzma:10mb:h4mb:normal:24:mc8
-----------------------------------------------------------------------------
72 files, 481,536,826 bytes, 468,998,126 compressed
All OK
[/more]


Добавлено:

Цитата:

исправляется опцией -mt1 при распаковке

Цитата:

arc x -m1 d:\boot-menu\production-bad.arc
FreeArc 0.67 (August 22 2012) extracting archive: d:\boot-menu\production-bad.arc
Extracted 72 files, 468,998,126 => 481,536,826 bytes. Ratio 97.3%
Extraction time: cpu 2.64 secs, real 1.83 secs. Speed 263,826 kB/s
All OK

Спасибо помогло, хотя 500 метров трафика уже сгорело

Цитата:

драг-н-дропнуть на sfx любой *.arc и этот *.arc извлёкся.

я анализировал и нашёл небольшую техническую проблему - синтаксис "sfx.exe filename" сейчас обозначает "извлечь один файл filename из sfx". понятно, что можно его поменять, но может это вызовет какие-либо проблемы? в частности, мне хотелось бы быть совместимым по синтаксису вызова sfx с rar/7zip

а так мне импонирует идея сделать синтаксис вызова sfx точно таким же как у unarc. это и код упростит, и число компилируемых модулей поможет сократить. сейчас посмотрел - rar и 7-zip используют разный синтаксис, но можно поддерживать оба. так что вполне возможно переделаю до выхода 0.70


Цитата:

Делать поправку раз в 15 секунд (общий размер "распакованных" файлов/скорость) не вариант ?

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


Цитата:

вот ещё бы 64-битную версию под Лин

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


Цитата:

необязательно использующую все преимущества 64 бит,  
хотя бы просто кросс-сборку, которая запускается

это как? я так понимаю, что без компиляции в 64 бита тут ничего не поделаешь

Bulat_Ziganshin
arc.ini/arc.groups полностью оригинальные, исходных файлов , к сожалению, на текущей машине нет.

http://rghost.net/39957505
При распаковке с -mt1
ERROR: read error (bad media?) in compression algorithm delta

>вы тот архив который с ppmd - пробовали с -mt1 распаковать?
Тот архив вообще успешно не создался.

Добавлено:
Сделал небольшое расследование:

1. Пакую содержимое архива с -m5 -mc-$text; получаю на выходе rest.arc с размером 5,334,777
2. Еще раз, но просто с -m5 --> rest2.arc 5,058,283
3. Снова с -m5 -mc-$text --> rest3.arc 5,000,626 - не распаковывается

Итого: найден баг с запаковкой!

такой вот общий вопрос (не только о FreeArc мб):
степень сжатия\компрессии уже достигла своего предела или можно что-то улучшить? на данный момент все архиваторы застопорились в этом плане и вся работа ведется над балансировкой процесса: "скорость компрессии\декомпрессии - размер архива"
и по FreeArc конкретно (может уже было но все же спрошу): при распаковке в установщике % распаковки отображается скачками\шагами, а не плавно, это проблема фриарк или скрипта InnoSetup? если сживать LZMA2 или rar в Inno то распаковка идет плавно

я этот архив и после -mx распаковать не могу. интересный набор.

Добавлено:

Цитата:

получаю на выходе rest.arc с размером 5,334,777

у меня 5.334.778 на выходе.

Цитата:

при распаковке в установщике % распаковки отображается скачками\шагами

если сам freearc отображает также - вопрос ко мне, чи ни - то ни

Цитата:

Спасибо помогло, хотя 500 метров трафика уже сгорело

вообще-то -m1 на распаковку никак не должно влиять. я -mt1 советовалю возможно дело было в нехватке свободной памяти из-за лишних dll


Цитата:

1. Пакую содержимое архива с -m5 -mc-$text; получаю на выходе rest.arc с размером 5,334,777  
2. Еще раз, но просто с -m5 --> rest2.arc 5,058,283
3. Снова с -m5 -mc-$text --> rest3.arc 5,000,626 - не распаковывается  

у меня:

I:\1>"C:\!FreeArc\freearc\Tests\Arc.exe" a a -r -t -m5 -mc-$text
Compressed 70 files, 23,060,330 => 5,333,786 bytes. Ratio 23.1%
Compression time: cpu 7.85 secs, real 4.36 secs. Speed 5,288 kB/s
Testing time: cpu 0.31 secs, real 0.36 secs. Speed 63,875 kB/s

I:\1>"C:\!FreeArc\freearc\Tests\Arc.exe" a a -r -t -m5 -mc-$text;
Compressed 70 files, 23,060,330 => 5,057,211 bytes. Ratio 21.9%
Compression time: cpu 7.58 secs, real 4.35 secs. Speed 5,302 kB/s
Тестирую 70 files, 23,060,330 bytes. Processed 3%
ОШИБКА: ошибка чтения в алгоритме (рас)паковки delta

I:\1>"C:\!FreeArc\freearc\Tests\Arc.exe" a a -r -t -m5
Compressed 70 files, 23,060,330 => 5,057,211 bytes. Ratio 21.9%
Compression time: cpu 7.55 secs, real 4.33 secs. Speed 5,330 kB/s
Тестирую 70 files, 23,060,330 bytes. Processed 3%
ОШИБКА: ошибка чтения в алгоритме (рас)паковки delta


т.е. -mc$text; - вообще ничего не меняет в алгоритме сжатия да и не должно (это отключение группы "$text;", которой разумеется нет), а вот ошибка распаковки - налицо. спасибо, посмотрю

Цитата:

сам freearc работает нормально?

Да, gui-версия распаковывает понятно
[more] [/more]


Цитата:

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

Молчание на эту тему тоже не факт что людей данная особенность не раздражает. Многие ленивы или терпеливы.
Я честно говоря не увидел замедления при распаковке GUI-версией. Возможно просто не присматривался. Но sfx-ы встречаются чаще "полного архиватора".
Факт занесения Вами в todo данной особенности меня вполне устраивает :) Возможно присмотритесь и со временем сделаете выводы о нужности/ненужности, всё равно же я Вас уговаривать не буду (максимум - приведу доводы за или против).

cross125

Цитата:

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

Оцените соотношение степень сжатия/время упаковки. У FreeArc есть очень интересный алгоритм tornado. Лишь за одно это у меня живёт freearc. При записи на флешку "кучи мелочи" (да и вообще) упаковываю на флешку freearc-ом, получаю ощутимый выигрыш по времени и контроль целостности, критичное закрываю паролем.

FreeArc 0.67 (August 22 2012)
http://yadi.sk/d/AtJvYB2TMnI8

Vladimyr
у меня это показывается как вездесущая " ошибка чтения в алгоритме (рас)паковки delta", в общем ясно что баг серьёзный, ищу

Добавлено:
new alpha version:fixed stupid bug in last alpha resulted in numerous decompression errors with "error reading" or "exhaustive pattern" messages


Новая альфа-версия:исправлена глупая ошибка в последней альфе, приводившая при распаковке к вылету с сообщениями "ошибка чтения" или "exhaustive pattern"

Цитата:

число linux-пользователей крайне мало

дык потому и мало, что нет 64-битной версии!
кто ж систему ради архиватора на 32 бита менять захочет?

Цитата:

когда буду делать win64 версию

буду надеяться, что это время всё же настанет

Может кто помочь?
Почему при запаковки rep dispack и чем то другим кроме lzma при распаковке пишет неизвестный метод запаковки архива?

Возможно ли использовать Freearc --sync для бэкапа системного раздела с использованием Shadow Copy?

Bulat_Ziganshin
всё действительно исправлено, благодарю!

muzf
freearc не умеет использовать VSS, и я вообще не рекомендую использовать его для бекапа - всё же версия 0.666 о чём-то говорит


Цитата:

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

улучшения идут, посмотри paq8

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


Цитата:

Bulat_Ziganshin, спасибо вам за хороший архиватор. Есть пару предложений насчет GUI: в основном, измененные строки и упрощения. Многое, наверняка, уже озвучивалось. Согласен с тем, что это неприоритетно, но к релиз-версии может пригодиться
 
http://i.imgur.com/3Q8XP.png
http://i.imgur.com/RNy7W.png
http://i.imgur.com/aJMoj.png
 
 
1. Возможность скрывать тулбар
2. Отказ от иконок в меню "Файл": в современных приложениях их уже давно нет.
3. Кнопка "Обновить" возде адресс-бара, а не на тулбаре.
4. [..] в качестве "Вверх".
5. Реализация базовых команд проводника: копировать, вставить и т.д.
6. Мы все ждем контекстное меню

Добавлено:
UbiSergei
и забыл спросить - какое контекстное меню вы ждёте, вытянутое из Explorer или с командами из самого архиватора (extract и т.п.)? если второе - перечислите пункты, пож-та. это ес-но вопрос не только к тебе, но ко всем

Добавлено:
ну вот , первый ответ. из интересного он предлагает заменить "{PP% H:MM:SS} Operation" на "PP% H:MM:SS | Operation" и говорит что в меню Файл можно перенести операции Open наверх чтобы это было более похоже на общепринятые интерфейсы. точнее что меню Файл вообще как-то не так выглядит и он не знает точно как его сделать выглядящим правильно

Цитата:

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

это где такой посмотреть, у меня в списке такого нет режима, есть fast, normal, high, ultra и т.д. С теми данными которые я сжимаю наилучшие результаты по сжатию я получаю всегда с best assymetric, жмет сильнее чем ультра или максимум

cross125
tornado используется в режимах, которые быстрее чем fast вообще если не хватает сжатия freearc - смотри nanozip, zpaq, zcm