» FreeArc: бесплатный open-source архиватор

Цитата:

CTACKo
ты лучше скажи до скольких ты ее (игру) сжал в -mx режиме?

я с ней еще не закончил Но, по предварительным данным, 2-язычная версия, т.е. англ+рус получилась ровно 5Гб


Цитата:

Цитата:
скачайте игру call of duty world at war

дайте линк на ту версию над которой опыты ставили.

не могу - скачал на локальном фтп - он не доступен в инет. но это обычная оригинальная англоязычная версия от Reloaded, образ называется rld-cod5.iso, размер 7 442 939 008 байт.
Правда етсь у меня 2 опасения, во-первых я не уверен что сжимал именно -мх, а не -м9х. И еще это могла быть другая игра... я еще раз протестю и скажу точно.

meanwhile, хочу сообщить следующий прикол
я сжимал фарком абсолютно одинаковый набор данных, с одинаковыми параметрами, но на разных машинах - результат оказался разным. Атлон 64 Х2 5000+ сокет АМ2 - 1553822766 байт и Атлон 64 Х2 3000+ сокет939 - 1553822754 байт. Разница ничтожно мала, НО ЕСТЬ! Если математика одна, набор данных один, то и результат должен быть одинаков...
Парадоксально, но факт - на более слабой машине архив вышел меньшего размера...

версия фарка от 24.01.2009.

Цитата:

Разница ничтожно мала, НО ЕСТЬ! Если математика одна, набор данных один, то и результат должен быть одинаков...

У меня есть сомнения что набор данных был абсолютно одинаков, скорее всего даты файлов\папок отличались.

Добавлено:
Возможно были отличия в количестве оперативной памяти.

Добавлено:
или набор данных был не одинаков, какие-нибудь файлики descript.ion потерялись или изменились

Добавлено:

Цитата:

я с ней еще не закончил Но, по предварительным данным, 2-язычная версия, т.е. англ+рус получилась ровно 5Гб

для максимального сжатия надо вручную паковать
учитывая что lzma\ppmd неупаковываемые данные умеличивает в размера на 1-2%, соответственно их или вообще не упаковывать, либо прогонять их только rep.

Добавлено:
или Вы образ жмёте?

Цитата:

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

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

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

Bulat_Ziganshin

Цитата:

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

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

Цитата:

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

они будут загружаться только если есть образение к url

...и останутся там до перезапуска программы?

Цитата:

...и останутся там до перезапуска программы?

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

Bulat_Ziganshin
Вопрос конечно про консольную версию больше касается, что год назад, что сейчас картинку портит (system32\comctl32.dll), но для использования настроек не по-умолчанию. Для создания архива ещё не сильно портит, а для распаковки портит (если архив создавать на Win64).


Цитата:

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

К GUI много всяких dll цепляется, по-сути основной рабочий кусок
между 0x10000000 - 0x5B260000 (UxTheme.dll) для WinXP SP2 (и скорее всего SP3, если ничего нового цепляться не будет).
Если выходит в сеть ещё dll цепляются, вот и сторонняя подцепилась mdnsNSP.dll (0x16080000) (Bonjour Namespace Provider), если это дело установлено.
Чтобы использовать настройки предельные (по-умолчанию) скорее всего понадобится /3GB, т.к. остальные блоки будут маленькие, но это на вскидку.
в Win64, там вторые 2ГБ полностью доступны, проблем нет.
про Vista ничего сказать не могу.


Цитата:

кажется, есть возможность и выгрузки назад

Цитата:

...и останутся там до перезапуска программы?

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

А может, FA перед загрузкой DLL должен прихватизировать все большие блоки памяти? Желательно, конечно, вообще перед запуском.

Цитата:

настройки предельные (по-умолчанию)

кстати как-то говорили про настройки, чтобы было 1023m.

Добавлено:
или это было 2047m не помню уже...

главная проблема - это распаковка под обычным win32. чтобы пользователи, не съевшие собаку на fa, не натыкались на грабли. я пока думаю надо сделать -ld768m по умолчанию

а динамическая загрузка dll для url - это так, мелкий бонус, поскольку gui версия как я понимаю, всё равно будет иметь проблемы с наличием 1гб куска?

Цитата:

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

