» FreeArc (часть 4)

Цитата:

muzf PackArc/PackJpg сжимают пофайлово, а precomp-у приходится работать с бинарниками, откуда ему знать что этоти 2 jpg нужно жать солидом?  
Как Вы себе это представляете?

Как вариант - для мультимедиа файлов отключать precomp и сжимать пофайлово.
Но проблема вообще-то в самом precomp (в 043 проблема осталась). Судя по -v он определяет размер второго jpeg stream всего в 493390 байт, когда он должен быть раз в 9 больше.
Эта проблема проявляется и в таблице squeezechart у Precomp.

Shuld
Благодарю, поиогло.

snkreg
приоритеты такие
- исправление ошибок (больно много их со всех сторон)
- улучшение usability
- документацию наконец-то написать

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

кстати, сейчас я столкнулся с тем, что многие отдельные пожелания к GUI укладываются в схему "настройки по фильтру файлов". например:
- не показывать hidden/system файлы под windows и с именами вида ".*" под unix
- показывать архивы в начале списка и/или выделять их цветом
- добавлять '*' к именам зашифрованных файлов

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

Bulat_Ziganshin
Процессор E8400 (2 ядерный, 3.6GHz), Win7 64-разрядная, ОЗУ 4 ГБ

142 файлов: exe, dll, sys. размером 224,346,129 bytes
Метод Размер Скорость

И никто не напишет что последняя альфа не работает? Приколисты вы народ ))

Paramon111

Цитата:

И никто не напишет что последняя альфа не работает? Приколисты вы народ ))

Это только у приколистов, видимо, не работает.
У меня работает. Всё до мелочей не проверял, но стандартные операции без проблем.

Bulat_Ziganshin

Цитата:

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

Я имел ввиду вот что: пытается ли FA одновременно и читать и записывать? Т.е. может ли начаться сброс выходного буфера, если в данный момент идёт чтение; и наоборот, может ли FA подать команду на чтение, если сейчас идёт сброс выходного буфера?

точно, я не заметил что использовал 0.666 версию
0.67 мартовскую я в другую папку скинул, потому как мне показалось что скорость
архивирования упала

сейчас проверил 4x4 с разными blocksize, все нормально
сразу видно что работает, потому как требование к памяти изменяется

Файл.doc --> FreeArc --> Add to Archive --> Всё дефолтное --> Ok:
c_szDefaultExtension:unsupported archive type

Добавлено:
Ok --> Cancel --> Ok - вешает процесс FA

Добавлено:
Хотя не совсем,
thread blocked indefinetely

Потом всё исчезает.

vishyakov
да. хотя одно время это было запрещено:


-- |При работе с одним физическим диском (наиболее частый вариант)
-- нет смысла выполнять несколько I/O операций параллельно,
-- поэтому мы их все проводим через "угольное ушко" одной-единственной MVar
-- UPDATE: Seems that this is no more holds for Vista
--
--oneIOAtTime = unsafePerformIO$ newMVar "oneIOAtTime value"
--fileReadBuf file buf size = withMVar oneIOAtTime $ \_ -> fileReadBufSimple file buf size
--fileWriteBuf file buf size = withMVar oneIOAtTime $ \_ -> fileWriteBufSimple file buf size

fileReadBuf = fileReadBufSimple
fileWriteBuf = fileWriteBufSimple

Bulat_Ziganshin

Цитата:

new alpha version

А это, того самого ...
Не планируете пока делать ?

Суть пожелания в добавлении функциональности sfx-a:
(1. drag&drop мышой архива архив.arc на sfx-архив
2. архив.arc распаковывается)

Правда уже вошло в привычку делать sfx-ы. Минус в том что некоторые антивирусы того ... Дрожат и боятся ... Иногда очень долго на флешку писать большие sfx-ы. Или из интернета скачивать заново ....

Paramon111

Цитата:

И никто не напишет что последняя альфа не работает? Приколисты вы народ ))

глючный релиз


Добавлено:
Bulat_Ziganshin
FreeArc
1. например упаковываем Папку bin\, ничего не создаётся
Упаковать - ок - окно закрылось
ничего не происходит

2. например упаковываем Папку FreeArc-portable-0.67-alpha-win32\

Упаковать - ок

c_szDefaultExtension: unsupported archive type

Кстати
А окно так должно выглядеть?

vasulpr
Польза от rep-а на большом объеме данных, превышающем словарь lzma.
В вашем случае объем данных сравним с объемом словаря lzma, поэтому от него эффекта не чувствуется.
Попробуйте на нескольких ГБ.
Вообще, в моих экпериментах, наоборот, обычно без деления на группы результат лучше!

Bulat_Ziganshin

Такой нубский вопрос... можно ли как-то самому скомпилировать unarc.dll чтоб в ней самой была добавлена опция -pПАРОЛЬ? Возможно это глупо, но пока я ничего больше не смог придумать чтоб ISDone распаковывал запароленые архивы. Тк поддержка паролей уже появилась в анарке, пробовал разные unarc.dll, но в скрипте исдана это не работает.

Andarin 20:41 16-11-2012

Цитата:

У меня работает. Всё до мелочей не проверял, но стандартные операции без проблем.

Приношу извинения - запускал не с того файла, не последнее обновление. Последняя версия не работает.

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


Цитата:

озможно надо создать еще одну группу файлов: исполняемые данные?
Поскольку на compressed и binary - exe дает ухудшение сжатия, тай скорость чуть-чуть падает.

