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

» FreeArc (часть 4)

Автор: muzf
Дата сообщения: 06.04.2013 23:28
--volume=SIZE несовместима с --sync ?
Эта опция могла бы стать выходом. Например обновлялись бы только те куски, в которых были изменения (удаление/добавление/изменения), причём небольшой размер куска позволял бы обработать ситуация, когда из источника удаляется большая часть файлов и заменяется новой, а на приёмнике нет места для пересоздания всего архива.
Автор: PAQer
Дата сообщения: 22.09.2012 13:49

Цитата:
мне кажется что в процессе архивации сотые интересны только конченым гикам.

А мне кажется что гики тоже люди. А для не совсем конченных гиков, можно и десятые доли выводить.
Фриарк, ведь, для таких маньяков/гиков и разрабатывался, да и кто, если не ты, Булат, что-то сделает для гиков?
Тем более что:

Цитата:
а зачем нормальному пользователю использовать freearc, а не rar/zip?

Автор: terenty79
Дата сообщения: 06.04.2013 23:50
чё то 0.7 версию обещали скоро, но потом всё заглохло как то.
Автор: Evgenii66
Дата сообщения: 07.04.2013 04:31
хе-х.привыкай. :-\
Автор: Andrey_Verkhoglyadov
Дата сообщения: 22.09.2012 13:52
WildGoblin
пожалуйста -
Bulat_Ziganshin

Цитата:
v8

красивое решение.
Автор: Bulat_Ziganshin
Дата сообщения: 07.04.2013 11:28
muzf
дописывать новые данные в конец существующего файла из всех известных мне архиваторов умеет только zpaq, плюс в нём дедупликация и поколения файлов, так что рекомендую для бекапов

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


Цитата:
Ну да, на логе в UTF-8 показало что текста мало:

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


Цитата:
Burat нашел один баг.

спасибо, записал


Цитата:
--volume=SIZE несовместима с --sync ?

-v не работает с arc-архивами, а 7-zip если и обновляет многотомники, то создаёт новые копии

terenty79
пока идёт работа над переводами
Автор: sabio
Дата сообщения: 22.09.2012 14:28
Bulat_Ziganshin
ещё одна вариация с отступлением от "классических канонов" - (v9)

..............Files .... Compressed ........ Bytes ...... Time
Processed ....... 8 ..... 6,229,876 ... 16,188,368 ... 0:00:02
Total .......... 35 .. ~ 51,893,133 .. 134,844,601 . ~ 0:00:17
.............................. | ...... | .. | ............ |
.............................. +- 38 % -+ .. +- 7,970 kB/s -+
................................ Ratio .......... Speed

не совсем логично получается, что Compressed и Bytes переставлены местами
зато Ratio и Speed очень наглядны, кмк

более логичный, но и более громоздкий вариант - (v10)

..............Files ........ Bytes .... Compressed ...... Time
Processed ....... 8 ... 16,188,368 ..... 6,229,876 ... 0:00:02
Total .......... 35 .. 134,844,601 .. ~ 51,893,133 . ~ 0:00:17
.............................. | ............ | ........... |
..................... Ratio .. +---- 38 % ----+ ........... |
..................... Speed .. +--------- 7,970 kB/s -------+
Автор: juvaforza
Дата сообщения: 07.04.2013 12:13
Bulat_Ziganshin

Цитата:
пока идёт работа над переводами

В примере меню нужно пару строк (19 и 62) обновить
Автор: Bulat_Ziganshin
Дата сообщения: 22.09.2012 14:30
все варианты на одной странице со ссылками на загрузку соответствующих freearc.exe: http://freearc.org/download/testing/progress/
Автор: Bulat_Ziganshin
Дата сообщения: 07.04.2013 12:21
SREP 3.2 (6 апреля 2013 г.)-m2 -lN теперь эквивалентно -m3 -lN -cN: степень сжатия посередине между -m1 и -m3, а скорость как у -m2 в прежних версиях
-a0: та же степень сжатия как при -a1, памяти требуется на 5-10% меньше, но в 1.5-2 раза медленней
-a32/-a64: с large pages обычно ещё быстрее чем -a16, но требует ещё больше памяти
-slp[+/-/]: форсировать/отключить/попробовать(по умолчанию) использовать large pages, т.е. страницы виртуальной памяти в 2-4 мб

Мелкие изменения:-v[0..2]: уровень детализации выводимой информации
-pcMAX_OFFSET: выводит внутренние счётчики производительности только для матчей ближе чем MAX_OFFSET
-l64k/-c1mb - поддержка нового синтаксиса (суффиксы k/m/kb/mb для обозначения килобайт/мегабайт)
32-битная и 64-битная версии откомпилированы GCC 4.7
32/64-битные динамические и статические (-static) компиляции под Linux



SREP 3.2 (April 6, 2013)-m2 -lN now is the same as -m3 -lN -cN: compression ratio is average between -m1 and -m3, while speed is the same as in old versions
-a0: the same compresssion ratio as -a1, memory usage is smaller by 5-10%, but 1.5-2x slower
-a32/-a64: sometimes faster than -a16 (only with large pages), but needs even more memory
-slp[+/-/]: force/disable/try(default) large pages support

Minor changes:-v[0..2]: verbosity level
-pcMAX_OFFSET: print performance counters for matches closer than MAX_OFFSET
-l64k/-c1mb syntax support (k/m/kb/mb suffixes for kilobytes/megabytes)
Both 32-bit and 64-bit default executables are compiled with GCC 4.7
32/64-bit dynamic/static linux builds
Автор: Bulat_Ziganshin
Дата сообщения: 22.09.2012 16:55
ruduk
подретушировал твои варианты и добавил их как v11 и v12 на http://freearc.org/download/testing/progress/



Добавлено:
вариация v8, выводящая Speed справа:

v13 - http://freearc.org/download/testing/progress/FreeArc13.exe :
Автор: sabio
Дата сообщения: 22.09.2012 18:29
сделал вот картинки
v9


v10
Автор: muzf
Дата сообщения: 07.04.2013 23:33

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

Да, есть такое, бывает 5-10 строк подряд одинаковой длины.


Цитата:
или классически - один архив с базовой версией, плюс дополнительные для инкрементов

С удовольствием бы, но ситуацию "удалил 300гб и записал 300гб новых данных" это не обработает, так как место на источнике и приёмнике примерно одинаково, и эти удалённые 300гб не очистяться.
Автор: Bulat_Ziganshin
Дата сообщения: 22.09.2012 18:48
sabio
спасибо, добавил на http://freearc.org/download/testing/progress/

Добавлено:
v14:
Автор: muzf
Дата сообщения: 16.04.2013 14:03
Arc.exe умеет сжимать каждый файл в отдельный архив, и при --sync перепаковке менять только те которые изменились ?
Автор: Bulat_Ziganshin
Дата сообщения: 23.09.2012 13:33
Another proposal for idea from v9+v10 in text:

..............Files......Time............Bytes.... .Compressed..
Processed ........8.....0:00:02.......16,188,368.....6,229,876..
Total ...........35...~ 0:00:17......134,844,601..~ 51,893,133..
..........................|..............|....|... ....|........
..........................+- 7,970 kB/s -+....+- 38 % -+........
...............................Speed .......... Ratio...........

Автор: Bulat_Ziganshin
Дата сообщения: 17.04.2013 21:34
Один товарищ разработал библиотеку для распаковки архивов FreeArc в NSIS: http://www.smart-arab.com/2013/04/freearc-for-nsis-plugin/

или на офсайте: http://nsis.sourceforge.net/FreeArc_plug-in

muzf
попробуй - наверно получится
Автор: Andarin
Дата сообщения: 23.09.2012 15:05
Всё это субъективно, но мне больше всего нравятся v13 (или v12)
Автор: Edison007007
Дата сообщения: 19.04.2013 14:07
Булат, сейчас в ФА присутствуют компрессоры/препроцессоры: REP, Delta, dispack, exe, tta, mm, dict, lzma, lzp, lz4, tor, ppm, grzip, это все? Или я что-то пропустил?
Автор: Bulat_Ziganshin
Дата сообщения: 23.09.2012 15:30
v15 - http://freearc.org/download/testing/progress/FreeArc15.exe :



это v11 с Ratio и Speed в обратном порядке. я думаю что мне надо центрировать Speed/Ratio в последней строке, отказавшись от какого-либо выравнивания с числами над разделителем. и возможно добавить ETA (время завершения операции) в самом конце - это очень удобно для длительных операций

Добавлено на http://freearc.org/download/testing/progress/
Автор: Bulat_Ziganshin
Дата сообщения: 21.04.2013 11:15
Edison007007
ppmd,4x4,cls,external + 4 алгоритма шифрования
Автор: sabio
Дата сообщения: 24.04.2013 13:00
странные эти гугловцы..
сделали зачем-то алгоритм, которому нужно в 100 - 1000 раз больше CPU для повышения сжатия на 3-8 % по сравнению с zlib

Compress data more densely with Zopfli - Google Developers Blog
http://googledevelopers.blogspot.nl/2013/02/compress-data-more-densely-with-zopfli.html

при том, что в 7-zip сто лет в обед есть оптимизированный тот же самый Deflate, который даёт такой же выигрыш по сжатию гораздо меньшими усилиями:
"For ZIP and GZIP formats, 7-Zip provides a compression ratio that is 2-10 % better than the ratio provided by PKZip and WinZip"

