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

ну, постараюсь. я ведь ещё им вообще не занимался

ps: хотя ты наверно обращался к SCINERу

Цитата:

Привет всем и с наступающим НГ!С интересом слежу за развитием архиватора.У меня такой вопрос:а возможно будет сделать так,чтоб файлы не по отдельности в GUI добавлять,а сразу папки,как в раре и 7зипе?

Drag&Drop работает нормально.
Скачай на всякий случай новую версию. Там есть изменения.

Вроде работает. Конечно, выводит предупреждения на каждый упаковываемый каталог, но работает! ВСЁ! Теперь GUI могу не ждать! а mutivolume действительно для файлообменников нужен.

Bulat_Ziganshin
Пожелания перед январём\февралём.

GUI
1. Интерфейс:
1.1. Добавление файлов как в WinRK, т.е. возможность накидывать, но в FreeArc с возможностью выбора каким методом паковать. Возможно сделать деление файлов на группы - перетаскиванием на иконку или область например txt\binary\..
1.2. Возможность выбора каким интерфейсом пользоваться, у всех разные предпочтения, кому-то WinRAR подавай и т.п.
2. Интеграция с Explorer - чтобы была возможность выбора названия пункта в контекстном меню - или при установке или в настройках программы.

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

(Анализ+препроцессор)+основная цепочка алгоритмов.

Цитата:

добавил ссылку на http://flashmobile.ru/arc

очень надеюсь, что будущее GUI от Булата не будет требовать .Net Framework. я этот чудо-глюкодром от майкрософт принципиально не устанавливаю по идеологическим соображениям. даёшь родное win32-приложение!

Цитата:

но работает! ВСЁ!

а ты говорил "первое марта" конкуренция - двигатель прогресса!

а почему расширение сменили на WRC (WorldRaceChampionship ) ?

Цитата:

очень надеюсь, что будущее GUI от Булата не будет требовать .Net Framework

и ты готов финансировать разработку на низкоуровневолм ЯП? или ты до сих пор пребываешь в счастливом неведении относительно причин использования .net программистами и полагаешь что делается это исключительно с целью насолить своим пользователям?

Егор - записал. насчёт сжатия - это и есть сегментация

народ - тестируйте TC. SCINER - делай английскую версию. как сделаю релиз - народ повалит на сайт

Bulat_Ziganshin

Цитата:

Егор - записал. насчёт сжатия - это и есть сегментация

обатное не заявлял.
имел ввиду по-ходу не объеденяя.

С наступающим!
Президент вроде выступает уже!

уже отвыступался!

А как насчет BCJ3
Помнится на своем форуме Игорь писал про разработку BCJ3, но что у него не сложилось...
Да и еще один момент:
Фриарк жестко проиграл 7-зипу!
8мб текстур .TGA из игры MOH >>> 7-зип 1.12 мб | фриарк 1.78 мб. Вот такой не слабый слив
Виноваты походу MM+grzip vs. LZMA.

Bulat_Ziganshin
Цитата:

и ты готов финансировать разработку на низкоуровневолм ЯП? или ты до сих пор пребываешь в счастливом неведении относительно причин использования .net программистами и полагаешь что делается это исключительно с целью насолить своим пользователям?

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

Цитата:

8мб текстур .TGA

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


Код: 1074 0001:000A42C0 1075 0001:000A42CE 1076 0001:000A42DC 1077 0001:000A42EA
1078 0001:000A42F8 1079 0001:000A4306 1080 0001:000A4314 1081 0001:000A4322
1082 0001:000A4330 1083 0001:000A433E 1084 0001:000A434C 1085 0001:000A435A
1086 0001:000A4368 1087 0001:000A4376 1088 0001:000A4384 1089 0001:000A4392

Цитата:

назовите мне хоть один популярный архиватор написанный на .net

Интерфейс FreeARC вроде как делается на основе gtk, а не .net, чтобы иметь возможность одинаково легко сделать версии и под win, и под linux.

Bulat_Ziganshin

Цитата:

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

Т.е. что-то типа брут-форса алгоритмов на маленьком кусочке файла ? Думаю, действительно в некритичных ко времени режимах (вроде максимального) можно попробовать.

p.s. С Новым годом всех !

Здравствуйте. Меня очень порадовало появление подобного архиватора с множеством препроцессоров и возможностью их настройки . Особенно - rep - он хоть и жадный до памяти, но очень быстрый и подходящий как раз для немалой доли используемых мною файлов - а именно таких, в которых есть два или более больших файла (скажем, образов CD/DVD приставочных игр), в которых большая часть информации попросту идентична, но находится на большом расстоянии.

Поэтому хочется разобаться с парочкой проблем связанных с rep . Во-первых (в версии 0.40-prerelease 4), объём памяти требуемой и используемой паямти отображается не совсем корректно - например, rep:544mb ребует вовсе не 680 mb для компрессии, а все 800 - потому какразмер хэш-таблицы устанавливается в 256 mb а не 544/4=136 mb. Но это не самая критичная проблема - дело в том, что у меня (судя по всему оно связано с предыдущей) архивация иногда вылетает с ошибкой:
Stack space overflow: current size 8388608 bytes.
use '+RTS -Ksize' to increase it.
arc: compression Lib_d42d: interrupted

