» FreeArc (часть 4)

REP + LZ4B

FreeArc v2012-11-28
Протестировал различные комбинации, результаты с размером чанка 128 здесь:
[more] [/more]
(Папка 566 Мб – та, что передал мне Paramon111)
В первой таблице приведены типовые данные. Видно, что зависимость от параметров rep достаточно слабая. Во второй таблице собраны наиболее значимые результаты, по этим данным наиболее оптимальный вариант rep:1g:176:c128:d1m:s128+xlz4.

Результаты с размером чанка c64 и наиболее значимыми результами, здесь:
[more] [/more]
Зависимость от параметров более существенная, по имеющимся данным наиболее оптимальный вариант rep:1g:128:c64:d1m:s64+xlz4.

Для размера чанка c256 отклонение от параметров rep:1g:256:c256+xlz4 во всех моих тестах без исключения приводило к ухудшению сжатия.

Аналогично для чанка c512: rep:1g:512:c512+xlz4

Специального исследования по влиянию параметра b у lz4 не проводил (как обычно, где-то его увеличение до 64 Mb улучшает сжатие, где-то наоборот). Но возможно, уменьшение его до 512к было бы более оптимально. (и вряд ли займусь этим, поскольку улучшения на уровне менее 0,1 %, что не так уж и важно)

Получился такой набор оптимальных сочетаний по возрастанию степени сжатия и времени (в скобках присвоенные мной названия методам):
rep:1g:512:c512+xlz4 (m800)
rep:1g:256:c256+xlz4 (m80)
rep:1g:176:c128:d1m:s128+xlz4 (m801)
rep:1g:128:c64:d1m:s64+xlz4 (m802)

REP + TOR:3

FreeArc v2012-12-12
Протестировал влияние параметров rep на размер архива.

Первый случай.
-mrep:1g:...:c128+xtor:3:4m:h16k (= –m810)
Результаты приведены в таблице
[more] [/more]
Здесь представлены результаты тестирования тех же папок, что в предыдущем случае с LZ4B, оптимум для чанка c128 получился тот же самый
-mrep:1g:176:c128:d4m:s128+xtor:3:4m:h16k

Второй случай.
-mrep:1g:...:c64+xtor:3:4m:h32k (= –m81)
[more] [/more]
Оптимум получается
-mrep:1g:112:c64:d4m:s64+xtor:3:4m:h32k
Здесь уже видно отличие от результатов с LZ4b, на тех же данных. Там оптимум был для -mrep:1g:128:…


Добавлено:
Третий случай
-mrep:1g:...:c32+xtor:3:4m:h64k (= –m811)
[more] [/more]
Вблизи оптимума несколько методов:
-mrep:1g:80:c32:d4m:s48+xtor:3:4m:h64k
-mrep:1g:64:c32:d4m:s48+…
-mrep:1g:80:c32:d4m:s40+…
-mrep:1g:64:c32:d4m:s40+…
(Примечание. Для папки 359 536 713 минимум равен 62 825 826 для …176:c64:d4m:s64…)

vishyakov
а у меня подпольный стук

я просто подумал раз есть псевдометод tempfile который просто говорит архиватору читать данные с темп-файла
то почему бы не указать что результат упаковки не сохранять непросто чтобы упаковать при прожорливости метода
а чтобы не ждать долго операции завергения внешнего(как это часто бывает с ГБ файлами precomp, ну и с 3,4[и >] гб файлами srep) а подложить уже готовенький файл

vishyakov
Т. е. не молчите, скажите больше существенных (с вашей точки зрения) подробностей: какая ошибка, как часто появляется, как возможно её воспроизвести (подробно), какой архив и можете ли вы его приватно выложить Булату.

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

4eLLka
из окна самой программы - нет. а вот перетаскивание правой кнопкой мыши в Explorer я сейчас делаю

Добавлено:
kalpak
реализовать это можно - извлечение промежуточных потоков и их вставку назад. просто это тоже такая второстепенная вещь. можно же на потоках подобрать оптимальную схему сжатия и затем сжать всё с нуля:

arc a a -m0 --nodir -dsgernp tempfile.1 files...
arc a a -m=precomp --nodir tempfile.2 tempfile.1
arc a a -m=srep --nodir tempfile.3 tempfile.2
arc a a -m=lzma --nodir tempfile.4 tempfile.3
...

и окончательное сжатие
arc a a archive files... -m=precomp+srep+lzma

new alpha version:

-mc option: new ways to modify compression method by adding/replacing/removing specified algorithms
Compression page: added "Experimental compressors" frame
arc.ini: updated for precomp042/srep3 compatibility
precomp 0.4.2 and srep 3.0 executables added to the FreeArc\bin directory


