Re: [fpc-devel] compiler bug?
El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste:
you are forciblly putting an out of range value in a variable what do you
expect to happen?
I think it's slightly subtler. I guess that this code:
if not b then
WriteLn('False')
else if b then
WriteLn('True')
else
WriteLn('Other');
...could throw a different result.
IIRC, any non-zero value is evaluated as True for a Boolean variable. The
problem with the case statement is that Jesús is asking the compiler which
specific value it chooses for assignements... and getting surprised because
it's not what he expected. I guess the compiler uses 1 instead of 255. But
it's surely documented anyway.
--
saludos,
Nico Aragón
[EMAIL PROTECTED]
http://espira.net/nico/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
On Sat, 1 Jan 2005, DrDiettrich wrote: In the meantime I downloaded the Abbrevia package from SourceForge, and came across several unpleasent constructs. Please let me introduce my preferred programming model for portable code. 1) Target Dependencies I don't accept any OS or machine specific conditional compilation in code, except in dedicated units. In Abbrevia the same fixes occur in various places in the code, instead of in a dedicated OS specific procedure. Such a procedure exists, but unfortunately only in the unpatched form :-( Also compiler specific conditionals should be used only where absolutely necessary (local options, syntax differences...). 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. 2) Code Checks It should be possible to check code for compilation on other platforms. This requires that target specific code can be compiled on any host, somehow. Consequently it must be possible to override the compiler generated symbols that describe the environment. Why, you can simply cross-compile ? 3) Standard Units Portable code shall use standard procedures and units for target specific actions. This requires the definition, implementation, and consequential use of one or more standard units for: - Machine specific data types and procedures (endianness...) Compiler defines the endianness. System unit has 'guaranteed' types. - OS specific data types and procedures ? This is not portable. - C and POSIX specific data types (for code ported from GNU/C) Then it should be clear which portable data types and procedures should be taken from which unit. It also should be easier to determine which procedures need special considerations in portable code, from the defined data types and procedures in these units. It's not necessary that everybody follows these principles, but I will do so in my own published portable code. Otherwise I can continue to write my code for Delphi, and let it to somebody else to port that code to e.g. FPC. In the simplest case these units will have an unconditional interface part, the target specific data type declarations and the implementation part can be included conditionally from the appropriate locations. For testing purposes fake units or code sections can contain the OS specific procedure declarations, with empty bodies. This way I could verify that my changes to the main stream code would not break the code for other environments, due to the use of not yet ported constants or data types etc. This model has one disadvantage, in so far as complex procedures with small embedded platform specific code could no more be checked, because it often was impossible to determine the impact of changes to local variables etc. in the conditionally excluded code. It also was and is impossible to automatically verify that the conditional sections really are implemented for every target! In another implementation of a target independent library I defined portable classes with standardized methods. These virtual methods were almost abstract in the base class, so that they had to be overridden in every derived class. In the initialization section of the unit the appropriate class was created and assigned to the according variable, based on the actual or desired target environment. Of course this approach has the disadvantage of increasing runtime (how much?), due to the virtual method calls. Nonetheless I think that in many cases the difference from the traditional method will not be noticeable, due to the (unknown, long?) runtime spent in the embedded OS calls. The best compromise might be a mix of both methods. The interface can be fully procedural, and objects with virtual methods are used only in the implementation part, and only when this approach makes sense. Perhaps somebody finds another way to achieve the same goal, with less disadvantages? I don't think you should worry about virtuals. For archiving purposes, it's the compression/decompression algorithms that will take most time, and tha actual reading/writing from stream. 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. I will be pleased to help where I can. But send a proposal before you start, I wouldn't want to you end up rewriting half your code after a discussion. ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Demo prog problem
Hi, As someone new to Pascal and to FreePascal, I've tried to compile and run the supplied demo pascal programs. However, I'm having trouble compiling dlltest.pp. I get a compile error dlltest.pp(15,24) Fatal:syntax error. : expected but const string found. testdll.pp compiled OK and created a .dll. Also winhello.pp compiled and run OK. Can someone let me know what is the problem compiling dlltest.pp please? Note that I'm not yet subscribed to the list so can you copy email reply to me please. Thanks in advance for any help. John. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
Hello, The Free Pascal Team is pleased to announce that FPC version 1.9.6 (or 2.0.0-RC1) is available and ready for download. This is a pre-release of version 2.0. As such, it is considered a beta of the upcoming 2.0 release, which is expected to be released in one or two months from here. While this is officially a beta, we believe that this version is release quality. We would very much like you download and install this version, and give any feedback regarding bugs and other issues. If no major bugs are found, version 2.0 will be released in a short timeframe. Highlights in this version: Compiler: + New platforms: - Linux: x86_64, amd64, sparc, PowerPC architectures. - Mac OS and Mac OS X (Darwin). - Netware Libc. - MorphOS. + Code generation improvements: Register variable support (-Or) for all targets, better inlining support. + MacPas compiler mode (-Mmacpas). RTL/FCL/FV: + New heap manager that releases memory back to the OS. + TThread.Synchronize support. + Further additions for improved Delphi compatibility. + Many other additions (RTTIUtils, new Datasets, FPCUnit test framework). * Free Vision Updated to fvision implementation, first official release. IDE: * Lots of improvements and stability fixes. * Support latest gdb 6.2.x and 6.3.x releases. Docs: + Lots of updates. + Easier to navigate html documentation. * fpDoc is used to generate all unit documentation. And of course many many bugfixes. A complete list of changes can be found in the whatsnew.txt file in the distribution. Downloads are available from the website for the following platforms: - Darwin (Mac OS X) - Dos (Go32V2) - FreeBSD - Linux (I386/Sparc/PPC/x86_64 (amd64)) - Mac OS - Netware (clib and libc) - OS/2 (native) - Win32 To download, go to http://www.freepascal.org/sdown.html and select a mirror near you. Look in the section 'official beta releases' and select the platform of your choice; then follow the download instructions. If you choose the SourceForge mirror, the download instructions are different. Also note that sourceforge mirrors are not immediatly up-to-date. Enjoy it, and a Happy New Year from The Free Pascal team. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
I think it's slightly subtler. I guess that this code:
if not b then
WriteLn('False')
else if b then
WriteLn('True')
else
WriteLn('Other');
...could throw a different result.
IIRC, any non-zero value is evaluated as True for a Boolean
variable. The
No, and no. There your assuming some implementation of the type Boolean.
I Peter stated, bitwise logic and Boolean logic are neatly separated in
Pacal. You say you're not counting on how it's implemented and still insists
in expressions as True 0. No way.
problem with the case statement is that Jesús is asking the
compiler which
specific value it chooses for assignements... and getting
surprised because
it's not what he expected. I guess the compiler uses 1 instead of
¨¨¨
255. But
Dodi told you, Peter told you and I tell you now. Don't guess anything about
how a compiler internally implementens a type. Peter could have said so
louder but not clearer: if you cast a type into another type that can result
in an overflow, it's programmer's fault, 'cause at least in Pascal
(exceptions apart) those cast have to be done explicitly. And you can't
trust wheter True is 255, 1, -1 or use simply another bit pattern or
whathever, which is perfectly legal, Don't ya say you agree with everyone
when you are clearly on the contrary.
I think this is goin' far behind this list is intended to. All I can say is
that there should be some kind of compatibility for those who, as me (:-(
guilty), sometimes recurre to Fix'n Dirty, I mean: FPC (at least in FPCOBJ
or DELPHI compatibilty mode), Kilyx and Delphy should behave the same, but
as long as Kylix and Delphi don't keep the same (sane?) behaviour, it's up
to you, FPC developers to choose what you find more (efficient?, accurate to
reality, compatible? I dunno, but surely you do)
Anyway, I think it's pointless to go on with this
it's surely documented anyway.
The internal implementation of a Boolean type, I guess it ain't? Surely for
every compiler it is, but there's no standard way and I'm quite sure there's
no standard how it should behave when typecasting.
--
saludos,
Nico Aragón
Bye, Nico and everyone.
--
JMR
BTW: I don't wish everyone Happy Christmas 'cause there are a lot of
religions, and to too many of them, Christmas has no sense. Anyhow my best
wishes to everyone
For Dodi's Sake (What he asked Nico about his 'rudimentary spanish'), and to
anyone who might be interested:
a) ¡Hola, Torpedo!
That's slang. You could translate it into 'Hi, Dork!'
b) Feliz Año:
In effect, it's the same as in English: It means merely: 'Happy new year!'
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpUmask in Darwin
On 31 dec 2004, at 02:00, Gary Handelman wrote: Does anyone know what happened to the fpUmask function under fpc Darwin 1.9.5 [2004/08/08] for powerpc? I'm guessing that It's supposed to be in the baseunix unit, and I have verified this under fpc Linux 1.9.4 [2004/05/30] for i386. Using the Darwin compiler gives me: Identifier not found fpUmask. This has been added in 1.9.7, the fix didn't make it in time for 1.9.6 Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization error causes pyacc and plex to fail
On 1 jan 2005, at 19:49, [EMAIL PROTECTED] wrote: Can't seem to get bug submission to work so I'm sending this here. The 1.9.x distributed binaries of plex and pyacc both fail, as well as any created from a 1.9.5 source snapshot. plex ends normally but only creates 2 states. pyacc fails with a RTE 216 on a move in procedure setunion of yaccbase. The makefile compiles these programs with the -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both work correctly. I am using unmodified versions of both programs so am only attaching the output of each scenario. Feel free to contact me if you need anything else. Could you try again with the 1.9.6 release? Several optimizer bugs have been fixed this week. I can't test since I don't have any yacc/lex grammar available. Thanks, Jonas ___ 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: 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 Checks Why, you can simply cross-compile ? No, I can't, neither in Delphi nor (AFAIK) in the Windows version of fpc. 3) Standard Units Compiler defines the endianness. Correct, but this definition must be evaluated to produce the appropriate code. E.g. RPM defines a function htonl, read: HostToNetworkLong, that then is used to convert Long values in Network byte order (big endian?) into the Host byte order. Such a function should reside in a common unit, where the according implementation depends on the endianness of the host machine. It also should have an handy name, so that it's almost obvious how to replace htonl in the ported code. System unit has 'guaranteed' types. Fine, but these names often are not very descriptive, like ShortInt and SmallInt. Names like cUInt16 make it more obvious that this type has a fixed size and is unsigned. More standard C names have to be mapped to the predefined types. E.g. in Abbrevia the file size type (IMO) initially has been Integer, later was conditionally extended to LongInt and then to Int64, depending on the capabilities of the compiler and platform. Here it can be seen that a replacement of some type by the currently appropriate System standard name is not a good idea. A distinct data type like off_t (standard C) would make all related adaptations much simpler, with exactly one definition of that data type. - OS specific data types and procedures ? This is not portable. When porting code, that was written for a specific platform, the names of the procedures and related data types should not be changed. Instead these procedures should be declared in a general unit, together with the according implementations for other platforms. Please note the different handling of OS functions and types, where the names should not be changed, in contrast to the htonl function mentioned above, that should be renamed to the according (to be defined) common procedure name. The best compromise might be a mix of both methods. The interface can be fully procedural, and objects with virtual methods are used only in the implementation part, and only when this approach makes sense. Perhaps somebody finds another way to achieve the same goal, with less disadvantages? I don't think you should worry about virtuals. I don't worry at all, but many people (assembler freaks...) will. That's why I want to collect opinions before proceeding. For archiving purposes, it's the compression/decompression algorithms that will take most time, and tha actual reading/writing from stream. This is an rather obvious case, but there exist other cases... 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. I will be pleased to help where I can. But send a proposal before you start, I wouldn't want to you end up rewriting half your code after a discussion. ;-) After a closer look at Abbrevia I'm not sure whether it's a good example for porting code. The recent Kylix extension is crap, and also the preceding conversions into Windows specific procedures and Pascal standard types must be reverted to the original definitions. That's why I'd prefer to use the better ported and portable code from e.g. zlib and bzip2, instead of again porting the according miserable code from Abbrevia. More to follow... 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: 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. I will be pleased to help where I can. But send a proposal before you start, I wouldn't want to you end up rewriting half your code after a discussion. ;-) Here some comments and questions about the Abbrevia port. 1) Conditionals I've redesigned the AbDefine.inc file, with two important changes: In the first place a DEBUG symbol allows to replace everything else by another AbDebug.inc file. This switch will allow (me) to define the OS etc. at will, for debugging purposes. Defining this symbol and the file contents is entirely up to the user, the file will not occur in CVS or any distribution. In the next place the FPC symbol is used to replace the Borland specific part by an AbFpc.inc file. This file, with an appropriate name, can be contributed by some FPC user, I don't care for this conditional branch for now. Question: Rename all files? All lowercase...? The LINUX symbol can clash with the according FPC symbol. It should be renamed e.g. into KYLIX - does somebody know what Kylix defines for itself? Question: How to use the FPC provided target symbols? I'm not happy with the UNIX keyword, I'd used POSIX instead. But that's only my opinion, I don't want to introduce another symbol. I'm also not familiar with the differences between the Unix/POSIX systems. Currently I make no according differences myself, I only separate the existing code into conditional MSWINDOWS and UNIX parts. 2) File Restructuring I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS and UNIX sections, each containing complete procedures. These sections could be moved into dedicated OS specific include files - what's the preferred way? It may be desireable to use another dedicated unit for strictly platform dependent procedures, apart from AbUtils? According to my first impression of the Abbrevia coding conventions I'd prefer to use the existing and better ported and portable code in the already existing paszlib and bzip2 libraries, instead of porting the according Abbrevia implementations. Perhaps the whole de/compressor part of Abbrevia could be reduced to the base classes, from which inherit the new wrappers for the FPC ports. 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? A direct port IMO requires more work than a redesign. In a redesign also much Windows/Delphi/Kylix specific stuff could be removed or replaced by more portable procedures. The entire file handling stuff in Abbrevia IMO is too Windows-centric, the Linux/Kylix extensions only are patchwork that tries to map the Windows file handling to the very different POSIX file handling, what can result in loss of file attributes on POSIX platforms. 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? IMO this type also should be used in the TStream classes, replacing the current conditional distinction (seek64bit) between 32 and 64 bit methods. Why write two implementations, when the compiler can use the actual type definition immediately? DWORD will be replaced by cUInt32 (or equivalent - what?), as far as this type is used outside dedicated MSWINDOWS code. The 16 bit word datatype IMO should not be used in 32 bit code, unless where required in datastructures with a fixed layout. Similar considerations and decisions will be required during porting, I only presented these examples as a concrete base for a general discussion. 4) Exceptions, Error Codes etc. IMO it would be sufficient to use one general exception class for the de/compression errors. An application cannot draw any advantage from many specialized exception classes, and exception handlers inside a specific class can use the class specific error code in the exception object. For the same reasons I think that public error codes only should be specified for those error conditions that can or must be handled in some specific way. These common codes then should be used by all de/compressor classes. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization error causes pyacc and plex to fail
Jonas Maebe wrote: On 1 jan 2005, at 19:49, [EMAIL PROTECTED] wrote: Can't seem to get bug submission to work so I'm sending this here. The 1.9.x distributed binaries of plex and pyacc both fail, as well as any created from a 1.9.5 source snapshot. plex ends normally but only creates 2 states. pyacc fails with a RTE 216 on a move in procedure setunion of yaccbase. The makefile compiles these programs with the -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both work correctly. I am using unmodified versions of both programs so am only attaching the output of each scenario. Feel free to contact me if you need anything else. Could you try again with the 1.9.6 release? Several optimizer bugs have been fixed this week. I can't test since I don't have any yacc/lex grammar available. h2pas? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimization error causes pyacc and plex to fail
On 1 jan 2005, at 19:49, [EMAIL PROTECTED] wrote: Can't seem to get bug submission to work so I'm sending this here. The 1.9.x distributed binaries of plex and pyacc both fail, as well as any created from a 1.9.5 source snapshot. plex ends normally but only creates 2 states. pyacc fails with a RTE 216 on a move in procedure setunion of yaccbase. The makefile compiles these programs with the -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both work correctly. I am using unmodified versions of both programs so am only attaching the output of each scenario. Feel free to contact me if you need anything else. Could you try again with the 1.9.6 release? Several optimizer bugs have been fixed this week. I can't test since I don't have any yacc/lex grammar available. (today's 1.9.7) -bash-2.05b$ touch h2pas.y There is mail for you! -bash-2.05b$ gmake /home/marcov/bin/pyacc h2pas.y TP Yacc Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... sort ... closures ... Runtime error 216 at $08051474 $08051474 MOVE, line 76 of /home2/marcov/cvs/devel/fpc/rtl/i386/i386.inc $0804F0A1 SETUNION, line 349 of yaccbase.pas $08049167 CLOSURES, line 94 of yaccclos.pas $0804E55A GENERATE_PARSER, line 580 of yaccsem.pas $08062EA4 YYACTION, line 250 of pyacc.pas $08062A9A YYPARSE, line 2079 of pyacc.pas $0806494A main, line 2479 of pyacc.pas gmake: *** [h2pas.pas] Error 216 -bash-2.05b$ touch scan.l -bash-2.05b$ gmake /home/marcov/bin/plex scan.l TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... DFA construction ... code generation ... DONE 839 lines, 88 rules, 555/1200 p, 2/600 s, 0/1200 t. /home/marcov/bin/ppc386 -Sg -Fu../../rtl/units/i386-freebsd -FE. -FUunits/i386-freebsd -di386 h2pas.pas Free Pascal Compiler version 1.9.7 [2005/01/02] for i386 Copyright (c) 1993-2005 by Florian Klaempfl Target OS: FreeBSD/ELF for i386 Compiling h2pas.pas Compiling scan.pas scan.pas(232,6) Note: Local variable i not used scan.pas(943,25) Error: High range limit low range limit scan.pas(943,25) Error: Upper bound of range is less than lower bound scan.pas(946,2) Error: Illegal expression scan.pas(946,2) Error: Illegal expression scan.pas(946,2) Fatal: Syntax error, ) expected but ; found gmake: *** [h2pas] Error 1 -bash-2.05b$ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
No offence meant but, Can this thread (see subject) please be stopped ? It is no longer interesting for the rest of us, and threatens to lead to a flame war. I'm sure no-one is interested in that either. 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
On Friday 31 December 2004 14:24, [EMAIL PROTECTED] wrote: Normally one never uses a fully qualified identifier. So I'm not normal. ;) I *always* use them. Makes life easier. Only when a possible name conflict exists, which - Should be very rare, and avoided in the first place. IBTD. I even often use the same names for same things, but in different units (like Open/Close, ...). I don't see any reason to not use the unit-name for identifiers. This also avoids C-like prefixes to each name. One usually does the same with OOP techniques where each constructor is called Init or Create. ;-) And BTW, it is not very long ago that this actually saved me from intermixing Objects.NewStr with SysUtils.NewStr. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
On Sun, 2 Jan 2005 23:35:10 +0100 (Romance Standard Time), Michael Van Canneyt
wrote
On Sun, 2 Jan 2005, DrDiettrich wrote:
Michael Van Canneyt wrote:
.
.
2) File Restructuring
I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS
and UNIX sections, each containing complete procedures. These sections
could be moved into dedicated OS specific include files - what's the
preferred way?
{$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).
Tomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
