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

Bulat_Ziganshin

Есть возможность подкорректировать такое распределение ресурсов? Или это к GTK+?

Цитата:

правда, у меня vista x64

Надо искать третьего, с xp 32.

Цитата:

нет, пока сделай копию в другом месте

Гм, а у меня работает и пробелами, правда путь к логу задан из программы.
egor23
Сколько к тебе на скрины не гляди, все будет по-другому

Цитата:

Есть возможность подкорректировать такое распределение ресурсов? Или это к GTK+?

может тебе его переставить? или попробовать версию с 2.16 Егора?

Bulat_Ziganshin
Я на это особо не жалуюсь, просто мысли вслух, что не рационально используется место. Вы это тоже можете повторить, и с русским языком.

juvaforza

Цитата:

Есть возможность подкорректировать такое распределение ресурсов? Или это к GTK+?

ещё неплохо бы сюды выложить файлик freearc.menu
какой скин (тема GTK) используется

Цитата:

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

это FreeArc, а настройка для Arc.exe

Цитата:

Сколько к вам скрины не гляди, все будет по-другому

поконкретнее, на скрине:
gtk-theme-name = "MS-Windows"
тема в Windows - Классическая

Цитата:

не рационально используется место

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

Цитата:

ещё неплохо бы сюды выложить файлик freearc.menu

и файлик языка из arc.languages

Добавлено:
Bulat_Ziganshin

Цитата:

если отключить подписи - это в settings есть

плотнее кнопки разместить,
возможно настройку ввести в freearc.menu - интервал(расстояние) между кнопками

files.mail.ru/8ZP7WE
Bulat_Ziganshin

Цитата:

пиши в след. раз яснее что тебе нужно.

Хорошо.

Цитата:

я думал, это опять багрепорт.

Проблема (видно на скриншоте) - ширина кнопок с одной буквой не зависит от ширины самой надписи, а от самой широкой надписи.
На скриншоте все отображено в очень явной форме, а сама проблема возникает при локализации - кнопки с одинак. кол-ом букв на разных языках имеют разную ширину.
Ещё момент - размеры окна параметров при выборе языка меняются. Можно их зафиксировать, и добавить, например, прокрутку. Видно, если выбрать немецкий язык.
egor23
Тема та, что идет с дистрибутивом (FreeArc-portable-0.50-win32-alpha-2009-04-19_gtk_2.10)

Цитата:

поконкретнее, на скрине:

Рациональнее рассматривать вид на теме, которая будет использована по умолчанию, а ? (Да и всем привычно. )

Цитата:

возможно настройку ввести в freearc.menu - интервал(расстояние) между кнопками

Не надо лучше.

Цитата:

Ещё момент - размеры окна параметров при выборе языка меняются. Можно их зафиксировать

а если пользователь сменит размер шрифта? и чего хорошего в фиксированнгом размере - размер окна меняется как раз чтобы всё влезало


Цитата:

Тема та, что идет с дистрибутивом (FreeArc-portable-0.50-win32-alpha-2009-04-19_gtk_2.10)

я думаю, что всё же лучше сменить gtk на 2.16, так что Егоровская сборка как раз релевантна


Цитата:

Проблема (видно на скриншоте) - ширина кнопок с одной буквой не зависит от ширины самой надписи, а от самой широкой надписи.

я это никак не контрлирую и вероятно это как раз баг в gtk. может даже, в 2.16 его уже исправили


Цитата:

Проблема (видно на скриншоте) - ширина кнопок с одной буквой не зависит от ширины самой надписи, а от самой широкой надписи.
На скриншоте все отображено в очень явной форме

пока ты не написал, я этого не понял


Цитата:

возможно настройку ввести в freearc.menu - интервал(расстояние) между кнопками

вот полное описание его формата:
http://haskell.org/gtk2hs/docs/gtk2hs-docs-0.9.12/Graphics-UI-Gtk-ActionMenuToolbar-UIManager.html#XML-UI
я иуда ничего внести не могу

Bulat_Ziganshin

Цитата:

Или это к GTK+?

Я просто не знаю, в ваших ли силах это изменить.

Добавлено:
Запоздал с обновлением.

Цитата:

пока ты не написал, я этого не понял

В очень явном виде - в переборщенном виде

Цитата:

я думаю, что всё же лучше сменить gtk на 2.16

Сейчас Егор скажет результат у него.

juvaforza

Цитата:

files.mail.ru/8ZP7WE

gtk_2.10