это зависит от софта установленного у пользователя.


Цитата:

я пока думаю надо сделать -ld768m по умолчанию

это тоже может быть не достаточно
-ld512m лучше

Bulat_Ziganshin

Цитата:

главная проблема - это распаковка под обычным win32. чтобы пользователи, не съевшие собаку на fa, не натыкались на грабли. я пока думаю надо сделать -ld768m по умолчанию

Тут просто нужно определиться с критерием "граблей".

Как вариант: архив, созданный любым из стандартных пресетов должен гарантированно распаковываться на машине с 256 Mb памяти. Ну или что-то в этом роде.

Если же юзер вместо стандартного пресета использует собственный набор параметров сжатия, то это уже его личные проблемы. Но среди "не съевших собаку на FA" таких точно не будет.

Benchmark

Цитата:

на машине с 256 Mb памяти.

это уже перебор для таких нужно будет -ld128m (+\- )

Цитата:

архив, созданный любым из стандартных пресетов

если это будет создаваться на машине с 256МБ, то параметры и так скорректируются.

egor23

Цитата:

это уже перебор

Это не перебор. Да, новые компьютеры сейчас продаются с объемом памяти от 1 Gb и выше. Но парк активно используемых старых компьютеров, на которых стоит 768, 512 или даже 256 Mb - весьма велик.

Поэтому когда встанет вопрос: использовать RAR, который гарантированно распакуется везде, или FA, который не факт что вообще распакуется на целевой машине, выбор будет очевиден и отнюдь не в пользу FA.

p.s.
Цитата:

если это будет создаваться на машине с 256МБ, то параметры и так скорректируются

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

это не перебор. на моей машине гую доступно около 550 мб из-за dll

Benchmark

Цитата:

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

Вот, юзер, выставит, уже изменил настройки, по-умолчанию стоит нормальное (-m4)
упаковка\распаковка - 132m, там же написано, если юзер не думает головой его проблемы.
и тем более

Цитата:

я пока думаю надо сделать -ld768m по умолчанию

это лимит относится больше к виртуальной памяти, а не физической, если у юзера 128МБ опер.памяти, он наверно знает об этом, и что настройки нужно по проще выбрать.

Registered_User

Цитата:

это не перебор.

те проблемы, которые были у юзеров напримере 7-zip, показали что блок в 512МБ есть, с другой стороны если адресное пространство сильно порезано, можно использовать параметр /3GB, будет ещё блок 1023МБ, и тогда точно распакуется.

egor23

Цитата:

Вот, юзер, выставит, уже изменил настройки

Нет. Это стандартный пресет. Который обязан работать на подавляющем большинстве машин. Это основы юзабилити.

Людей, которые не думают головой и не читают документацию - вагон. Максимум, такой юзер поинтересуется: "А как тут выставить максимальное сжатие ? -mx ? Отлично !". И влупит этот -mx везде, где сможет. А после будет удивляться, почему на некоторых компьютерах архив не распаковывается. Виноват, конечно, будет "кривой и глючный FreeARC".



Цитата:

те проблемы, которые были у юзеров напримере 7-zip, показали что блок в 512МБ есть, с другой стороны если адресное пространство сильно порезано, можно использовать параметр /3GB, будет ещё блок 1023МБ, и тогда точно распакуется

FreeARC позиционируется как архиватор для массового пользователя, а не как очередная игрушка для compression-фриков.

Так вот, массовый пользователь в подавляющем большинстве понятия не имеет ни про ключи /3GB, ни про непрерывные блоки памяти, ни "про прочие внутренние детали". И совершенно не обязан это знать. Точно так же, как больной не обязан знать состав и способ синтеза таблеток, которые он принимает.

Голосую за оставление в гуи только пресетов с памятью для распаковки <192мб. остальные пусть будут в консоли.

Цитата:

Людей, которые не думают головой и не читают документацию - вагон. Максимум, такой юзер поинтересуется: "А как тут выставить максимальное сжатие ? -mx ? Отлично !". И влупит этот -mx везде, где сможет.

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


Цитата:

Так вот, массовый пользователь в подавляющем большинстве понятия не имеет ни про ключи /3GB, ни про непрерывные блоки памяти, ни "про прочие внутренние детали".

