Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: hammerxp1
Дата сообщения: 16.04.2014 13:28
Расшифруйте пожалуйста, сколько реальной памяти понадобится для распаковки при таких параметрах:
1.rep:256mb+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128
2.rep:256mb+lzma:64mb:h64m:normal:bt4:128
Автор: Bulat_Ziganshin
Дата сообщения: 16.04.2014 14:09
hammerxp1
256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Highpass
спасибо!
Автор: hammerxp1
Дата сообщения: 18.04.2014 12:58

Цитата:
256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?
Или 256+132 это сколько требуется памяти на поток? Потому что если выставить одноядерный процессор то всё работает.
Без параметра 4x4 всё отлично, но с моим количеством обрабатываемых данных (около 40гб) не хватает скорости, а 4x4 дает ускорение при распаковке минимум в 2 раза.
Пока что перешёл на эксперименты с rep:256+tor:15, разница в размере получаемого архива не такая значительная, зато скорость распаковки почти в 2 раза выше. Кстати tor:16 при упаковке тоже не хватает памяти.
Автор: UbiSergei
Дата сообщения: 25.04.2014 12:29
Shud поднял тему прогресс-бара, хочу высказаться.

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

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

Другие предложения:
1) Мне очень не нравятся пустые места между параметрами и значениями. (Time-много-пустого-места-0:12).
2) Больная часть исходных данных, по моему мнению не нужна. Количество файлов смело можно выкидывать, с этой информацией ничего не поделаешь (не остановится же пользователь посередине архива, достигнув магического числа). Текущий размер во время обработки выкидываем по той же причине. Также не вижу, зачем нужен размер информации (исходный и обработанный), роль заменяется процентом.
3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!
4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час. Вместо 'of' можно использовать слэш. Идея из uTorrent.
5) Заголовок: я бы поменял вертикальныю черту на слэш. Но это на усмотрение, у меня какая-то нелюбовь к этому знаку. Еще можно поставить разделитель между процентом и временем.



Вместо жирности можно использовать различие размеров шрифта, сейчас это модно, и смотрится неплохо.


Добавлено:
По поводу набора команд в меню Explorer. Некоторы предложения для строк.

1) Выкиньте 'the selected files' -- файловое меню не показывается при отсутствии выделенных файлов
2) 'using Freearc' -> '(Freearc)', или 'with Freearc', 'via Freearc' (сэкономит целый симбол в меню); еще лучше совсем Freearc выкинуть, как в меню 7-Zip. Мы же все равно рассчитываем, что Freearc в скором будущем станет единственный архиватором на машинах пользователей
3) '... via dialog', 'Extract, Test with Freearc' -> Compress, Open, Extract, Test archive (tnx 7-Zip).
4) 'Extract to a folder', 'Extract here'.


Добавлено:
В голову пришла еще одна замечательнаяы идея. Вчера смотрел видео на ted.com, понравилось как у них время отображается по краям на прогресс-баре. Идею с легкостью можно перенести и сюда.

Прогресс = Обработано данных/ Всего данных
Всего времени = Прошло времени * (Всего данных/Обработано данных)
Прошло времени / Всего времени = Обработано данных / Всего данных

Превьюшка с метро-дизайном


Добавлено:
И в дробных числах лучше использовать точку, я не запятую.
Автор: Shuld
Дата сообщения: 26.04.2014 14:14
UbiSergei
Первый бар (в моем предложении) - "процент" выполненой работы (в целом, а не по файлам!)
Второй бар - размер "архива", т.е. показатель "эффективности" работы!
Автор: UbiSergei
Дата сообщения: 27.04.2014 17:26
Shuld
Значит второй бар просто показывает коэфициент сжатия, понятно. Как обидно это было бы не говорить, но надобности в нем тоже не вижу: на протяжении процесса жизни ратио колеблется слабо. Бары для вещей у которых есть начало и конец, ратио же почти постоянен.