рассказать им что ли?..
Автор: Snoopak96
Дата сообщения: 23.09.2012 15:32
Bulat_Ziganshin
v14 как-то больше нравится, всё просто и понятно
Автор: insorg
Дата сообщения: 23.09.2012 16:25
Имхо, самым компактным и удобным вариантом было бы нечто такого типа:

Proceeded:                 58%
Files:               2823/5447
Bytes:       24984984/52046849
Compressed:    4984984/2046849
Ratio:                     72%
Time:        01:02:03/20:22:24


На первом месте - процент обработанного, далее - количество файлов (сделано/всё) и аналогично байты общие и обработанные, после этого логичнее всего показывать процент сжатия, и в конце - время по схеме [прошло/общее] или [прошло/осталось].

Как вариант, можно время разделить:

Обработано: 58%
Файлы: 2823/5447
Всего байт: 24984984/2046849
Сжатых байт: 4984984/2046849
Степень сжатия: 72%
Прошло: 01:02:03
Осталось: 20:22:24


Или даже так...

Proceeded:                 58%    Time:        01:02:03/20:22:24    
Files:               2823/5447    Ratio:                     72%    
Bytes:       24984984/52046849    Compressed:    4984984/2046849    



з.ы.
Числа взяты рандомные, просто для наглядности что как должно выглядеть.
Автор: Bulat_Ziganshin
Дата сообщения: 24.04.2013 13:28
sabio
да я вообще не понимаю, почему гугл пользуется устаревшим deflate вместо прогрессивного freearc
Автор: sabio
Дата сообщения: 24.04.2013 14:04
Bulat_Ziganshin

Цитата:
да я вообще не понимаю, почему гугл пользуется устаревшим deflate вместо прогрессивного freearc

это, конечно, да - FreeArc рулит!

но, к сожалению, не везде его (сейчас) получится использовать
например, PNG основан на Deflate или, скажем, сжатие HTTP трафика
Автор: sabio
Дата сообщения: 23.09.2012 17:37
Bulat_Ziganshin

Цитата:
Another proposal for idea from v9+v10

как-то не интуитивно получается - "знаменатели" слева от "числителей"
(Speed = Bytes / Time, Ratio = Compressed / Bytes)
Автор: Edison007007
Дата сообщения: 27.04.2013 11:17
1. При попытки заменить при распаковке существующий файл с атрибутом "Скрытый" / "Только чтение" получаем ошибки:
GUI: "FileName": open: permission denied (Permission denied).
Uharc.exe: ERROR: can't open file "FileName" | с атрибутом "Только чтение" - распаковывается нормально.
Arc.exe:"FileName": open: permission denied (Permission denied).

2. Если начать распаковывать архив, нажать "отмена", то можно получить следующиe ошибки:
2.1: Распаковываем частично (через GUI папка/файл(ы)): ArcExtract.hs:152:56-126-Non-exhaustive patterns in lambda. Повторное нажатие "отмена": User error.
2.2: Распаковываем весь архив, через меню: wclose: invalid argument (Bad file description).
2.3: Распаковываем весь архив через GUI: User error - два раза. Повторное нажатие "отмена": User error -> CompressionLib_dbHm: interrupted.
После пунктов 2.1 и 2.3, FreeArc закрывается.
Было бы неплохо если распаковку можно было прерывать без ошибок
Автор: insorg
Дата сообщения: 23.09.2012 18:08
Точно, забыл про скорость:

Proceeded:                 58%    Files:               2823/5447    
Compressed:    4984984/2046849    Ratio:                     72%    
Speed:                5204kb/s    Time:        01:02:03/20:22:24    
Автор: Bulat_Ziganshin
Дата сообщения: 27.04.2013 14:59
just one screenshot of my current work

C:\>timer exdupe.exe -o -x0 -t12 -v5 i:\4g nul
COMPRESSED 4,531,060,447 bytes in 1 file(s) into 3,675,346,418 bytes

Kernel Time = 1.388 = 00:00:01.388 = 17%
User Time = 48.953 = 00:00:48.953 = 604%
Process Time = 50.341 = 00:00:50.341 = 621%
Global Time = 8.096 = 00:00:08.096 = 100%


C:\>srep64g.exe -m0 -l4k -nomd5 -mmap -s22. I:\4g nul
100%: 4,531,060,447 -> 3,603,337,912: 79.53%. Cpu 597 mb/s (7.238 sec), real 591 mb/s (7.315 sec) = 99%

Kernel Time = 0.936 = 00:00:00.936 = 12%
User Time = 7.238 = 00:00:07.238 = 98%
Process Time = 8.174 = 00:00:08.174 = 111%
Global Time = 7.347 = 00:00:07.347 = 100%

Добавлено:
Edison007007
1. посмотрю
2. да, там большие проблемы с обработкой ошибок. к сожалению, надо основательно код переписать чтобы их решить. планируется в следующей версии

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

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


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