вот именно. те, кто знают, пусть выставляют и -ld побольше - под свою ответственность

Bulat_Ziganshin

Цитата:

вот именно. те, кто знают, пусть выставляют и -ld побольше - под свою ответственность

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

Цитата:

Голосую за оставление в гуи только пресетов с памятью для распаковки <192мб

на мой личный взгляд это не является необходимым. ни одной жалобы на то что сжали на 500 мб, а у нас на машине всег 256, не было (хотя это мождет просто потому, что сейчас презета именно на 500 мб и нету)

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

Bulat_Ziganshin
FreeArc 27.01.2009
GUI:
1. Упаковка: вывод информации о текущем файле, сделайте "выравнивание по левому краю", т.е. чтобы был видно имя файла, а сейчас начинается вывод с папки, и если путь длинный не видно какой файл упаковывается.

2. Настройки: Профиль упаковки: можно сохранить, а удалить нельзя.

3. АркИнфо:
Словарь: выводится всего два значения, причём первое и последние в цепочке.
например:
-mrep:256m+rep:32m+rep:76m+rep:75m
будет выведено 256mb + 75mb

Arc.exe:
дата стоит 24.01.2009

Добавлено:
Bulat_Ziganshin

Цитата:

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

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

updated http://www.haskell.org/bz/arc1.arc

Цитата:

DoubleClick/Enter on non-archives now executes them

Ура.
- А чего файлы через консоль запускаются?
- Запись в окошке событий об попытки открыть архив - "архив абв.abc поврежден ..."
- Файлы с русскими именами и пробелами не открываются.
- Если внутри самого архива щелкуть на файле, открывается пустое окно, лучше бы тогда вообще никаких действий не выполнялось.

первые три пункта поправлены

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



Цитата:

1. Упаковка: вывод информации о текущем файле, сделайте "выравнивание по левому краю", т.е. чтобы был видно имя файла, а сейчас начинается вывод с папки, и если путь длинный не видно какой файл упаковывается.

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


Цитата:

-mrep:256m+rep:32m+rep:76m+rep:75m
будет выведено 256mb + 75mb

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


Цитата:

2. Настройки: Профиль упаковки: можно сохранить, а удалить нельзя.

записал


Цитата:

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

1) придётся переделывать все алгоритмы сжатия или хотя бы распаковки (точнее 4 - lzma, rep, ppmd, tor)
2) после этого они станут работать медленней, хотя скорей всего ненамного
тоже записал

Bulat_Ziganshin
А вот еще пара моментов к GUI.

1. По кнопочке "UP" можно выйти максимум в корень диска. Чтобы перейти на другой диск, надо вбивать его имя вручную. Неудобно.

2. Следствие из п.1 При вводе вручную имени диска без слэша после двоеточия (например C: вместо C:\) GUI наглухо виснет.

Цитата:

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

все бы хорошо, только вот параметры были -mx -ld512
но да, реально видно разное кол-во ОЗУ из физических 4Гб: 2.84Гб (б0льший архив) и 3.00Гб (меньший архив). вынь32 не в силах явить 4Гб ОЗУ, думаю не надо объяснять почему
и набор данных был абсолютно одинаков - я просто скопировал, перепроверил сколько папка занимает и тогда на обеих машинах стартовал сжатие.
и я перепроверил тесты сжатия файлов iwd из папки main в cod5. lzma сжал до 2.02Гб (2.01 при ultra), fa -mx -ld512 до 1.99Гб. Разницы практически нет. Скорее всего fa сильно проиграл при сжатии -м9х - разница получалась в несколько сотен Мб, примерно до 300, т.е. ~2.3Гб.

Bulat_Ziganshin

Цитата:

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

Сортировка:
имя - сортирует в обратном порядке, т.е. для столбца имя, по-умолчанию, стрелка вверх должна быть.
в WinRar и 7-zip настройки помнятся (хоть в 7-zip стрелки и не отображаются).

GUI:
При прерывании упаковки выскакивает ошибка и FreeArc закрывается:
gtk2hs_closure_marshal: uncaught exception


Цитата:

1. По кнопочке "UP" можно выйти максимум в корень диска. Чтобы перейти на другой диск, надо вбивать его имя вручную. Неудобно.