Это же идея из винрара? Похоже, что авторы изначально не продумали концепцию.
Автор: Shuld
Дата сообщения: 27.04.2014 20:53
UbiSergei
Вы постоянно путаете.
В WinRAR как раз по-файлово.
Автор: UbiSergei
Дата сообщения: 04.05.2014 16:26
Shuld
Спасибо за поправку. Давно им не пользовался.
Автор: hammerxp1
Дата сообщения: 07.05.2014 07:01
Пока занимался своей разработкой, случайно получился эксперимент.
Имеем 3 папки, в каждой папке набор файлов с системного диска разных ос.
(dll,exe,mui,inf и тд. и тп.)

1. файлов 57671, размер 8,86 Гб.
2. файлов 79349, размер 13,57 Гб.
3. файлов 75584, размер 12,21 Гб.

После сжатия всех папок (rep:256mb+tor:15, сортировка -dsgercpn) получаем размер архива 2,43 Гб. (2 613 137 764)

Удаляем в каждой папке дублированные файлы. Получаем:
1. файлов 37124, размер 4,96 Гб.
2. файлов 49469, размер 7,62 Гб.
3. файлов 49895, размер 7,19 Гб.

После сжатия: (rep:256mb+tor:15, сортировка -dsgercpn) получаем размер архива 2,42 Гб. (2 605 761 577)

Вывод: rep прекрасно справляется с дупликацией файлов.
Автор: Bulat_Ziganshin
Дата сообщения: 07.05.2014 13:42
hammerxp1
Вывод: в данном случае rep со словарём 256 мб прекрасно справляется с дупликацией файлов поскольку rep:256m по определению не может найти повторы на расстоянии больше 256 мб, очевидно что в данном случае -dsgercpn успешно переупорядочила файлы так, чтобы повторы находились на меньшем расстоянии. но не всегда это возможно, для таких случаев и нужен srep, который находит повторы на всём объёме данных

Добавлено:

Цитата:
Верхний прогресс-бар и все, что выше - относится к исходным данным
Нижний прогресс-бар и ниже - к архиву.

а, я тогда это не заметил даже. и что в нём за проценты - степень сжатия? показ степени сжатия возможен в основном индикаторе - часть зелёной полоски, соответствующая текущему размеру архива, покрашена ещё каким-то цветом. я даже так делал лет 20 назад - имхо не очень это нужно. а если уж делать отдельный инидкатор, то он должен быть непохож на индикатор прогресса, иначе все так же путаться будут. может скажем сбоку как в rar'овском arcinfo степень сжатия показывается?..
Автор: Bulat_Ziganshin
Дата сообщения: 07.05.2014 23:08

Цитата:
Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?

там много всего намешано. -mt по умолчанию выставляется в кол-во ядер/потоков cpu. в 4x4 можно явно укзаать числдо потоков упаковки с помощью :t, по умолчанию оно приравнивается к опции -mt. после того как параметр же таким образом задан, arc проверяет хватит ли памяти для упаковки и если нет - обрезает его. при этом даже если вы явно задали :t при сжатии - он вырезается из записываемого в архив определения (смотрится командой arcindo/lt) исходя из предположения что этот параметр вы задали для сжатия, а при распаковке могут быть какие угодно (и неизвестные заранее) условия

при распаковке происходит примерно то же самое, только :t у нас понятно никакого нету - ему неоткуда взяться. но это делает arc. как работает unarc и как он определяет размер ОЗУ в виртуалке - надо посомтреть, помнится мне что там что-то проще сделано поскольку это отдельный алгоритм на C++, а основной в arc на хаскеле. опцию -mt в unarc наверно надо добавить для таких горемык

если tor:15 близко к lzma сжимает - его и используйте. добавьте ещё :c3 - это ускорит распаковку


Цитата:
Кстати tor:16 при упаковке тоже не хватает памяти.

с гигом озу? ну да, ему 1.5 гига нужно (с дефолтным 128 мб словарём), как и lzma:max. вообще с 40 гб файлом надо в сторону srep смотреть, вроде есть cls-srep.dll для его распаковки на лету
Автор: egor23
Дата сообщения: 08.05.2014 11:53
hammerxp1
если интересуетесь сжатием, вот подопытный
NDP452-KB2901951-x86-x64-DevPack.exe 328МБ
http://www.microsoft.com/en-us/download/details.aspx?id=42637

