[fpc-devel] Interface to compressed files and archives

2004-12-29 Thread DrDiettrich
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

Re: [fpc-devel] compiler bug?

2004-12-31 Thread DrDiettrich
Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. Forcing out-of-range values into strictly typed variables is a user bug, at the full risk of (and shame on) that user. Who's to blame when somebody applies

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

2004-12-31 Thread DrDiettrich
Marco van de Voort wrote: 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. Compressors can require any kind and number of arguments, that must be reflected somewhere, e.g. in the specific

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

2004-12-31 Thread DrDiettrich
[EMAIL PROTECTED] wrote: Naming a unit with 'u' standard does not seem useful to me, but this is a matter of taste. ... All other files are assumed to be units. (projects/packages have distinct extensions anyway) No problem at the directory level, but how to distinguish names of units,

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

2005-01-01 Thread DrDiettrich
[EMAIL PROTECTED] wrote: E.g.: gzip.xyz, is this based on a gzip unit or a gzip variable or... Does this matter to you ? Normally one never uses a fully qualified identifier. And that can become a problem, when a variable and a unit has the same name. That's why I do not only prefer to

Re: [fpc-devel] compiler bug?

2005-01-01 Thread DrDiettrich
Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. I don't. Do I? Yes, you do. How can you know what bit pattern is stored in a boolean variable? Using typecasts may result in silent type conversion,

Re: [fpc-devel] Portability Standards

2005-01-02 Thread DrDiettrich
Michael Van Canneyt wrote: 1) Target Dependencies Agreed 100%. In general, a component suite should have all os-dependent code in a single unit, presenting the rest of the suite with a uniform API. Fine :-) But how should that code be implemented? For various target platforms? 2) Code

Re: [fpc-devel] Portability Standards

2005-01-02 Thread DrDiettrich
Michael Van Canneyt wrote: I'm willing to demonstrate my ideas in a redesign and extension of Abbrevia, so that we have a concreter base for further discussions. But before starting with that work I would like to hear some encouraging g opinions or suggestions. I think you can do this.

Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out

2005-01-04 Thread DrDiettrich
[EMAIL PROTECTED] wrote: If no major bugs are found, version 2.0 will be released in a short timeframe. I would like to test the Win32 distribution, but the archives are too big for an download (narrow band) :-( So let me list the problems I encountered with a preceding version: - Mouse

Re: [fpc-devel] Portability Standards

2005-01-04 Thread DrDiettrich
Tomas Hajny wrote: {$ifndef unix} {$i abiuwin.inc} // more to follow later: e.g. Mac OS, Netware etc. {$else} {$i abiulin.inc} {$endif} There's at least one (IMHO not worse at least) alternative to that (already used in FPC itself among others) - keep the include file name the same,

Re: [fpc-devel] Abbrevia Port (was: Portability Standards)

2005-01-04 Thread DrDiettrich
Michael Van Canneyt wrote: Question: What's preferrable, a direct port of the Abbrevia library, or a new and better portable design instead, that interfaces with the not otherwise available worker classes as implemented in Abbrevia? Second option. Here's my general idea of an Abbrevia

Re: [fpc-devel] Portability Standards

2005-01-04 Thread DrDiettrich
Marco van de Voort wrote: You might also want to have a look at http://www.stack.nl/~marcov/porting.pdf and http://www.stack.nl/~marcov/unixrtl.pdf Ah, thanks :-) There are 4 cases for Unix: 1 Kylix 2 FPC/Linux/x86 reusing Kylix libc code. 3 FPC/Linux/x86 using general FPC unix

Re: [fpc-devel] Portability Standards

2005-01-04 Thread DrDiettrich
Michael Van Canneyt wrote: The FPC units are not POSIX, hence, UNIX. (long threads have already been spent on that, and it is a done deal) I don't want to resurrect a discussion, but can somebody give me an idea how UNIX and POSIX are different, with regards to FPC? Question: What's

Re: [fpc-devel] Portability Standards

2005-01-06 Thread DrDiettrich
Michael Van Canneyt wrote: POSIX says nothing about pascal, it's basically a C interface. To me POSIX means primarily the very different file handling, with regards to devices, path separators, owner/group/world access rights etc. This is what bites not only me when porting GNU software to

Re: [fpc-devel] Portability Standards

2005-01-06 Thread DrDiettrich
Tomas Hajny wrote: I only don't know how to implement or check the other branches - is the Windows version of FPC equipped for crosscompilation? The compiler itself can compile for all platforms listed in help pages The problem is that the installed FPC doesn't show any help - no files

Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out

2005-01-06 Thread DrDiettrich
Peter Vreman wrote: If no major bugs are found, version 2.0 will be released in a short timeframe. Only one major problem so far. Congratulations! :-) So let me list the problems I encountered with a preceding version: - Mouse buttons inoperative (W2K, no menu selection...) - \\

Re: [fpc-devel] Portability Standards

2005-01-07 Thread DrDiettrich
Jonas Maebe wrote: Why? There are cvs clients for pretty much any OS out there. Or does your working OS not have a network connection? I have a network connection, that I use rarely when I need to access some device built into my old computer. Everything else goes over the phone line. But

Re: [fpc-devel] ansistrings and widestrings

2005-01-07 Thread DrDiettrich
Florian Klaempfl wrote: The only universal international representation for strings is Unicode (currently 32 bit), that doesn't require any conversions. That's not true. E.g. the german umlauts can be represented by 2 chars when using UTF-32 (the char and the two dots), same apply to a

Re: [fpc-devel] Portability Standards

2005-01-07 Thread DrDiettrich
Jonas Maebe wrote: On 6 jan 2005, at 22:21, DrDiettrich wrote: The FPC baseunix/unix units mimic more or less the POSIX standard As already mentioned, I couldn't find these units :-( They only exist for unix-like OS'es. They are not generic units which you can use to port software

Re: [fpc-devel] ansistrings and widestrings

2005-01-08 Thread DrDiettrich
peter green wrote: it should be noted that pascal classes are really not suited to doing strings. IMO we should distinguish Strings, as containers, from Text as an interpretation of data as, ahem, text of some language, in some encoding, possibly with attributes... to do strings with

[fpc-devel] File Dates

2005-01-23 Thread DrDiettrich
Currently I'm trying to define an object for file dates. This object shall allow to compare time stamps for files on disk and in archives, and it also shall be usable to set time stamps for such files. Now I'm undecided what unique internal date/time representation to use in such an object. For

Re: [fpc-devel] File Dates

2005-01-28 Thread DrDiettrich
Michael Van Canneyt wrote: What time stamps are in use on the various platforms? Too various. I suggest using simply TDateTime. It has microsecond resolution, which should be more than enough. It offers the additional advantage that no transformations are necessary for display compare

[fpc-devel] Abbrevia and Delphi compatibility

2005-02-15 Thread DrDiettrich
After eliminating dozens of bugs now I have a working version of Abbrevia for Delphi. Unfortunately this version is not usable with FPC, primarily because FPC doesn't support properties for the Object type. In my code I like to use Object for records with methods and properties, which need no

Re: [fpc-devel] Bug in PWidechar and refcounting

2005-02-15 Thread DrDiettrich
Alexey Barkovoy wrote: PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design. In Delphi WideString is not reference counted at all. The layout of the

Re: [fpc-devel] Abbrevia and Delphi compatibility

2005-02-17 Thread DrDiettrich
Marco van de Voort wrote: 2) Sets with minimal size, at least with 1 and 2 bytes for replacement of Byte and Word types. I consider both features as vital in translations from C to Pascal, and in the detection and elimination of bugs. Will it be possible to add these features to FPC,

Re: [fpc-devel] Abbrevia and Delphi compatibility

2005-02-17 Thread DrDiettrich
Peter Vreman wrote: 1) Properties for Object type. Since which Delphi version is a property allowed in an normal object? I'm not sure, but at least D4 supports such properties. Currently FPC has special code that forbids property in objects for delphi mode. Then it would be sufficient

Re: [fpc-devel] TShiftState as enum

2005-02-17 Thread DrDiettrich
Marco van de Voort wrote: TShiftState is defined as TShiftState = set of (...); How can I iterate through the enums? If not, can we split and add an enum: TShiftStateEnum = (...) TShiftState = set of TShiftStateEnum; ? Of course that is possible. It requires some

Re: [fpc-devel] TShiftState as enum