фишка в том, что разделение на отдельные группы исполныемых и остальных бинарных данных приведёт к тому, что lzma/rep не сможет закодировать повторы между ними. поэтому так и сделано - в отдельную группу вынесены редкие obj, которым exe-фильтр очень вредит. а бинарные, которым exe-фильтр почти безвреден, объединены с exe - польза от кодирования повторов больше потерь от бесполехзного применения exe


Цитата:

Для новой группы предлагаю не использовать rep, поскольку в реальных архивах доля выполняемых данных небольшая и пользы от repа абсолютно никакой.

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

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

Цитата:

D:\backups>arc a -di -m4x4:b100mb:lzma:d8mb archive gasbillingok_full_backup.bak

FreeArc 0.67 (September 10 2011) Creating archive: archive.arc using 4x4:b100mb:
lzma:8mb:normal:32
Memory for compression 1228mb, decompression 1354mb, cache 256kb
Compressed 1 file, 9,263,288,832 => 782,623,813 bytes. Ratio 8.4%
Compression time: cpu 3838.13 secs, real 983.00 secs. Speed 9,423 kB/s
All OK

D:\backups>arc a -di -m4x4:b1020mb:lzma:d8mb archive gasbillingok_full_backup.ba
k
FreeArc 0.67 (September 10 2011) Creating archive: archive.arc using tempfile+4x
4:t1:i0:b1020mb:lzma:649mb:normal:32
Memory for compression 2425mb, decompression 2296mb, cache 256kb
Compressing 1 file, 9,263,288,832 bytes. Processed 0.0%arc: wclose: invalid ar
gument (Bad file descriptor)


ERROR: can't close file C:\DOCUME~1\SINERK~1\LOCALS~1\Temp\freearc2093978113.tmp
\$$arcdatafile$$.tmpProgram terminated by user!

почему второй вариант меняет размер словаря LZMA?

Bulat_Ziganshin
ещё были фризы\подтормаживания системы,
виновником был Hardware Interrupts and DPCs

откатился на "предыдущую версию" 23.05.2012

Цитата:

в отдельную группу вынесены редкие obj

так я ни одного с файлов этой группы и не сжимал


Цитата:

что lzma/rep не сможет закодировать повторы между ними

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


Цитата:

а бинарные, которым exe-фильтр почти безвреден

халявных 200 кб на 650мб + чуть большая скорость упаковки это по вашему лишнее?

Я все таки протестовал бы ФА с новой группой, поэтому если будет время это реализовать, то я с удовольствием помогу с тестированием!

kalpak
второй вариант требует больше 2 гб памяти, поэтому fa пытается уменьшить его требования к озу и делает лажу. я же тебе говорил, проверяй с -lc- -ld-

egor23
краткое содержание предыдущей серии

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

мне кажется это не совсем равнозначно разбить файл на блок 1гб и сжимать lzma:8mb
и пытаться запустить lzma:>512mb
а он не может если не хватает памяти для загрузки блока его в файл записать и потом этот файл и сжать
так можно будет и с большими блоками сжимать

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


Цитата:

халявных 200 кб на 650мб + чуть большая скорость упаковки это по вашему почти безвредность?

именно. ты получил лучшие результаты на одном тесте, и не понимаешь, что на других будет наоборот

есть ещё один фактор, который я забыл упомянуть - не всегда файлы, содержащие исполняемый код, имеют расширение exe/dll

Bulat_Ziganshin

Цитата:

краткое содержание предыдущей серии

имелось ввиду сдвинуты Обработано\всего

в своё время нравилось окно WinUHA

Bulat_Ziganshin

Можно ли как-то убрать пароль из зашифрованного архива чтоб не перепаковывать его, то бишь декриптировать архив?

egor23
да, я специально сделал чтобы они могли перекрываться. когда там реальные данные - это почти незаметно, зато позволяет немного уменьшить ширину диалога. собственно мог бы и сам посмотреть - не работает только сжатие в arc из gui/explorer. или вообще в предыдущей версии - я вроже ничего не менял

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

Добавлено:
мне тоже диалог прогресса winuha нравился - он был самый информативный среди всех GUI архиваторов. но сейчас единственное в чём он имхо превосходит fa - написано сколько озу используется. нам бы тоже такое добавить не помешало

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

Bulat_Ziganshin
А если в группу obj внести все другие группы (кроме exe конечно) сделав их как бы подгруппам, такое возможно?
файлы группы obj при архивировании выносятся отдельным блоком в котором не используется препроцессор exe?

ndch
постараюсь посмотреть. кстати, не лучше ли просто сделать gui-шный unarc.exe? взять обычный sfx, но запрашивать в начале работы какой файл будем распаковывать


Цитата:

unarc.dll чтоб в ней самой была добавлена опция -pПАРОЛЬ?

постараюсь посмотреть почему это не работает


Цитата:

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

во-первых это надо реализовывать. во-вторых, при распаковке приджётся делать то же самое

Bulat_Ziganshin

Цитата:

собственно мог бы и сам посмотреть - не работает только сжатие в arc из gui/explorer

gui/explorer - глючит\ не работает

а консоль работает и arc и FreeArc:
arc a a ..\
FreeArc.exe a a ..\


Цитата:

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

а полгода пролетело незаметно...
времени не хватает

Добавлено:

Цитата:

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

WinUHA 2.0 RC1 (2005.02.27)



Добавлено:

Цитата:

но сейчас единственное в чём он имхо превосходит fa - написано сколько озу используется.

превосходит:
1. изменение приоритета
2. Фоном - сворачивает в трей,
но при нажатии фоном приоритет не меняется на минимальный, тоже есть недоделки.

Цитата:

А если в группу obj внести все другие группы (кроме exe конечно) сделав их как бы подгруппам, такое возможно?

можно просто перенести в неё все расширения кроме exe/dll


Цитата:

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

да