содержимое можно сжать сильнее, как минимум до 150МБ
Автор: Bulat_Ziganshin
Дата сообщения: 08.05.2014 21:11
опцию -mt в unarc/dll/sfx приделал
Автор: Bulat_Ziganshin
Дата сообщения: 09.05.2014 15:37

Цитата:
2) Большая часть исходных данных, по моему мнению не нужна. Количество файлов смело можно выкидывать, с этой информацией ничего не поделаешь (не остановится же пользователь посередине архива, достигнув магического числа). Текущий размер во время обработки выкидываем по той же причине. Также не вижу, зачем нужен размер информации (исходный и обработанный), роль заменяется процентом.  

3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!

4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час.

дело в том что нынешний "широкий" индикатор прогресса разработан для гиков, для тех кому важна каждая деталь выполняемой операции. поэтому там размеры до байтов, время в секундах и прочее. я думаю, что надо делать альтернативный индикатор прогресса с минимумом деталей, твой дизайн под него мне кажется подходящим, вместе с упрощением самой информации (размер в МБ, время в часах-минутах и т.д.). т.е. исходить из того что большинству людей интересно. имхо, это ratio, speed, исходный размер данных, (предсказываемое) общее время работы
Автор: Shuld
Дата сообщения: 10.05.2014 14:07
Bulat_Ziganshin
Может быть более прогрессивный вариант?
Каждый индикатор может быть размещен где хочется пользователю (мышкой), правой кнопкой мыши - количество знаков после запятой (или показывать или нет секунды и т.п.)
Все это запоминается в настройках (скинах?).
Я лично тогда сделаю, как мне будет удобно.

Добавлено:

Цитата:
и что в нём за проценты - степень сжатия?

Верхний прогресс-бар - обработанные исходные данные/ все исходные данные

Нижний прогресс-бар - текущий размер архива/ все исходные данные.
Когда сжатие закончится - это будет процент сжатия.
Автор: aslav
Дата сообщения: 11.05.2014 13:53
Как десктопный архиватор сабж более не развивается автором?
Я не для флейма интересуюсь, и говорить - "возьми и скачай, пользуйся - работает же".

4 года новой паблик версии нет. роадмэп завис на 2012 году.

Отсюда вопрос - для паблика вскоре планируется что-то или сабж можно рассматривать как поле для экспериментов энтузиастов борьбы за минимизацию интересующимися и личное хобби автора?
Автор: Shuld
Дата сообщения: 14.05.2014 19:18
aslav
Постоянно выходят новые версии.
И в этом году уже были.
Вы в топике ссылку
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=0&limit=1&m=1#1
смотрели?
Или здесь:
http://freearc.org/Download-Alpha.aspx
Я бы версией 0,666 пользоваться не советовал - в ней есть ошибки.
Почему автор не обновляет релиз?
Не знаю. Ищет идеала...
Автор: hammerxp1
Дата сообщения: 20.05.2014 13:39

Цитата:
опцию -mt в unarc/dll/sfx приделал

Просто отлично! но, как работает можно поподробнее,и где скачать, потестить.

Цитата:
с гигом озу? ну да, ему 1.5 гига нужно

Упаковываю я на мощной машине, это распаковывать пытаюсь на слабых конфигурациях.

Идея про дубликаты файлов:
Под свои потребности пока что реализовал так: написал махонькую программку,перед упаковкой она ищет дубликаты файлов, создает txt файлик в корне упаковываемой папки, в нём чётные (отсчёт с нуля) строки это относительные пути к файлу оригиналу, не чётные это пути к файлу дубликату. Потом пробегается по нечётных строкам и удаляет все файлы.
Далее упаковываем, а когда распаковываем архив запускается программа опять, она берет файл с чётной строки и копирует его в путь нечётной.
Примерно так выглядит txt:
\test\file1.dll -чётн
\test\1\file1.dll -нечётн
\test\file1.dll -чётн
\test\2\otherfile1.dll -нечёт (имя может быть другим, а содержание тоже)
\test\file2.exe
\test\2\file2.exe.bak