2005-02-20 Thread DrDiettrich
Alexey Barkovoy wrote: Delphi dowsn't allow sets with ordinal values larger than 255 too: That's incorrect. Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation 1.pas(2) Error: Sets may have at most 256 elements Sets are restricted to a maximum of 256 members, but the

Re: [fpc-devel] Modernising Pascal

2005-02-23 Thread DrDiettrich
Jamie McCracken wrote: Just wandering if any of you are interested in modernising Pascal which is looking quite dated when compared to modern languages like Python. I note free pascal supports a variety of pascal dialects but none of them are particular modern. I'd suggest Oberon or a

Re: [fpc-devel] Modernising Pascal

2005-02-27 Thread DrDiettrich
peter green wrote: one thing i have heared (i don't use garbage collected languages much so i've never seen this myself) is that the GC gets some CPU time and starts causing stuff to be swapped in. This slows other threads down which gives the GC more CPU and causes more stuff to be swapped

Re: [fpc-devel] Improving Ref Counting

2005-02-27 Thread DrDiettrich
Peter Vreman wrote: Why are you looking at GC/Refcounting when the problem is the try..finally? It is better to rewrite the try..finally code using the C++ ABI for exception handling. Where do you see improvements in the C++ ABI? Or even differences? Windows implements this ABI, and every

Re: [fpc-devel] Improving Ref Counting

2005-02-27 Thread DrDiettrich
Jamie McCracken wrote: Rather than continuing the GC stuff which seems fruitless I thought it might be better to improve what we have with ref counting (whilst taking a leaf out of the GC book as well). A reasonable attempt. 2) Have a single linked list that contains references to all

Re: [fpc-devel] Improving Ref Counting

2005-02-28 Thread DrDiettrich
Jamie McCracken wrote: A GC needs to trace an object's references to see if anything still points to it. How else can it decide whether an object is no longer in use? GC starts from known alive object references, in static or local variables, and follows the references in these objects to

Re: [fpc-devel] Improving Ref Counting

2005-03-01 Thread DrDiettrich
Jamie McCracken wrote: A GC needs to trace an object's references to see if anything still points to it. How else can it decide whether an object is no longer in use? GC starts from known alive object references, in static or local variables, and follows the references in these objects to

Re: [fpc-devel] Improving Ref Counting

2005-03-04 Thread DrDiettrich
peter green wrote: surely this also means 1: there has to be rtti for every field in every class so the compiler can follow the paths from the class That's almost required, not only for classes but for all data types that contain references (pointers) to managed objects. It's not

Re: [fpc-devel] utf8 reading

2005-03-12 Thread DrDiettrich
Uberto Barbini wrote: Using natively utf-8 I think is impossible, because the encoding. Support might be implmemented like/in MBCS support. Please note that at every Borland conference there is someone asking for Unicode support since Delphi2... Not only for Delphi ;-) There are several

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-15 Thread DrDiettrich
Michael Van Canneyt wrote: 1. What happens if f would use a variable from somefun, and f is called when somefun is no longer executed ? This can not happen when the function parameter cannot be stored anywhere. 2. I see no difference whatsoever between typ_fun and iso_fun, except

[fpc-devel] Friend classes?

