Finally, the Free Pascal 3.2.0 release is available from our servers and from sourceforge.Thank you Marco and others!
I do not see .deb packages for 32/64. I'm certainly missing something...
Will the next version of Lazarus be shipped with FPC 3.2.0? If yes, when? Thanks!
Will the next version of Lazarus be shipped with FPC 3.2.0? If yes, when? Thanks!
The energy now goes towards the next major version, Lazarus 2.2, which will be branched around the time FPC 3.2 gets released. Then there will be release candidates before the actual release.
Hello,
Finally, the Free Pascal 3.2.0 release is available from our servers and from sourceforge.
...
Enjoy!
The Free Pascal Compiler Team
My question stays the same for many years. Is it Delphi 2009 compatible? Or not? I really want to fully migrate to Lazarus, cuz I've got sick of that "out of memory" problems with large modules.
Free Pascal doesn't provide a win64 compiler, only a win32->win64 crosscompiler.
The reason for that is that the win64 (due to the pecularities of Microsoft floating point support) can't bootstrap other i386/x86_64 compilers.
Large modules or auto generated crazy sized procedures?Generics.
Will the next version of Lazarus be shipped with FPC 3.2.0? If yes, when? Thanks!
Usually lazarus switches FPC version only with major Lazarus (.x.y.0) releases. So it probably depends if the current series still has life in it or not.
My question stays the same for many years. Is it Delphi 2009 compatible? Or not? I really want to fully migrate to Lazarus, cuz I've got sick of that "out of memory" problems with large modules.
It seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0.
It depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions).Closures are required for my project. I can't get rid of them. They're used as unit test callbacks with ability to pass arbitrary data to them via capturing. I mean Delphi 2009 compatible - any Delphi 2009 project can be compiled via FPC. May be with some minor tweaks.
It depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions).Closures are required for my project. I can't get rid of them. They're used as unit test callbacks with ability to pass arbitrary data to them via capturing. I mean Delphi 2009 compatible - any Delphi 2009 project can be compiled via FPC. May be with some minor tweaks.
It depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions).Closures are required for my project. I can't get rid of them. They're used as unit test callbacks with ability to pass arbitrary data to them via capturing. I mean Delphi 2009 compatible - any Delphi 2009 project can be compiled via FPC. May be with some minor tweaks.
Uhm, does that also apply for the definition pictures used in the reference guide ? e,g, they currently do not take generics definition(s) into account.It seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0.
That indeed appears to be the case. Please report bugs for these.
However, I do not see SRC for 3.2.0 in .TAR, only .RPM. This can be extracted anyway and used in Ubuntu, or better to download from SourceForge with SVN or GIT?https://sourceforge.net/projects/freepascal/files/Source/3.2.0/
Uhm, does that also apply for the definition pictures used in the reference guide ? e,g, they currently do not take generics definition(s) into account.It seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0.
That indeed appears to be the case. Please report bugs for these.
Hi,please start a new thread for questions outside the fpc or rtl.
well done.
But I have an issue with my class/interface hierarchic which is working with 2.0.8 / 3.0.4.
But with 2.0.8 / 3.2.0 I'm getting the error
Is my hierachic correct?
Best regards,
antispam88
Hi,
well done.
But I have an issue with my class/interface hierarchic which is working with 2.0.8 / 3.0.4.
But with 2.0.8 / 3.2.0 I'm getting the error
Is my hierachic correct?
Best regards,
antispam88
But with 2.0.8 / 3.2.0 I'm getting the errorCarefully read Methods_implementing_interface_methods_and_overloads (https://wiki.freepascal.org/User_Changes_3.2.0#Methods_implementing_interface_methods_and_overloads) from User_Changes_3.2.0 and add an overload directive.Is my hierachic correct?
But with 2.0.8 / 3.2.0 I'm getting the errorCarefully read Methods_implementing_interface_methods_and_overloads (https://wiki.freepascal.org/User_Changes_3.2.0#Methods_implementing_interface_methods_and_overloads) from User_Changes_3.2.0 and add an overload directive.Is my hierachic correct?
It depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions).
Any plans for the future related to the implementation of anonymous methods?
Fpcupdeluxe uses the required bootstrap versions that are available in the FPC Makefile.
Now it seems that FPC 3.2.0 also defines itself (3.2.0) as bootstrapper.
Is this a new policy ?
How can I find out which bugs are fixed in the 3.2.0 and which are not?
In which FPC version will these bug fixes be merged?
I can see a bug found in 3.2.0rc1 reported "resolved" months ago which fix is not merged in the final version 3.2.0: https://bugs.freepascal.org/view.php?id=36863
I can see a bug found in 3.2.0rc1 reported "resolved" months ago which fix is not merged in the final version 3.2.0: https://bugs.freepascal.org/view.php?id=36863
Something being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release.
Something being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release.
Something being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release.
If it is a regression from previous release (as said in bug report), would you merge to fixes branch?
What can be done ?
Hi!
The false positive alarm of Bitdefender increases in the last year.
The last false positive alarm was about YajHFC (Yet another Java HylaFAX client) which runs on our Windows clients since 7 years. Unchanged.
There were some more issue with false positive of Bitdefender.
Hard times for the AV companies.
Winni
This is a technical question, you may get more knowledgeable responses when posting this in the General (https://forum.lazarus.freepascal.org/index.php/board,62.0.html) or FPC development (https://forum.lazarus.freepascal.org/index.php/board,62.0.html) boards.
Good afternoon!
I often use Byte, Word, LongWord as flags.
Attached is a screenshot. And I would like to know the code that is highlighted, in this variant and gets into the program?
If so, for what reason, the check is carried out during the execution of the program? Why does this check not occur at the link stage, when the program has not yet been compiled.
I specifically checked, yes, the program crashes by mistake, reporting that there was an overflow. But there was no warning that the number was taken more than it was possible to take.
In this case, I think, initially there should be a warning, and if the programmer (the person creating the program) does not want to pay attention to what the compiler told him, then simply "cut off" this number for him.
This check will neither help the development of the program, nor its work, nor the search for errors that have occurred.
You probably did not notice, debug code is wrapped inside the selection. It checks the dimension, and if the size is out of range, it generates an error and the program crashes with an error. This code should not be there in principle! It increases the size of the program, in any way does not affect the performance of the final program (when debugging is disabled) and, adds errors to the code when debugging is enabled.
If we made a program and accidentally printed a number larger than possible, then during normal compilation the number will simply be "cut off" (no warnings !!!) and will work fine. And when we want to debug this code, then at startup, we will get "Error 211" - because the debug code was added to the code. And the reason for such an error is difficult to find. After all, initially the program worked fine.
As ccrause said, Pascal evaluates (in this case) Field or ACTIVE using the native width of the processor (in this case 64-bit) and then assigns this again to a 8-bit field. Thus it inserts a range check upon the assignment as long as range checks are enabled.Я лишь оповестил. Вероятно, вы ещё не раз столкнётесь с этой проблемой. И чтоб от неё избавится, лучше данный код сделать на эмулируемом уровне, и, было бы хорошо чтоб он вообще не включался в рабочий код. (многие даже не отключают отладку и не знают об этом).
No, if compilation with range checks triggers an error then your program might appear to work fine if compiled without range checks, but it contained errors nevertheless. And these might show in even harder to debug circumstances.
I only notified. You will probably encounter this problem more than once. And in order to get rid of it, it is better to make this code at the emulated level, and it would be good that it should not be included in the working code at all. (many don't even turn off debugging and don't know about it).
I'm sorry, but your answer is more like: "We don't give a damn about this error."
When do you plan RC or final version for FPC 3.2.1?
If so, for what reason, the check is carried out during the execution of the program? Why does this check not occur at the link stage, when the program has not yet been compiled.Range checks errors can't usually be checked during compilation/linking. Some will (i.e. accessing array[-1] of an array[0..100]) but with a variable there is no way to check during linking, only during execution of your program. That's why you should debug and test with range check on. After that, when you check your program is flawless ( ::) ) you can disable range check (and other debugging options) for your release to client.
Range checks errors can't usually be checked during compilation/linking. Some will (i.e. accessing array[-1] of an array[0..100]) but with a variable there is no way to check during linking, only during execution of your program. That's why you should debug and test with range check on. After that, when you check your program is flawless ( ::) ) you can disable range check (and other debugging options) for your release to client.Флаги нельзя проверять по переменным! А если это будет сделано, то компилятор как раз выдаст ошибку, если переменные будут разной размерности.
I hope I have detailed enough?
P.S. in the structure the bytes will be checked for dimension.
It is right that the compiler currently does not complain at compile time, because it can't. Once the compiler does the EditMode or EDIT_TRUE operation (which will result in a value of native width, in the case of a 64-bit target indeed a 64-bit value) it no longer knows that a constant was involved and thus it can't generate an error at compile time when that value is assigned to EditMode. And EditMode or EDIT_TRUE is a valid expression even if EDIT_TRUE is larger than the size of EditMode.
When do you plan RC or final version for FPC 3.2.1?
We are currently in the progress of merging fixes and improvements from trunk, so it will still take some time. Maybe before Christmas, but don't take that for granted.