Кстати я реализовал ещё круче вместо файлов дубликатов (при условии что система на диске ntfs) создаются хардлинки (жёсткие ссылки) что после распаковки ещё и место на диске экономит. Но тут много подводных камней и не всегда применимо.
Надеюсь более менее понятно написал, я в "весёлом настроении"
Автор: vvvyg
Дата сообщения: 01.06.2014 22:21
12345
Автор: useretail
Дата сообщения: 02.06.2014 00:03
извиняюсь, но не знаю где спросить
<offtopic>
Как можно распаковать InnoSetup с данными пожатыми FreeArc-ом? Не очень хочется запускать инсталлятор который зачем-то требует админ-привилегий и как минимум гадит в пуск, реестр и тп. 95% случаев всё прекрасно работаeт без каких либо записей в реестре, для оставшихся 5% можно почитать скрипт и вручную добавить то что нужно
innounp данные не распаковывает, только скрипт установки и то что в setup.exe/.bin

В некоторых случаях архивы еще и зашифрованы, пароль видимо тоже зашит в инсталляторе, как его извлечь?
</offtopic>
Автор: addhaloka
Дата сообщения: 02.06.2014 01:06
useretail 02:03 02-06-2014
Цитата:
Как можно распаковать InnoSetup с данными пожатыми FreeArc-ом? Не очень хочется запускать инсталлятор который зачем-то требует админ-привилегий и как минимум гадит в пуск, реестр и тп.

Как вариант: Sandboxie или виртуалка.
Автор: useretail
Дата сообщения: 02.06.2014 19:13

Цитата:
Sandboxie или виртуалка

Спасибо, с этими способами знаком. Думал что есть попроще - напрямую.
Автор: Paramon111
Дата сообщения: 05.06.2014 12:14
Bulat_Ziganshin
Последняя версия не встраивается в меню эксплоера если устанавливать в чистую. Просто когда обновился, этого не заметил. А недавно переустановил винду и такое дело. Думал может винда косячная, установил еще одну, но fa и в нее встраиваться не пожелал. Скачал версию 0.666 (20 мая 2010 г.) и все нормально заработало.
P.S. Неплохо было бы сделать как раньше было чтобы при установке fa встраивался в меню эксплоера по умолчанию.
Автор: Bulat_Ziganshin
Дата сообщения: 05.06.2014 12:22
спасибо, проверю в виртуалке. винда какая? название, редакция, битность
Автор: Paramon111
Дата сообщения: 05.06.2014 13:54
Bulat_Ziganshin
пробовал на винде 7 х32 максимальная и домашняя расширенная.
Автор: kastellan
Дата сообщения: 05.06.2014 14:49

Цитата:
Последняя версия не встраивается в меню эксплоера


Цитата:
винда какая?

На XP (pro) и 2003 сервере (ent) x32 - та же беда была.
Решил просто - установил 0.666 и накатил 0.67a поверх.
Автор: Bulat_Ziganshin
Дата сообщения: 07.06.2014 01:53
Paramon111
kastellan
спасибо, исправил ошибку. она была только в последней альфе - 32-битный менеджер интеграции был откомпилирован как 64-битная программа
Автор: hammerxp1
Дата сообщения: 02.07.2014 14:13
Очень жду правленый unarc.dll с 4х4, уже выпустил в свет первую наверное в мире сборку Windows с использование FreeArc. в 6,6Гига влезли от Win7 до 2012 почти все редакции.
Автор: Bulat_Ziganshin
Дата сообщения: 02.07.2014 14:24
извини, я тут постоянно отвлекаюсь. всё не доберусь обновить альфу, так что пока вот: http://freearc.org/download/testing/unarc2014-06-07.zip

кстати ошибку в win81 поправил, но есть кое-что ещё

PS: ссылка твоя у меня открывает pixel.gif а вообще сейчас всё что больше гигабайта, сжимается или в fa, или в 7z+srep
Автор: hammerxp1
Дата сообщения: 02.07.2014 16:16
Спасибо! Это не моя ссылка это руборд сам знакомые слова помечает.
Я так думаю здесь нельзя такие ссылки давать но рискну: http://hammerxp.tw1.ru/viewtopic.php?f=7&t=11

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.