Re: [fpc-devel] Interface to compressed files and archives

2004-12-30 Thread Marco van de Voort
 I'm new to this list and want to introduce myself and my intended
 contributions to FreePascal.

You are not new to everybody:-)
 
 archive files (cpio, tar...).  I've already update or implemented some
 of these modules, now I want to define a common interface and API for
 compressed and archive streams, based on TStreams. The zstream unit is
 dedicated to a single compressor, but it has an handy name. How should I
 name a more general unit, would zstreams be acceptable?

Maybe just streams. I also have a encryption stream (Rijndael) based on a PD
unit that I could try to adapt. Of course that depends on how specific the
interface is for compression  (compres//decompress crypt/decrypt are similar)

 Then a general Open or Decompress procedure can determine which
 decompressor to use for an given stream, and can create the appropriate
 decompressor object. For compressors it may be better to create the
 according object directly, according to the desired compression format,
 in which case the according arguments also can be passed to the
 constructor of that class in the appropriate form.

Better have a separate way. Otherwise you can't set e.g. a compressionlevel
for that stream, _or_ you have to have lots of different constructors.

One other thing to keep in mind (iirc) is that some algo's require the
uncompressed size to unpack, and some the compressed size. So probably
your interface has to support both. 

And use a 64-bit size and an endianness indicator if possible.

 Archive files deserve a more elaborate API, so that the files in an
 archive can be extracted to individual files or streams. There was
 already a suggestion, to define something like a virtual file system
 interface for archive files. I suspect that something like this already
 exists for use in the GUI browsers of both Linux and Windows. This may
 deserve some research, before an accordingly compatible interface can be
 defined. Now I'm waiting for according contributions from the OS gurus
 before proceeding with this approach.

Search for zfs (zip filesystem). It was FPC compat for a while.
 
 Now you should have gotten the big picture of my intended activities.
 Many more questions will arise when I proceed with my work. I already
 decided to replace my own stdc unit by the FPC libc unit, with
 hopefully no changes to that unit. 

Then change them again to use BaseUnix/Unix :-)

The libc unit is not a base unit of FPC, but exists merely for Kylix
porting purposes, since it is pretty much only a direct x86 glibc
translation, and not a general POSIX abstraction. It is only supported for
Linux/x86.

As said, a portable subset is available in units baseunix/unix, with
threadsafe errno and most calls have fp prefixed to avoid nameclashes with
older FPC unix units (oldlinux) and Kylix' libc.

See http://www.freepascal.org/docs-html/rtl/  for some docs, and 
http://www.stack.nl/~marcov/unixrtl.pdf  

 For further compatibility it will be
 necessary to find compromises between my coding style, and the style
 used by the FPC community. E.g. I prefer to prefix all my units with an
 u, so that the base names remain available for procedures or
 variables. I also use upper case characters in the unit names, what may
 not be appreciated by users from the Unix world. As a compromise it may
 be possible to use a lib prefix, but this may conflict with existing
 library names (libz...). Any ideas?

unit prefixes for units belonging together are not uncommon (see e.g. the
image and db routines), but I would avoid the uppercase unitnames and don't
use already taken prefixes like lib, db, unix and fp
 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Interface to compressed files and archives

2004-12-30 Thread Michael . VanCanneyt


On Thu, 30 Dec 2004, DrDiettrich wrote:

 Hi there,
 
 I'm new to this list and want to introduce myself and my intended
 contributions to FreePascal.
 
 My name is Dr. Hans-Peter Diettrich, and I live in Flensburg (Germany).
 For brevity I use to sign my messages as DoDi. My main interests are
 decompilers and (tools for) porting code. Usually I work with Delphi,
 but this behaviour may change ;-)
 
 Recently I came across some interesting library modules of FPC, that I
 want to use in my own projects. Some of these modules deserve updates,
 in general and for use with Delphi, and I want to contribute my
 according work to the FPC community.
 
 Currently I'm implementing an RPM clone for Windows, which in detail
 should support source rpm's, better than the original RPM. Hereby I have
 to deal with compressed files in various formats (gzip, bzip2), and
 archive files (cpio, tar...).  I've already update or implemented some
 of these modules, now I want to define a common interface and API for
 compressed and archive streams, based on TStreams. The zstream unit is
 dedicated to a single compressor, but it has an handy name. How should I
 name a more general unit, would zstreams be acceptable?
 
 My idea of a general (de-)compression interface is as follows:
 

