Not sure if this is considered a bug or not :)
I have found this function returns TRUE if passed 'E1/E2/etc'
I am guessing it is seeing the 'E' as exponent
function IsNum( const sSrc :string ) :boolean;
var
Code :integer;
Num :real = 0;
begin
Num := Num;
Val(sSrc, Num, Code);
Exit( Co
Am 23.02.2016 23:28 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> Serguei TARASSOV wrote:
>
>> There is no perfect way so why the language extension is the safest
>> (remember recent discussion about IfThen pseudo-function).
>
>
> More relevant to your situation, I remember
Serguei TARASSOV wrote:
There is no perfect way so why the language extension is the safest
(remember recent discussion about IfThen pseudo-function).
More relevant to your situation, I remember discussion about adding an
identifier to WITH to use as an explicit shortcut, i.e. something like
On 23.02.2016 17:21, Serguei TARASSOV wrote:
> Michael Van Canneyt wrote
>> I hope you will send the same mail to embarcadero/Idera.
>> When they added methods to TPoint, they broke have the VCL code ?
>>
>> To avoid this, we would need to freeze the code as soon as it is released.
>
> Compared w
2016-02-20 9:23 GMT+01:00 Sven Barth :
> Am 20.02.2016 06:25 schrieb "Michalis Kamburelis" <
> michalis.ka...@gmail.com>:
> > I remember a thread on fpc-devel "Pascal Smart Pointers Idea + ARC
> > implementation" where the original author (Maciej Izak) was already
> > working to overcome this:
> >
On Di, 2016-02-23 at 15:58 +0100, Bernd Mueller wrote:
> Marc Santhoff wrote:
>
> > Did you use the stmf103fw.pas translation from Jeppe or make you own
> > unit for supporting the 429?
>
> I needed only a few peripherals (GPIO, USART, RCC and embedded FLASH). I
> wrote this stuff by myself.
OK
Michael Van Canneyt wrote
> I hope you will send the same mail to embarcadero/Idera.
> When they added methods to TPoint, they broke have the VCL code ?
>
> To avoid this, we would need to freeze the code as soon as it is released.
Compared with Unicode migration, introducing the methods into re
On 2016-02-23 14:13, Mark Morgan Lloyd wrote:
> And the extra typechecks etc. mean that FPC is a bit better than most
> language implementations at catching things like that.
Exactly. I prefer getting an error so I can fix my code and know it will
work as intended - instead of the compiler silent
Marc Santhoff wrote:
Did you use the stmf103fw.pas translation from Jeppe or make you own
unit for supporting the 429?
I needed only a few peripherals (GPIO, USART, RCC and embedded FLASH). I
wrote this stuff by myself.
My target would be f407, although the project in mind has to be done
u
Graeme Geldenhuys wrote:
On 2016-02-23 10:54, Serguei TARASSOV wrote:
I see, but *it's not my code*, its a code of the big third-party framework
that is working well with all version of Delphi/C++ builder and Lazarus 1.x
with FPC 2.6.4.
Well, now it doesn't work with FPC 3.0. ;-)
You cannot
I have the latest version of Devart pgdac and virtualtable.pas compiles
fine.
On Feb 23, 2016 3:33 AM, "Serguei TARASSOV" wrote:
> Hello,
>
> Sorry, my previous example was not complete.
> Here is a problem detected when compiling UniDAC 6.2.8.
> Taken from real code in VirtualTable.pas
>
> progr
Henry Vermaak wrote on Tue, 23 Feb 2016:
On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote:
It would probably be useful if we added support to the compiler to
generate a warning (or even error) in case a with statement hides an
existing symbol in scope though.
Yes, please. Somethi
On Di, 2016-02-23 at 12:25 +0100, Bernd Mueller wrote:
> Michael Ring wrote:
> >
> > (Glad to hear that basic functionality works...)
>
> I finished my first (small) project with the STM32F429ZI controller and
> everything went smooth :-) Even with optimization level -O2.
>
> Thanks everyone, w
On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote:
> It would probably be useful if we added support to the compiler to
> generate a warning (or even error) in case a with statement hides an
> existing symbol in scope though.
Yes, please. Something like -Wshadow would be very useful.
H
On Tue, 23 Feb 2016, Serguei TARASSOV wrote:
Okay, okay, I see.
For info, the indicated error is not critical because of its visibility at
compile-time.
All other codes inside "with" statement like
x := FieldDef;
will be compiled without errors and should be checked.
Thank you, guys, for a
Serguei TARASSOV wrote on Tue, 23 Feb 2016:
Thank you, guys, for a good compatibility support
Come on. The only way this kind of problems can be avoided is by us
never adding any new field or property to any class, ever.
It would probably be useful if we added support to the compiler to
Okay, okay, I see.
For info, the indicated error is not critical because of its visibility at
compile-time.
All other codes inside "with" statement like
x := FieldDef;
will be compiled without errors and should be checked.
Thank you, guys, for a good compatibility support and adding the features
On Tue, 23 Feb 2016, Graeme Geldenhuys wrote:
On 2016-02-23 10:54, Serguei TARASSOV wrote:
I see, but *it's not my code*, its a code of the big third-party framework
that is working well with all version of Delphi/C++ builder and Lazarus 1.x
with FPC 2.6.4.
Well, now it doesn't work with FP
On 2016-02-23 10:54, Serguei TARASSOV wrote:
> I see, but *it's not my code*, its a code of the big third-party framework
> that is working well with all version of Delphi/C++ builder and Lazarus 1.x
> with FPC 2.6.4.
Well, now it doesn't work with FPC 3.0. ;-)
> You cannot recommend them to cha
On Tue, 23 Feb 2016, Serguei TARASSOV wrote:
Michael Van Canneyt wrote
The problem is in your code and the use of WITH, as I surmised in my
previous mail.
In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef.
The code compiles ok.
In 3.0.0, FieldDef is a NEW READ-ONLY property in T
Michael Ring wrote:
(Glad to hear that basic functionality works...)
I finished my first (small) project with the STM32F429ZI controller and
everything went smooth :-) Even with optimization level -O2.
Thanks everyone, who is involved in the ARM compiler/rtl development.
Regards, Bernd.
Michael Van Canneyt wrote
> The problem is in your code and the use of WITH, as I surmised in my
> previous mail.
>
> In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef.
> The code compiles ok.
>
> In 3.0.0, FieldDef is a NEW READ-ONLY property in TField.
> Because of the WITH, the com
On Tue, 23 Feb 2016, Serguei TARASSOV wrote:
Hello,
Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8.
Taken from real code in VirtualTable.pas
program Project1;
{$MODE DELPHI}
uses
SysUtils, Classes, DB;
procedure InternalCreateFieldDefs
Hello,
Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8.
Taken from real code in VirtualTable.pas
program Project1;
{$MODE DELPHI}
uses
SysUtils, Classes, DB;
procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
var
F
24 matches
Mail list logo
