Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
On Fri, 7 Jan 2005, DrDiettrich wrote: So let me list the problems I encountered with a preceding version: - Mouse buttons inoperative (W2K, no menu selection...) - \\ contained in all stored pathes, IMO due to input of the FPC directory ending with an \. Please only report bugs on the latest version. The above bugs still apply :-( Here the bugs with W2K: - The mouse buttons don't work. The clicked character is highlighted, but that's all. Applies to installer and IDE. This is probably because your DOS window has the 'QuickEdit' mode enabled. There is nothing we can do then. You must disable this mode. Let me know when the installer is updated, then I will check this again. Somebody else should check with WinXP! The next installer will be a native installer, created with Inno Setup. So most of these problems will no longer be present. (But the current installer is cross-platform, so it will still be used, and bug reports are necessary) Some tool (Netscape?) changed the dots in the filenames into underscores, so that nothing but the docs were installed in my first try. I also got an empty install.dat, due to unreported connection problems with the ftp server. If I hadn't compared the file sizes, I had no idea what has gone wrong. These problems IMO also are worth a note in the readme. Windows users are a bit stupid, you know? ;-) I still have to download the IDE, until now everything seems to work :-) Is make and asld required as well? asld is, make not. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
On Thu, 06 Jan 2005 22:29:45 +0100, DrDiettrich wrote 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 installed. There's something wrong with that FPC version :-( I only could install an older verion, but AFAIR that one cannot cross compile at all. The new version is out of reach to me, unless I get it on a CD. I'm not sure what exactly you mean. If you mean that you can't get beyond the installer successfuly (i.e. no installation proceeds), then it probably isn't that important which platforms it can compile for anyway. g If FPC gets installed at all (even if you just unpack base*.zip), the help pages which I meant are displayed by fpc.exe (or ppc*.exe) when started without any parameters (from command line). Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
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 perhaps I missed some important features of the local CVS client? Good IDE's have cvs syncing integrated ;) Lazarus? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ansistrings and widestrings
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 lot of other languages. Okay, this is where I didn't understand the difference between code points and whatsoever. Doesn't in the umlaut and accented case exist a unique glyph and according code, that could be used in the first place? In other languages (Arabic...) the glyph may vary with the context, here I have no idea how to compare such text, but the native writers (speakers) of such glyphs should know ;-) Encoding isn't the main problem, you need dedicated procecures and functions for unicode comparision, upper/lower conversion etc. Agreed, these will become the string class methods. It may be necessary to partition Unicode into code pages, with different methods for comparison etc. In the worst case, if we cannot find or agree about a so-far unique representation for text, an uncomparable value has to become a valid result of a comparison. To achive this platfrom independend is very hard ... How that? I agree that here the existence of definitely compatible/portable OS services is not guaranteed. But when the methods have to be implemented for platforms that do not have such services at all, then these implementations can be used on all other platforms as well. All in all I'd say that we do not intend to implement a text processing or translation system. What we can do is to define a string or text class, that contains text in a well defined form, for processing with all specified methods. The key point is the import of text into an object of any such class. If no appropriate class has been implemented, the import is simply impossible. Inside, i.e. between these classes, all the methods should work. Perhaps with graceful uncomparable or unconvertable results, when somebody insists in using incompletly implemented classes. We don't want the impossible, the doable will be sufficient ;-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
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 from *nix to Dos/Windows (although in theory they should compile on Windows with a POSIX-compliant libc installed, if some small include files with type definitions are made). In a port from C to Pascal it's required to implement the OS specific procedures for all targets, as far as possible. This requires knowledge of the available target specific procedures, that can be used on the various platforms. In most cases the C code is written for Unix/POSIX, so that only a connection to e.g. Windows must be implemented, somehow. In other cases, like Abbrevia, the Unix connection must be implemented, and that's when I need detailed information about the available FPC libraries, even if I'm working on Windows. In my discussion with Linux people, about the distribution of FSF/GNU/open source... code, I had an idea for a more practical system for writing and distributing portable code. My ideas were not understood by the C people, perhaps I'll find a less biased audience here? Most readers will know the procedures used to install portable C code on e.g. Linux, from a *.src.tar.gz or like that. The most critical step is ./configure, where the package tries to find out all required information about the host and target system. IMO it's not a good idea to leave it to every single package to implement these tests. In the case of C code it would be much simpler to support an set of common header files, containing all ported data types and procedure prototypes. These header files map the portable functions to the functions available on the actual target, provide defines for the available functionality (memory mapped files just come into mind). These header files can be distinct from the header files of the platform and compiler, they only have to provide the appropriate mapping to the available procedures. The difference from the actual automake... procedure is the simplified maintenance of these header files, required exactly once for every target OS. Then not much is left what configure or the author can or should do at all. The makefiles can use platform specific macros for e.g. producing shared libraries, making libtool superfluous. The only decisions, left to the author of portable software, are about the workarounds when a feature, like MM files, is not available on a platform. In the simple case a Make will fail with unresolved external symbols, in the more elaborated case the code will check for the availability of a feature, and use standard procedures on less comfortably equipped platforms instead. Even if the exact procedures are somewhat different for C and Pascal, e.g. the standard header files correspond to Pascal units, the idea IMO already is part of FPC. What remains to do is the creation and maintenance of further portable units, in addition to (or extending) the already existing portable System, Classes, SysUtils etc. units. Wouldn't it be great to demonstrate to the C world how easy it can be to write portable software, based on the FPC philosophy? Not that I want to convince anybody to use Pascal instead of C, but I dream of open source code that compiles and runs on every (supported) platform, without autobloat and all that can of worms :-) I even would accept that Windows is not an official supported platform, because then I would maintain the portable units for that target myself. That wouldn't be really hard to do, it only were required to check the changes to the portable header files or units (interface sections), and to implement the new or changed funcionality as appropriate for Windows. Nothing more would be required, to turn Windows or any other best-hated g OS into a supported platform for really portable code ;-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] ansistrings and widestrings
it should be noted that pascal classes are really not suited to doing strings. to do strings with classes you really need language features which fpc doesn't have. doing strings with non garbage collected heap based classes would make something that was as painfull to work with as pchars and that was totally different from any string handling pascal has seen before. just as pascal doesn't consider two strings with different cases to be equal it should probbablly not consider two strings of unicode code points to be equal unless they are binary equivilent. conversion between ansistring and widestring should be done by functions that take one and returns the other (use a const param to avoid the implicit try-finally) so that no limitations are put on how the conversion is done. Theese functions should be indirected through procvars so that the default fallback versions can be replaced by versions supplied by a unit which provides proper internationalisation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich Sent: 07 January 2005 15:06 To: FPC developers' list Subject: Re: [fpc-devel] ansistrings and widestrings 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 lot of other languages. Okay, this is where I didn't understand the difference between code points and whatsoever. Doesn't in the umlaut and accented case exist a unique glyph and according code, that could be used in the first place? In other languages (Arabic...) the glyph may vary with the context, here I have no idea how to compare such text, but the native writers (speakers) of such glyphs should know ;-) Encoding isn't the main problem, you need dedicated procecures and functions for unicode comparision, upper/lower conversion etc. Agreed, these will become the string class methods. It may be necessary to partition Unicode into code pages, with different methods for comparison etc. In the worst case, if we cannot find or agree about a so-far unique representation for text, an uncomparable value has to become a valid result of a comparison. To achive this platfrom independend is very hard ... How that? I agree that here the existence of definitely compatible/portable OS services is not guaranteed. But when the methods have to be implemented for platforms that do not have such services at all, then these implementations can be used on all other platforms as well. All in all I'd say that we do not intend to implement a text processing or translation system. What we can do is to define a string or text class, that contains text in a well defined form, for processing with all specified methods. The key point is the import of text into an object of any such class. If no appropriate class has been implemented, the import is simply impossible. Inside, i.e. between these classes, all the methods should work. Perhaps with graceful uncomparable or unconvertable results, when somebody insists in using incompletly implemented classes. We don't want the impossible, the doable will be sufficient ;-) DoDi ___ 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
