Working on my arm-linux cross compiler (which used to at least build a
compiler etc), I currently hit this with fpc trunk:
C:/development/fpctrunk/compiler/ppcrossarm.exe -Tlinux -Parm
-XParm-linux- -Xr -Ur -Xs -O2 -n -Fuarm -Fusystems
-FuC:/development/fpctrunk/rtl/units/arm-linux -Fiarm
-FDC:\dev
On Wed, Jan 8, 2014 at 3:31 AM, leledumbo wrote:
> As in the data structure theory, a tree is just a graph without cycle.
> So I guess it should be made that way. There are a lot of graph and tree
> variations though, so I think I need to take some time to design before
> implementing.
I don't kn
First, thanks to all involved in documenting the existing FPC trunk
Unicode situation on the wiki. Exactly the kind of docs I was looking for!
I'm trying to avoid ambiguity for an UTF8 (without BOM) encoded file and
tried this:
{$ifdef fpc}
//Explicitly specify this is an UTF8 encoded file.
//
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
> boun...@lists.freepascal.org] De la part de Reinier Olislagers
> Envoyé : mercredi 8 janvier 2014 13:58
> À : FPC Mailing list
> Objet : [fpc-pascal] Is it just me or... trunk cross compile failure
On 08/01/2014 16:40, Pierre Free Pascal wrote:
>> -Message d'origine-
>> Objet : [fpc-pascal] Is it just me or... trunk cross compile failure on
>> arm-linux
>> C:\development\cross\bin\arm-linux\arm-linux-ld.exe: cannot find
>> arm\units\arm-linux\pexpr.o
>> pp.pas(238,36) Error: Error whi
On 08 Jan 2014, at 15:58, Reinier Olislagers wrote:
I'm trying to avoid ambiguity for an UTF8 (without BOM) encoded file
and
tried this:
{$ifdef fpc}
//Explicitly specify this is an UTF8 encoded file.
//Alternative would be UTF8 with BOM but writing UTF8 BOM is bad
practice.
//See
http:
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
> boun...@lists.freepascal.org] De la part de Reinier Olislagers
> Envoyé : mercredi 8 janvier 2014 17:05
> À : FPC Mailing list
> Objet : Re: [fpc-pascal] Is it just me or... trunk cross compile
> fa
Am 08.01.2014 17:08 schrieb "Reinier Olislagers" <
reinierolislag...@gmail.com>:
> Mmm, interesting. Seems opposite on trunk. -CaEABI works; -CaEABIHF
> fails (I'm using current trunk as a starting compiler)
*sigh* I thought you were one of those who already knows this, but it seems
not: *ALWAYS*
Today I found
this type definition in some FreePascal sources:
Type
Real = type Double;
I wondered
what
On 08/01/2014 17:17, Jonas Maebe wrote:
>
> On 08 Jan 2014, at 15:58, Reinier Olislagers wrote:
>
>> I'm trying to avoid ambiguity for an UTF8 (without BOM) encoded file and
>> tried this:
>> {$ifdef fpc}
>> //Explicitly specify this is an UTF8 encoded file.
>> //Alternative would be UTF8 with
On 08/01/2014 18:01, Pierre Free Pascal wrote:
>
>
>> -Message d'origine-
>> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
>> boun...@lists.freepascal.org] De la part de Reinier Olislagers
>> Envoyé : mercredi 8 janvier 2014 17:05
>> À : FPC Mailing list
>> Objet : Re:
On 08/01/2014 19:00, Sven Barth wrote:
> *sigh* I thought you were one of those who already knows this, but it
> seems not: *ALWAYS* compile using the last release as starting compiler.
I do know this and...
> We won't provide support if a trunk version (be it a non-released fixes
> or the main de
On 08/01/2014 18:16, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second “type” keyword means here (I have never seen
this before).
You are being rather obtuse.
Ignore the diagrams in the docs if they don't
Reinier Olislagers schrieb:
>On 08/01/2014 18:01, Pierre Free Pascal wrote:
>>
>>
>>> -Message d'origine-
>>> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
>>> boun...@lists.freepascal.org] De la part de Reinier Olislagers
>>> Envoyé : mercredi 8 janvier 2014 17:05
On 08.01.2014 19:40, Howard Page-Clark wrote:
On 08/01/2014 18:16, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second “type” keyword means here (I have never seen
this before).
You are being rather obtuse
On 08.01.2014 19:16, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second “type” keyword means here (I have never seen
this before).
So I looked at
http://www.freepascal.org/docs-html/ref/refch3.html#refse17
On 08/01/2014 20:01, Sven Barth wrote:
On 08.01.2014 19:40, Howard Page-Clark wrote:
On 08/01/2014 18:16, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second “type” keyword means here (I have never seen
thi
On Wed, 8 Jan 2014, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second “type” keyword means here (I have never seen this
before).
So I looked at
http://www.freepascal.org/docs-html/ref/refch3.html#re
On Wed, 8 Jan 2014, Howard Page-Clark wrote:
On 08/01/2014 20:01, Sven Barth wrote:
On 08.01.2014 19:40, Howard Page-Clark wrote:
On 08/01/2014 18:16, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second
Am 08.01.2014 21:01, schrieb Sven Barth:
> No, an alias would be
> === code begin ===
> type
> Real = Double;
> === code end ===
> Using the "type" behind the "=" tells the compiler to declare a new
type based on the right side.
> So a "Double" and a "Real" are not assignment compatible and can
On Wed, 8 Jan 2014, Jürgen Hestermann wrote:
Am 08.01.2014 21:01, schrieb Sven Barth:
No, an alias would be
=== code begin ===
type
Real = Double;
=== code end ===
Using the "type" behind the "=" tells the compiler to declare a new type
based on the right side.
So a "Double" and a "Real"
Am 08.01.2014 22:11 schrieb "Jürgen Hestermann" :
> But why is it not part of the documentation?
We are all just human beings that make mistakes. Nobody is perfect and so
is the documentation.
> If nobody takes care of the documentation anymore
> then it should better be removed at all.
It's act
On Wed, Jan 08, 2014 at 09:01:34PM +0100, Sven Barth wrote:
On 08.01.2014 19:40, Howard Page-Clark wrote:
On 08/01/2014 18:16, Jürgen Hestermann wrote:
Today I found this type definition in some FreePascal sources:
TypeReal =type Double;
I wondered what the second “type” keyword means here (
On 09 Jan 2014, at 00:17, joha...@nacs.net wrote:
> Is there any way to get support in Free Pascal for the old six byte REAL type
> that was provided by the old Borland DOS Turbo Pascal compilers?
The only support we have is a routine to convert a TP-style real to double:
http://www.freepascal
Hi All,
I would like to know what is the difference between AnsiStrscan and
strscan, or, generically, the Ansi* functions versus non-ansi versions?
Thanks a lot.
Xiangrong
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepas
Am 2014-01-08 21:12, schrieb Sven Barth:
>> I don’t know whether the first 'type' is the standard type definition
>> entry keyword but if so it should be typed in bold font.
> No, it's not the keyword, it's a "reference" to the syntax diagram named
> "type" directly below it (though I have to admi
On 09.01.2014 07:22, Jürgen Hestermann wrote:
>> Where can I find the documentation for my original question about
the double TYPE keyword?
> This link explains it a bit:
http://docwiki.embarcadero.com/RADStudio/XE5/en/Type_Compatibility_and_Identity
But that's not part of the Free Pascal doc
On Thu, 9 Jan 2014, Jürgen Hestermann wrote:
Am 2014-01-08 21:12, schrieb Sven Barth:
I don’t know whether the first 'type' is the standard type definition
entry keyword but if so it should be typed in bold font.
No, it's not the keyword, it's a "reference" to the syntax diagram named
"type"
Am 08.01.2014 22:01, schrieb Michael Van Canneyt:
You can preview the result at
http://www.freepascal.org/~michael/ref/refch3.html
You might additionally mention that these type aliases also allow
different operator and (AFAIK also) function overloads.
Regards,
Sven
__
29 matches
Mail list logo