gtk_2.16


Bulat_Ziganshin
не одно, так другое вылазеет

juvaforza

Цитата:

Тема та, что идет с дистрибутивом (FreeArc-portable-0.50-win32-alpha-2009-04-19_gtk_2.10)

что-то не очень похожа на gtk-theme-name = "MS-Windows"

Вы сборкой с gtk_2.10 или 2.16 пользуетесь?


Цитата:

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

тема по-умолчанию в FreeArc
gtk-theme-name = "MS-Windows"
а тема в Windows - это уже отдельный разговор, у меня Классическая

Добавлено:

Цитата:

не одно, так другое вылазеет

Цитата:

я иуда ничего внести не могу

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

Добавлено:
juvaforza
а размер шрифта какой в теме gtk?

тема в Windows - Windows XP - стандартная (голубая), настройки темы крутили?

Добавлено:
Bulat_Ziganshin

Цитата:

не одно, так другое вылазеет

кстати вылезло в 2.16 ещё с выбором языка

Цитата:

FreeArc + gtk_2.16

Цитата:

Проблема (видно на скриншоте) - ширина кнопок с одной буквой не зависит от ширины самой надписи, а от самой широкой надписи.

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


Цитата:

не одно, так другое вылазеет

Цитата:

кстати вылезло в 2.16 ещё с выбором языка

какие проблемы, я опять не догнал?

Bulat_Ziganshin

Цитата:

какие проблемы, я опять не догнал?

наверно уже поправили (в 2.16 расстояние немного больше между кнопками)

Цитата:

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

Bulat_Ziganshin
При попытке упаковать 3 млн мелких файлов с длинными именами FreeArc упал где-то на 2/3 процесса считывания файлов. Свободной памяти было - по его сообщению - 1161 Мб.

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

Maximum Compression
18-April-2009 : Added FreeArc 0.50a (April 15 2009)
http://www.maximumcompression.com/data/summary_mf2.php

Nick222

Цитата:

При попытке упаковать 3 млн мелких файлов с длинными именами FreeArc упал где-то на 2/3 процесса считывания файлов.

в теории потребуется, для FreeArc-0.50-win32-alpha-2009-04-19:
поиск файлов - 3ГБ
сортировка файлов - 3ГБ
метод сжатие - допутим - 1ГБ
итого - 7ГБ

если очень хочется, то сможите сделать, в теории:
на x32 /3GB
поиск файлов - возможно найдёт все файлы
на x64
поиск файлов - должен найти все файлы
сортировка файлов - немного сортировку сделает


Цитата:

Свободной памяти было - по его сообщению - 1161 Мб.

это не свободной, а максимальный непрерывный блок

Цитата:

в теории потребуется, для FreeArc-0.50-win32-alpha-2009-04-19:
поиск файлов - 3ГБ
сортировка файлов - 3ГБ

нет, Егор, ты неправильно понял. сортировка увеличивает потребность в памяти, но не вдвое, а 1кб на файл я указывал с учётом сортировки (так как она включена по умочланию)

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

Bulat_Ziganshin

Цитата:

нет, Егор, ты неправильно понял. сортировка увеличивает потребность в памяти, но не вдвое, а 1кб на файл я указывал с учётом сортировки (так как она включена по умочланию)

это должно было быть
а на данный момент
практика говорит (FreeArc-0.50-win32-alpha-2009-04-19):

Цитата:

test_111000.iso - 111000файлов

Случай 1
FreeArc.exe GUI - открыли диск выделили папки
-mlzma:10m
поиск файлов - 115МБ
сортировка и последующее сжатие - расходуется 220МБ

т.е. ~ поиск отъел 100МБ и сортировка отъела 100МБ

Bulat_Ziganshin
Спасибо. Жду нового билда

Сейчас freearc.history и freearc.ini выполняют одни функции, может стоит оставить один файл, в котором хранить настройки? (а историю - в другом, или в том же)


Цитата:

а если пользователь сменит размер шрифта? и чего хорошего в фиксированнгом размере - размер окна меняется как раз чтобы всё влезало

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

Добавлено:
Svetovid
Если для чайников.
Он может сжать лучше и быстрее. Если вам хочется попробовать консольную версию, можете смело взять версию 0.40, если хотите попробовать версию с графическим интерфейсом - подождите следущей альфа-версии 0.50. Переходить или нет - решите сами, только постепенно, попользуйтесь вначале несколько месяцев в тестовом режиме.

Цитата:

