Andrew Brunner wrote on Wed, 01 Jul 2015:
When compiling FPC 2.6.4 bootstrap I determined that :
-OpARMV71 is not a supported option.
-cfVFPV3 is not a supported option.
The correct parameter is -Cfvfpv3, with a capital C.
On make sourceinstall I determined that there is something wrong
On 7/1/15, Peter pe...@pblackman.plus.com wrote:
Agree it would be nice to have a wider range for Floor Ceil.
I would suggest raising a bug report for this.
Its not been fixed in trunk (as of this post).
Opened a ticket: http://bugs.freepascal.org/view.php?id=28370
Bart
On 2015-07-01 16:47, Michael Van Canneyt wrote:
If you want to use these features all the time, just put them in your config
file.
+1
And we all know Embarcadero so often _copy really bad ideas_ from other
languages - giving no thought to the beauty and structure of the Object
Pascal
Jonas Maebe wrote:
This is currently quite hard with FPC, as every library compiled with
FPC contains its own RTL and hence does not share the RTL state with the
applications that use it. To solve that, you need Delphi-style dynamic
packages support, which Sven is working on.
Where is
Jonas Maebe wrote:
It doesn't matter whether the products or tools are commercial or not.
The LGPL means that if you link statically against TDBF, you have to
provide (on request) the object files of your program to customers that
bought the original tool so they can relink it against
Adriaan van Os wrote on Wed, 01 Jul 2015:
Jonas Maebe wrote:
There is no reason why you would ever have to release your own source
code, except if you would start mixing your own source code into the
TDBF units or so.
Wikipedia
Adriaan van Os wrote on Wed, 01 Jul 2015:
Jonas Maebe wrote:
This is currently quite hard with FPC, as every library compiled
with FPC contains its own RTL and hence does not share the RTL
state with the applications that use it. To solve that, you need
Delphi-style dynamic packages
On 30/03/15 18:56, Bart wrote:
Hi,
Floor and Ceil (math unit) only return integers.
Should there be an overloaded one for Int64 as well?
B = 111.000
Trunc(B)= 111 [0002964619C7]
Frac(B) = 0.10687255859
Floor(B)=
On 01/07/2015 17:08, fpc-pascal-requ...@lists.freepascal.org wrote:
Date: Wed, 01 Jul 2015 16:54:30 +0200
From: Jonas Maebejonas.ma...@elis.ugent.be
To: FPC-Pascal users discussionsfpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Delphi mode for new features?
Message-ID:
Serguei TARASSOV wrote on Wed, 01 Jul 2015:
As I see (may be mistaken), some _new_ Delphi features are available
only in $MODE DELPHI.
This way lead to divergence of two compilers.
Why do not implement them in FPC by default (when it not
constrained by basic concepts and legacy code) to
On 2015-07-01 15:54, Jonas Maebe wrote:
all new language features we add these days can be selectively enabled
and disabled via mode switches.
That was/is a very good decision, and makes it quite flexible per project.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit
On 01/07/15 17:40, Serguei TARASSOV wrote:
On 01/07/2015 17:08, fpc-pascal-requ...@lists.freepascal.org wrote:
Such new Delphi features are only enabled by default in FPC modes if
we consider them to not run counter to the spirit of Pascal. That's
obviously subjective, but so is Embarcadero's
Am 01.07.2015 16:21 schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
Adriaan van Os wrote on Wed, 01 Jul 2015:
Jonas Maebe wrote:
This is currently quite hard with FPC, as every library compiled with
FPC contains its own RTL and hence does not share the RTL state with the
applications that
Hi All,
My question is inspired by some things asked here last weeks.
As I see (may be mistaken), some _new_ Delphi features are available
only in $MODE DELPHI.
This way lead to divergence of two compilers.
Why do not implement them in FPC by default (when it not constrained
by basic
On Wed, 1 Jul 2015, Serguei TARASSOV wrote:
and disabled via mode switches.
This is a good example of complicating the life.
One option by feature to activate every new language feature lead to growth
of end-user documentation and using $MODE DELPHI when it is not required at
all.
In the
Hi,
Is it possible to make the importtl tool work under Linux? Is it just a
matter of defining a bunch of Windows types?
I use Linux for development and cross compile to Windows when needed,
and hence the question. And just to rule out solutions such as 'use the
tool once on Windows to
Marco van de Voort wrote:
Also RTTI like class info (not used over typinfo unit) like IS, AS,
.InheritsFrom?
IOW Objecttype identity operations.
Thanks for the info. I suggest to document this somewhere. But I am not (in my own code projects)
using RTTI, class info, FPC memory allocation,
In our previous episode, Sven Barth said:
exception class), anything involving global variables (either
implementation or interface) in units that exist both in the library and in
the program.
Not to mention RTTI (basically a superset of the exception handling case
mentioned by Jonas).
Am 01.07.2015 21:40 schrieb Marco van de Voort mar...@stack.nl:
In our previous episode, Sven Barth said:
exception class), anything involving global variables (either
implementation or interface) in units that exist both in the library
and in
the program.
Not to mention RTTI
19 matches
Mail list logo
