Re: [fpc-devel] Windows Console App
(laughter)
I know how to write console apps; I even know how to start them :-)
{I have no experience with GUI progarms, but that's another story :-( }
No, my question was: how did you put the "D" in the keyboard buffer? I would
like to put out the next command
- Original Message -
From: Ozz Nixon
To: Gerhard Scholz
Cc: FPC developers' list
Sent: Sunday, April 26, 2020 8:31 AM
Subject: Re: [fpc-devel] Windows Console App
Sure! I assume you are asking how to make a console app?
You do not need {$APPTYPE CONSOLE} ... instead, you simply write your code
like normal:
Program example;
Uses
CRT;
Begin
ClrScr;
Writeln('Wassup?!');
Readln;
End.
then in the command prompt (any OS), simply fpc example then
.\example, or ./example - depending upon your OS... voila. "Console App"
now, that is not a DOS 16bit APP... that requires other mess, and since I
own Turbo Pascal 7.0 source, I have my own TP 32bit compiler that produces
TP 7 compatible 16bit Units and Apps. ;-)
@ you can get me at ozzni...@gmail.com if you need any help (I do not
normally code GUI apps - money in the Legacy market) so I have made a wide
range of solutions. This email was started because of something odd on
Windows recently for me...
Ozz
On Sun, Apr 26, 2020 at 1:27 AM Gerhard Scholz wrote:
Hi,
I would like to know how you did that since it was exactly what I was
searchomg for a while ago...
Could you send me a piece of code?
Greetings
Gerhard
- Original Message -
From: Ozz Nixon via fpc-devel
To: FPC developers' list
Cc: Ozz Nixon
Sent: Sunday, April 26, 2020 2:21 AM
Subject: [fpc-devel] Windows Console App
Anyone ever experience making a console app (cross-platform), but, on
windows when the app finishes, it appears to have put an uppercase C or D in
the keyboard buffer, so the Prompt now has C:\>D ???
Every time I run my app, be it show help screen and end, or actually
execute - when it finishes I end up with a letter sitting at the prompt. (A
few months ago, I was having a problem, and it was related to compiling all
of the methods with cdecl. That build would leave a stray "C" at the start
of the prompt upon exiting. Now, I ran into a new problem where I needed to
recompile with -FcUTF8 to track down which units it thought were having a
UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8
compile option, then it actually showed what file had ''
strings ... so I switched to # and it compiles, but, the
prompts have "D" at the start of them now.(hopefully I described that
understandable).
Environment: Windows XP 32bit
C:\FPC\3.0.4\bin\i386-Win32\fpc.exe
If no one else has experienced/has a solution, I will sit down and bang out
test cases until I find what combination (units, code, whatever) is
producing this result.
Ozz
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows Console App
Hi, I would like to know how you did that since it was exactly what I was searchomg for a while ago... Could you send me a piece of code? Greetings Gerhard - Original Message - From: Ozz Nixon via fpc-devel To: FPC developers' list Cc: Ozz Nixon Sent: Sunday, April 26, 2020 2:21 AM Subject: [fpc-devel] Windows Console App Anyone ever experience making a console app (cross-platform), but, on windows when the app finishes, it appears to have put an uppercase C or D in the keyboard buffer, so the Prompt now has C:\>D ??? Every time I run my app, be it show help screen and end, or actually execute - when it finishes I end up with a letter sitting at the prompt. (A few months ago, I was having a problem, and it was related to compiling all of the methods with cdecl. That build would leave a stray "C" at the start of the prompt upon exiting. Now, I ran into a new problem where I needed to recompile with -FcUTF8 to track down which units it thought were having a UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8 compile option, then it actually showed what file had '' strings ... so I switched to # and it compiles, but, the prompts have "D" at the start of them now.(hopefully I described that understandable). Environment: Windows XP 32bit C:\FPC\3.0.4\bin\i386-Win32\fpc.exe If no one else has experienced/has a solution, I will sit down and bang out test cases until I find what combination (units, code, whatever) is producing this result. Ozz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] test on TP
BP 7.0 (real)
BP7.0 (protected)
VP2.1b279
all: not assigned
- Original Message -
From: Marco van de Voort mar...@stack.nl
To: fpc-devel@lists.freepascal.org
Sent: Wednesday, May 14, 2014 11:46 AM
Subject: [fpc-devel] test on TP
Can sb test this program on TP/BP7 and tell me the result? Thank you.
program sometest;
{$ifdef fpc}
{$mode tp}
{$endiof}
Type
PChildThing = ^TChildThing;
TChildThing = object
constructor init;
end;
PSomething = ^TSomething;
TSomething = object
ct:PChildThing;
constructor init;
end;
constructor TSomething.init;
begin
new(ct,init);
end;
var p : PSomething;
constructor TChildThing.Init;
begin
if assigned(p) then
writeln('assigned')
else
writeln('not assigned')
end;
begin
p:=nil;
p:=new(PSomething,Init);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
I know that the examples are stupid and most of them senseless. Sometimes I used similar workarounds (more senseful), so I just wanted to know if the type helper construct produces more efficient code. It doesn't. The main advantage of helpers compared to your example is that the compiler will do the type checking. That's an advantage. 12345678.showvalue ; // 4712? And the last line should show 12345678 hopefully :) Yes. it does. Greetings Gerhard - Original Message - From: Sven Barth To: FPC developers' list Sent: Friday, February 08, 2013 8:24 PM Subject: Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers Am 08.02.2013 19:52 schrieb Gerhard Scholz g...@g--s.de: Thanks for the help, I understood it now; I also found the test progs. As far I see, it could already be substituted by the following constructs: program RHelper1v ; type poLongint = ^ oLongint ; oLongint = object li : longint ; procedure ShowValue ; procedure put ( j : longint ) ; Function inc : poLongint ; end ; procedure oLongInt.showvalue ; begin Writeln ( 'Value=', li ) ; end ; procedure oLongInt.put ( j : longint ) ; begin li := j ; end ; function oLongInt.inc : polongint ; begin system.inc ( li ) ; result := @self ; end ; function v ( i : longint ) : polongint ; begin result := addr(i) ; end ; var i : LongInt ; begin i := 3 ; olongint(i).showvalue ; olongint(i).put ( 4711 ) ; olongint(i).showvalue ; olongint(i).inc ; olongint(i).showvalue ; olongint(v(12345678)^).put ( 4711 ) ; // senseless, but possible olongint(v(12345678)^).inc ;// senseless, but possible olongint(v(12345678)^).showvalue ; // 4712? end. And it produces the same assembler code as the construct TYPE HELPER FOR LONGINT (which is definitely better readable). Impressive O.o I would have never thought to use objects like that. The main advantage of helpers compared to your example is that the compiler will do the type checking. The same program with type helper: program RHelper1f ; type pLongInt = ^ longint ; tLongIntHelper = type helper for LongInt procedure ShowValue ; procedure put ( j : longint ) ; Function inc : pLongint ; end ; procedure TLongIntHelper.showvalue ; begin Writeln ( 'Value=', self ) ; end ; procedure TLongIntHelper.put ( j : longint ) ; begin self := j ; end ; function tLongInthelper.inc : plongint ; begin system.inc ( self ) ; result := @self ; end ; var i : LongInt ; begin i := 3 ; i.showvalue ; i.put ( 4711 ) ; i.showvalue ; i.inc ; i.showvalue ; 12345678.put ( 4711 ) ; // senseless, but possible 12345678.inc ; // senseless, but possible 12345678.showvalue ; // 4712? end. The last 3 lines show that the type helpers allow useless code. I assume such useless code is not catchable by the compiler. If we could keep track of writes to Self and then mark the methods accordingly we could at least provide a warning or a hint. And the last line should show 12345678 hopefully :) Regards, Sven ___ 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
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
@Sven:
the problem is gone...
I made a new SVN run, and made a totally fresh compiler out of it. Now the
program compiles.
Maybe I didn't understand the syntax correctly: I didn't see how to get the
value inside the method?
example:
type
TLongIntHelper = type helper for LongInt
class procedure ShowValue; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Value=',self);
end;
var i : longint ;
begin
i:= 3 ;
.showvalue ;
end.
- Original Message -
From: Sven Barth
To: FPC developers' list
Sent: Friday, February 08, 2013 7:49 AM
Subject: Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type
helpers
Am 08.02.2013 07:22 schrieb Paul Ishenin i...@kmiac.ru:
08.02.2013 14:03, Sven Barth пишет:
0:25:46,51 G:\ob\syncdirsppc386 -vv -al -CioOrt -Cs600 -gclt
-Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u
-Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u
-FiP:\gs\tp55\includes -Fif:\-u -FE. thelper
thelper.pas(2,33) Error: Identifier not found helper
thelper.pas(2,33) Error: Error in type definition
thelper.pas(2,33) Error: Can't create unique type from this type
thelper.pas(2,33) Fatal: Syntax error, ; expected but FOR found
Fatal: Compilation aborted
The compiler is freshly generated from the SVN
Does the compiler expect special options to invoke the record helper
feature?
Did you add {$mode objfpc} to your program?
Look at the compile string argument: -Mobjfpc
It's too early in the morning to look at command lines :)
@Gerhard: could you please check that the compiler is indeed from a current
SVN checkout?
Regards,
Sven
___
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
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
Thanks for the help, I understood it now; I also found the test progs.
As far I see, it could already be substituted by the following constructs:
program RHelper1v ;
type
poLongint = ^ oLongint ;
oLongint = object
li : longint ;
procedure ShowValue ;
procedure put ( j : longint ) ;
Function inc : poLongint ;
end ;
procedure oLongInt.showvalue ;
begin
Writeln ( 'Value=', li ) ;
end ;
procedure oLongInt.put ( j : longint ) ;
begin
li := j ;
end ;
function oLongInt.inc : polongint ;
begin
system.inc ( li ) ;
result := @self ;
end ;
function v ( i : longint ) : polongint ;
begin
result := addr(i) ;
end ;
var
i : LongInt ;
begin
i := 3 ;
olongint(i).showvalue ;
olongint(i).put ( 4711 ) ;
olongint(i).showvalue ;
olongint(i).inc ;
olongint(i).showvalue ;
olongint(v(12345678)^).put ( 4711 ) ; // senseless, but possible
olongint(v(12345678)^).inc ;// senseless, but possible
olongint(v(12345678)^).showvalue ; // 4712?
end.
And it produces the same assembler code as the construct TYPE HELPER FOR
LONGINT
(which is definitely better readable).
The same program with type helper:
program RHelper1f ;
type
pLongInt = ^ longint ;
tLongIntHelper = type helper for LongInt
procedure ShowValue ;
procedure put ( j : longint ) ;
Function inc : pLongint ;
end ;
procedure TLongIntHelper.showvalue ;
begin
Writeln ( 'Value=', self ) ;
end ;
procedure TLongIntHelper.put ( j : longint ) ;
begin
self := j ;
end ;
function tLongInthelper.inc : plongint ;
begin
system.inc ( self ) ;
result := @self ;
end ;
var
i : LongInt ;
begin
i := 3 ;
i.showvalue ;
i.put ( 4711 ) ;
i.showvalue ;
i.inc ;
i.showvalue ;
12345678.put ( 4711 ) ; // senseless, but possible
12345678.inc ; // senseless, but possible
12345678.showvalue ; // 4712?
end.
The last 3 lines show that the type helpers allow useless code. I assume
such useless code is not catchable by the compiler.
Gerhard
- Original Message -
From: Paul Ishenin paul.ishe...@gmail.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Friday, February 08, 2013 3:21 PM
Subject: Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type
helpers
08.02.13, 21:52, Gerhard Scholz wrote:
Maybe I didn't understand the syntax correctly: I didn't see how to get
the value inside the method?
By accessing Self
example:
type
TLongIntHelper = type helper for LongInt
class procedure ShowValue; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Value=',self);
end;
Replace your static class procedure with regular method:
procecure TLongIntHelper.Test;
begin
WriteLn(Self);
end;
Class static method is only needed if you are going to call it for the
type declaration itself like: LongInt.PrintSize:
class procedure TLongIntHelper.PrintSize;
begin
WriteLn(SizeOf(LongInt));
end;
static methods don't have a magic Self variable.
In any case I suggest to look for test which had been commited together
with Sven patch.
Best regards,
Paul Ishenin
___
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
[fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
Hello,
I tried to compile the example:
type
TLongIntHelper = type helper for LongInt
class procedure Test; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Test');
end;
var
i: LongInt;
begin
i.Test;
$12345678.Test;
LongInt.Test;
end.
Result:
0:25:46,51
G:\ob\syncdirsppc386 -vv -al -CioOrt -Cs600 -gclt -Mobjfpc -O1 -OpPENTIUM
-Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u -Fiz:\-u -FuP:\gs\tp55\includes
-Fuf:\-u -Fiu:\ -FiM:\u -FiP:\gs\tp55\includes -Fif:\-u -FE.
thelper
thelper.pas(2,33) Error: Identifier not found helper
thelper.pas(2,33) Error: Error in type definition
thelper.pas(2,33) Error: Can't create unique type from this type
thelper.pas(2,33) Fatal: Syntax error, ; expected but FOR found
Fatal: Compilation aborted
The compiler is freshly generated from the SVN
Does the compiler expect special options to invoke the record helper
feature?
Gerhard
- Original Message -
From: Sven Barth pascaldra...@googlemail.com
To: fpc-annou...@lists.freepascal.org
Cc: fpc-pas...@lists.freepascal.org; FPC developers' list
fpc-devel@lists.freepascal.org
Sent: Wednesday, February 06, 2013 10:49 AM
Subject: [fpc-announce] Feature announcement: Type helpers
Hello Free Pascal community!
I'm pleased to announce the addition of type helpers which extend the
existing helper concept with the ability to extend primitive types.
Motivation:
With class and record helpers the possibility was created to extend
classes and records with types without subclassing the type (which
wouldn't be possible with records anyway). This allows to add e.g. methods
to types in units that you can't influence or where you can't influence
with type is instantiated (e.g. the TStrings descendant used in TMemo).
Now it is logical to extend this also to other types supported by Pascal,
but here more driven by the possibility to group methods together and have
them appear to belong to the primitive type.
While this does not bring the concepts of boxing of managed
languages/environments like Java and .NET to Pascal it does nevertheless
look this way.
Syntax:
The declaration of type helpers looks as follows:
TYPENAME = type helper[(BASEHELPER)] for EXTENDEDTYPE
DECLARATIONS
end;
Like class and record helpers they support all visibility sections and you
can define methods, properties and constructors. Inside methods declared
in the helper Self will be of the extended type's type and it's value
can also be changed.
Similar to record helpers class methods MUST be declared as static.
Usage:
A type helper is active if it is in scope. This means it must either have
been declared in the same unit before the code which wants to use the
helper or it needs to be declared in a used unit. As with class and type
helpers only one helper for a given type can be active and thus you need
to keep in mind the scoping rules when using helpers (e.g. the current
unit is searched in the order implementation section then interface
section (if the code is in the implementation section) and then the used
units are searched from right to left and each unit from top to bottom).
In some cases the meaning of a type depends on the compiler settings the
helper is compiled with. E.g. the type Integer is either a ShortInt or a
LongInt depending on the current mode (fpc/tp vs. objfpc/delphi) and the
type String is different depending on the switches {$H+/-} and
{$modeswitch unicodestring}. This needs to be kept in mind when working
with these generic types. Another special case is the type Extended on
platforms that don't support that type (and thus it will be defined as
Double).
Additionally a type declared as NewType = type OldType is considered a
completly independant type as it is the case with e.g. operator overloads
as well.
If a helper for the type is in scope you can simply invoke it's methods or
properties like you'd do on classes or records. Let's suppose we have a
helper with method ToString: String for the type LongInt in scope then
it will look like this:
=== example begin ===
var
i: LongInt;
begin
Writeln(i.ToString);
end.
=== example end ===
Additionally to invoking type helpers on variables they can also be used
on constants though special care needs to be taken that the correct type
is used. E.g. the constant 200 will be handled as a Byte whereas 20
will be handled as SmallInt. Also the type of string constants depends
on the current mode switch (especially {$H+/-} and {$modeswitch
unicodestring}) and also the content of the string. E.g. in case of
{$mode objfpc}{$H+} a string containing unicode characters will be
handled as a UnicodeString constant and thus only helpers for
UnicodeString will apply.
For the following example let's assume the helper from the previous
example is in scope again:
=== example begin ===
begin
Writeln($12345678.ToString);
end.
=== example end ===
Additionally addresses (e.g. @i) (type: Pointer)
Re: [fpc-devel] 'with' operator in inlined functions
I also found it a while ago, and then I was told it was already an open bug. Still it seems to be an open bug. -Ursprungliche Nachricht- Von: Ozerski Pavel [EMAIL PROTECTED] An: FPC developers' list fpc-devel@lists.freepascal.org Gesendet: Donnerstag, 13. Oktober 2005 08:16 Betreff: [fpc-devel] 'with' operator in inlined functions Hi all, It seems that an using the with operator inside of procedures/funcctions which are declared as inline causes AVs or internal errors (depend on compiler 2.x.x versions) at compiling stage. Is it a real problem? ___ 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
Re: [fpc-devel] inline and asm code
I found out that for operators which are declared to be inline and have asm code inside the inlining option is ignored (I assume the same would be true for procs/funcs). Is that intentional? Does it have a reason? Would be great if that could be stopped. Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug while evaluating macros
I have tried to put this into the bug list but got an error message (I have
put that error into the buglist: bug# 4228), so I have to put it in the
mailing list, sorry.
Bug while evaluating macros:
Compilerversion of 25.7.2005 has error (18.7.2005 works!)
{$note hello1}
{$if sizeof ( integer ) = 2 }
{$ifdef BCDgr4 }
VAR
myMinIntBCD : tBCD ;
{$endif}
{$else}
{$note hello2}
{$if sizeof ( integer ) = 4 }
{$note hello2a}
{$ifdef BCDgr9 }
{$note hello2b}
VAR
myMinIntBCD : tBCD ;
{$endif}
{$else}
{$if sizeof ( integer ) = 8 }
{$ifdef BCDgr18 }
VAR
myMinIntBCD : tBCD ;
{$endif}
{$else}
{$fatal You have an interesting integer type! Sorry, not supported}
{$endif}
{$endif}
{$endif}
{$note hello3}
The sizeof ( integer ) = 4 produces the error:
22:55:40 P:\FmtBCDppc386 -al -Croit -Cs70 -Op1 fmtbcdgs
Free Pascal Compiler version 2.1.1 [2005/07/25] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Note: Switching assembler to default source writing assembler
Target OS: Win32 for i386
Compiling fmtbcdgs.pas
fmtbcdgs.pas(10,66) Warning: Comment level 2 found
fmtbcdgs.pas(13,6) Warning: Comment level 2 found
fmtbcdgs.pas(13,46) Warning: Comment level 2 found
fmtbcdgs.pas(52,3) Note: User defined: BCD Digits 4
fmtbcdgs.pas(56,3) Note: User defined: BCD Digits 9
fmtbcdgs.pas(60,3) Note: User defined: BCD Digits 18
fmtbcdgs.pas(64,3) Note: User defined: BCD Digits 64
fmtbcdgs.pas(68,3) Note: User defined: BCD Digits 180
fmtbcdgs.pas(192,4) Note: User defined: ansi
fmtbcdgs.pas(807,3) Warning: Comment level 2 found
fmtbcdgs.pas(808,3) Warning: Comment level 2 found
fmtbcdgs.pas(963,2) Note: User defined: hello1
fmtbcdgs.pas(970,2) Note: User defined: hello2
fmtbcdgs.pas(971,7) Fatal: Compilation aborted
An unhandled exception occurred at $00421661 :
EAccessViolation : Access violation
$00421661 SEARCHSYM, line 1833 of symtable.pas
$00476FDC READ_FACTOR, line 580 of scanner.pas
$00476A8B READ_TERM, line 739 of scanner.pas
$0047695B READ_SIMPLE_EXPR, line 764 of scanner.pas
$00476543 READ_EXPR, line 790 of scanner.pas
$004764E8 PARSE_COMPILER_EXPR, line 843 of scanner.pas
$00477951 BOOLEAN_COMPILE_TIME_EXPR, line 850 of scanner.pas
$00479AE5 TSCANNERFILE__IFPREPROCSTACK, line 1674 of scanner.pas
$004779BB DIR_IF, line 857 of scanner.pas
$00479E22 TSCANNERFILE__HANDLECONDITIONAL, line 1756 of scanner.pas
$0047A1ED TSCANNERFILE__HANDLEDIRECTIVES, line 1849 of scanner.pas
$0047AD59 TSCANNERFILE__SKIPCOMMENT, line 2349 of scanner.pas
$0047B071 TSCANNERFILE__READTOKEN, line 2492 of scanner.pas
$004852F4 CONSUME, line 137 of pbase.pas
$0048F674 READ_PROC, line 1284 of psub.pas
$0048FA22 READ_DECLARATIONS, line 1374 of psub.pas
$0048CCA8 BLOCK, line 161 of psub.pas
I assume it has something to do with the withsymtable (weren't there
changes?)
I was not able to construct a short example; when I shortened to a simple
example it did work. So the full code can be found on
http://g--s.de/pas/fmtbcdgs.pas (sorry, 112 kB!)
Solution for the moment: to go back to the FPC version of 18.7.2005
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dateutils: ...julian...
I have seen, that the Julian-Routines in dateutils are a little bit incomplete. Since I have a working Julian (and the other way round: nailuJ) -function, I could integrate them, or deliver the functions so somebody else who wants to integrate them. For integrating I would need more information about the parameters, especially the meaning of the double, and: which day has a julian value of 1 (in my routines 1.1.1600 is the base) What is JulianDate vs. ModifiedJulianDate? Function DateTimeToJulianDate(const AValue: TDateTime): Double; Function JulianDateToDateTime(const AValue: Double): TDateTime; Function TryJulianDateToDateTime(const AValue: Double; var ADateTime: TDateTime): Boolean; Function DateTimeToModifiedJulianDate(const AValue: TDateTime): Double; Function ModifiedJulianDateToDateTime(const AValue: Double): TDateTime; Function TryModifiedJulianDateToDateTime(const AValue: Double; var ADateTime: TDateTime): Boolean; Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
...
Inc ( v, i ) and Dec ( v, i ) produce rangecheck or overflow check with
{$r+,q+}
...
This looks similar to bug 4152 that I submitted recently.
Colin
...
I agree. Some overstrong range checking in Inc and Dec. Seems to occur if
1. the first param is unsigned (Pointer is also a kind of unsigned)
and
2. the second param is negative
Gerhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
...
Bug 4152 is partly fixed. The compiletime error is removed. Only the
runtime overflow is left. That still needs to be decided how to handle it.
The following code also fails with an overflow
{$Q+}
var
v : cardinal;
begin
v:=100;
inc(v,-1);
end.
The reason is that -1 is in fact an addition of $ resulting in the
carry flag being set and therefor an overflow.
Maybe the cleanest way is (in the $r+ $q+ mode) to handle
inc ( v, d ) ;
the same as
v := v + d ;
I replaced my code like this when I found the bug, and now my code works.
Gerhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
... var v : cardinal; begin v:=100; inc(v,-1); end. The reason is that -1 is in fact an addition of $ resulting in the carry flag being set and therefor an overflow. For cardinal IMHO not-a-bug? I think it's a bug for cardinals and other unsigned ints also (as long as the result is in the range of the result variable) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] bug: Inc(v,i)/Dec(v,i)
I've tried to submit this as a bug report, but after pressing on Submit bug
nothing happens on http://www.freepascal.org/bugs/add.php3
Inc ( v, i ) and Dec ( v, i ) produce rangecheck or overflow check with {$r+,q+}
Without checks the program runs corrctly.
The values and results are in range; the errors shold not occur.
Example program:
{$r+,q+,s+}
{ $r-,q-,s-}
program incdec ;
uses
sysutils ;
var
pre : 0..132 ;
fra : -132..132 ;
procedure init ; begin pre := 1 ; fra := -1 ; end ;
begin
init ; pre := pre + fra ; writeln ( pre ) ;
init ; pre := pre - fra ; writeln ( pre ) ;
init ; inc ( pre, fra ) ; {Dec/Inc error? } writeln ( pre ) ;
init ; Dec ( pre, fra ) ; {Dec/Inc error? } writeln ( pre ) ;
end.
The assembler code shows that Inc/Dec assumes that the second parameter
has the same type as the first. This is not true in this case.
Assembler code (shortened):
#...
# [18] init ; pre := pre + fra ; writeln ( pre ) ;
call P$INCDEC_INIT
movzbl U_P$INCDEC_PRE,%eax
movswl U_P$INCDEC_FRA,%edx
addl %eax,%edx
jno .L18
call FPC_OVERFLOW
.L18:
movl %edx,%eax
cmpl $132,%eax
jbe .L19
call FPC_RANGEERROR
.L19:
movb %dl,U_P$INCDEC_PRE
#...
# [19] init ; pre := pre - fra ; writeln ( pre ) ;
call P$INCDEC_INIT
movzbl U_P$INCDEC_PRE,%edx
movswl U_P$INCDEC_FRA,%eax
subl %eax,%edx
jno .L32
call FPC_OVERFLOW
.L32:
movl %edx,%eax
cmpl $132,%eax
jbe .L33
call FPC_RANGEERROR
.L33:
movb %dl,U_P$INCDEC_PRE
#...
# [20] init ; inc ( pre, fra ) ; {Dec/Inc error? } writeln ( pre ) ;
call P$INCDEC_INIT
movzbl U_P$INCDEC_PRE,%eax
movzbl U_P$INCDEC_FRA,%edx
addl %eax,%edx
jae .L46
call FPC_OVERFLOW
.L46:
movl %edx,%eax
cmpl $132,%eax
jbe .L47
call FPC_RANGEERROR
.L47:
#...
movb %dl,U_P$INCDEC_PRE
# [21] init ; Dec ( pre, fra ) ; {Dec/Inc error? } writeln ( pre ) ;
call P$INCDEC_INIT
movzbl U_P$INCDEC_PRE,%edx
movzbl U_P$INCDEC_FRA,%eax
subl %eax,%edx
jae .L60
call FPC_OVERFLOW
.L60:
movl %edx,%eax
cmpl $132,%eax
jbe .L61
call FPC_RANGEERROR
.L61:
#...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Function variables and overload
... Bram Kuijvenhoven wrote: function MyOverloadedFunc:boolean; alias MyOverLoadedFuncNoParams; function MyOverloadedFunc(i:integer):boolean; alias MyOverLoadedFuncInt; Another note is that the 'alias' keyword might already be in use for some other purpose (I don't exactly remember which), so we might need another keyword or construction to give alias names. I'd prefer the import syntax, using name instead of alias. DoDi ALIAS is already in use for giving a proc another external name, but in the form procedure ping ; alias : 'pang' ; (remark the colon followed by string) so, the form procedure ping; alias pong ; should be parsable by the compiler. Still conbinations would be valid: procedure ping ; alias pong ; alias : 'pang' I think this looks better than using the NAME keyword. IMHO the really worst solution would be to introduce a new keyword. This inflation of keywords is a similar horror as inflation of money, and forces me from time to time to change sources. Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] concernig Bug Id 4145: Request for Bit-level packing in MacPas mode
-Ursprüngliche Nachricht-
Von: Adriaan van Os [EMAIL PROTECTED]
An: FPC developers' list fpc-devel@lists.freepascal.org
Gesendet: Samstag, 2. Juli 2005 04:01
Jonas Maebe wrote:
Gerhard Scholz wrote:
if really someone does this, it would be nice to have it in
standard (FPC)
mode also.
You will be able to activate it with a preprocessor switch.
I assume it would be very important to have it switchable in the source.
e.g.
p = packed record
a : 0..100 ;
b : boolean ;
end ; { this should be really packed; 1 byte }
q = packed record
a : 0..100 ;
b : boolean ;
end ; { this should be standard packed; 2 bytes }
so both versions could coexist, either by some new {$packrecords extreme} local
compilerdirectives or e.g. STRICT PACKED RECORD or something similar (please: no
new keyword!).
not just packed records, but also packed arrays:
packed array [ 1..2 ] of 0..15 { one byte }
packed array [ 1..8 ] of boolean { one byte }
The implementation of that would be completely separate from the
support required for records. Also, since that is not required for
compatibility, that will have a lower priority (unless someone submits
a clean patch for it, of course)
I am not trying to say that bit-level packing should have high priority
(there are ways to work around it) but, since you mention
compatibility, I would like to note that bit-level packed arrays are
indeed a feature of UCSD, MPW, Think, MetroWerks, and GNU Pascal.
It came into my mind that nearly everything to integrate (for the moment I call
them strict) strict packed records/arrays is already in the compiler: the
trick would be to see such a record or array as an object (some little inline
preprocessor ?) with some static read/write/index properties (should work for
objects (and maybe classes) also). The ref.pdf describes these properties only
for classes, not for objects, but I tried it and found out that the compiler
didn't read the documentation :-) , properties for objects seem to work o.k.
I assume the best point to incorporate this would be when the structure
definition has been read.
Fields, which are not packable, should stay untouched.
A working example, which should make clearer what I mean, is in the appendix.
The resulting code even looks quite compact. But of course in the ref manual it
should be stated quite clear that using bit-packing is punished by additional
execution time. On the other side there are enough situations where you have to
look into bytes and have to to all shifts/masks yourself. Then bit-packing would
be a help. Or you just have huge amounts of small data to store (the usual
example is the array [ 1..100 ] of boolean).
Another issue that comes to my mind is passing components of packed
structures as actual variable parameters. Standard Pascal doesn't allow
it at all, but it is more practical to forbid it only if the packed
component uses bit-packing.
The packed records or arrays, as they are implemented now, allow it to use their
fields as var params (I just tried some simple examples) obviously.
In my proposal, as a side-effect, bit-packed fields are forbidden as var-params,
but fields which are not bit-packable are allowed.
Gerhard
pckrecar.pas
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] concernig Bug Id 4145: Request for Bit-level packing in MacPas mode
if really someone does this, it would be nice to have it in standard (FPC)
mode also.
not just packed records, but also packed arrays:
packed array [ 1..2 ] of 0..15 { one byte }
packed array [ 1..8 ] of boolean { one byte }
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] concernig Bug Id 4145: Request for Bit-level packingin MacPas mode
...
not just packed records, but also packed arrays:
packed array [ 1..2 ] of 0..15 { one byte }
packed array [ 1..8 ] of boolean { one byte }
The implementation of that would be completely separate from the
support required for records. Also, since that is not required for
compatibility, that will have a lower priority (unless someone
submits a clean patch for it, of course)
Jonas
has been in Pascal (running on CDC), but Borland dropped it .
Gerhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$DEFINE x := something}
... There is a reason why the whole compiler sources are lower case: the sources are rather complex with a lot of nested ifs etc. so we use a very high screen resolution to edit the source. I use usually 70 lines on a 17 TFT or 19 CRT and such high resolutions are much easier to read if everything is lower case because it makes the distance between lines bigger. [I use usually 70 lines on a 17 TFT or 19 CRT...]: autsch, I wouldn't be able to read anything. With that resolution the screen is a collection of some coloured or grey points. Where did you get your eagle eyes? In future I will lowcase my patches. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]
about two weeks ago -Ursprüngliche Nachricht- Von: Florian Klaempfl [EMAIL PROTECTED] An: FPC developers' list fpc-devel@lists.freepascal.org Gesendet: Mittwoch, 29. Juni 2005 09:41 Betreff: Re: [fpc-devel] Gerhard Scholz wrote: I'm sorry, I have my problems with SVN, I tried to download with svn -co, but in the middle somewhere (in the directory tests) it stopped (it didn't really stop, the internet connection was busy, but no more files were transmitted). After that svn -cleanup didn't even work, the only thing that did work was to throw away the subdirectory and retry. But the retry came to the same result, and after the 3rd time I gave up. When did you test this? Recently we'd trouble with a hard disk in the server hosting svn. svn is completly back now. ___ 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
Re: [fpc-devel] {$DEFINE x := something}
-Ursprüngliche Nachricht-
Von: Peter Vreman [EMAIL PROTECTED]
An: FPC developers' list fpc-devel@lists.freepascal.org
Gesendet: Mittwoch, 29. Juni 2005 17:05
Betreff: Re: [fpc-devel] {$DEFINE x := something}
...
Next time please supply diffs (svn diff mypatch.diff) of the changes
that you make.
It seems SVN runs now here. So, next time.
And also don't change the sourcecode style. If makes huge
diffs and applying of patches will take a lot of manual work and time.
Sorry; I have a program for that upcasing/lowcasing. Next time I will
reverse the changes before supplying.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]
Problem with real parameters in overloaded procs: When defining an operator P with a CURRENCY parameter, and overloading that operator with a DOUBLE parameter, the compiler cannot decide which one to take when it is called with an EXTENDED actual parameter. The same seems to be true for overloaded procs/funcs. I suggest the following change: the sort order for searching the appropriate routine should be done as follows: 1. exact match (as it is done now); 2. extending the precision upward; 3. shrinking the precision downward. This search for a similar real parameter should only be done for SINGLE/DOUBLE/EXTENDED; COMP and CURRENCY are too special. (I know that formally COMP and CURRENCY are reals; but I consider them too special for automatic conversions). The neccessary code can be found in the appendices. I'm sorry, I have my problems with SVN, I tried to download with svn -co, but in the middle somewhere (in the directory tests) it stopped (it didn't really stop, the internet connection was busy, but no more files were transmitted). After that svn -cleanup didn't even work, the only thing that did work was to throw away the subdirectory and retry. But the retry came to the same result, and after the 3rd time I gave up. So the code comes in pieces in the appendix. is the is_real function in defutils.pas is the new function in htypechk.pas is the changed function in htypechk.pas; the old function shows the parameters in the debug info in reverse order Would be nice if this could be incorporated in the compiler. Gerhard tcallcandidates.get_information_in_htypechk.pas Description: Binary data is_real_in_defutil.pas Description: Binary data paratreestr_in_htypechk.pas Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 4004
The check for overflow is obviously implemented different in 2.0.0 and 2.1.1
This is the line
d := Ord(a)-Ord(b)
in the function, translation result to assembler:
with 2.0.0 (win32):
.Ll2:
.stabn 68,0,6,.Ll2 - P$TORD_D$CHAR$CHAR$$SMALLINT
# [6] d := Ord(a)-Ord(b);
movzbl -4(%ebp),%edx
movzbl -8(%ebp),%eax
subl %eax,%edx
jno .L8
call FPC_OVERFLOW
.L8:
movl %edx,%eax
subl $-32768,%eax
cmpl $65535,%eax
jbe .L9
call FPC_RANGEERROR
.L9:
movw %dx,-12(%ebp)
.Ll3:
with 2.1.1 (win32):
.Ll2:
.stabn 68,0,6,.Ll2 - P$TORD_D$CHAR$CHAR$$SMALLINT
# [6] d := Ord(a)-Ord(b);
movzbl -4(%ebp),%edx
movzbl -8(%ebp),%eax
subl %eax,%edx
jae .L8
call FPC_OVERFLOW
.L8:
movl %edx,%eax
cmpl $32767,%eax
jbe .L9
call FPC_RANGEERROR
.L9:
movw %dx,-12(%ebp)
.Ll3:
A solution would be to replace that line by:
d := integer(Ord(a))-Ord(b)
It seems that the compiler now sees a ord(c) to be a BYTE, and BYTE - BYTE
shall give a BYTE, and -1 is not in the range allowed for a BYTE.
The line i := Ord('0')-Ord('1') in the main program is not interesting,
since it contains a constant expression and is converted to i := -1 by
the compiler.
Greetings
gs
- Original Message -
From: Colin Western [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Saturday, June 04, 2005 1:38 PM
Subject: [fpc-devel] Bug 4004
Can I ask somebody to have another look at this bug - it was flagged
unreproducable on the web system, but I still get it from the current
svn as shown below.
(Note that the orginal report was on ppc but I have the same fault on
i386)
Colin
$ fpc ord.pas
Free Pascal Compiler version 2.1.1 [2005/06/04] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling ord.pas
Linking ord
13 Lines compiled, 0.0 sec
$ ./ord
-1
Runtime error 215 at $080480C5
$080480C5
$0804813A
$ more ord.pas
{$R+}{$Q+}
function d(a,b:Char):Integer;
begin
d := Ord(a)-Ord(b);
end;
var
i: Integer;
begin
i := Ord('0')-Ord('1');
WriteLn(i);
WriteLn(d('0','1'));
end.
___
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
Re: [fpc-devel] Re: [fpc-l] type discussion
- Original Message - From: Hans-Peter Diettrich [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 02, 2005 3:27 PM ... More important: Unicode literals. But I know that this would require a very big change to the scanner, and to all code editors and other tools. Perhaps somebody has another idea how to solve this problem? How should they look like? (example please) Or do you think about writing the programs in Unicode text files? gs ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [fpc-l] type discussion
I followed this discussion if that construction (see below) should be allowed or not (I think it should be allowed, but it's possible to live without it; I can imagine situations where it could make easier to read), and I'm missing a bit a discussion forum about the future of FPC. It should contain what is planned to be implemented, it should contain about ideas of what could be implemented. I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail). Beside of compatibility towards Delphi or MacPascal or others FPC should be open to other modifications/extensions (maybe Delphi one day copies FC a bt :-), and not always the other way round) Useful extensions I would see: bigger sets: set of -10..10 (e.g.) a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) writing of enums to text file; more operators which can be overloaded (should follow the ALGOL68 rules) the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol automatic assignment operators: operator * ( a : type1 ; b : type2 ) : type1 should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; multiple assignments: a := b := c := d := 0 ; etc. That are just some ideas. Maybe there are more? Greetings Gerhard - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Sunday, May 29, 2005 2:05 PM Subject: Re: [fpc-pascal] Re: ... type pMyRec = ^tMyRec; type tMyRec = Record data:pointer; next:pMyRec; end; and this: type pMyRec = ^tMyRec; tMyRec = Record data:pointer; next:pMyRec; end; ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
- Original Message - From: Marco van de Voort [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wednesday, June 01, 2005 1:50 PM Subject: Re: [fpc-devel] Re: [fpc-l] type discussion ... (shortened) Useful extensions I would see: bigger sets: set of -10..10 (e.g.) I'd like that too. nice that we agree a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) Rarely used. Specially since more than base 36 becomes a notational problem. However it has been brought up before. range 2..36 for the base should be enough. I have a working implementation; notation is: base_digits (the base is in decimal, the digits then the usual 0..9a..z) e.g.: 36_z = 35 seldom used, I admit, but easier to read than these $- and %- notations ... (shortened) more operators which can be overloaded (should follow the ALGOL68 rules) IMHO this is asking for a mess, and the use is limited. sorry, I'm don't know that abbreviation: IMHO; the use might look limited, but when implemented, people will find their use. ALGOL68 not only allowed operators like + - // etc, but also words/identifiers. should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; Why to save two characters? The C operators were afaik mostly added to ease porting critical C code. However IMHO one shouldn't use them in new code, and there is no need to start adding variations on the C syntax. X is just an example, more useful of course it is in situations like anArray[i,j]^ := anArray[i,j]^ * y ; Similar to inc(x) compared to x:=x+1; in C (and if I remember correct, ALGOL68 also) uses this as a hint for optimization: the reference to anArray[i,j]^ is evaluated only once (similar as it is handled in an WITH statement). I checked it with the FPC (nice that there are assembler files as output); the GNU C compiler translates arr[ii] += 1 better than FPC. Specially when C code is ported it is wise to look at the results; they might be different!. Beside, this is not C syntax, but ALGOL68 syntax, which is some years older. multiple assignments: a := b := c := d := 0 ; etc. Same point. Totally useless. easier to read, especially in sequencies of variable initializations Greetings Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: bug report
I tried this example, but it does compile! No problem!
- Original Message -
From:
To: fpc bug
Sent: Saturday, May 21, 2005 4:10 AM
Subject: [fpc-devel] Fwd: bug report
fpc 2.0.0 win32
problem:
I can't see pi in proceudre pre but I can see it in procedure kmp.
pre is a procedure belonging to kmp.
I found that I could only see vars in this proceudre/function and main
program, but I couldn't see vars in the procedure that this procedure
belongs to.
code:
var
t,p:string;
procedure kmp(t,p:string);
var
n,m,q,i:integer;
pi,match:array[1..255] of integer;
procedure pre(p:string);
var
k,q:integer;
begin
pi[1]:=0;
k:=0;
for q:=2 to m do begin
while (k0) and (p[k+1]p[q]) do k:=pi[k];
if p[k+1]=p[q] then k:=k+1;
pi[q]:=k;
end;
end;
begin
n:=length(t);
m:=length(p);
q:=0;
pre(p);
fillchar(match,sizeof(match),0);
for i:=1 to n do begin
while (q0) and (p[q+1]t[i]) do begin
match[i-q]:=q;
q:=pi[q];
end;
if p[q+1]=t[i] then q:=q+1;
if q=m then begin
match[i-q+1]:=q;
q:=pi[q];
end;
end;
write(match[1]);
for i:=2 to n do write(' ',match[i]);
writeln;
end;
begin
readln(t);
readln(p);
kmp(t,p);
end.
[EMAIL PROTECTED]
Do You Yahoo!?
150MP3
1G1000
___
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
Re: [fpc-devel] Re: [fpc-l] type discussion
my marks start with :
- Original Message -
From: Ales Katona [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wednesday, June 01, 2005 6:52 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote:
var
x : type1, y : type2 ;
x *:= y ;
in my humble opinion(IMHO):
thanks for the explanation
:= is based on the fact that A: is written normaly in math etc. where it
means this is a fact about A
So when someone writes A:=5; it means it's a fact that A equals 5
fine, but in programming := usually means becomes
Writing A*:= is stupid. If nothing else do it like this:
A:*=
But IMHO it's useless in ANY case. Even C people tend to not use it when
they want readible code(especialy * which is so ambiguos)
the star * here just was an an example for any operator, could have
been +, / or AND or whatever
As to the ASM:
in C if you do a+=b; and a is int b is longint it does this actualy:
a = a + (int)b;
which is stupid and unsafe.
I do not see this is an argument.
var a:integer; b:longint; sb : integer ;
{1} a += b ;
{2} a := a + b ;
{3} sb := b ; a+=sb ;
All three versions produce the same nonsense. To avoid such nonsense I like
the compiler checks (range on, overflow on, stack overflow on, ioerror on).
Just my 0.05 euros
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] some little errors/notes
Hello,
some notes on the compiler:
1.)
I tried to compile the compiler itself (make win32zip) and found the
following:
a)
the routine packages\extra\winunitsjwawownt16.pas contains the line (#55)
{$WARN SYMBOL_PLATFORM OFF}
which is not recognized and gives an error.
I made a real comment out of it:{ $WARN SYMBOL_PLATFORM OFF}
b)
the unit parabase.pas in the compiler, line# 240
function ParaNrCompare(Item1, Item2: Pointer): Integer;
...
begin
Result := I1.paranr - I2.paranr ;
end ;
gives an overflow (I compiled the whole thing with range check on, stack
check on, overflow check on, and then the compler dies while compiling
itself!!)
I then replace the assignment with:
{$ifopt Q+}
{$define OVERFLOW_ON}
{$Q-}
{$endif}
{$ifopt R+}
{$define RANGE_ON}
{$R-}
{$endif}
Result:=I1.paranr-I2.paranr;
{$ifdef OVERFLOW_ON}
{$Q+}
{$undef OVERFLOW_ON}
{$endif}
{$ifdef RANGE_ON}
{$R+}
{$undef RANGE_ON}
{$endif}
This still is a hack, a cleaner solution would be:
Result := sign ( longint ( l1.paranr ) - longint ( l2.paranr ) ) ) ;
With these modifications the make win32zip comes to an end and produces a
lot of ZIP-files.
I wasn' able to find out why the compiler is compiled three times, the RTL
even four times.
2.)
a)
The power operator (**) seems to be integrated in the compiler, but only
partial. I didn't find a description of it in the Reference Manual.
I tried a little program
PROGRAM x;
BEGIN
WRITELN ( 1 ** 2 ) ;
END.
which died with the runtime error 221 (I didn't find a description of this
error, either).
Obviously the operator(s) are defined in the unit math, with a USES MATH the
program runs.
Without the MATH unit the routine SYSTEM_starstar$VARIANT$VARIANT$$VARIANT
is called, which seems not to work.
There are some optimizations for the power operator in nadd.pas (only for
REAL ** REAL, not for INT ** INT). But since the operator is overloaded,
this code is not reached...
There is missing an operator overload for REAL ** INT, which could be
handled more optimized than converting it to REAL ** REAL.
b)
in pexpr.pas there is a declaration:
operator_levels:ARRAY[Toperator_precedence] OF SET OF ttoken=
[_PLUS,_MINUS,_OP_OR,_PIPE,_OP_XOR],
[_CARET,_SYMDIF,_STARSTAR,_STAR,_SLASH,
_OP_AS,_OP_IS,_OP_AND,_AMPERSAND,_OP_DIV,_OP_MOD,_OP_SHL,_OP_SHR],
[_STARSTAR] );
The _STARSTAR_ occurs two times in that sets; I assume the first occurence
is a typing error.
c)
Operators of same precedence are evaluated from left to right:
a - b + c - d
means:
( ( a - b ) + c ) - d
This follows the natural precedence of mathematical formulas. But with the
power operator the natural precedence is from right to left:
a ** b ** c ** d
normally means:
a ** ( b ** ( c ** d ) )
The FP compiler evaluates a ** b ** c ** d as:
( ( a ** b ) ** c ) ** d
This should be changed to the natural behaviour. Other programming
languages (like FORTRAN; if I remember correctly, also the old ALGOLs)
follow the right-to-left-scheme (for ** only, of course).
This can be implemented by (in PEXPR.PAS, about line# 2440):
old code:
IF pred_level=highest_precedence THEN
p2:=factor(False)
ELSE
p2:=sub_expr(Succ(pred_level),True);
new code:
IF pred_level=highest_precedence THEN
{!!}p2:=sub_expr(pred_level,True)
ELSE
p2:=sub_expr(Succ(pred_level),True);
That's all for today.
Greetings
Gerhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] some little errors/notes
yes, exactly like this. and other compilers also follow this scheme, so people who convert code from other languages will have problems at a place they do not expect. Gerhard -Ursprüngliche Nachricht- Von: Jonas Maebe [EMAIL PROTECTED] An: FPC developers' list fpc-devel@lists.freepascal.org Gesendet: Donnerstag, 26. Mai 2005 21:36 Betreff: Re: [fpc-devel] some little errors/notes On 26 mei 2005, at 21:22, Micha Nelissen wrote: Define natural please ? If I write 2**3**5, I probably mean 2^3^5 = (2^3)^5, not 2^(3^5). In this case, FP is right. Well, I guess he means that if you write it on paper, you write (view in fixed width font) 4 3 2 which indeed is 2^(3^4) Jonas ___ 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
[fpc-devel] daily snapshot?
Hello, the daily snapshot does not exist any more? ftp://ftp.freepascal.org/pub/fpc/snapshot/v21/source/fpc.zip is a dead link in the moment. Greetings Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
