[fpc-pascal] Possible bug in Numeric test
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( Code = 0 ); end; Thanks - SteveG ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like > > with foo= bar do > foo.someField := ... > What would really help here would be the warning that Jonas mentioned... For the above you could just use a local variable and be done with it. No need to try to "fix" the with-statement. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 with foo= bar do foo.someField := ... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 with Unicode migration, introducing the methods into records is not > breaking :) Adding methods to the TPoint or TRect record is *exactly* like adding a method/property to TField. If you use "with" you might find yourself in a dangerous/problematic situation. That *did* happen with various code after we introduced the new methods to TPoint and TRect. > The code is not frozen but for the core level units the modifications are > rare and very risky without vast codebase and testing. > DB is a vary mature unit, almost all DACs based on it so 100% compatibility > with Delphi does matter. And the DB code is Delphi compatible. But if you (as in "general you") are using a feature that is *known* to lead to problems if fields and properties are added then that's your own problem. From great power comes great responsibility. We take backwards compatibility very serious, but there has to be a line drawn somewhere. > However, there are some useful methods to extend: > - subclassing (the safest) > - class helpers > - property/method's attributes (need to be introduced at compiler level) > - interfaces (when creating new interface for every extension) And to burden everyone else with the need to e.g. include a unit with a helper restricting them from adding their own if they don't derive from the original helper? No thank you. We are no slaves to Delphi. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Primitive Record Wrappers
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: > > > https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg33172.html > > . His reasons was similar (force the contents to be initialized with > > zero) and his solution felt cleaner -- introduce "class operator > > Initialize" where you can initialize your record. > > > > Any chance that this would be added/merged to FPC one day?:) > > I'm indeed inclined to implement this one day, though I don't know yet how > exactly I want it to look. > Finally I have some time to continue my work on this. I need to take break from Sparta/Lazarus :P. Hopefully all will be available soon on smart_pointers branch. -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
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. > > My target would be f407, although the project in mind has to be done > > using an Atmel SAM7 now, programmed in C... :| > > I used the AT91SAM7S256 controller 5 years ago (with fpc 2.3.1 btw). If > I had to use ATMEL, I would look at the SAM3S or SAM4S family. They > should replace the SAM7 which is now over 10 years old. But since ATMEL > has been bought by Microchip, I would avoid them. I know, I know. But it is a low volume device and the chips are in stock. Plus there is the complete compiler and support/HAL-library stuff already done. -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 records is not breaking :) The code is not frozen but for the core level units the modifications are rare and very risky without vast codebase and testing. DB is a vary mature unit, almost all DACs based on it so 100% compatibility with Delphi does matter. However, there are some useful methods to extend: - subclassing (the safest) - class helpers - property/method's attributes (need to be introduced at compiler level) - interfaces (when creating new interface for every extension) I.e. adding attribute "new" to property/method the compiler will generate the error when conflicting to resolve names in existing code. There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function). - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724291.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 silently working around the problem and possibly producing incorrect result (only noticed months down the line). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
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 using an Atmel SAM7 now, programmed in C... :| I used the AT91SAM7S256 controller 5 years ago (with fpc 2.3.1 btw). If I had to use ATMEL, I would look at the SAM3S or SAM4S family. They should replace the SAM7 which is now over 10 years old. But since ATMEL has been bought by Microchip, I would avoid them. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. And the extra typechecks etc. mean that FPC is a bit better than most language implementations at catching things like that. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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
>
> program Project1;
>
> {$MODE DELPHI}
>
> uses
> SysUtils, Classes, DB;
>
> procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
> var
> F: TField;
> FieldDef: TFieldDef;
> begin
> begin
> with F do
> begin
> FieldDef := FieldDefs.AddFieldDef;
> // in FPC 3.0.0 Error: No member is provided to access property
> // in FPC 2.6.4 compiles OK
> end;
> end;
> end;
>
> begin
> end.
>
>
>
>
> -
> --
> Regards,
> Serguei
> --
> View this message in context:
> http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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. Something like -Wshadow would be very useful. That already exists and is enabled by default for local variables and parameter names hiding fields. It even gives errors in FPC and ObjFPC modes, rather than warnings. It's just not (yet) implemented for with-statements (and local variables or fields hiding global variables, but that's a different matter). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
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, who is involved in the ARM compiler/rtl development. Did you use the stmf103fw.pas translation from Jeppe or make you own unit for supporting the 429? My target would be f407, although the project in mind has to be done using an Atmel SAM7 now, programmed in C... :| -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 good compatibility support and adding the features to the principal units that break the existing code of "real world programs". 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. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 generate a warning (or even error) in case a with statement hides an existing symbol in scope though. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 to the principal units that break the existing code of "real world programs". - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724281.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 FPC 3.0. ;-) You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. Exactly. See e.g. the recent changes in TPoint, which necessitated a lot of changes in the LCL, because "with" was used a lot. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. Plus, it's another excellent example of why you shouldn't use WITH. I don't care how many disagree with me, I always thought it a bad language design. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 TField. Because of the WITH, the compiler resolves FieldDef to this property, but it is read-only, an so it gives an error. 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. You cannot recommend them to change code. If course I can, I just did. The mode Delphi is declared. The mode is entirely irrelevant. It should be compatible. We introduced the FieldDef property in TField. This was a conscious decision. They chose to use "with", and then this kind of thing can happen at any point. So, they must adapt their code. Don't use "with" if you're not prepared to deal with such issues. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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 compiler resolves FieldDef to this property, but > it > is read-only, an so it gives an error. 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. You cannot recommend them to change code. There are many other errors during compile, if someone is interesting I can provide the list. So the problem is in DB unit. The mode Delphi is declared. It should be compatible. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724276.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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(Fields: TFields; FieldDefs: TFieldDefs);
var
F: TField;
FieldDef: TFieldDef;
begin
begin
with F do
begin
FieldDef := FieldDefs.AddFieldDef;
// in FPC 3.0.0 Error: No member is provided to access property
// in FPC 2.6.4 compiles OK
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 compiler resolves FieldDef to this property, but it
is read-only, an so it gives an error.
Change your code to
Var
AFieldDef: TFieldDef;
and
AFieldDef := FieldDefs.AddFieldDef;
and all will be well.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
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: TField;
FieldDef: TFieldDef;
begin
begin
with F do
begin
FieldDef := FieldDefs.AddFieldDef;
// in FPC 3.0.0 Error: No member is provided to access property
// in FPC 2.6.4 compiles OK
end;
end;
end;
begin
end.
-
--
Regards,
Serguei
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
