Hello FPC-Pascal,
Tuesday, January 26, 2010, 4:14:07 PM, you wrote:
>> Yes and the hunting was not easy :( fortunatly the code is quite
>> small.
MK> Cool! Many thanks for that fix! I was reviewing the code for nearly two
MK> days without any usable result.
Well I use a quite simple approach a l
On Tue, 26 Jan 2010 13:51:35 +0100, JoshyFun wrote:
> Hello FPC-Pascal,
>
> Tuesday, January 26, 2010, 7:52:08 AM, you wrote:
>
> GG> I am planning on using LZMA in the future (no timeframe available
yet),
> but
> GG> could you guys make the fixed code available somewhere in a
repository
> or
>
Hello FPC-Pascal,
Tuesday, January 26, 2010, 7:52:08 AM, you wrote:
GG> I am planning on using LZMA in the future (no timeframe available yet), but
GG> could you guys make the fixed code available somewhere in a repository or
GG> as a sub-project of Lazarus CCR?
More tests should be applied as I
JoshyFun wrote:
>
> Found the bug in URangeDecoder.pas
I am planning on using LZMA in the future (no timeframe available yet), but
could you guys make the fixed code available somewhere in a repository or
as a sub-project of Lazarus CCR?
Otherwise others developers downloading the LZMA SDK from
Hello FPC-Pascal,
Monday, January 25, 2010, 7:14:05 PM, you wrote:
>> I hope to have some spare time this afternoon to test it, as I also
>> need LZMA decompress in 64 bit.
MK> I checked it: Decompressing files on 64bit-machines which were compressed
MK> on 32bit-linux does not work. Which means:
>>> So the question a 32 bits compressed LZMA can be decompressed with 32
>>> bits "decode", and the same stream decompressed with the 64 bits
>>> version ?
> MK> I'll try, but I think it won't work.
>
> I hope to have some spare time this afternoon to test it, as I also
> need LZMA decompress in
Hello FPC-Pascal,
Monday, January 25, 2010, 2:27:00 PM, you wrote:
MK> I cpmpressed a stream with the 64bits version. I can uncompress it
MK> successfully on 32bit, but not on 64bit.
MK> I haven't tried to decompress 32bit compressed files under 64bit, but
MK> decompressing files compressed under
> Strange, apparently shl/shr are not automatically changed to 64 bit when
> compiling for a 64 bit platform. I don't know why that is the case.
>
> You can force a 64 bit shift by typecasting v to int64.
> At least the person who translated it supposedly knows it. Otherwise, you
> have to go bac
> The stream is compressed with 32 bits version ? Or are the 64 bits
> compressed files the ones that fail to be decompressed in 64 bits also
> ?
I cpmpressed a stream with the 64bits version. I can uncompress it
successfully on 32bit, but not on 64bit.
I haven't tried to decompress 32bit compresse
On 25 Jan 2010, at 13:29, Matthias Klumpp wrote:
>
>> I think the code there is currently actually only correct on 64 bit
>> platforms and wrong on 32 bit platforms: it seems that it should read an
>> int64 in little endian format and converts it on-the-fly to the native
>> endianess, but that c
Hello FPC-Pascal,
Monday, January 25, 2010, 1:29:48 PM, you wrote:
MK> The problem is that no Pascal developer knows this code. It was translated
MK> from Java code.
MK> Can you imagine another difference between 64bit and 32bit which may cause
MK> those error? The bitshifts result in the same v
> I think the code there is currently actually only correct on 64 bit
> platforms and wrong on 32 bit platforms: it seems that it should read an
> int64 in little endian format and converts it on-the-fly to the native
> endianess, but that currently only happens correctly on 64 bit platforms.
I
>
On 23 Jan 2010, at 15:12, Matthias Klumpp wrote:
> On Sat, 23 Jan 2010 14:19:23 +0100, Jonas Maebe
> wrote:
>>> Does anyone know why the code fails to work?
>>
>> Not really, but at least the following is will be evaluated differently
>> on 32 and 64 bit platforms:
>>
>> [...]
>> v is a byte,
On Sat, 23 Jan 2010 14:19:23 +0100, Jonas Maebe
wrote:
>> Does anyone know why the code fails to work?
>
> Not really, but at least the following is will be evaluated differently
on
> 32 and 64 bit platforms:
>
> [...]
> v is a byte, i is a longint (integer in Delphi mode). Outsize is an
int64.
> Does anyone know why the code fails to work?
Not really, but at least the following is will be evaluated differently on 32
and 64 bit platforms:
>
> ###
> ~~~
> CodeSequence [-1-]:
> -
>
> var inStre
Hello!
I use the LZMA-SDK for Pascal to compress files. (
http://www.birtles.org.uk/programming/ )
I can compress files on 64bit and 32bit architecture. But if I try to
decompress LZMA-Compressed files on AMD64, it fails.
I use code [-1-] to decompress files. The action works perfectly on i386,
but
16 matches
Mail list logo
