[fpc-devel] Interface to compressed files and archives
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: In the general decompression unit a list of all available compressors is maintained, every implemented and used compressor adds itself to this list, in the initialization section of it's main unit. 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. The use of the de/compression stream objects should be obvious, Read or Write is called until the EOF. The legacy C code of the compressors is based on error codes and conditions that must be checked after almost every call to an internal function, and which are available as the final result after the information is fully processed. I want to modify that model, so that errors will raise the predefined stream exceptions. This approach will simplify, and make more transparent, the existing code as well as the application code. It also will allow to hide the compressor specific error codes from the application. Such a change will be incompatible with the inherited decompressor API's, but does anybody see a need to further support alternative and specialized access to de/compressors, beyond the stream support? If we can agree about the above details, I plan to convert the gzip, bzip2 and zip modules to that common interface. I'm also willing to update further modules for use of that interface, provided that the modules already exist as Pascal source code. --- 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. A much simpler interface could be based on enumeration and callback procedures, that will allow to process existing archive files sequentially. It also may be possible to create an directory tree for an archive, but for now I will leave such an implementation to somebody else ;-) For the creation of new archive files, methods are required to add files to the archive directory. The simplest approach will be based on physical (existing) files, whose attributes can be retrieved by the archiver from the existing file system. Then the application code must not care about all related details. --- 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. 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? I'll stop now and thank you for your patient reading. Feel free to modify the subject or to open new threads for discussing details. Happy New Year DoDi ___ fpc-devel maillist - fpc-devel@lists.freepas
Re: [fpc-devel] bug reporting system down
peter green wrote: Warning: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) in /FPC/html/bugs/bugs.php on line 11 Warning: MySQL Connection Failed: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) in /FPC/html/bugs/bugs.php on line 11 An error occurred while executing an mYSQL query: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) Warning: Access denied for user: '[EMAIL PROTECTED]' (Using password: NO) in /FPC/html/bugs/bugs.php on line 13 Warning: MySQL Connection Failed: Access denied for user: '[EMAIL PROTECTED]' (Using password: NO) in /FPC/html/bugs/bugs.php on line 13 Warning: MySQL: A link to the server could not be established in /FPC/html/bugs/bugs.php on line 13 An error occurred while executing an mYSQL query: Access denied for user: '[EMAIL PROTECTED]' (Using password: NO) Already fixed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
Michalis Kamburelis wrote: I suspected that every type that needs to be initialized/finalized creates such try...finally block, Yes, it does. but didn't have time to check. But I checked it now. OK, page in wiki is changed, and demo program there is changed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
Vincent Snijders wrote:
Michalis Kamburelis wrote:
Are there any other cases where this issue may be significant ? If no,
I'll mark this wiki page clearly as "only for FPC earlier than
2004-12-28" (to-be-removed when 2.0 comes in), else I will update it.
(Note: we can continue this talk on wiki page
http://www.freepascal.org/wiki/index.php/Talk:Avoiding_implicit_try_finally_section
already started by Vincent with that question)
Thanks!
I haven't tested it, but I have this hunch.
Ansistrings (not constant) also require implicit try finally.
If you use ansi strings only in a seldom used if-branch in a procedure,
you could extract the procedure too, just like you did for the resource
string.
for example:
If (i>0) then
'do something but not with ansistrings
else
writeln('Invalid value: '+IntToStr(i));
Regards,
Vincent.
I suspected that every type that needs to be initialized/finalized
creates such try...finally block, but didn't have time to check. But I
checked it now. OK, page in wiki is changed, and demo program there is
changed.
--
Michalis
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
Michalis Kamburelis wrote:
Are there any other cases where this issue may be significant ? If no,
I'll mark this wiki page clearly as "only for FPC earlier than
2004-12-28" (to-be-removed when 2.0 comes in), else I will update it.
(Note: we can continue this talk on wiki page
http://www.freepascal.org/wiki/index.php/Talk:Avoiding_implicit_try_finally_section
already started by Vincent with that question)
Thanks!
I haven't tested it, but I have this hunch.
Ansistrings (not constant) also require implicit try finally.
If you use ansi strings only in a seldom used if-branch in a procedure,
you could extract the procedure too, just like you did for the resource
string.
for example:
If (i>0) then
'do something but not with ansistrings
else
writeln('Invalid value: '+IntToStr(i));
Regards,
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resourcestrings file
On Wed, 29 Dec 2004, Tomas Hajny wrote: > On Wed, 29 Dec 2004 18:23:52 +0100, Florian Klaempfl wrote > > [EMAIL PROTECTED] wrote: > > > > Added to the wiki for future reference: > > http://www.freepascal.org/wiki/index.php/Using_resourcestrings > > > > I guess it's not in the docs yet else Michael would provide a link :) There IS a whole chapter in the docs. Programmer's reference. I always assume people have actually read the docs before asking questions on the list. (OK, you can call me an irresponsible optimist :)) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resourcestrings file
On Wed, 29 Dec 2004 18:23:52 +0100, Florian Klaempfl wrote > [EMAIL PROTECTED] wrote: > > Added to the wiki for future reference: > http://www.freepascal.org/wiki/index.php/Using_resourcestrings > > I guess it's not in the docs yet else Michael would provide a link :) Slightly updated (in Wiki). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resourcestrings file
[EMAIL PROTECTED] wrote: Added to the wiki for future reference: http://www.freepascal.org/wiki/index.php/Using_resourcestrings I guess it's not in the docs yet else Michael would provide a link :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resourcestrings file
On Wed, 29 Dec 2004, Rimgaudas Laucius wrote: > Hello, > > i am intresting for what purpose resourcestring file is created when > compiling program. Can it be translated and later compiled into executable? > How this can be done? The .rst file is created to provide a mechanism to localize your application. Currently, only one localization mechanism is provided: gettext. The steps are as follows: 1. Compiler creates .rst file. 2. rstconv tool converts to .po (input for gettext) This file can be translated to many languages. All standard gettext tools can be used. 3. Gettext creates .mo files. 4. .mo files are read by gettext unit and all resourcestrings are translated. The calls needed to translate all resourcestrings are in the objpas unit. They are documented. Nothing stops people from creating a mechanism that does not depend on gettext. One could implement a mechanism to create resource DLL's (as delphi does) which contain the translated texts. The reason gettext was chosen is that it's more or less standard on Unix. But Gettext is horribly inefficient, so if someone has a better idea, please do. Plus, GetText is context insensitive (it operates on the string itself), which is a drawback: sometimes the same word/sentence must be translated differently according to the context, and this is not possible. To implement another mechanism, 3 things are needed: 1. Update rstconv so it can output another format. 2. Tools to manipulate the other format. 3. Implement a unit that loads the other format at runtime. this is also the reason we create an intermediate file format: this was the compiler needs no knowledge of the translation tool. It just needs to create the .rst file. An alternate way of doing it would e.g. be create a ini file per language, with a section for each unit used, and a key for each string. ---english.ini--- [sysutils] SErrInvalidDateTime="%S" is not a valid date/time indication. ---dutch.ini--- [sysutils] SErrInvalidDateTime="%S" is geen geldige datum/tijd aanduiding. This would allow reuse of various files. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] resourcestrings file
Hello, i am intresting for what purpose resourcestring file is created when compiling program. Can it be translated and later compiled into executable? How this can be done? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
Vincent Snijders wrote: Michalis Kamburelis wrote: I felt that results of this discussion are so important that I created a page in FPC wiki about it: http://www.freepascal.org/wiki/index.php/Avoiding_implicit_try_finally_section There's an URL to mail archives of this discussion, and a small demo program that shows trick proposed by Mattias how to avoid this implicit try...finally block. (I also created Writing_efficient_code page, that links between FPC page and Avoiding_implicit_try_finally_section page). Michalis. Did you try this with today compiler? I think Peter Vreman turned of implicit try finally for resource strings. Vincent. I just updated from CVS and rebuild FPC, and indeed, timings of my test program are now Time of Foo_ResourceString:18 Time of Foo_ResourceString_Faster: 16 So it's fixed in compiler. Great! Are there any other cases where this issue may be significant ? If no, I'll mark this wiki page clearly as "only for FPC earlier than 2004-12-28" (to-be-removed when 2.0 comes in), else I will update it. (Note: we can continue this talk on wiki page http://www.freepascal.org/wiki/index.php/Talk:Avoiding_implicit_try_finally_section already started by Vincent with that question) Thanks! -- Michalis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