т.е. ~ поиск отъел 100МБ и сортировка отъела 100МБ

дело в том, что память используется нелинейно, просто когда кончается текущий блок памяти - выделяется вдвое больший. чтобы точно увидеть расход памяти - сделай
set GHCRTS=-c -F1.1



Цитата:

Сейчас freearc.history и freearc.ini выполняют одни функции, может стоит оставить один файл, в котором хранить настройки? (а историю - в другом, или в том же)

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

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

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

хранить их можно в реестре, глоб. файле, user-local файле

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

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

Добавлено:

Цитата:

Он может сжать лучше и быстрее.

забыл, что опций больше. вот из заставки:

FreeArc is free, open-source archiver for Windows and Linux. It features solid archives with smart updating, AES+Twofish+Serpent encryption, recovery record, self-extracting archives and wide range of compression profiles.

советую проглядеть доку на консольну. версию по диагонали, и прикинуть - что из этого тебе не хватало в 7zip

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

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

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

или у вас чисто теоретический интерес?

sabio
Вопрос сугубо практический - нужно делать ежемесячный бэкап.
Сейчас использую 7z - но есть пакет, где слишком много файлов (разрезать пополам нельзя).
TAR-ом я и сжал - но этот процесс очень долгий и каждый раз так делать не будешь - и потом, теряется вся автоматизация - сначала затарить, потом сжать... (я делаю полный бэкап каждый месяц и инкрементальный или как там его - каждую неделю).

Добавлено:
Bulat_Ziganshin
А если так сделать - понимаю, что бред:
1) ФриАрк анализирует размер непрерывной памяти;
2) Прикидывает, сколько файлов за раз сможет сжать;
3) Сжимает, допустим по 1 млн файлов - каждый в отдельный архив;
4) Полученные в (3) архивы тупо склеивает в один.

Не прокатит?

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

Bulat_Ziganshin
(оффтопик: на самом деле, у "формата" maildir, когда каждое письмо в отдельном файле, есть ряд существенных преимуществ перед форматом mailbox - от возможности одновременного доступа до надёжности в случае краха системы)

Nick222

Цитата:

и потом, теряется вся автоматизация - сначала затарить, потом сжать

а что мешает автоматизировать оба этих этапа? точнее, даже сразу всю связку
а почему TAR работает очень долго не совсем понятно - по сути, это ведь просто копирование; может, дело опять-таки в большом количестве файлов?
но даже если речь идёт про 2-3 часа - то и пусть себе - запустил бэкап вечером, к утру всё и готовоединственное ограничение здесь в том, что свободного места должно быть раза в полтора больше, чем объём всех данных

Цитата:

единственное ограничение здесь в том, что свободного места должно быть раза в полтора больше, чем объём всех данных

зачем? тарить на stdout и тут же сжимать 7z-ом

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

Цитата:

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

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

кстати! вспомнил рекордсмена по потреблению памяти - uharc. вот он точно 3 миллиона всосёт. вот из анналов:

Код: ======= C:\Base\Compiler (62 тысячи файлов + 5 тысяч каталогов) ==============================

uharc gs- 4.5 mb 6.5 sec (из них 4.5 сек. - в ОС)

7z en 39 mb 6 sec (из них 4.4 сек/28 mb - собственно поиск, из них 1.4 сек. - в ОС)

rar 11 mb 4 sec (из них 2.7 сек. - собственно поиск)
rar en 11 mb 7 sec
rar gen 11 mb 18 sec

ARC 16.12 (c UTF8Z + case-sensitive sortOn')
arc en -c 20 mb 10 sec (6.5+3.5gc)

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

Bulat_Ziganshin

Цитата:

дело в том, что память используется нелинейно, просто когда кончается текущий блок памяти - выделяется вдвое больший. чтобы точно увидеть расход памяти - сделай
set GHCRTS=-c -F1.1

на что должно оказать влияние данная переменная?
выставил

test_111000.iso - 111000файлов
FreeArc.exe GUI - открыли диск выделили папки
упаковывается папка 00100000 - 100000 файлов в корне папки.
-mlzma:10m
деление посик файлов \ сортировка - по показаниям окна упаковки

Цитата:

на что должно оказать влияние данная переменная?

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

установи в батнике и затем вызови arc.exe

Добавлено:
кстати, в твоей картинке 116 мег на 110к файлов - то, что я и говорил. вообще, статистику использования памяти печатает сам ghc RTS - надо добавить в него опцию -sstderr или -sFILENAME