Your idea is already implemented in Abbrevia from TurboPower. 
Abbrevia is open source, and is maintained on SourceForge. 
Free Pascal has a copy of it that compiles in CVS, check out
contrib/abbrevia

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Interface to compressed files and archives

2004-12-30 Thread Marco van de Voort
 Just don't use anything conflicting with other prefixes: lib, z, db, im, sys.
 
 If we can agree on an implementation for archive handling that can be 
 considered a standard implementation for FPC (i.e. distributed with the 
 FCL), 'fp' can (and should) be used.
 
 Naming a unit with 'u' standard does not seem useful to me, but this is
 a matter of taste. In general, in Delphi, I use only 4 fixed prefixes:
 
 fra for Frames
 frm for Forms
 dm  for DataModules
 mgr for Manager classes.

Only additional general one i use is

dlg for dialog


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Interface to compressed files and archives

2004-12-30 Thread Michael . VanCanneyt


On Thu, 30 Dec 2004, Marco van de Voort wrote:

  Just don't use anything conflicting with other prefixes: lib, z, db, im, 
  sys.
  
  If we can agree on an implementation for archive handling that can be 
  considered a standard implementation for FPC (i.e. distributed with the 
  FCL), 'fp' can (and should) be used.
  
  Naming a unit with 'u' standard does not seem useful to me, but this is
  a matter of taste. In general, in Delphi, I use only 4 fixed prefixes:
  
  fra for Frames
  frm for Forms
  dm  for DataModules
  mgr for Manager classes.
 
 Only additional general one i use is
 
 dlg for dialog

In my view, dialog=form, the only 'dialogs' are the windows stock dialogs.
But we have some forms that qualify. Thanks for the idea!!  :-)

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] compiler bug?

2004-12-30 Thread Jesus Reyes
 --- peter green [EMAIL PROTECTED] escribió: 
 you are forciblly putting an out of range value in a variable what
 do you
 expect to happen?
 
 


Of course the program was made to do that evident, but what happen
when you find a procedure, for example:

procedure doAorB(value: boolean);
begin
  case value of
true: doA;
false: doB;
  end;
end;

one might think either doA or doB will executed, but the reality is
that sometimes neither doA or doB will do.


 

_
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. 
http://net.yahoo.com.mx

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] compiler bug?

2004-12-30 Thread Nico Aragón
El Jueves, 30 de Diciembre de 2004 22:48, Jesus Reyes escribiste:
 procedure doAorB(value: boolean);
 begin
   case value of
 true: doA;
 false: doB;
   end;
 end;

if Value then
  DoA
else
  BoB;

-- 
saludos,

Nico Aragón
http://espira.net/nico/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] compiler bug?

2004-12-30 Thread peter green
I think the old saying goes garbage in garbage out.

range checking should probablly catch this sort of stuff but that has a high
performance penalty and is therefore usually disabled.

At the end of the day if you force out of range data into your booleans then
its your problem.



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes
 Sent: 30 December 2004 21:49
 To: FPC developers' list
 Subject: RE: [fpc-devel] compiler bug?


  --- peter green [EMAIL PROTECTED] escribió:
  you are forciblly putting an out of range value in a variable what
  do you
  expect to happen?
 
 
 

 Of course the program was made to do that evident, but what happen
 when you find a procedure, for example:

 procedure doAorB(value: boolean);
 begin
   case value of
 true: doA;
 false: doB;
   end;
 end;

 one might think either doA or doB will executed, but the reality is
 that sometimes neither doA or doB will do.




 _
 Do You Yahoo!?
 La mejor conexión a internet y 25MB extra a tu correo por $100 al
 mes. http://net.yahoo.com.mx

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel