» FreeArc (часть 4)
если хочешь, можешь его постестировать на реальных данных и нам рассказать. пока что я знаю - что сжатие хуже, распаковка быстрее. упаковка может распараллеливаться на много яджер, а не только два как у lzma
Цитата:
сейчас его размер можно изменить чтобы видеть больше или меньше символов в комбобоксах выбора метода сжатия и т.д.
ну да немного поспешил. пусть будет плавающее.
Цитата:
насчёт шифрования - давайте тогда обсудим как его вынести
в отдельную вкладку всунуть окно, которое сейчас вываливается после нажатия кнопки напротив шифрования. а саму опцию шифрования всунуть также в ту вкладку. ты ее нажимаешь и все другие опции становятся активны в этой вкладке
Цитата:
галочка перед сжатием используется например при модификации архива
даже незнаю куда ее тогда прилепить. а как это сделано в других архиваторах?
хотя, может создать отдельную опцию которая будет за это отвечать и появляться только при модификации архивов. (если это возможно)
или тогда в сам список всунуть опцию
Цитата:
пока что я знаю - что сжатие хуже
А насколько хуже ?
Цитата:
распаковка быстрее
Это большой плюс.
Цитата:
упаковка может распараллеливаться на много яджер, а не только два как у lzma
Т.е. на современных 4-х, 6-, 8- и более ядерных CPU он будет заруливать по скорости обычный LZMA в глубокие минуса.
Цитата:
в конце февраля первая альфа
Ждем. Главное, чтобы она в дальнейшем не осталась вечной альфой.
Цитата:
в отдельную вкладку всунуть окно, которое сейчас вываливается после нажатия кнопки напротив шифрования. а саму опцию шифрования всунуть также в ту вкладку. ты ее нажимаешь и все другие опции становятся активны в этой вкладке
это возможно. кстати, вот на этой странице мы уже обсуждали как эту страницу облагородить
интересно, что думают другие об этом предложении? сейчас там можно быстро поставить галочку, а пароль будет запрошен прямо в процессе архивации
Цитата:
а как это сделано в других архиваторах?
в них такой возможности нет
Цитата:
хотя, может создать отдельную опцию которая будет за это отвечать и появляться только при модификации архивов. (если это возможно)
в этих случаях диалог будет занимать больше места и будет неудобство - галка отдельно, выбор сжатия отдельно
кстати, напомню, было ещё предложение сделать эти опции в два столбца, как в winrar
Цитата:
...упрощает восприятие
согласен
Цитата:
...оно просто начинает мозолить глаза.
согласен
Цитата:
ну да, это пустая писанина.
и тут согласен
Цитата:
если ты пользуешься программой часто, оно просто начинает мозолить глаза
и опять согласен
Цитата:
...что действительно нужно увидеть
единственное что хочется видеть при процессе упаковки - это сколько осталось времени до завершения процесса и на сколько уменьшился объем первоначальной информации. И мне совершенно все равно что и как будет выглядеть на самом деле, но если есть вариант, то конечно хочется воспринимать информацию так чтобы не отвлекаться от основной задачи и просто контролировать (не задумываясь) процесс. Ведь согласитесь, по большому счету задача архивирования - второстепенная задача.
И все-таки оставьте старый (v0).
p.s. проведите опрос среди англоязычной публики ...
p.s.s. а почему бы не подумать на счет коммерческой составляющей, а !? если правильно построить маркетинговую политику по сравнению с конкурентами существующими на рынке, я думаю что успех может быть (англоязычные страны). отвечать по поводу коммерции не надо дабы избежать не нужный флуд.
Цитата:
сделать жёстким - а чем это лучше?
Согласен, будет в разы удобнее. У меня к примеру при первом запуске сужается вкладка "Сжатие"
Булат, предлагаю Вам опцию в духе "экспорт настроек сжатия в .bat" и сделать возможность создания отдельного setup.exe и рядом к примеру setup.arc к примеру если у человека не установлен ARC, столкнулся с такой проблеммой архивируя 5Гб данных. Мне удобнее хранить их в ARC, а портабельно было бы здорово, если бы рядом лежал setup.exe. Ну конечно setup я не правильно выразился, но если Вы сочтете это полезным - полагаю понимаете, о чем я веду речь.
На счет юзабилити - просто сделать удобную статику, в духе TrueCrypt, InsidePro.PasswordsPro, PSI+ - там нет ничего лишнего, все компактно и удобно, хотя та же Пся - ну очень уж богата настройками, как для простых юзеров - так и для продвинутых. А когда будет простое удобство - тогда уже умельцы и скинов наклепают, как для HaoZIP.
С уважением!
Цитата:
А насколько хуже ?
не знаю. я и предлагаю потестировать и сказать наколько он вам интересен для добавления в fa. я со своей стороны могу предварительно глянуть чтобы оценить сложность добавления
Добавлено:
Nail441
обратись к автору репака или - проще - скачай другой репак. мы тут не поможем
Цитата:
Согласен, будет в разы удобнее. У меня к примеру при первом запуске сужается вкладка "Сжатие"
почему? всё остальное вообще не понял
и всё-таки, мне кажется, Ratio и Speed как-то "некстати" среди остальных значений
по сути, они не столько к "прогрессу" относятся, сколько к "вспомогательной информации"
и если насчёт Ratio это несколько спорно, то уж Speed однозначно - кандидат в status bar
вот расчехлил paint и сварганил пару вариантов:
(v5) - Ratio и Speed задвинуты в самый низ, в "воображаемый status bar"