Правда, обычно такое бывает если использвоть последовательность двух rep подряд (зачем оно нужно? - скажем, при сжатии одной игрушки последовательность rep:32mb+rep:312mb дала примерно тот же результат, что и rep:512mb, а памяти потребовалось в 1.5 раза меньше - да и для других подобных архивов оно часто бывает верно, хоть и с другими размерами словарей).

Несколько тестов показали, что последовательность (на наборе данных примерно 2 Гб - тоже образы CD) rep:32mb:32+rep:544mb:32+tempfile+(любой алгоритм - хоть rep:1mb ) вылетатет с такой ошибкой, да что там, даже rep:32mb:32+rep:384mb:32:h26+tempfile+rep:1mb (вот если 372mb, а не 384 или больше, то работает) ... При этом без tempfile'а этой ошибки нету - но как же без него, если дальше надо сжимать lzma с тяжёлыми настройками, вроде 7bx (памяти у меня 1 Гб).

В общем, это уже известная ошибка?

Цитата:

объём памяти требуемой и используемой паямти отображается не совсем корректно

это ясно, исправлю


Цитата:

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

с предыдущим оно никак не связано. скорее может быть с тем, что у тебя используется два tempfile в алгоритме. использзуй -di+$ чтобы увидеть реально используемую цепочку алгоритмов сжатия для каждого солию-блока - tempfile d них вставляется автоматичсеки для "разгрузки" памяти

при испольщовании только одного rep эта ошибка хоть раз была?

QT явно лучше gtk. =)

Цитата:

QT явно лучше gtk. =)

в смысле на нём проще писать? так я в любом случае пишу не на С

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

qt, gtk, wx - всё пойдёт, лишь бы не .NET

Цитата:

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

Не, tempfile только один, -di+$ я нынче практически всегда использую. А вот rep'а - два. И если мне не изменяет память, с одним rep'ом эта ошибка не наблюдалась. Более того, она чаще наблюдалась при короткой длине слова и, похоже, при малом словаре первого rep'а. Например, цепочка
rep:1mb:1024+rep:256mb:256+tempfile+tor:3:4mb
выдаёт ту ошибку, а вот цепочки
rep:1mb:2048+rep:256mb:256+tempfile+tor:3:4mb
rep:1mb:1024+rep:256mb:512+tempfile+tor:3:4mb
rep:2mb:1024+rep:256mb:256+tempfile+tor:3:4mb
проходят нормально.

Цепочки эти чисто для выявления ошибки - судя по всему, что стоит после tempfile, не так и важно, будь то 1bx или 7bx.

Да, а если убрать tempfile, ошибки нету (но с 7bx его не уберёшь).

Bulat_Ziganshin
Я правильно понимаю, что текущая версия:
FreeArc 0.40 (2008-01-01 11:50) ?

Цитата:

Я правильно понимаю, что текущая версия:
FreeArc 0.40 (2008-01-01 11:50) ?

ну прям кусок хлеба не дают до рта донести!

Bulat_Ziganshin

Цитата:

0.40 (1.1.2008)
Сжатие: filetype detection!!!

filetype detection есть или нету?
Arc.exe a a -di -di+$ Arc.exe - 561 534
Arc.exe a a -di -di+$ Arc.txt - 639 793
поменял расширение Arc.exe в Arc.txt

вот такой есть вопрос, у РАРа есть такой параметр, -idp , не выодить проценты при архивации, помогает когда пишешь лог в файл, а есть такой параметр у freearc?

Цитата:

filetype detection есть или нету?

нету. в history это находится *после* релиза 0.40. считай то, что я несколько дней назад здесь опубликовал - это уже начало работы над 0.50. через недельку сделаю публичную бету на SF

Добавлено:

Цитата:

у РАРа есть такой параметр, -idp , не выодить проценты при архивации, помогает когда пишешь лог в файл, а есть такой параметр у freearc?

-i

спасибо булат! работает! только в лог почему то не пишет имена архивруемых файлов

Добавлено:
И может быть сделать простенький инсталятор в Nullsoft? а то руками копировать ломает немного каждый раз а вообще архиватору респект!

Цитата:

спасибо булат! работает! только в лог почему то не пишет имена архивруемых файлов

а такого варианта действительно нет. либо -i2 с именами, либо -i без имён. надо наверно сделать?


Цитата:

И может быть сделать простенький инсталятор в Nullsoft?

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

Bulat_Ziganshin
А вариант без инсталлятора возможен? Меня копировать руками не "ломает", а вовсе даже наоборот.

Я тоже за вариант без инсталлятора. Так хоть уверен, что тебе в реестр при установке ничего не напишут Надеюсь, консольная версия отдельно останется?

Я тоже за без инсталятора
Думаю для огромного числа он важен, поэтому если несложно то пусть будет 2-а варианта.
С и без.