Скачал исходники LZO - не пашет (порт Андрея Кудрявцева). Валится где-то в процедуре compress. Пытался сжать строку, так:

function LZOCompressStr(s: string): string;
var
 buffer: Pointer;
 size: Integer;
begin                        
 compress(PChar(s), Length(s), buffer, size);
 SetLength(result, size);
 Move(buffer^, pointer(result)^, size);
 FreeMem(buffer);
end;

В чём тут дело?

Сам не видел порта, но мб под buffer надо память выделять?

Ну это понятно, что надо бы. Но, с другой стороны, для теста я использовал очень короткие строки, которые вполне способны расположиться в стеке. Да и как можно выделить память под буфер, размер которого я изначально не знаю (могу знать только после того, как сжатие отработает)? Валится-то где-то в функции compress, сейчас не вспомню, но где-то в первой трети.

Автор порта, я так понял, здесь уже не появляется? Я в сжатии полный профан :(

А алгоритм самое то, что нужно: +2 кило кода к программе для компрессии и декомпрессии. И степень сжатия мне вполне подходит.

Да, надо было выделить память. Я неправильно понял readme, думал, compress сама выделяет память для буфера. Оказалось, нет. Сжатие заработало. Теперь не могу заставить работать декомпрессию :( Распаковывает какую-то шнягу......

покеж код, может посоветую чего =)

Извините за небольшой оффтоп, а LZO сильно лучше DEFLATE (zlib, gzip, zip, etc.)?

> покеж код

тот же самый, за исключением выделения памяти под буфер. В обоих случаях код один, разница только в функции (compress или decompress).
Но я нашёл проблему. Вместо decompress вызывал decompress_safe - заработало. Только глючно как-то... Ладно, домой приду, исходники скину "на посмотреть" :)


> LZO сильно лучше DEFLATE

неа. это адаптивное сжатие, типа LZH, жмёт не очень. Но на некоторых данных жмёт вполне ничего, при том что добавляет около 2 килобайт кода. Для моего случая это оптимальный вариант.

=BuckLr= ©   (24.04.08 11:25) [6]

> Но на некоторых данных жмёт вполне ничего, при том что добавляет около 2 килобайт кода. Для моего случая это оптимальный вариант.

Это на распаковщик? Вот тут есть tinf, распаковывает DEFLATE и добавляет 2 кб кода. Может, стоит портировать на Delphi.
http://www.ibsensoftware.com/download.html

> Это на распаковщик?

и распаковщик, и запаковщик :) 2 кило я примерно измерял, просто размер файла посмотрел до и после, так что весьма приблизительно...


> Может, стоит портировать на Delphi

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

> оки, глянем, что за зверь. Правда, я тут на днях пытался
> портануть lzma, но вскоре понял, что не осилю :)

Я в принципе, порт сделал, Encoder+Decoder дают 26к. Правда от классов не избавился, постараюсь заняться в ближайшее время. Еще бы кто сделал совместимость с 7z, вообще было бы хорошо. А то я боюсь не скоро доберусь...

> Я в принципе, порт сделал
Выложи, плиз! Хотя бы так, как есть, я хочу использовать его в следующей работе. Хотя на объекты вряд ли рискну перевести - моцка может не хватить :)

www.kolnmck.ru/KOL_LZMA.rar

Спасибо.

Да. Тут, навскидку, классы убрать несложно.

Не сложно, время только нужно, а его не хватает как всегда....:(

Убил классы, на полтора кило умеменьшилось.

Обновил архив

> Обновил архив

В исходники ещё не глядел, но потестил демо, оказалось: вылетает, если параметры сжатия установить по максимуму :( посмотри, мож где какой ляп..

> В исходники ещё не глядел, но потестил демо, оказалось:
> вылетает, если параметры сжатия установить по максимуму
> :( посмотри, мож где какой ляп..

Нет никакого ляпа. Вылетает если Dictionary Size поставить больше 26. В этом случае выделяется буфер больше 500 мб, соответственно и валится... Можно попробовать переделать работу с памятью, но я не буду. По моему на фиг не нужно, архиватор сжирающий 500 мб - перебор. Не зря же рекомендуют  Dictionary Size = 26 (~16мб).

mdv, а чем не понравился родной С код? Его несложно в дельфи слинковать. Родной С декомпрессор из LZMA SDK - 2-3кб добавляет.
LZO - отличается быстрой распаковкой (до 20МБ/с на Pentium 133 по словам автора), малым кодом распаковки (байт 200 распаковщик, не требует памяти кроме как под выходной буфер), слабым сжатием.
Еще есть NRV (библиотека UCL) того же автора, этот сжимает и распаковывает медленнее, зато обычно жмет лучше чем Deflate.

Мне нужно было под WinCE.
А потом, я же не делал порт из С в делфи, а просто под Кол адаптировал.:)
А паскалевский, код который я брал, вроде как оффициальный порт С в паскаль. А про память - это как раз упаковщик, длина словаря.