(тут несколько напрягает непонятное соседство Ratio и [+])
(v6) - Ratio и Speed в правом углу над progress bar
с одной стороны, не так "заброшены", как в предыдущем варианте, с другой - достаточно отделены от остальных значений

Цитата:
почему? всё остальное вообще не понял
Я не знаю, почему, вчера скачал новую версию и такое было (Win7)
Цитата:
всё остальное вообще не понял
Давайте поэтапно:
1) Я написал об экспорте настроек в .bat - для того, потому, что возникают много вопросов даже здесь в духе "а как сделать с помощью командной строки" - а экспорт в .bat был бы удобным в данном случае, например для репакеров.
2) сжимаем 5Гб данных (к примеру фото) - отправляем клиенту foto.arc и рядом instsall.exe, вместо того, чтобы отправлять один sfx, размером в 3Гб. Говорю все это на примере фотостудии, и когда отправляю в .arc - у клиентов его нет, а когда отправляю архив и рядом небольшой инсталлер - они спрашивают "О, а чем Вы так сжимаете".

Цитата:
2) сжимаем 5Гб данных (к примеру фото) - отправляем клиенту foto.arc и рядом instsall.exe
изучайте матчасть - вам нужно взять freearc.sfx и переименовать его в foto.exe.
При условии, что foto.arc и foto.exe в одном каталоге, при запуске foto.exe распакует foto.arc.
Можете взять консольный вариант arc.sfx вместо freearc.sfx, он немного меньше. Главное чтобы новое имя было как у архива, а расширение "ехе".
Цитата:
говоря кратко, есть предложение включить cls-precomp.dll и cls-srep.dll в комплект программы, и сделать в ней поддержку гибридных кодеков ..., что позволит ускорить распаковку ... что скажете?
скажу просто: Вам решать. Вы можете сделать это опционально (платно) или не сделать вообще. Что касается меня, то я бы не заморачивался на это ибо сейчас размер жесткого диска (или ssd диска) позволяет делать что и как угодно. Проще говоря человек, говорящий не по нашему

если не все, то планируется ли поддержка многоядерных процессоров?
Офигеть. Спасибо!
максимальное сжатие (а также high/ultra) - два ядра для сжатия, одно при распаковке, собственно как и в lzma. более слабые методы сжатия - многопоточные в обе стороны
Цитата:
в этих случаях диалог будет занимать больше места и будет неудобство - галка отдельно, выбор сжатия отдельно
ок. галку оставляю
Цитата:
кстати, напомню, было ещё предложение сделать эти опции в два столбца, как в winrar
тогда окно придется сильно растянуть, + там же у вас не только простые функции, но и со списком
главная и шифрования:


Даже между вкладками есть определенная симметрия. Как видно большинство изменений косметические, поэтому их можно было бы попробовать реализовать в версии 0,7
подобные вещи я делаю в "фоновом" режиме, просто когда наскучивает заниматься более скучными, но важными, так что речь не об этом. у меня вопрос к спецам по freearc - правильно ли я понял что там нужно сделать
Добавлено:
sabio
мне v5 и v6 не глянулись. положил их тоже на свой сервер:
http://freearc.org/download/image/progress5.png
http://freearc.org/download/image/progress6.png
Добавлено:
Цитата:
насчёт "по окончании" - надо просто не очищать поля слева, и асимметрии не будет
да и видно будет заодно, что все файлы и байты были обработаны
(или наоборот, если по какой-то причине файл обработать не получилось, будет видно, что число слева меньше правого)
там сейчас делается по-другому - если что-то не удалось обработать, то уменьшается сам Total. а столюцы справа очищаются именно когда total==current, это между прочим удобней - не надо самому думать, сравнивать их, всё сразу интуитивно ясно
Добавлено:
Цитата:
А еще проценты ratio можно с сотыми долями выводить.
мне кажется что в процессе архивации сотые интересны только конченым гикам. а лишняя информация - это сложность в восприятии нужной
Цитата:
а для консоли удобнее будет строки поменять местами
разумеется
Цитата:
только вот с Compressed и Time неувязка
да, не так там всё просто, но как начальная точка отсчёта подойдёт. что мне нравится - идея разместить totals сверху и несколько чисел под ним. в принципе, все 8 меняющихся полей можно вместить в одну строчку (очень длинную

Цитата:
единственное что хочется видеть при процессе упаковки - это сколько осталось времени до завершения процесса и на сколько уменьшился объем первоначальной информации.
для нормального юзера - да, для гика нужно больше. кстати, нетрудно сделать настраиваемым вывод в заголовок окна, к сожалению в самом диалоге это не выходит
Испытывал на компе AMD 3 Ghz, ram 6 Gb, на Wxp x86 , Win7 Ultimate x64 , в виртуальной машине VMware - Wxp x86 Ram 512 mb) В виртуальной машине вылетает через раз.
Далее пошли совсем чудеса. Распаковка из командной строки через Arc.exe работает без проблем, скорость фантастическая. После работы с Arc.exe несколько раз нормально отработала и гуевая оболочка, но в конце концов снова отказалась распаковывать. Упаковка в нормальном режиме занимает столько же времени сколько и в самых быстрых, а размер архива - вдвое меньше!.
IMHO для начала можно бы оставить меньше методов паковки, но чтоб хоть один работал устойчиво.
Если допилить релиз до стабильной работы то все остальные архиваторы пойдут лесом. Успехов автору в его трудах. Ждем с нетерпением и надеемся...
не знаю, насколько вам это будет интересно
попался на глаза такой вот супер-быстрый хэш: https://code.google.com/p/xxhash/
точно февральская 0.67 вылетает?
vasulpr
лучше писать новые посты. иначе по email я ничего не увижу
Буквально все архиваторы (алгоритмы), которые используют многопоточность - сжимают хуже! А памяти требуют больше!
Поэтому очень интересный вопрос, нужна ли многопоточность при сжатии.
Видимо, только на очень больших объемах данных, которые сжимать долго.
дайтека хоть один "битый" архив, самый маленький.
просто чего я с фриакром не делал, а делал всю акробатику

ну и..память не тестили? у меня давно проблемы были с раром, пока не вычислили, что одна планка памяти "завалилась".
Цитата:
столюцы справа очищаются именно когда total==current, это между прочим удобней - не надо самому думать, сравнивать их, всё сразу интуитивно ясно
может, тогда, чтобы всё же не появлялось асимметрии по окончании, вместо очистки, например, выключать bold?
хотя, как по мне, и очистка, и выключение жирного в момент окончания архивирования выглядят несколько странно и нелогично, неожиданно - число росло, росло и вдруг пропало
я бы оставлял всё на месте, как есть
а если надо что-то специально выделить (например, в случае ошибки) менял бы цвет на красный что ли?..
Цитата:
мне v5 и v6 не глянулись
я и сам на них посмотрел ещё раз - не то
но всё же, мне кажется, Ratio и Speed не должны быть "вперемешку" со значениями "xxx of yyy"
хотя бы как-нибудь так, может? (v7)

Цитата:
При распаковке архива FreeArc вываливается с ошибками
было бы не плохо сами Ошибки писать.
Цитата:
Буквально все архиваторы (алгоритмы), которые используют многопоточность - сжимают хуже!
Если разница в сжатии - считанные проценты, а скорость растет пропорционально количеству потоков, то многопоточность решает.
Цитата:
А памяти требуют больше!
Сегодня даже на компьютерах класса "печатная машинка" стоит минимум 4 Gb памяти.
Алгоритм, архитектурно упирающийся в 2 ядра - это тупик. Именно поэтому будущее за алгоритмами вроде LZHAM, а не за LZMA/LZMA2.
ссылко
Аддон для Total Commandera сначала не хотел работать, выдавал ошибки errorlevel 1 и 2, но после того как переставил multiarc с версии 1.4 на 1.2 и переустановил FreeArc (0.67) - заработал.
Так что теперь гуишный интерфейс не так уж и нужен.
Цитата:
для нормального юзера - да, для гика нужно больше
ну так архиватор то вы пишите для нормального юзера, я надеюсь. А для гика, пожалуйста, командная строка ...
Паковал, распаковывал разные файлы, выявилась закономерность - ошибка при распаковке вылезает при работе с русскими длинными наименованиями файлов. Там где имена на английском и в формате 8.3 ошибок не возникает.
Отредактировал в MultiArc.ini строки ссылок в виде
Archiver=c:\Program Files\FreeArc\bin\freearc.exe
List="c:\Program Files\FreeArc\bin\arc.exe v --noarcext -- %AQA"
Подробно см. по ссылке и теперь при паковке и распаковке через Total показывает окошко с прогресс баром и временем.
P.S. Нашел на чем спотыкается Freearc. При упаковке и распаковке он не отслеживает превышение длины пути плюс имя файла в 259 символов. При попытке распаковки слишком длинного пути происходит ошибка. Кстати последний Winrar ведет себя примерно так же. Только при попытке подсунуть ему слишком длинный путь для распаковки он выводит предупреждающее окно. FreeArc и WinRar при упаковке некорректных каталогов ничего не сообщают, но файлы с путем превышающем 259 символов просто в архив не попадают. Только WinZip работает (к его чести) корректно - сразу предупреждает при попытке паковать и распаковывать слишком длинные пути. Что интересно, в Total Commander внутренним упаковщиком zip поддерживается и упаковка и распаковка очень длинных путей - но при этом выводится соответствующее предупреждение - что другие программы могут споткнуться.
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275
Предыдущая тема: Punto Switcher (часть 3)
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.