Цитата:

New syntax of -mc option (backward-compatible with the old one):

-mc[GROUPS][:]OPERATION

where GROUPS may be empty or list of compression groups, where '$default' means the default group. Examples are:

$obj
$default
$default,$obj

Optional ':' is just a syntax sugar

OPERATION may be one of the following:

'-$group' or '$group-' means "remove $group from compression definition"
'-method' or 'method-' means "remove method from compression definition". RAR-compatible shortcuts like -mca- are also supported
'+method' or 'method+' means "add method at the head of every compression chain", f.e. -mc+precomp042:c-
'method1/method2' means "replace method1 with method2", f.e. -mc:rep/srep:mem256mb

GROUPS may be used to limit OPERATION to the specified groups, f.e. -mc$default,$obj:+precomp042:c-

--------------------------------------------------------------------------------------------------------------

Using these options, FreeArc implements "Exprerimental compressor" checkboxes in the following way:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/dispack070
srep: -mc:rep/srep:mem256mb
precomp: -mc$default,$obj:+precomp042:c-:t-j
intense: -mc$default,$obj:+precomp042:c-:intense:t-j
jpeg: -mc$default,$obj:+precomp042:c-
intense+jpeg: -mc$default,$obj:+precomp042:c-:intense

REP speed improvements:

REP: up to 4x faster due to multithreading and anchored hashing proposed by Eugene Shelwien
REP:c sets size of hashed chunks (f.e. rep:256:c256 is a quick-and-dirty replacement for rep:512)
REP: for rep:512..257/256..129/... default is :c128/64/...
REP: default hashsize = min(1/4,16/chunksize)*BlockSize


Цитата:

D:\>old_fazip rep:1g dll4g.dll nul
100%: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 358 mb/s, real 327 mb/s
D:\>new_fazip rep:1g:c256 dll4g.dll nul
100%: 4,531,060,447 -> 3,063,642,637: 67.61% Cpu 482 mb/s, real 1299 mb/s

D:\>old_fazip rep:1g:32 dll4g.dll nul
100%: 4,531,060,447 -> 2,245,307,773: 49.55% Cpu 117 mb/s, real 113 mb/s
D:\>new_fazip rep:1g:32:c16 dll4g.dll nul
100%: 4,531,060,447 -> 2,271,868,087: 50.14% Cpu 182 mb/s, real 274 mb/s

Improved method definitions:

-m1: added REP preprocessing (compression improved by 10-20%, speed remained the same thanks to the new ultra-fast REP engine)
-m1: removed separate $exe group in order to reduce number of disk seeks
-m2..m4: modified REP settings, utilizing new REP implementation in order to improve speed/compression ratio
-m3t/mex3t: modified so that compression runs slower but decompression is faster


Цитата:

D:\>old_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 435,620,877 bytes. Ratio 53.7%
Compression time: cpu 13.10 secs, real 1.76 secs. Speed 459,651 kB/s
D:\>new_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 369,825,442 bytes. Ratio 45.6%
Compression time: cpu 12.68 secs, real 1.84 secs. Speed 441,616 kB/s

D:\>old_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 354,958,875 bytes. Ratio 43.7%
Compression time: cpu 37.72 secs, real 5.41 secs. Speed 149,680 kB/s
D:\>new_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 353,083,639 bytes. Ratio 43.5%
Compression time: cpu 36.54 secs, real 5.11 secs. Speed 158,553 kB/s

D:\>old_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 340,430,540 bytes. Ratio 42.0%
Compression time: cpu 80.15 secs, real 12.00 secs. Speed 67,514 kB/s
D:\>new_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 338,976,484 bytes. Ratio 41.8%
Compression time: cpu 78.91 secs, real 11.33 secs. Speed 71,530 kB/s

D:\>old_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 326,333,902 bytes. Ratio 40.2%
Compression time: cpu 184.19 secs, real 24.19 secs. Speed 33,503 kB/s
D:\>new_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 324,126,352 bytes. Ratio 39.9%
Compression time: cpu 182.58 secs, real 24.01 secs. Speed 33,748 kB/s


D:\>old_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,840,442 bytes. Ratio 25.8%
Compression time: cpu 9.02 secs, real 1.58 secs. Speed 63,488 kB/s
Testing time: cpu 12.03 secs, real 2.14 secs. Speed 46,704 kB/s
D:\>new_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,221,121 bytes. Ratio 25.2%
Compression time: cpu 12.00 secs, real 2.18 secs. Speed 45,869 kB/s
Testing time: cpu 8.42 secs, real 1.61 secs. Speed 61,993 kB/s

