Re: [fpc-pascal] a suggestion...
ϸòð Êîñàðåâñêèé ñ mail.ru wrote: > FK> Jonas Maebe wrote: >>> On 24 mei 2006, at 17:30, Florian Klaempfl wrote: >>> Not really because it is simply a tar ball of several .tar.gz. Because gzip is spread wider, we use this instead of bzip2/7zip. >>> Isn't bzip2 available more or less everywhere nowadays? (at least where >>> gzip is available, and in particular on Linux?) > FK> At least on debian woody it wasn't installed by default. No idea about > FK> sarge. > > > Just wondering: is RAR considered "spread wide"? No. > > I know that compressor is commercial, Thus everybody building releases needs to buy a rar license? > but uncompressor is not (sources > are available, if I remember right), and it > compresses sources better than gzip by 25% (often even more). There > are better compressors, they are free (sometimes even open source), > but support matters (dos, windows, pocket pc, linux, free bsd and > macos x versions are ready to download). > > Or is it completely unacceptable because it isn't free? So the fpc installer needs to deliver a unrar binary? Forget about this on Linux, this requires more maintainance work than fpc itself ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
Tomas Hajny wrote: > On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: > First parameter is in eax, second in edx (third one is ecx) >> TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the first >> TH> parameter can be still skipped (and the stack frame is probably not >> useful >> TH> in this case either). So you'd get: >> TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; >> TH> asm >> TH> movb %dl,%cl >> TH> rolb %cl,%al >> TH> end ['cl']; >> TH> Tomas >> >> 1. So, is there any problem with including this functions and bit checks >> (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great too)? > > I guess there is no problem in including it. The > only questions from my point of view are: > > 1) Are they useful in general, so that it would > make sense to include them either in FPC itself > (as opposed to some standalone unit)? - they must be available for all cpu platforms, so we need at least a generic implementation - for an efficient implementation, this needs a compiler patch so the compiler can really efficiently inline ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
On Thu, 25 May 2006, Florian Klaempfl wrote: > Tomas Hajny wrote: > > On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: > > > First parameter is in eax, second in edx (third one is ecx) > >> TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the first > >> TH> parameter can be still skipped (and the stack frame is probably not > >> useful > >> TH> in this case either). So you'd get: > >> TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; > >> TH> asm > >> TH> movb %dl,%cl > >> TH> rolb %cl,%al > >> TH> end ['cl']; > >> TH> Tomas > >> > >> 1. So, is there any problem with including this functions and bit checks > >> (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great too)? > > > > I guess there is no problem in including it. The > > only questions from my point of view are: > > > > 1) Are they useful in general, so that it would > > make sense to include them either in FPC itself > > (as opposed to some standalone unit)? > > - they must be available for all cpu platforms, so we need at least a > generic implementation > - for an efficient implementation, this needs a compiler patch so the > compiler can really efficiently inline I don't think these functions are so useful that they warrant a compiler patch. We can include them in some separate unit, but I would highly object against putting them in the system unit. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
Jeff Pohlmeyer wrote: >> Because gzip is spread wider, we use this instead of bzip2/7zip. > > I think the size saved by compressing FPC with bz2 would be much > greater than the size of downloading and installing a bzip2 extractor. Yes, but it requires extra work :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] unit name with dots
hi,does fpc support unit names with more than one dot or is planned?in delphi 7 you can compile this:// unit main.dprprogram main;uses test.sec;begin test.sec.doit;end.
// unit test.sec.pasunit test.sec;interfaceprocedure doit;implementationprocedure doit;begin writeln('anda');end;end.thanks,marianop
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
Florian Klaempfl wrote: > Tomas Hajny wrote: >> On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: >> > First parameter is in eax, second in edx (third one is ecx) >>> TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the >>> first >>> TH> parameter can be still skipped (and the stack frame is probably not >>> useful >>> TH> in this case either). So you'd get: >>> TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; >>> TH> asm >>> TH> movb %dl,%cl >>> TH> rolb %cl,%al >>> TH> end ['cl']; >>> TH> Tomas >>> >>> 1. So, is there any problem with including this functions and bit >>> checks >>> (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great >>> too)? >> >> I guess there is no problem in including it. The >> only questions from my point of view are: >> >> 1) Are they useful in general, so that it would >> make sense to include them either in FPC itself >> (as opposed to some standalone unit)? > > - they must be available for all cpu platforms, so we need at least a > generic implementation Generic implementation in Pascal has already been provided in this thread as well, so this isn't an issue. > - for an efficient implementation, this needs a compiler patch so the > compiler can really efficiently inline Would this apply for the operator case too? Isn't it then similar to shl/shr (which "just work" now as well - even without special inlining support)? Of course, this would only make sense if we're convinced about the general usefulness of such operators. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit name with dots
mariano podesta wrote:
> hi,
> does fpc support unit names with more than one dot or is planned?
>
> in delphi 7 you can compile this:
This looks to me like a delphi bug. A unit must be a valid pascal
identifier. Or is there any use in supporting this?
>
> // unit main.dpr
> program main;
>
> uses
> test.sec;
>
> begin
> test.sec.doit;
> end.
>
> // unit test.sec.pas
> unit test.sec;
>
> interface
>
> procedure doit;
>
> implementation
>
> procedure doit;
> begin
> writeln('anda');
> end;
>
> end.
>
> thanks,
> marianop
>
>
>
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
Michael Van Canneyt wrote: > > On Thu, 25 May 2006, Florian Klaempfl wrote: > >> Tomas Hajny wrote: >>> On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: >>> >> First parameter is in eax, second in edx (third one is ecx) TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the first TH> parameter can be still skipped (and the stack frame is probably not useful TH> in this case either). So you'd get: TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; TH> asm TH> movb %dl,%cl TH> rolb %cl,%al TH> end ['cl']; TH> Tomas 1. So, is there any problem with including this functions and bit checks (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great too)? >>> I guess there is no problem in including it. The >>> only questions from my point of view are: >>> >>> 1) Are they useful in general, so that it would >>> make sense to include them either in FPC itself >>> (as opposed to some standalone unit)? >> - they must be available for all cpu platforms, so we need at least a >> generic implementation >> - for an efficient implementation, this needs a compiler patch so the >> compiler can really efficiently inline > > I don't think these functions are so useful that they warrant a compiler > patch. They give the programmer access to CPU instructions which can speed up certain algorithms without the need to write assembler. > We can include them in some separate unit, but I would highly object against > putting them in the system unit. They make no sense then. Going through the whole calling sequence is slower imo than or'ing shl/shr: function brol(b: byte; c: byte): byte;inline; begin result:=(b shr (8-c)) or (b shl c); end; which can be inlined perfectly by the compiler. That's also why I added the endian conversion functions to the system unit, e.g. the compiler can benefit a lot if they are implemented in a CPU dependend way. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] rotating bits
> > Tomas Hajny wrote: > > > I guess there is no problem in including it. The > > > only questions from my point of view are: > > > > > > 1) Are they useful in general, so that it would > > > make sense to include them either in FPC itself > > > (as opposed to some standalone unit)? Well, they are useful for specific tasks and algorithms. There were reasons to include them in i386 architecture. But they are obviously less common, than shl/shr. My answer on question two explains, why their place is in units. > > > 2) If they are to be included, should they be > > > included as functions, or possibly even as > > > operators (similarly to existing shl/shr)? Shl/shr already have a little issue: var b0,b1: byte; begin b0:=70; b1:=b0 shl 3; end. emits warning. They do not really pay attention (on intention?) to the size of what they shift. Rol/ror should pay great attention to the size of data they shift. They cannot be implemented in the same manner. > > > 3) If we decide to include them as functions, > > > where (which unit)? Any rtl unit without a lot of $defines, overloading and redefinings should fit. Functions should have names, indicating size: unexpected typecasting may be fatal. > > - they must be available for all cpu platforms, so we need at least a > > generic implementation Even I have supplied some bulky implementation in one of the previous messages (I only wanted them to work, because my knowledge of FPC intrinsics is obviously not enough to ensure fast work). > > - for an efficient implementation, this needs a compiler patch so the > > compiler can really efficiently inline Maybe, it should be done regardless of "rotating bits" topic. > I don't think these functions are so useful that they warrant a compiler > patch. > We can include them in some separate unit, but I would highly object against > putting them in the system unit. > Michael. I don't understand any of your arguments, but it doesn't matter much. Any rtl unit without much overhead suits great: I mean, including them to objfpc or sysutils would be strange. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit name with dots
On Wed, 24 May 2006 10:42:30 -0300 "mariano podesta" <[EMAIL PROTECTED]> wrote: > hi, > does fpc support unit names with more than one dot or is planned? > > begin > test.sec.doit; > end. Don't you think this is very confusing ? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit name with dots
On 5/25/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: mariano podesta wrote: > hi, > does fpc support unit names with more than one dot or is planned? > > in delphi 7 you can compile this: This looks to me like a delphi bug. A unit must be a valid pascal identifier. Or is there any use in supporting this? Maybe that was a build-up to the Delphi.Net version. I don't see the use of that in FPC. Regards, Graeme. -- There's no place like 127.0.0.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
> Jeff Pohlmeyer wrote: > >> Because gzip is spread wider, we use this instead of bzip2/7zip. > > > > I think the size saved by compressing FPC with bz2 would be much > > greater than the size of downloading and installing a bzip2 extractor. > > Yes, but it requires extra work :) Just a side remark, FreeBSD has bzip2 in base since 5.x. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
> > > > 1) Are they useful in general, so that it would > > make sense to include them either in FPC itself > > (as opposed to some standalone unit)? > > - they must be available for all cpu platforms, so we need at least a > generic implementation > - for an efficient implementation, this needs a compiler patch so the > compiler can really efficiently inline While I do think having inlinable assembler would be a nice thing to have, I think it'd be a lot of work (one would have to assign params and results to registers as well as used regs). But the problem with ROR/ROL is that any real use over shr/shl uses a hard to model carry flag? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit name with dots
> On 5/25/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: > > mariano podesta wrote: > > > hi, > > > does fpc support unit names with more than one dot or is planned? > > > > > > in delphi 7 you can compile this: > > > > This looks to me like a delphi bug. A unit must be a valid pascal > > identifier. Or is there any use in supporting this? > > Maybe that was a build-up to the Delphi.Net version. It is yes. > I don't see the use of that in FPC. Me too. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
Marco van de Voort wrote: >>> 1) Are they useful in general, so that it would >>> make sense to include them either in FPC itself >>> (as opposed to some standalone unit)? >> - they must be available for all cpu platforms, so we need at least a >> generic implementation >> - for an efficient implementation, this needs a compiler patch so the >> compiler can really efficiently inline > > While I do think having inlinable assembler would be a nice thing to > have, I think it'd be a lot of work (one would have to assign params and > results to registers as well as used regs). > > But the problem with ROR/ROL is that any real use over shr/shl uses a hard > to model carry flag? What has rol/ror to do with the carry flag on pascal side? It means only rotate a variable. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] rotating bits
> But the problem with ROR/ROL is that any real use over shr/shl uses a hard > to model carry flag? Ugh, I don't understand well, but the talk is about rotating bits, no low level features like CF are requested (it doesn't mean very much if you rotate by several bits). Who talked about CF? I didn't talk about RCL/RCR either. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
On Thu, 25 May 2006, Florian Klaempfl wrote: > Michael Van Canneyt wrote: > > > > On Thu, 25 May 2006, Florian Klaempfl wrote: > > > >> Tomas Hajny wrote: > >>> On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: > >>> > >> First parameter is in eax, second in edx (third one is ecx) > TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the > first > TH> parameter can be still skipped (and the stack frame is probably not > useful > TH> in this case either). So you'd get: > TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; > TH> asm > TH> movb %dl,%cl > TH> rolb %cl,%al > TH> end ['cl']; > TH> Tomas > > 1. So, is there any problem with including this functions and bit checks > (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great too)? > >>> I guess there is no problem in including it. The > >>> only questions from my point of view are: > >>> > >>> 1) Are they useful in general, so that it would > >>> make sense to include them either in FPC itself > >>> (as opposed to some standalone unit)? > >> - they must be available for all cpu platforms, so we need at least a > >> generic implementation > >> - for an efficient implementation, this needs a compiler patch so the > >> compiler can really efficiently inline > > > > I don't think these functions are so useful that they warrant a compiler > > patch. > > They give the programmer access to CPU instructions which can speed up > certain algorithms without the need to write assembler. I program since 1984, and I have never seen these instructions used. > > We can include them in some separate unit, but I would highly object > > against > > putting them in the system unit. > > They make no sense then. Going through the whole calling sequence is > slower imo than or'ing shl/shr: > function brol(b: byte; c: byte): byte;inline; > begin > result:=(b shr (8-c)) or (b shl c); > end; > > which can be inlined perfectly by the compiler. > > That's also why I added the endian conversion functions to the system > unit, e.g. the compiler can benefit a lot if they are implemented in a > CPU dependend way. Well, if we're going in that direction anyway: Why not include all possible assembler instructions then ? Let's be serious. You must draw the line somewhere. I think these instructions are so exotic, they are pollution of the system unit. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rotating bits
Michael Van Canneyt wrote: > > On Thu, 25 May 2006, Florian Klaempfl wrote: > >> Michael Van Canneyt wrote: >>> On Thu, 25 May 2006, Florian Klaempfl wrote: >>> Tomas Hajny wrote: > On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote: > First parameter is in eax, second in edx (third one is ecx) >> TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the >> first >> TH> parameter can be still skipped (and the stack frame is probably not >> useful >> TH> in this case either). So you'd get: >> TH> function brol(b: byte; c: byte): byte; assembler; nostackframe; >> TH> asm >> TH> movb %dl,%cl >> TH> rolb %cl,%al >> TH> end ['cl']; >> TH> Tomas >> >> 1. So, is there any problem with including this functions and bit checks >> (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great too)? > I guess there is no problem in including it. The > only questions from my point of view are: > > 1) Are they useful in general, so that it would > make sense to include them either in FPC itself > (as opposed to some standalone unit)? - they must be available for all cpu platforms, so we need at least a generic implementation - for an efficient implementation, this needs a compiler patch so the compiler can really efficiently inline >>> I don't think these functions are so useful that they warrant a compiler >>> patch. >> They give the programmer access to CPU instructions which can speed up >> certain algorithms without the need to write assembler. > > I program since 1984, and I have never seen these instructions used. 2002-07-23 21:42 michael <[EMAIL PROTECTED]> * packages/base/md5/: Makefile, Makefile.fpc, md5.pp, md5.ref, md5test.pp: + Initial implementation >From packages/base/hash/md5.pp procedure rot(var x: Cardinal; n: Byte); begin x:=(x shl n) or (x shr (32 - n)); end; You even implemented a rol :) That's the point why I want to include compiler support: rol/ror is very important for several cryptographic algorithms. > >>> We can include them in some separate unit, but I would highly object >>> against >>> putting them in the system unit. >> They make no sense then. Going through the whole calling sequence is >> slower imo than or'ing shl/shr: >> function brol(b: byte; c: byte): byte;inline; >> begin >> result:=(b shr (8-c)) or (b shl c); >> end; >> >> which can be inlined perfectly by the compiler. >> >> That's also why I added the endian conversion functions to the system >> unit, e.g. the compiler can benefit a lot if they are implemented in a >> CPU dependend way. > > Well, if we're going in that direction anyway: > Why not include all possible assembler instructions then ? > > Let's be serious. You must draw the line somewhere. > I think these instructions are so exotic, they are pollution of the system > unit. The are somehow exotic but the key to speed up several cryptographic algorithms. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] rotating bits
> Well, if we're going in that direction anyway: > Why not include all possible assembler instructions then ? Because some of them are not designed for calculations. But ror/rol are. > Let's be serious. You must draw the line somewhere. > I think these instructions are so exotic, they are pollution of the system > unit. > Michael. They are widely used in encryption/decryption algorithms. Unfortunately, I don't really know why they were introduced in 8086 assembler. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
On 25/05/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: Jeff Pohlmeyer wrote: >> Because gzip is spread wider, we use this instead of bzip2/7zip. > > I think the size saved by compressing FPC with bz2 would be much > greater than the size of downloading and installing a bzip2 extractor. Yes, but it requires extra work :) What do you think about having two archives, to make everyone happy : one compressed with gzip ( for those concerned about compatibility) and one compressed with bzip2 (for those concerned about the size) ? -- Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
Adrian Maier wrote: > On 25/05/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: >> Jeff Pohlmeyer wrote: >> >> Because gzip is spread wider, we use this instead of bzip2/7zip. >> > >> > I think the size saved by compressing FPC with bz2 would be much >> > greater than the size of downloading and installing a bzip2 extractor. >> >> Yes, but it requires extra work :) > > What do you think about having two archives, to make everyone happy : > one compressed with gzip ( for those concerned about compatibility) > and one compressed with bzip2 (for those concerned about the size) ? Extra work for us :) We're already overloaded when doing releases. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
Florian Klaempfl wrote: > Adrian Maier wrote: >> On 25/05/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: >>> Jeff Pohlmeyer wrote: >>> >> Because gzip is spread wider, we use this instead of bzip2/7zip. >>> > >>> > I think the size saved by compressing FPC with bz2 would be much >>> > greater than the size of downloading and installing a bzip2 >>> extractor. >>> >>> Yes, but it requires extra work :) >> >> What do you think about having two archives, to make everyone happy : >> one compressed with gzip ( for those concerned about compatibility) >> and one compressed with bzip2 (for those concerned about the size) ? > > Extra work for us :) We're already overloaded when doing releases. ... plus it would have impact to required storage on all our mirrors. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
On 25 May 2006, at 12:43, Florian Klaempfl wrote: What do you think about having two archives, to make everyone happy : one compressed with gzip ( for those concerned about compatibility) and one compressed with bzip2 (for those concerned about the size) ? Extra work for us :) We're already overloaded when doing releases. I really think requiring bzip2 for Linux users is not a problem. Those few Debian Woody users who might not yet have installed bzip2 can easily do an "apt-get install bzip2" Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
Jonas Maebe wrote: > > On 25 May 2006, at 12:43, Florian Klaempfl wrote: > >>> What do you think about having two archives, to make everyone happy : >>> one compressed with gzip ( for those concerned about compatibility) >>> and one compressed with bzip2 (for those concerned about the size) ? >> >> Extra work for us :) We're already overloaded when doing releases. > > I really think requiring bzip2 for Linux users is not a problem. Those > few Debian Woody users who might not yet have installed bzip2 can easily > do an "apt-get install bzip2" I tend also to agree. Does anybody know something newer than Woody coming without bzip2 by default? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: a suggestion...
On 5/25/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: I tend also to agree. Does anybody know something newer than Woody coming without bzip2 by default? DamnSmallLinux -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] a suggestion...
> bzip2 has similar compression rates (except maybe for multimedia > files, which isn't the case) and 7zip/LZMA usually compresses better > than RAR. > 7zip isn't installed by default in any distro AFAIK, but at least it > open source. > RAR would be my last option... I tried to benchmark a little. Archivers were limited to 512 Mb. Timings only in the second test. Precision is kept 1 Mb/10 seconds intentionally. There are many comprehensive benchmarks, but I tested nearly the last versions. OpenOffice 2.0.2 sources, 1209 Mb (there are several .gz and other binary files inside). (RAR and 7z had the advantage of managing files themselves to create "solid" archives, gzip and bzip2 were used on a 1209 Mb "ball" made by RAR.) Rar (3.60 beta 2): 212 Mb gzip (1.2.4): 276 Mb bzip2 (1.0.3): 230 Mb 7z PPMd (4.4.2):190 Mb 7z LZMA (--""--): too slow (~100 Kb/s, more than three hours) After that I tried to compress FPC SVN (153 Mb), and the numbers were in different order (FPC "ball" was created in 2 minutes by Rar): Rar 21 Mb 5 minutes gzip29 Mb 1 minute 30 seconds bzip2 20 Mb 3 minutes 40 seconds (is it optimized for pascal?) 7z PPMd 17 Mb 8 minutes 20 seconds 7z LZMA 16 Mb 25 minutes (well, it would be better, I believe it had memory problems) I tried PPMonster archiver (open source, from the author of PPMd algorithm), while sources are less than 60 Kb in C, speed is often about 20 Kb/s. However, it promised 0.548 bits per byte of the FPC "ball" (but >1.5 for OpenOffice). Naturally, there is still no good reason to change something. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
