Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
[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 buttons inoperative (W2K, wireless USB mouse: no menu selection...) - Install dialog: last tab not reachable (no mouse support, Alt-C -> Continue!) - "\\" contained in all stored pathes, IMO due to input of the FPC directory ending with an "\". DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
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, place
> it in separate directories for different targets (like UNIX, WIN32, etc.) and
> provide the right paths using a Makefile (see e.g. fcl/Makefile.fpc + Makefile
> in our source tree). The advantage of this approach is that you don't need any
> ifdefs at all (especially when there are more targets supported it could get
> somewhat messy).
A good idea - at least for FPC ;-)
For Delphi it does no harm to implement just the Windows specific part,
in a dedicated directory.
I only don't know how to implement or check the other branches - is the
Windows version of FPC equipped for crosscompilation?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
Florian Klaempfl wrote: > Not everything is a matter of OS. It could be also a matter of toolkit, > database, word size of the cpu or whatever. Further smaller files are > usually easier to handle: > - cvs works much better with small files Hmm... > - easier navigation in editors Definitely NO, with regards to include files! (May miss your point?) 1) Navigation inside one file is more powerful (search, replace..) 2) How to determine all related files, e.g. for other targets? 3) How many windows are required for one unit? 4) Long search pathes require accordingly featured tools (target switching...) 5) How to produce diffs for multiple versions (targets) of one unit? > - last but not least: work with small units as much as possible Hmmm... I think that I prefer compact projects, with few units and no include files. At least I don't like units consisting effectively only of includes. That's near C, with it's sea of header files and unrelated implementation modules, and the effectively compiled text becomes visible only after running the preprocessor :-( BTW, I already wrote an preprocessor to produce single files from the FPC units. Now I have to extend it, for multiple targets... > - easier overview what has been modified when checking logs: which log > entry is better: >rtl/system.pp: fixed writeln >rtl/morphos/ossysc.inc: fixed writeln I'm not sure about the logging conventions. Precise logs require to save almost every single change, with an appropriate comment. After half an hour with multiple related corrections it's hard to find a really descriptive common subject. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia Port (was: Portability Standards)
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 compatible redesign: The working name for this new project is Directories+DirectoryItems, with a "di" prefix for the unit names etc. The project unifies the handling of archives, compressed and encrypted files. The basic objects are Directories and DirectoryItems. This should allow to cover the file systems of all platforms, as well as archive files, networks etc. Directories are DirectoryItems themselves (subdirectories), in general containers for DirectoryItems, with according management functions. One method allows to enumerate all contained DirectoryItems. A callback function can process the items and signal abort (when the file is found) or recurse (into a subdirectory). This IMO is a better replacement for the FindFirst/FindNext/FindClose crap, applicable also to the contents of archive files. Other DirectoryItems are files and links. Links transparently wrap the linked file for file related operations, and have additional methods for managing the links themselves (redirect...). File items can be opened and closed, open files have an according Stream object/property. Archive files must be mappable into Directories, somehow. A Mount method might return the appropriate Directory object for the files inside an archive. Question: On Posix (Unix?) file systems the ownership (UID, GID) as well as specific file (executable...) and directory (sticky...) attributes are important, when extracting files from archives. Does FPC already provide according portable access and management procedures? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
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 code > 4 Other FPC Unix targets using general FPC unix code > > Since 1->2 is an easy port often, so I think in general FPC/Linux/x86 should > remain switchable between "libc" and "FPC-UNIX" mode. How important is Kylix at all? Isn't it almost dead now? > I think it would wise to not use exceptions too deep in the code. > Compression is one of those things where OOP and exception overhead still > count. I'd use exceptions only for fatal errors, which can be caught in the application code. The cost for raising such exceptions is neglectable, and catching outside the compressor does not affect the efficiency of the worker code. The worker code can become simpler this way, because error checks in every level then are superfluous. OTOH all local resources then must be protected by try-finally blocks... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
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 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. I have already started with a revival of my TXStream classes, now with hopefully better portability. One problem are required changes and extensions to the TStream base class. The new stream classes will be either input or output streams, and will have I/O buffers used for crypting and compression. What's the recommended base class herefore? THandleStream? > > 3) Data Types > > "off_t" now replaces the Integer/LongInt/Int64 mess, for all file size > > related values. I took this name from the C standard, but perhaps it > > should be replaced by some Pascal name? > > I think the best way - for now - is to define a set of basic types > in some base unit: > - TFileHandle > - TSeekOffset > - ... > Which should be used consistently throughout the system. That's why I choose the well defined C names for now, like size_t, off_t. off_t could be replaced by TFileSize, what's the reason for moving from 32 to 64 bit for huge files, whereas TSeekOffset also indicates that this type must be signed for moves in both directions. size_t must not necessarily become a new type. I used it for the amount of data in Read and Write, where (signed) 32 bits are sufficient on 32 bit machines, with regards to buffer size in memory. > These base types can then be mapped on a per-os basis to whatever fits best. > (or to basic FPC types, when (not if!) FPC introduces them. The best base unit IMO is where the low level I/O procedures are defined, which wrap the OS I/O calls (FileRead...). > The current implementation is done for compatibility with Delphi, and > for optimization. Hmm, compatibility with which Delphi version? ;-) Apropos optimization, in many FPC units I found constructs like: if x = 0 then f(0) else f(x) In these cases the IF is superfluous. > > "DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as > > this type is used outside dedicated MSWINDOWS code. > > The native pascal type is 'Cardinal'. But see the remark about basic types. DWORD often is used for exactly 32 bits, so that Cardinal is not an appropriate replacement. Perhaps we should discuss the (new and old) data types explicitly, for a precise description of the intended use, naming, and general properties (signedness, fixed or minimum bit size...). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
>> 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) :-( There are separate downloads available. And if you want even smaller download use CVS and build it from source. > So let me list the problems I encountered with a preceding version: > > - Mouse buttons inoperative (W2K, wireless USB mouse: no menu > selection...) > - Install dialog: last tab not reachable (no mouse support, Alt-C -> > Continue!) > - "\\" contained in all stored pathes, IMO due to input of the FPC > directory ending with an "\". Please only report bugs on the latest version. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
DrDiettrich wrote: Florian Klaempfl wrote: Not everything is a matter of OS. It could be also a matter of toolkit, database, word size of the cpu or whatever. Further smaller files are usually easier to handle: - cvs works much better with small files Hmm... - easier navigation in editors Definitely NO, with regards to include files! (May miss your point?) Probably yes, you can easily open two editor windows viewing e.g. declaration and definition at once. Using splitted view is always a mess and requires mouse usage. 1) Navigation inside one file is more powerful (search, replace..) grep/sed is more powerfull than any search/replae of an editor :) Even more if grep is integrated into the editor :) 2) How to determine all related files, e.g. for other targets? 3) How many windows are required for one unit? I don't know, but usually two are enough when modifying e.g. a class: definition and declaration. 4) Long search pathes require accordingly featured tools (target switching...) Well, this might be sometimes a problem, usually it isn't anymore. 5) How to produce diffs for multiple versions (targets) of one unit? Modify it; do a cvs diff fcl > fcl.diff - last but not least: work with small units as much as possible Hmmm... I think that I prefer compact projects, with few units and no include files. Having nested ifdefs with matching endifs or elsifs several hundred lines further _is_ a hell if you didn't write the code. At least I don't like units consisting effectively only of includes. That's near C, with it's sea of header files and unrelated implementation modules, and the effectively compiled text becomes visible only after running the preprocessor :-( If you have projects were a _team_ works on, having multiple include files is definitively better. BTW, I already wrote an preprocessor to produce single files from the FPC units. Now I have to extend it, for multiple targets... - easier overview what has been modified when checking logs: which log entry is better: rtl/system.pp: fixed writeln rtl/morphos/ossysc.inc: fixed writeln I'm not sure about the logging conventions. Precise logs require to save almost every single change, with an appropriate comment. After half an hour with multiple related corrections it's hard to find a really descriptive common subject. When fixing bug by bug in 10min you don't think about better log messages :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia Port (was: Portability Standards)
On Tue, 4 Jan 2005, DrDiettrich wrote: > 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 compatible redesign: > > The working name for this new project is Directories+DirectoryItems, > with a "di" prefix for the unit names etc. The project unifies the > handling of archives, compressed and encrypted files. > > The basic objects are Directories and DirectoryItems. This should allow > to cover the file systems of all platforms, as well as archive files, > networks etc. > > Directories are DirectoryItems themselves (subdirectories), in general > containers for DirectoryItems, with according management functions. One > method allows to enumerate all contained DirectoryItems. A callback > function can process the items and signal abort (when the file is found) > or recurse (into a subdirectory). This IMO is a better replacement for > the FindFirst/FindNext/FindClose crap, applicable also to the contents > of archive files. On the condition that you also implement by default also a method returning a TList or TStringList with TDirectoryItems. Not everyone is comfortable with callbacks. The TList/TStringlist method should work fine for not-too-large lists. > > Other DirectoryItems are files and links. > Links transparently wrap the linked file for file related operations, > and have additional methods for managing the links themselves > (redirect...). > File items can be opened and closed, open files have an according Stream > object/property. > Archive files must be mappable into Directories, somehow. A Mount method > might return the appropriate Directory object for the files inside an > archive. This seems all pretty much OK. > > Question: > On Posix (Unix?) file systems the ownership (UID, GID) as well as > specific file (executable...) and directory (sticky...) attributes are > important, when extracting files from archives. Does FPC already provide > according portable access and management procedures? No. We have stuck to the lowest common denominator, i.e. Windows, mainly for compatibility reasons. I think that if we're going to be having a new implementation, we should go for the maximum, and provide sensible defaults for the 'lesser' OS-es. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
On Tue, 4 Jan 2005, DrDiettrich wrote: > 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? FPC and POSIX are totally unrelated. Unix is a superset of POSIX. Most Unices out there are POSIX compliant. POSIX says nothing about pascal, it's basically a C interface. The FPC baseunix/unix units mimic more or less the POSIX standard, so 1. It would be easy to write Pascal code, based on C examples. 2. It can be mapped on Libc for porting purposes. If you port to a new platform, and it has a Posix-confirming C library, you will have little work to do. > > > > 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. > > I have already started with a revival of my TXStream classes, now with > hopefully better portability. One problem are required changes and > extensions to the TStream base class. The new stream classes will be > either input or output streams, and will have I/O buffers used for > crypting and compression. What's the recommended base class herefore? > THandleStream? No. TStream. An archive stream does not have a handle. > > > > 3) Data Types > > > "off_t" now replaces the Integer/LongInt/Int64 mess, for all file size > > > related values. I took this name from the C standard, but perhaps it > > > should be replaced by some Pascal name? > > > > I think the best way - for now - is to define a set of basic types > > in some base unit: > > - TFileHandle > > - TSeekOffset > > - ... > > Which should be used consistently throughout the system. > > That's why I choose the well defined C names for now, like size_t, > off_t. 1. They are not "well-defined", but this is another story :-) 2. I absolutely HATE underscores in types/variables/whatever for documentation purposes it is a horror (I use TeX) > off_t could be replaced by TFileSize, what's the reason for moving from > 32 to 64 bit for huge files, whereas TSeekOffset also indicates that > this type must be signed for moves in both directions. > size_t must not necessarily become a new type. I used it for the amount > of data in Read and Write, where (signed) 32 bits are sufficient on 32 > bit machines, with regards to buffer size in memory. > > > These base types can then be mapped on a per-os basis to whatever fits best. > > (or to basic FPC types, when (not if!) FPC introduces them. > > The best base unit IMO is where the low level I/O procedures are > defined, which wrap the OS I/O calls (FileRead...). Sysutils, then. > > > The current implementation is done for compatibility with Delphi, and > > for optimization. > > Hmm, compatibility with which Delphi version? ;-) 5 at least. > > Apropos optimization, in many FPC units I found constructs like: > if x = 0 then f(0) else f(x) > In these cases the IF is superfluous. You can send a list of such things to any core member. > > > > "DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as > > > this type is used outside dedicated MSWINDOWS code. > > > > The native pascal type is 'Cardinal'. But see the remark about basic types. > > DWORD often is used for exactly 32 bits, so that Cardinal is not an > appropriate replacement. Cardinal = 32 bits _always_. Also on 64 bit. > > Perhaps we should discuss the (new and old) data types explicitly, for a > precise description of the intended use, naming, and general properties > (signedness, fixed or minimum bit size...). The old are not subject to discussion. You can introduce new ones in any way you see fit. Rule number 1 when creating a new (big) Delphi project: "Subclass ALL classes you will be needing." Saves a lot of trouble afterwards. Same rule applies here. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
On Sun, 02 Jan 2005 21:41:59 +0100, DrDiettrich wrote > [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) :-( . . You can always download just the needed parts from ftp://ftp.freepascal.org/pub/fpc/beta/i386-win32-1.9.6/separate/ (for win32). You should always get install.exe and install.dat, then base.i386-win32.zip which contains the compiler and RTL. Whatever else is up to you (IDE, FCL, FV, miscellaneus other packages, documentation and individual source files). Hope this helps Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
Michael Van Canneyt wrote: On Tue, 4 Jan 2005, Tomas Hajny wrote: On Sun, 02 Jan 2005 21:41:59 +0100, DrDiettrich wrote [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) :-( . . You can always download just the needed parts from ftp://ftp.freepascal.org/pub/fpc/beta/i386-win32-1.9.6/separate/ (for win32). You should always get install.exe and install.dat, then base.i386-win32.zip which contains the compiler and RTL. Whatever else is up to you (IDE, FCL, FV, miscellaneus other packages, documentation and individual source files). Maybe we should start making CDs and sell them for the price of CD+Shipping. Like Marco proposed. (He's been shouting in the desert since years... ;-) ) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel If you go this way I'd suggest adding also Lazarus. I know the thing is "just another project made with FPC" but I think it would be good for both. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
On Tue, 4 Jan 2005, Tomas Hajny wrote: > On Sun, 02 Jan 2005 21:41:59 +0100, DrDiettrich wrote > > [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) :-( > . > . > > You can always download just the needed parts from > ftp://ftp.freepascal.org/pub/fpc/beta/i386-win32-1.9.6/separate/ (for win32). > You should always get install.exe and install.dat, then base.i386-win32.zip > which contains the compiler and RTL. Whatever else is up to you (IDE, FCL, > FV, miscellaneus other packages, documentation and individual source files). Maybe we should start making CDs and sell them for the price of CD+Shipping. Like Marco proposed. (He's been shouting in the desert since years... ;-) ) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
> > > >Maybe we should start making CDs and sell them for the > >price of CD+Shipping. Like Marco proposed. > >(He's been shouting in the desert since years... ;-) ) > > > > > >Michael. > > > > > If you go this way I'd suggest adding also Lazarus. > I know the thing is "just another project made with FPC" but I think it > would be good for both. I wouldn't DREAM of creating a CD with Lazarus NOT on it!! How dare you think this ? ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
> grep/sed is more powerfull than any search/replae of an editor :) Even > more if grep is integrated into the editor :) Two advantages of using an editor search tool is: * Interactive replace, because often not all of the possible replacements should actually be replaced. * Batch search where the result set is browseable. Also not everybody is fully comfortable with grep/sed :) Olle ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich 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 (those running on the same CPU). However, you need GNU tools (as & ld at least) for every target - some of them are pre-built for you and can be downloaded from ftp://ftp.freepascal.org/pub/fpc/contrib/cross/. Alternatively, you can compile with "-s" parameter, which gives you the generated assembler code for your source files and scripts necessary to assemble&link somewhere where the right tools are available (like the target platform itself). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
> On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich 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 > (those running on the same CPU). However, you need GNU tools (as & ld at > least) for every target - some of them are pre-built for you and can be > downloaded from ftp://ftp.freepascal.org/pub/fpc/contrib/cross/. > Alternatively, you can compile with "-s" parameter, which gives you the > generated assembler code for your source files and scripts necessary to > assemble&link somewhere where the right tools are available (like the > target platform itself). crosscompilation from windows to unix using libraries is also not that easy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
Marco van de Voort wrote: On Tue, 04 Jan 2005 02:14:33 +0100, DrDiettrich 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 (those running on the same CPU). However, you need GNU tools (as & ld at least) for every target - some of them are pre-built for you and can be downloaded from ftp://ftp.freepascal.org/pub/fpc/contrib/cross/. Alternatively, you can compile with "-s" parameter, which gives you the generated assembler code for your source files and scripts necessary to assemble&link somewhere where the right tools are available (like the target platform itself). crosscompilation from windows to unix using libraries is also not that easy. I did it already for arm/linux: simply copy the *.a files to win32 and pass the path with -Fl to the compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
> Marco van de Voort wrote: > > > > crosscompilation from windows to unix using libraries is also not that easy. > > I did it already for arm/linux: simply copy the *.a files to win32 and > pass the path with -Fl to the compiler. I did it for small programs in sept-okt 2003 (mkxmlrpc specially). Didn't manage with textmode ide though. It always segfaulted on startup. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
>If you go this way I'd suggest adding also Lazarus. >I know the thing is "just another project made with FPC" but I think it >would be good for both. lazarus and freepascal are far closer than that. lazarus is essentially what completes the cloning of delphi by freepascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
On 4 jan 2005, at 15:27, peter green wrote: lazarus is essentially what completes the cloning of delphi by freepascal. I prefer to think that we're much more than just a clone of Delphi :) In fact, I've never even used Delphi in my entire life (nor really used Lazarus, for that matter). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Win32 RTL: Strange definition of constants in defines.inc
Hi, I've found that the definition of some constants like RT_RCDATA or IDI_EXCLAMATION from the latest RC1 is a little bit strange. These "constants" are defined as functions, which return a value using the function MakeIntResource, which in turn does a type casting from integer to LPTSTR. So all this only does returning a fixed integer value as LPTSTR. Why do this? Even if inline functions would remove most of the overhead, it seems odd. The compiler perfectly understands a type cast in a constant definition like const TestConst = LPTSTR(5); At least in Delphi mode this compiles fine. I didn't check the other modes, though. Another side effect of this function approach is that these "constants" can never be used as values for default parameters. The following function does not compile in FPC 1.9.6, but works fine in Delphi: function GetResource( lpszName : PChar; szType : PChar = RT_RCDATA; hInst: HINST = 0) : Pointer; Bye, Frank ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
Jonas Maebe wrote: On 4 jan 2005, at 15:27, peter green wrote: lazarus is essentially what completes the cloning of delphi by freepascal. I prefer to think that we're much more than just a clone of Delphi :) In fact, I've never even used Delphi in my entire life (nor really used Lazarus, for that matter). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel By the qotes I ment that someone might think so. I view lazarus as sometimes more important than FPC itself when it comes to spreading the word(tm). Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Another small issue in win32 package
The precompiled units of sqlite, cdrom ,odbc, winver and tcl comes in the install file (fpc-1.9.6.i386-win32.zip) but arent installed in the units folder. Luiz Americo __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] OS/2 install program
Thank you for the latest FreePascal update for OS/2. Unfortunately, I am unable to run the install.exe program which comes with the os2196.zip distribution. It seems that the IDE-type window comes up but the program terminates immediately. This happens too fast for me to be sure what comes up. There are no error messages written to the screen, as it is cleared when the program terminates. Further, there are no entries in popuplog.os2 on the boot drive. I have tried to run this from a DOS box, using rsx, but get the following error message (which might not be related): --- $ install.exe process 2 get hardware fault 5 (bound check) at 1D writing core file Process terminated by SIGILL --- Regards, Arnstein. Arnstein Prytz [EMAIL PROTECTED] School of Maths and Physics ph: 61-7-47815183 James Cook University fax: 61-7-47815880 Townsville, Queensland 4811, Australia ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ansistrings and widestrings
if i do ansistringvar := widestringvar or widestringvar := ansistringvar what does the compiler do? 1: use the systems default encoding (if so obtained from where?) 2: use utf-8 3: use iso-8859-1 4: use something else? furthermore if the encoding used is one not capable of representing all unicode code points what are the reduction rules used in the conversion from widestring to ansistring? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ansistrings and widestrings
if i do ansistringvar := widestringvar or widestringvar := ansistringvar what does the compiler do? 1: use the systems default encoding (if so obtained from where?) 2: use utf-8 3: use iso-8859-1 4: use something else? furthermore if the encoding used is one not capable of representing all unicode code points what are the reduction rules used in the conversion from widestring to ansistring? Compiler internally uses Wide2AnsiMoveProc and Ansi2WideMoveProc functions which can be reassigned by user. Currently their are just maping lower 128 chars in one representation to other. On Windows there are system functions that can be used to do conversion: MultiByteToWideChar and WideCharToMultiByte - these functions can take into account specified or globally set code page. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
