riginal 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
li
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
BP 7.0 (real)
BP7.0 (protected)
VP2.1b279
all: "not assigned"
- Original Message -
From: "Marco van de Voort"
To:
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;
{$if
8, 2013 8:24 PM
Subject: Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type
helpers
Am 08.02.2013 19:52 schrieb "Gerhard Scholz" :
>
> 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 follow
013 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
TLongI
@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
clas
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:\o
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"
Gesendet: Donnerstag, 13. Oktober 2005 08:16
Betreff: [fpc-devel] 'with' operator i
I would suggest an "experimental" solution {$inline unsafe ?} which does the
inline without checks, and maybe gives a warning at compiletime: Warning:
inlined func/proc might be unsafe.
Could save some code and some exection time.
I do not understand the argument with e.g. EBP usage. I would say
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
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 ) =
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 a
- Original Message -
From: "Peter Vreman" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Friday, July 08, 2005 6:31 PM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
> >> v:=v+-5;
> >
> > I'm sorry, v IS unsigned, delta IS signed, and the computation has to be
> > done. Besides
- Original Message -
From: "Vinzent Hoefler" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Friday, July 08, 2005 1:24 PM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
...
> Agreed. It's not readable at all. So don't do that, instead
>
> {$IFDEF BIG}
> type My_Type = SmallInt;
>
- Original Message -
From: "Marco van de Voort" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Friday, July 08, 2005 11:52 AM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
> > Solution 1 of course would be:
> >
> > if delta < 0
> > then dec ( v, -delta )
> >
- Original Message -
From: "Vinzent Hoefler" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Thursday, July 07, 2005 9:47 AM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
> On Thursday 07 July 2005 05:39, Peter Vreman wrote:
>
> > > shouldn't it implement inv(v,-1) in exactly the
...
> > 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 unsign
...
> 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 th
...
> >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
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 rang
-Ursprüngliche Nachricht-
Von: "Adriaan van Os" <[EMAIL PROTECTED]>
An: "FPC developers' list"
Gesendet: Samstag, 2. Juli 2005 04:01
> Jonas Maebe wrote:
>
> > Gerhard Scholz wrote:
> >
> >> if really someone does this, it would
...
> 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 remembe
...
> > 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
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
...
> 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 e
-Ursprüngliche Nachricht-
Von: "Peter Vreman" <[EMAIL PROTECTED]>
An: "FPC developers' list"
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
This repairs two bugs concerning macros:
1.
There is a check that the macro name is not a reserved keyword. If the macro
name starts not with a letter (with other words: starts with an underline),
the compiler fails (when it is compiled with $R+).
2.
The check should be done when it is clear that
about two weeks ago
-Ursprüngliche Nachricht-
Von: "Florian Klaempfl" <[EMAIL PROTECTED]>
An: "FPC developers' list"
Gesendet: Mittwoch, 29. Juni 2005 09:41
Betreff: Re: [fpc-devel]
> Gerhard Scholz wrote:
> > I'm sorry, I have my problem
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
22:55:42,18 P:[EMAIL PROTECTED]>del withstat.exe
22:55:42,19 P:[EMAIL PROTECTED]>ppc386 -Op1 -al -gl withstat
Free Pascal Compiler version 2.1.1 [2005/05/25] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Win32 for i386
Compiling withstat.pas
withstat.pas(20,50) Warning:
...
> I'm not sure, at least
>
> > .L9:
> > movw %dx,-12(%ebp)
> > .Ll3:
>
> suggests that the target is not an integer, but instead is a (possibly
> unsigned) word type. Please check again!
...
This is the result of the compilation: "ppc386 tord -al" (shortened of
course).
Since "MOVW" move
#x27;)
seems to be a little compiler "weakness".
Gerhard
- Original Message -
From: "Colin Western" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Monday, June 06, 2005 10:24 PM
Subject: Re: [fpc-devel] Bug 4004
> Gerhard Scholz wrote:
>
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),%e
- Original Message -
From: "Hans-Peter Diettrich" <[EMAIL PROTECTED]>
To: "FPC developers' list"
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.
>
my marks start with :
- Original Message -
From: "Ales Katona" <[EMAIL PROTECTED]>
To: "FPC developers' list"
Sent: Wednesday, June 01, 2005 6:52 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
> Gerhard Scholz wrote:
>
> >>&
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
- Original Message -
From: "Marco van de Voort" <[EMAIL PROTECTED]>
To: "FPC developers' list"
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
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
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"
Gesendet: Donnersta
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 o
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/mai
41 matches
Mail list logo