Other changes:

CRC in arc/unarc/dll/sfx became 2x faster (500->1000 mb/s); CRC in facompress.dll still runs at 1600 mb/s
I/O: reading files to compress in 1mb chunks (optimized for Vista/Win7)
DICT: fixed bug with error -6 at end of decompression (detectable with -m=bcj+dict -t)
i18n: NEW Portuguese Standard translation by Nuno Rego!

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


Цитата:

из окна самой программы - нет. а вот перетаскивание правой кнопкой мыши в Explorer я сейчас делаю

а почему сразу по человечески сделать нельзя? чтобы ЛКМ и в нужную тебе папку

vasulpr
потому что GUI основан на gtk, а там Drag&Drog вроде не очень работает
(может из за кроссплатформенности?)

На люнекс системах сидит лишь 0,04% пользователей, так может ну ту кросс платформенность?

Новая альфа-версия:
Опция -mc: позволяет изменить метод сжатия путем добавления/замены/удаления заданных алгоритмов
Страница сжатия: добавлена вкладка "Экспериментальные алгоритмы"
arc.ini: обновлен для совместимости с precomp042/srep3
Исполняемые файлы precomp 0.4.2 и srep 3.0 добавлены в директорию FreeArc\bin

Цитата:

Новый синтаксис опции -mc (обратно-совместимый со старым):

-mc[ГРУППЫ][:]ОПЕРАЦИЯ

где ГРУППЫ может быть пустым или содержать список групп файлов, причем '$default' означает группу по умолчанию. Примеры:
$obj
$default
$default,$obj

Опциональный символ ':' является разделителем

ОПЕРАЦИЯ может быть одна из следующих:
'-$group' или '$group-' означает "исключить $group при сжатии"
'-method' или 'method-' означает "исключить method при сжатии". RAR-совместимые команды, такие как -mca-, также поддерживаются
'+method' или 'method+' означает " добавить method в начало каждой цепочки сжатия", например -mc+precomp042:c-
'method1/method2' означает "заменить method1 на method2", например -mc:rep/srep:mem256mb

ГРУППЫ могут быть использованы для ограничения ОПЕРАЦИИ определенными группами файлов, например -mc$default,$obj:+precomp042:c-

--------------------------------------------------------------------------------------------------------------

Используя эти опции, FreeArc реализует чекбоксы "Экспериментальных алгоритмов" следующим образом:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/dispack070
srep: -mc:rep/srep:mem256mb
precomp: -mc$default,$obj:+precomp042:c-:t-j
intense: -mc$default,$obj:+precomp042:c-:intense:t-j
jpeg: -mc$default,$obj:+precomp042:c-
intense+jpeg: -mc$default,$obj:+precomp042:c-:intense

Улучшение скорости REP:
REP: ускорен в 4 раза благодаря многопоточности и надежному хешированию предложенному Евгением Шелвиным
REP:c устанавливает размер хешируемых блоков (например, rep:256:c256 это более быстрая, но менее аккуратная замена rep:512)
REP: для rep:512..257/256..129/... значения по умолчанию следующие :c128/64/...
REP: по умолчанию hashsize = min(1/4,16/chunksize)*BlockSize

Цитата:

D:\>old_fazip rep:1g dll4g.dll nul
100%: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 358 mb/s, real 327 mb/s
D:\>new_fazip rep:1g:c256 dll4g.dll nul
100%: 4,531,060,447 -> 3,063,642,637: 67.61% Cpu 482 mb/s, real 1299 mb/s

D:\>old_fazip rep:1g:32 dll4g.dll nul
100%: 4,531,060,447 -> 2,245,307,773: 49.55% Cpu 117 mb/s, real 113 mb/s
D:\>new_fazip rep:1g:32:c16 dll4g.dll nul
100%: 4,531,060,447 -> 2,271,868,087: 50.14% Cpu 182 mb/s, real 274 mb/s

Улучшения методов сжатия:
-m1: добавлен препроцессор REP (сжатие улучшилось на 10-20%, скорость осталась та же благодаря новому супер-быстрому движку REP)
-m1: удалена отдельная группа $exe, чтобы уменьшить кол-во перемещений головки диска при сжатии
-m2..m4: изменены настройки REP, используя возможности нового REP для улучшения скорости/сжатия
-m3t/mex3t: изменен таким образом, что сжатие идет дольше, но распаковка быстрее

Цитата:

D:\>old_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 435,620,877 bytes. Ratio 53.7%
Compression time: cpu 13.10 secs, real 1.76 secs. Speed 459,651 kB/s
D:\>new_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 369,825,442 bytes. Ratio 45.6%
Compression time: cpu 12.68 secs, real 1.84 secs. Speed 441,616 kB/s

D:\>old_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 354,958,875 bytes. Ratio 43.7%
Compression time: cpu 37.72 secs, real 5.41 secs. Speed 149,680 kB/s
D:\>new_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 353,083,639 bytes. Ratio 43.5%
Compression time: cpu 36.54 secs, real 5.11 secs. Speed 158,553 kB/s

D:\>old_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 340,430,540 bytes. Ratio 42.0%
Compression time: cpu 80.15 secs, real 12.00 secs. Speed 67,514 kB/s
D:\>new_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 338,976,484 bytes. Ratio 41.8%
Compression time: cpu 78.91 secs, real 11.33 secs. Speed 71,530 kB/s

D:\>old_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 326,333,902 bytes. Ratio 40.2%
Compression time: cpu 184.19 secs, real 24.19 secs. Speed 33,503 kB/s
D:\>new_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 324,126,352 bytes. Ratio 39.9%
Compression time: cpu 182.58 secs, real 24.01 secs. Speed 33,748 kB/s


D:\>old_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,840,442 bytes. Ratio 25.8%
Compression time: cpu 9.02 secs, real 1.58 secs. Speed 63,488 kB/s
Testing time: cpu 12.03 secs, real 2.14 secs. Speed 46,704 kB/s
D:\>new_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,221,121 bytes. Ratio 25.2%
Compression time: cpu 12.00 secs, real 2.18 secs. Speed 45,869 kB/s
Testing time: cpu 8.42 secs, real 1.61 secs. Speed 61,993 kB/s

Остальные изменения:
CRC в arc/unarc/dll/sfx стал в 2 раза быстрее (500->1000 mb/s); для сравнения, CRC в facompress.dll имеет скорость 1600 mb/s
I/O: чтение файлов для сжатия блоками по 1мб (оптимизировано под Vista/Win7)
DICT: исправлен баг с ошибкой -6 в конце распаковки (появлялась при -m=bcj+dict -t)
i18n: НОВАЯ локализация: Португальский Стандартный от Nuno Rego!

(перевод Шегората)

vasulpr
GUI-система GTK-кроссплатформенная
может поэтому Drag&Drop там непросто сделать
(уже ен помню, но вроде когда спрашивали, то был такой ответ)

vasulpr

Цитата:

лишь 0,04% пользователей, так может

А если себя в проценты перевести? (делите на 6 млрд и умножаете на 100).

Цитата:

ну ту кросс платформенность

Не в ней одной дело.

Цитата:

пожалуйста сделайте горячие клавиши независимыми от языка

А вот это проблема реализации GTK+, и ей уже не один год.

Цитата:

Цитата:
лишь 0,04% пользователей, так может

А если себя в проценты перевести? (делите на 6 млрд и умножаете на 100).

0,04% от общего количества пользователей ФА, а не всего населения планеты


Цитата:

А вот это проблема реализации GTK+, и ей уже не один год.

т.е. о нормальной работе горячих клавиш можно забыть?

Цитата:

так может ну ту кросс платформенность?

предлагаешь ещё 4 года делать новую версию только ради d&d?

i've set up Mercurial repository: http://source.freearc.org:8002/freearc/, although URL may be changed later

juvaforza
не ну ведь просто тупо удобно ^/^

Добрый день, Bulat_Ziganshin
freearc.exe при архивировании с удалением файлов, иногда не выдает ошибки (в логе пишет "архив успешно создан"), удаляет что может (могут остаться пустые папки), но не переименовывает freearc1.tmp в "имя_архива.arc".
Возможно ли сделать удаление после переименования и с каким-нибудь прогресс-баром?
Прошу прощения за сумбурное изложение. Версия альфа от 23 ноября и от 5 февраля.

vasulpr

Цитата:

0,04% от общего количества пользователей ФА, а не всего населения планеты

Ну, может, пользователи окон в N раз чаще сносят систему.

Цитата:

т.е. о нормальной работе горячих клавиш можно забыть?

Из всех искусств для нас важнейшим является ... Gimp&Inkscape. Т. е., возможно, проблем не будет в реализации 3-й версии GTK+. Сейчас можно поставить Англ. раскладку основной по умолчанию.

Bulat_Ziganshin

Экспериментирую с новой версией.

В методе -m1 при замене:
-m1 -mc:rep/rep:96m:64:c64 -mc:4x4/4x4:tor:3:2m:h128k
у меня обычно уменьшается время и улучшается сжатие, например:

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.
Compressed 1,026 files, 758,272,286 => 614,504,948 bytes. Ratio 81.0%
Compression time: cpu 30.90 secs, real 8.75 secs. Speed 86,655 kB/s

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.
Compressed 1,026 files, 758,272,286 => 613,661,514 bytes. Ratio 80.9%
Compression time: cpu 28.27 secs, real 8.41 secs. Speed 90,147 kB/s

Проверьте на своих данных.

Добавлено:
Вот результат для вашего же файла
http://freearc.org/HFCB.aspx
(мой компьютер примерно в 1,5 раза медленнее)

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,295,281,921 bytes. Ratio 30.5%
Compression time: cpu 104.02 secs, real 79.33 secs. Speed 53,500 kB/s

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:128:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,281,669,520 bytes. Ratio 30.1%
Compression time: cpu 100.78 secs, real 79.89 secs. Speed 53,126 kB/s

Здесь время примерно одинаковое.

Добавлено:
Извиняюсь, по ошибке rep:...128:с64.
Привожу для 64:с64

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,278,343,363 bytes. Ratio 30.1%
Compression time: cpu 101.21 secs, real 79.17 secs. Speed 53,605 kB/s

juvaforza
это что за язык? ))
можно по понятнее

kalpak

Цитата:

можно по понятнее

Как поменять «Язык ввода по умолчанию» на «Английский» - написано здесь -> ergosolo.ru/reviews/hotkeys/typewriter. Тогда клавиши Ctrl+* будут работать и при русской раскладки.

По поводу GTK+ 3 (что это такое - узнать не проблема): просто ещё никто не знает, будут ли сочетания работать как надо, или не будут - требовать от разработчиков исправления ошибок второй версии не приходиться, а в их рассылке и багтрекере об этом много, но почти ни о чем не говориться. Для прояснения этого вопроса можно ожидать эволюционного развития ситуации - перехода популярных программ (напр. Gimp, Inkscape) на тройку (точно неизвестно когда, API ведь поменялся), в связи с этим появления официальной реализации для Windows. Можно поступить и по-другому - воспользоваться неофициальной реализацией (download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/), и с её помощью скомпилировать любое простое приложение под тройку.

имеет смысл проверить на промежуточном 128:c128, по отдельности изменения в rep и tor, на большем числе файлов и исключить влияние I/O (в частности слить 1031 файл в один)

Цитата:

У меня архив проходит тестирование, но при распаковке происходит ошибка.

Всё, разобрался. Оказывается, чтобы увидеть сообщение об ошибке, надо раскрыть комбобокс...

juvaforza
да я не про сочетания
Drag&Drop также из за особенностей реализации не пашет в GTK+?
и что мешает его подкрутить?(ведь в хаскелл можно вызывать сишные функции)
или там сложность возникает какая-то?

Цитата:

имеет смысл проверить на промежуточном 128:c128

Вообще-то я проверяю все, начиная от 256:с256 и до 16:с16, включая 128:с64.
Проверять долго. (На вскидку, крайние варианты: 256:с256 и 16:с16 малоинтересны.
Вариант 128:с128 интересен, скорее всего для самых быстрых tor:3:...:h64k)


Цитата:

по отдельности изменения в rep и tor

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

kalpak
По-моему, Булат сказал, что его трудоемней трудоемного (*-)) подкрутить, т. к., в частности, для разных ОС это по-разному реализовывается. В том же Gimp он (D&D) функционирует.

Добавлено:

Цитата:

Drag&Drop также ... не пашет в GTK+

В FreeArc он не пашет, т. к. не предусмотрен.

kalpak
насколько я помню, d&d файлов не реализован на уровне gtk/win32

1. Качаю архив и выбираю открыть http://www.snort.org/downloads/1416
2. Захожу в FA во второй архив - новое окошко открывается.
3. Выбираю директорию doc - Extract.
4. Получаю ошибку что архива нет.

Добавлено:
Так же есть проблема если это действие выполнить несколько раз
Архив скачивается несколько раз Firefox
snort-2.9.2.1.tar.gz
snort-2.9.2.1.tar-1.gz
snort-2.9.2.1.tar-2.gz

Вложеный архив в первом открывается нормально. В последующих появляется проблема.
Похоже что проблема вызвана пересечением имён и как следствие созданием уникального имени с snort-2.9.2.1.tar-1 который FA незнает как открыть и появляется окошко Windows с предложение выбрать программу для открытия неизвестного типа файла.