2005-03-15 Thread DrDiettrich
I just came about code that uses protected members of other classes, defined in other units. In Delphi this possible by a declaration like: type TFriendClass = class(TNotMyClass); After this declaration the protected (and private?) members of TNotMyClass are accessible, using TFriendClass as an

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-18 Thread DrDiettrich
[EMAIL PROTECTED] wrote: Let me add some more thoughts about procedural types: - I like the ability to declare procedural types, the ISO convention looks like one of the many incredible C hacks to me :-( But it is standard pascal. And we need to support those zillion lines of code

Re: [fpc-devel] Local procedures as procedural parameter

2005-03-19 Thread DrDiettrich
Jonas Maebe wrote: Couldn't the framepointer be last parameter in all modes ? That would still require some ugly hacks inside the parameter passing code, because of the fact that on x86 the callee removes the parameters from the stack and not the caller (so you'd still need a check

Re: [fpc-devel] Friend classes?

2005-03-20 Thread DrDiettrich
Ales Katona wrote: C++ requires friend only because it lacks the idea of modularity. Since all classes are apart they need some way to tell each other I can use you In pascal you simply put them into 1 unit. That's why the C++ model is better, there exists no requirement to implement related

Re: [fpc-devel] Friend classes?

2005-03-20 Thread DrDiettrich
Michael Van Canneyt wrote: sorry, but I fail to see the problem ? The above makes all protected members of a class visible. This is normal, that is why they are protected. If you want to avoid that, make the members private. Then they are visible only in the same unit, even for other classes

Re: [fpc-devel] Friend classes?

2005-03-22 Thread DrDiettrich
Micha Nelissen wrote: The real question is: was the design of the code ok ? Some dependencies cannot be removed by a redesign :-( In some cases interfaces instead of classes can help, because they don't need implementation in the same unit. But then the classes have to be implemented as well.

Re: [fpc-devel] Friend classes?

2005-03-24 Thread DrDiettrich
Florian Klaempfl wrote: C++ creates one monster module in this case as well. I disagree. Neither the declarations (interface, header files) nor the definitions (implementation, code modules) must reside in one file. How the sources are splitted doesn't matter. The compiler handles it

Re: [fpc-devel] Friend classes?

2005-03-26 Thread DrDiettrich
Micha Nelissen wrote: Perhaps you missed that in C/C++ the preprocessor is typically (99.999%) used to include header files, not source files. This is comparable to Pascal uses, not to {$Include}! What's the difference between a 'header' file, and a source file ? Header files often

Re: [fpc-devel] Friend classes?

2005-03-29 Thread DrDiettrich
Marco van de Voort wrote: The definitions of templates, inline procedures or macros do not immediately contribute to the size of a compiled module, only when they are *used* in code modules. That goes for all routines. I'm not sure what you mean. A global procedure, exported in the

[fpc-devel] First benchmark of Abbrevia 4.0

2005-03-29 Thread DrDiettrich
A friend of mine just has tested my archiver, with the following results for an TAR with a million of files: PowerArchiver: 530 minutes. My Unarch: 160 minutes. I hope to get the original .tgz archive soon, in order to test it with GNU gzip and tar as well. The time may decrease again when the

Re: [fpc-devel] First benchmark of Abbrevia 4.0

2005-03-30 Thread DrDiettrich
Michael Van Canneyt wrote: On Sun, 27 Mar 2005, DrDiettrich wrote: A friend of mine just has tested my archiver, with the following results for an TAR with a million of files: PowerArchiver: 530 minutes. My Unarch: 160 minutes. Huh ? Who creates archives with million of files

Re: [fpc-devel] Friend classes?

2005-03-30 Thread DrDiettrich
Marco van de Voort wrote: Do you mean that only one level of dependencies must be checked with uses, whereas even the indirectly #included files must be checked for changes? You always have to do the #include. Always. Pre-compiled headers are possible, not trivial, since it requires a

Re: [fpc-devel] Quick patch for bug 3762

2005-03-31 Thread DrDiettrich
Tomas Hajny wrote: The main problem is that there's a lot platform independent functionality in Crt unit which is re-implemented for every platform again and again. The best solution would be to throw all the individual implementations away completely and implement cross-platform Crt unit

Re: [fpc-devel] natural unicode support for WinNT via UTF-8

2005-04-16 Thread DrDiettrich
Yury B. wrote: Two RTLs should be for Win32, one compiled for ANSI/DBCS and the other for UNICODE UCS-2 (WinNT), where a special type, say TUniString is AnsiString in the first version and UnicodeString in the second version. What do you think of it? IMO there exists no

Re: [fpc-devel] problem with is operator

2005-04-18 Thread DrDiettrich
Linuxer Wang wrote: Hello, Can anybody tell me how can I know which specific type an instance of class is? Check the ClassType or ClassName. The is operator seems weird when interface is used. Add a GetObject method to your interfaces, that returns the object that implements the

Re: [fpc-devel] integer, cardinal

2005-04-18 Thread DrDiettrich
Ales Katona wrote: I think that pascal typesystem requires a bit overhaul when it comes to integers. First of all Integer should be size independent, that is, xy bits depending on the platform. All others should be specific. I agree with an application wide integer/cardinal type, but there