помимо "UP" хочется видеть строчку с ... для подъёма на уровень выше.


Цитата:

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

про выравнивание слева это надо понимать не дословно.
опять по старой памяти на WinUha ориентировался.
с другой стороны сейчас окно можно растягивать, но не поможет при очень длинных путях - вывод идёт в одну строку.
в WinRar: не выводит пути, только имя файла.
в 7-zip вывод в две строки:
путь на первой (лишнее вырезается в середине)
имя файла на второй.

CTACKo

Цитата:

все бы хорошо, только вот параметры были -mx -ld512

параметры цепочки могут меняться взависимости от доступности памяти.

Цитата:

но да, реально видно разное кол-во ОЗУ из физических 4Гб: 2.84Гб (б0льший архив) и 3.00Гб (меньший архив). вынь32 не в силах явить 4Гб ОЗУ, думаю не надо объяснять почему

а программы не работают на прямую с ОЗУ.
кстати не могли бы на системе, где ОЗУ из физических 4Гб видится 2.84Гб
выложить логи от утилит: memo2g.exe и memo4g.exe
для лога memo4g.exe, нужно систему с параметром /3GB запускать
http://www.haskell.org/bz/memo.7z
и написать что за система и какое железо стоит.


Цитата:

и я перепроверил тесты сжатия файлов iwd из папки main в cod5. lzma сжал до 2.02Гб (2.01 при ultra), fa -mx -ld512 до 1.99Гб.

Не нужно забывать, что есть предел сжатия данных (выше головы не прыгнишь).
не плохобы взяглянуть на лог упаковки -mx -ld512 -di -di+$%

Цитата:

Скорее всего fa сильно проиграл при сжатии -м9х - разница получалась в несколько сотен Мб, примерно до 300, т.е. ~2.3Гб.

Очень хороший вопрос, можно на него просто ответить, настройки алгоритмов сжатия (lzma) были хуже, чем в 7-zip, но для точного ответа нужен лог.
-m9x -di -di+$%

Bulat_Ziganshin
Обратил внимание, что rep в -mx есть, а в -m9x нету, не совсем понял почему так?

Добавлено:

Цитата:

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

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

Цитата:

кстати почему нельзя выделять память небольшими блоками, т.е. какие минусы при этом будут?
1) придётся переделывать все алгоритмы сжатия или хотя бы распаковки (точнее 4 - lzma, rep, ppmd, tor)
2) после этого они станут работать медленней, хотя скорей всего ненамного
тоже записал

А не проще ли поковыряться с winapi? Ведь в будущем к FA могут подключаться другие библиотеки,с которыми тоже надо бороться.
Задача: выделить память, прежде чем DLL'ки загрузятся.

Цитата:

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

я не понял, претензия только к тому, что при старте программы стрелочка не отображается, или ещё что-то?


Цитата:

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

какой-то поток сознания


Цитата:

в 7-zip вывод в две строки:

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


Цитата:

При прерывании упаковки выскакивает ошибка и FreeArc закрывается:

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


Цитата:

Обратил внимание, что rep в -mx есть, а в -m9x нету, не совсем понял почему так?

-m*x - это методы сжатия с быстрой и требующей мало памяти распаковкой. просто быстрая распаковка - -m*d, описанные в станд. arc.ini

Bulat_Ziganshin

Цитата:

я не понял, претензия только к тому, что при старте программы стрелочка не отображается, или ещё что-то?

нет стрелка показывает вниз (имя), т.е. сортировка по убыванию, а сортирует по возрастанию.

а так у всех столбцов по-умолчанию стрелка вниз смотрит, для столбцов Размер и Изменён это правильно, а для Имя нет.

То что не отображается при запуске, сразу не заметил, тоже мелкая недоработка.

Цитата:

какой-то поток сознания

непонятно написал?

Цитата:

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

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

Цитата:

-m*x - это методы сжатия с быстрой и требующей мало памяти распаковкой.

но rep под это описание вписывается, неужели медленней lzma распаковывается со словарём 128m?

Добавлено:

Цитата:

- -m*d, описанные в станд. arc.ini

в документации про m*d написано в разделе Конфиг-файл arc.ini
а в разделе Настройка сжатия нет упоминания.