the moment to test the compatibility of your codebases with the future FPC is _NOW_!This code
l.s.
A branch was made for a future series of 3.2.x FPC releases. A first release
of this branch is still months away, but the moment to test the compatibility
of your codebases with the future FPC is _NOW_!, while there is still time
to do something about it.
The svn designation of this fixes branch is branches/fixes_3_2
As a consequence, trunk will be updated to version 3.3.1, some people might have to update their scripts.
2.0 RC1I am confused.
ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2032%20bits/Lazarus%202.0RC1/
ftp://ftp.freepascal.org/pub/lazarus/releases/Lazarus%20Windows%2064%20bits/Lazarus%202.0RC1/
I am confused.You asked the same question in another thread. I don't know why you are confused.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?
I am confused.With FPC 3.0.4 obviously. FPC 3.2.0 will not be released for a long time. There is even no RC1 yet.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?
That said, testing with 3.2 branch is still recommended too, since once 3.2 is out the next minor (Lazarus 2.0.x) will probably use it.
Sorry for duplicating my post.I am confused.You asked the same question in another thread. I don't know why you are confused.
Which one is most probably to be released: Lazarus 2.0.0 with FPC 3.0.4 or FPC 3.2.0?
gives no warning at 3.0.4 but with the latest trunk it givesYes I am also interested, will it be fixed?
"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes
In MSEgui I useQuotethe moment to test the compatibility of your codebases with the future FPC is _NOW_!This codegives no warning at 3.0.4 but with the latest trunk it gives
procedure TForm1.Button1Click(Sender: TObject); var a: array of Integer; i: Integer; begin SetLength(a, 10); //HERE for i:=0 to length(a)-1 do a[i]:=i; end;
"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes parameter by refrence (var) but it is same in 3.0.4 and 3.1.1.
For Windows users: https://sourceforge.net/projects/lazarus-snapshots/files/I uploaded up to date 3.2.0-beta installers for windows, bundled with Lazarus 2.0RC1
Ensure to set the checkbox "secondary installation", then they do not interfere with your stable install.
It seems that something with the IsMultiThread variable changed.
@marco
I don't know anything about multithreading and IsMultiThread variable in fpc.
I wanted only inform the developers and users of fpc.
In example from above and in ibx-examples with fpc 3.0.2 IsMultiThread is in OnFormCreate true but with fpc 3.2.0. it is false.
It seems that something with the IsMultiThread variable changed.Yes, there was a bug (https://bugs.freepascal.org/view.php?id=30535) in the previous version that fixed.
I compile fpc 3.2.0.r59470 with fpc 3.2.0.r39795 from 2018/9/23I am on Windows 7 Pro 64bit using Lazarus 2.0 RC1 32bit SVN Revision 59712M and FPC 3.2.0 beta 32bit '2018-09-18 rev 39766' trying to reach SVN Revision 40301.
I compile fpc 3.2.0.r59470 with fpc 3.2.0.r39795 from 2018/9/23I am on Windows 7 Pro 64bit using Lazarus 2.0 RC1 32bit SVN Revision 59712M and FPC 3.2.0 beta 32bit '2018-09-18 rev 39766' trying to reach SVN Revision 40301.
Should "C:\lazarus\tools\install\win\build-fpc.bat" be an easy way to recompile FPC 3.2.0 beta updated via SVN fixes_3_2?
I am trying to rebuild FPC 3.2.0 beta, but it's not working.
-----------------------------------------------------------------------
Microsoft Windows [versão 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Todos os direitos reservados.
C:\Users\valdir>cd \lazarus\tools\install\win
C:\lazarus\tools\install\win>build-fpc.bat
C:\lazarus\tools\install\win>SET OLDCURDIR=C:\lazarus\tools\install\win
C:\lazarus\tools\install\win>SET OLDCURDRIVE=C:
C:\lazarus\tools\install\win>SET FPCSRC_DIR=\fpcsrc
C:\lazarus\tools\install\win>SET SOURCE_DIR=\fpc-source
C:\lazarus\tools\install\win>export -q \fpcsrc \fpc-source
'export' não é reconhecido como um comando interno
ou externo, um programa operável ou um arquivo em lotes.
C:\lazarus\tools\install\win>\f
'\f' não é reconhecido como um comando interno
ou externo, um programa operável ou um arquivo em lotes.
C:\lazarus\tools\install\win>cd \fpc-source
O sistema não pode encontrar o caminho especificado.
C:\lazarus\tools\install\win>if [] == [] GOTO NO_PATCH
C:\lazarus\tools\install\win>gmkdir -p \fpc\source
'gmkdir' não é reconhecido como um comando interno
ou externo, um programa operável ou um arquivo em lotes.
A sintaxe do comando está incorreta.
C:\lazarus\tools\install\win>cp -pr \fpc-source\rtl \fpc\source\rtl >>
C:\lazarus\tools\install\win>
-----------------------------------------------------------------------
Could FPC have SVN Revision Number similar to Lazarus About Form?
Or could Lazarus About Form also shows FPC SVN Revision Number?
Revision number in IDE main window caption
http://forum.lazarus.freepascal.org/index.php/topic,42342.0.html
-----------------------------------------------------------------------
C:\Users\valdir>C:\lazarus\fpc\3.2.0\bin\i386-win32\fpc.exe -iV
3.2.0
C:\Users\valdir>C:\lazarus\fpc\3.2.0\bin\i386-win32\fpc.exe -iW
3.2.0-beta
C:\lazarus\fpc\3.2.0\bin\i386-win32>fpc.exe
Free Pascal Compiler version 3.2.0-beta [2018/10/21] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
C:\lazarus\fpc\3.2.0\bin\i386-win32\fpc.exe [options] <inputfile> [options]
Only options valid for the default or selected platform are listed.
C:\type C:\lazarus\fpc\3.2.0\utils\fpcm\revision.inc
'2018-09-18 rev 39766'
-----------------------------------------------------------------------
I apologise for not expressing myself entirely clearly.I am on Windows 7 Pro 64bit using Lazarus 2.0 RC1 32bit SVN Revision 59712M and FPC 3.2.0 beta 32bit '2018-09-18 rev 39766' trying to reach SVN Revision 40301.You probably need to install subversion client tools into your computer.
Should "C:\lazarus\tools\install\win\build-fpc.bat" be an easy way to recompile FPC 3.2.0 beta updated via SVN fixes_3_2?
I am trying to rebuild FPC 3.2.0 beta, but it's not working.
Could FPC have SVN Revision Number similar to Lazarus About Form?
Or could Lazarus About Form also shows FPC SVN Revision Number?
Revision number in IDE main window caption
http://forum.lazarus.freepascal.org/index.php/topic,42342.0.html
I recommend TortoiseSVN : https://tortoisesvn.net/
Get the 64-bit version and remember to select 32-bit version and the command line tools at the setup screen.
I apologise for not expressing myself entirely clearly.I am on Windows 7 Pro 64bit using Lazarus 2.0 RC1 32bit SVN Revision 59712M and FPC 3.2.0 beta 32bit '2018-09-18 rev 39766' trying to reach SVN Revision 40301.You probably need to install subversion client tools into your computer.
Should "C:\lazarus\tools\install\win\build-fpc.bat" be an easy way to recompile FPC 3.2.0 beta updated via SVN fixes_3_2?
I am trying to rebuild FPC 3.2.0 beta, but it's not working.
Could FPC have SVN Revision Number similar to Lazarus About Form?
Or could Lazarus About Form also shows FPC SVN Revision Number?
Revision number in IDE main window caption
http://forum.lazarus.freepascal.org/index.php/topic,42342.0.html
I recommend TortoiseSVN : https://tortoisesvn.net/
Get the 64-bit version and remember to select 32-bit version and the command line tools at the setup screen.
I have already done all that you suggest, but my problem still lies on how to build/compile FPC 3.2.0 beta after SVN fixes_3_2 updates for testing it with Lazarus 2.0 RC (also updated via SVN fixes_2_0)?
Can you help me on that?
Besides Lazarus 2.0 RC having "menu Tools > Build Lazarus" to build itself, it would be of great help another option for building FPC from inside Lazarus.
Do you have previous release version of FPC (3.0.4) installed and in your path environment variable when executing your commands?Not exactly.
After deleting all *.ppu and *.o, I am trying to compile FPC 3.2.0 beta with fixes_3_2 using FPC 3.0.4 and I got stuck at:Do you have previous release version of FPC (3.0.4) installed and in your path environment variable when executing your commands?Not exactly.
I have installed to "c:\Lazarus":
lazarus-2.0.0RC1-59029-fpc-3.2.0-beta-20181021-win32.exe
lazarus-2.0.0RC1-59029-fpc-3.2.0-beta-20181021-cross-x86_64-win64-win32.exe
Then, I have installed "fpc-3.0.4.i386-win32.exe" to "C:\lazarus\fpc\3.0.4".
What should I do next?
1) Do you need to rebuild:I would like to compile the whole thing.
- the compiler
- the rtl
- package(s)
?
the compiler...I've already read it before:
the official answer is buildfaq.pdf
Here is how I do it (hope I make no copy and paste error)I'll try it.
checkout (fully recursive)
https://svn.freepascal.org/svn/fpc/trunk
https://svn.freepascal.org/svn/fpcbuild/trunk
Have ready an install (eg lazarus) of the latest released fpc.
Include in your PATH
- the installed released fpc directory
- build_trunk\install\binw32 or binw64 (and if needed crosstools)
build_trunk is svn/fpcbuild/trunk
Make sure you do not have Delphi's make in the path.
cd path/in/svndir/fpc/trunk
make clean distclean
make.exe all OPT="-gw"
you may want to add (at your option)
make.exe all OPT="-gw" COPYTREE=echo UPXPROG=echo
then
make.exe install INSTALL_PREFIX=yourinstdir COPYTREE=echo UPXPROG=echo
generate your fpc.cfg
fpcmkcfg.exe -d "basepath=__yourinstdir__" -o "__yourinstdir__\bin\%FPCFULLTARGET%\fpc.cfg"
I did some work on my snapshot script, it is online here (http://www.stack.nl/~marcov/files/buildscript.zip):I'll try it.
It is a windows .cmd file with a small, optional FPC compiled utility that is a substitute for the *nix "time" command.
The script allows building for win32 and win64, and has several parameterizable options, configurable by editing batch variables in the script, and warns if a step (build or install) went wrong.
I use two copies of this, one for win32 and one for win64. (one line difference). Please read over the first half to check variables.
It assumes a FPC directory (with tools like make etc) in the %PATH%, but allows to use the starting compiler to be specified explicitely. This is so that it works when I have a development snapshot in the path, but still want to start the build using the release compiler.
On current multicore machines, using a script can significantly decrease FPC snapshot building times.
Times for install+ build on machines with SSD:
i7-3770: 2mins 8s
i5-6500T (?) laptop about the same.
Ryzen 2600: 1min 35s
Odd...Mine. I was still trying to adapt my "make distclean clean all install".
Which way? Mine or Marcov?
This is an unmodified copy of fixes 3.2? (first get the unmodified to build, then see what happens when you make changes...)Thanks.
I just did a build of fixes3.2 rev 40528. So it the build is not broken. Sometimes it just is a bad commit.
Also sometimes it will fail if build with certain options (I several times noticed that it was unable to build with -CR / but there may be other options). So try building with no extra opts at all.
CustApp is in fcl-base (filesystem search) and that is listed in the include path on your output.
Restart your build (without cleaning) but in OPT add -va
Hopefully that gives you some extra output about what it is looking for.
Hi,
we are using the pascalio package (https://github.com/SAmeis/pascalio (https://github.com/SAmeis/pascalio)).
The package uses following construct with inheritance:
TADConverter = class(TObject) protected class function GetMaxValue: Longint; static; virtual; abstract; ... public class property MaxValue: Longint read GetMaxValue; ... end;
With Lazarus 1.8.4 / FPC 3.0.4 it is compiling without an error but with 2.0.0 RC3 / 3.2.0 (rev. 59877) I'm getting following error:
fpadc.pas(60,50) Error: Procedure directive "VIRTUAL" cannot be used with "STATIC".
So for me there are two questions:
1) Is it an error that this is possible in 1.8.4/3.0.4? See https://www.freepascal.org/docs-html/3.0.0/ref/refse39.html (https://www.freepascal.org/docs-html/3.0.0/ref/refse39.html).
2) And how is the correct solution for that problem?
Best regards,
antispam88
The reason for the requirement is that a class property is associated to the particular class in which it is defined, but not to descendent classes. Since class methods can be virtual, this would allow descendent classes to override the method, making them unsuitable for class property access.
I can confirm, this was bug, fixed in 3.2.x (see my rev. 35724)QuoteThe reason for the requirement is that a class property is associated to the particular class in which it is defined, but not to descendent classes. Since class methods can be virtual, this would allow descendent classes to override the method, making them unsuitable for class property access.
As the documentation say, you can't use class property getters/setters that way. If 3.0.4 version of FPC allows it, then it is a bug and it is fixed 3.2.x series.
You have morons, idiots and people who fail to verify:As usual you insult people without looking at the context. This is i386 and not arm. The handling of calculations is assembly dependant and is implemented per processor type.
Don't spread rumors if you do not test....
BTW this is even back-ported < Grumpy indeed >:D >:D >:D >:D >
That is strange:
...
That means you can re- open the bug report if you want (And can prove it is still there, or again there with a simple example).
I can not reproduce it, though (Windows 10, 64 to 32 cross-compiler from today)
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.3.1 [2019/01/02] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
Linking test.exe
21 lines compiled, 0.3 sec, 67712 bytes code, 4180 bytes data
3 warning(s) issued
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
1000.00000
Just wondering what the next "stable" version of FPC will be and when it's due for release?
Just wondering what the next "stable" version of FPC will be and when it's due for release?
The next stable will be 3.2.0 (hence this thread) and it's expected some time this year.
Im eager to help with next fpc release, i'm wondering if there is anything i can do with a feature i'm very eager to use: anonymous functions:
https://foundation.freepascal.org/projects/project-2 & http://lists.freepascal.org/pipermail/fpc-devel/2017-July/038101.html
Is there any work for me that i can do, helping get anonymous functions merged in?
Im eager to help with next fpc release, i'm wondering if there is anything i can do with a feature i'm very eager to use: anonymous functions:
https://foundation.freepascal.org/projects/project-2 & http://lists.freepascal.org/pipermail/fpc-devel/2017-July/038101.html
Is there any work for me that i can do, helping get anonymous functions merged in?
This work is not yet in trunk, so out of the question for 3.2.
Ok, so how can i help get it into trunk?
Ok, so how can i help get it into trunk?
Work on it/ finish it? Afaik it isn't, or at least not for all architectures. I don't know the details, ask on fcl-devel maillist if you are interested in helping out.
Or try a separate post in one of the freepascal development subforums on this forum.
Mailing lists are archaic & slightly inaccesible, i will attempt to post in the freepascal forum section.
You must be very, very young ... email is inaccesible? :o :)I am not exactly young (50), and I think that mailing lists are incredibly awkward to walk through in order to get information about a subject.
This is a (actual) known feature comming from a change in a interface of fpc. See https://bugs.freepascal.org/view.php?id=34804 and http://forum.lazarus.freepascal.org/index.php?topic=43828.0Thanks.
I guess no need to remove all.It worked perfectly.
Just delete the "config_lazarus"-folder and use fpcupdeluxe to rebuild/update Lazarus.
No new downloads needed.
Some modules, such as [...] tvplaneit, break Lazarus build process. Even uninstalling them keeps Lazarus broken.Normally report in bugtracker. Yes, write an individual report for each component because there are different maintainers.
1. Where should I report these problems?
2. Should I individualize each report by broken module?
In theory, uninstall module should do the job.You are right, some modules were uninstalled in my first try.
If not, the config removal is the only thing that fpcupdeluxe can do in these cases.
Before reporting problems, always search the bugtracker of FPC and Lazarus.Ok.
Ok.Some modules, such as [...] tvplaneit, break Lazarus build process. Even uninstalling them keeps Lazarus broken.Normally report in bugtracker. Yes, write an individual report for each component because there are different maintainers.
1. Where should I report these problems?
2. Should I individualize each report by broken module?
As for tvplanit (which is maintained by myself - so, no need to report anything here), I just build laz trunk / fpc trunk with having tvplanit installed, and I did not experience any problems. But when using the OPM version I saw a compilation error. I'll make an updated version available for OPM as soon as possible.Thanks.
As for OPM: The issue is not in OPM but in VirtualTreeView which is affected by a change in the parameter list of an ActiveX-related procedure introduced by fpc trunk and backported already to fpc-fixes. The related correction in VTV has been applied to Laz- trunk but had not yet been merged back to Laz-fixes. But now I merged the patch to Laz-fixes manually, and the combination Laz-2.0fixes + fpc 3.2-fixes can be installed with fpcupdeluxe again.Thanks.
I think I confused these fpcupdeluxe modules with OPM, sorry.
Where do these modules come from? How are they updated? Why does fpcupdeluxe distribute its own packages when there is now OPM which is even integrated in the IDE?
I think I confused these fpcupdeluxe modules with OPM, sorry.You're welcome.
Where do these modules come from?Please, see the attached image.
How are they updated?I don't know.
Why does fpcupdeluxe distribute its own packages when there is now OPM which is even integrated in the IDE?I don't know.
I don't intend to build games. I was just trying to install all available modules for testing purposes.About BGRAGames not compiling, is an outdated package, I should check if I can fix it, but for making a game better use Castle Game Engine that is cross platform and works for mobile devices.
* bgragames (the modules bgrabitmap, bgracontrols and bgracontrolsfx were previously properly installed)
Edit: I see LazPaint in the list, is not a package that can be installed, is a regular lazarus project. In the past that repo included bgrabitmap, but now they are in 2 separate repos.I didn't know.
Something must be badly wrong with this list. I quickly tested some of the packages that I know, CalLite, Industrial, ColorPalette, LazBarCode, mbColorLib - and they all compile fine.I am using FPCUPdeluxe to test Lazarus 2.0 RC 3 + fixes_2_0 and FPC 3.2 beta + fixes_3_2.
Which IDE and which FPC are used? I used Laz trunk / fpc 3.0.4 / 32 bit on Win10 / 64 bit.
Why are fpvectorial and lazopenglcontext in the list? They is contained in the standard Lazarus distribution.I don't know.
I think I confused these fpcupdeluxe modules with OPM, sorry.As soon as OPM got back compiling, I will test on Lazarus 2.0 RC 3 + fixes_2_0 and FPC 3.2 beta + fixes_3_2 the packages I should really use.
Why does fpcupdeluxe distribute its own packages when there is now OPM which is even integrated in the IDE?
I am using FPCUPdeluxe to test Lazarus 2.0 RC 3 + fixes_2_0 and FPC 3.2 beta + fixes_3_2.You are not mentioning the bitness of your OS, but further up I get the impression that it is 32 bit. In this case, the number of packages that you want to install are way too much and you will run out of memory - there are some threads about this here in the forum. I don't know what fpcupdeluxe will tell you in this case.
Correct, I am testing Lazarus 32bit.I am using FPCUPdeluxe to test Lazarus 2.0 RC 3 + fixes_2_0 and FPC 3.2 beta + fixes_3_2.You are not mentioning the bitness of your OS, but further up I get the impression that it is 32 bit.
In this case, the number of packages that you want to install are way too much and you will run out of memory - there are some threads about this here in the forum.I didn't know that, yet.
I don't know what fpcupdeluxe will tell you in this case.Neither do I. :)
Should I open a bug report?Do you know, is it comming from FPC 3.2 or a Lazarus 2.0 Problem ?! Look if this is eventually fixed on trunk. So you can make a request for backporting.
fpReport is a new package for future FPC 3.2.0. I am trying to test it.Should I open a bug report?Do you know, is it comming from FPC 3.2 or a Lazarus 2.0 Problem ?! Look if this is eventually fixed on trunk. So you can make a request for backporting.
using config file D:\data\lazdev\work\lazarus\lazarus.cfgThere is a dll missing.
[FORMS.PP] ExceptionOccurred
Sender=EInOutError
Exception=Can not load Freetype library "freetype-6.dll". Check your installation.
Stack trace:
$00E70209
$00E7028D
$00E7030A
fpReport is a new package for future FPC 3.2.0. I am trying to test it.Should I open a bug report?Do you know, is it comming from FPC 3.2 or a Lazarus 2.0 Problem ?! Look if this is eventually fixed on trunk. So you can make a request for backporting.
No Problem to compile and install fpreport. BUT Lazarus wont start. On commandline no message, but if i activate --debug-log=log.txt on the commandline i seeI never used fpreport, but Andreas, I think you did: Since fpreport was written by the fpc or Lazarus team (I did not follow these activities) a bug report has some chance to be read. I think fpreport should be modified such that it does not link these dlls statically into the Lazarus exe. SQLDB does not do the same with sqlite3 and firebird and other dlls. Only at runtime, the dll should be loaded and maybe terminate the program if not found. A component which can crash the IDE because something is missing is always a bad choice.Quoteusing config file D:\data\lazdev\work\lazarus\lazarus.cfgThere is a dll missing.
[FORMS.PP] ExceptionOccurred
Sender=EInOutError
Exception=Can not load Freetype library "freetype-6.dll". Check your installation.
Stack trace:
$00E70209
$00E7028D
$00E7030A
Edit: You have to install freetype-6.dll AND zlib1.dll !!! for your bitness eg. 32bit for a 32Bit Lazarus.
I am not the best person for the job, but I did it:No Problem to compile and install fpreport. BUT Lazarus wont start. On commandline no message, but if i activate --debug-log=log.txt on the commandline i seeI never used fpreport, but Andreas, I think you did: Since fpreport was written by the fpc or Lazarus team (I did not follow these activities) a bug report has some chance to be read. I think fpreport should be modified such that it does not link these dlls statically into the Lazarus exe. SQLDB does not do the same with sqlite3 and firebird and other dlls. Only at runtime, the dll should be loaded and maybe terminate the program if not found. A component which can crash the IDE because something is missing is always a bad choice.Quoteusing config file D:\data\lazdev\work\lazarus\lazarus.cfgThere is a dll missing.
[FORMS.PP] ExceptionOccurred
Sender=EInOutError
Exception=Can not load Freetype library "freetype-6.dll". Check your installation.
Stack trace:
$00E70209
$00E7028D
$00E7030A
Edit: You have to install freetype-6.dll AND zlib1.dll !!! for your bitness eg. 32bit for a 32Bit Lazarus.
So, my point is: Could somebody with experience in fpreport write a bug report that this component crashes the installation of Lazarus when these dlls are missing?
I am using FPCUPdeluxe to test Lazarus 2.0 RC 3 + fixes_2_0 and FPC 3.2 beta + fixes_3_2. Everything is 32bit.Workaround complete. Lazarus is back starting.
When I install any or all of the packages lclfpreport.lpk, lazfpreportdesign.lpk, lazidefpreport.lpk from "C:\fpcupdeluxe\lazarus\components\fpreport\" and "C:\fpcupdeluxe\lazarus\components\fpreport\design\", Lazarus gets broken during rebuild and doesn't work anymore.
No, my only safe place is my PC. I think i have loaded this from the sites as found on https://www.zlib.net/Thanks.
Edit:
freetype-6 : http://gnuwin32.sourceforge.net/packages/freetype.htm
zlib1 : http://gnuwin32.sourceforge.net/packages/zlib.htm
But naming of the freetype6.dll to freetype-6.dll is needed.
Do you have a very trust-worthy source for the zlib dll ?Thanks for sharing:
With trust I mean safe !
For windows user, the actual Laz2.0 with updated fpc fixes 3.2: https://sourceforge.net/projects/lazarus-snapshots/files/Thanks.
Can we expect FPC 3.2.0 to be released in the second semester of 2019?No, other than "probably in the second half of this year".This change will be available in the upcoming FPC 3.2.0Off topic but wondering, is there a reasonably solid estimate of when FPC 3.2.0 will be released ?
Can we expect FPC 3.2.0 to be released in the second semester of 2019?
From July through December... :)Can we expect FPC 3.2.0 to be released in the second semester of 2019?Which months are you thinking of for second semester?
From July through December... :)
I can't download Window 64 folder's files.
When I click on files on folder:
https://sourceforge.net/projects/lazarus-snapshots/files/Window%2064/lazarus-2.0.2-60960-fpc-3.2.0-beta-41793/
I am redirected back to:
https://sourceforge.net/projects/lazarus-snapshots/files/
Can you try again?It worked. Thanks.
AFAIR in 2019 autumn.
I would be curious as to what bug is being referred to?the bug is related to finalization of some specific types of interface variables at the end of certain methods.
Currently working on a project and unfortunately there is a compiler bug in FPC versions less than 3.2.0 that causes it to fail. This bug has been fixed in fixes 3.2.0 but unfortunately policies prevents me from using non stable versions in the project.Maybe it is not a complex fix so you can apply just the patch related to this bug? Or use whole unit file from 3.2.0 with some/none adaptation? That will not work in most cases since changes from 3.0 to 3.2 can be massive but maybe you are lucky...
Maybe it is not a complex fix so you can apply just the patch related to this bug? Or use whole unit file from 3.2.0 with some/none adaptation? That will not work in most cases since changes from 3.0 to 3.2 can be massive but maybe you are lucky...unfortunately this is not some RTL based issue rather some bug related to compiler codegen and I can't dissect which commit fixes this issue.
AFAIR in 2019 autumn.https://www.miniwebtool.com/first-day-of-autumn/?year=2019&location=1
When it is done.... Silly question....;D
When it is done.... Silly question....
Seems 2 required (for CudaText app) fixes not done:
- FreeBSD DirectoryExists not working (reported at maillist)
- Solaris bad code https://bugs.freepascal.org/view.php?id=35450
The next FPC release, version 3.2, is planned for later this year.
On the FPC site :QuoteThe next FPC release, version 3.2, is planned for later this year.
I guess that ain't gonna happen. Any update on progress?
Nice!
If it is not the same as trunk, will FPC 3.2 ship with generic.collections by default?
Seems 2 required (for CudaText app) fixes not done:
- FreeBSD DirectoryExists not working (reported at maillist)
- Solaris bad code https://bugs.freepascal.org/view.php?id=35450
Do you use a stock kernel? People are reporting problems with own build compilers that leave out legacy features.
IF Dir(MessagesFile) = "" THEN
statements.
Hi freinds,
We are in 2020 ( happy new year to all :) )
But >:( Where is the new release version of fpc planed to the end of 2019 ?!
>:D
Hi freinds,
We are in 2020 ( happy new year to all :) )
But >:( Where is the new release version of fpc planed to the end of 2019 ?!
>:D
Well, the next holiday after christmas/new year is Easter >:D
You can choose between different calendars if you like. O:-)
You can choose between different calendars if you like. O:-)
Well, by the Islamic calendar we are still in the 1440s so there is still a "little" time for a 2019 release :D 8-)
Any news on FPC 3.2?
Now it is already FebruaryCan you post a small example?
I hope fpc3.2 comes soon.
I spend today replacing arrays of strings with arrays of arrays in my project, and it became much faster, but now I notice, it does not compile with fpc 3.0 anymore :/
Can you post a small example?
Can you post a small example?
It was kind of like this:
program p; type TObjectArray = array of TObject; procedure testOld(a: array of string); begin //... for s in a do s.split(',') ... end; procedure testNew(a: array of TObjectArray); begin //... end; var x, y, a, b: tobject; begin testOld(['x,y','a,b']); testNew([[x,y],[a,b]]) end. ~
Well, in trunk this compiles, note array initialization in mode delphi and mode objectfpc are different:
program p; {$mode delphi} type TObjectArray = array of TObject; procedure testOld(a: array of string); begin //... for s in a do s.split(',') ... end; procedure testNew(a: array of TObjectArray); begin //... end; var x, y, a, b: tobject; begin testOld(['x,y','a,b']); testNew([[x,y],[a,b]]) end.
Of course I assume your trunk is reasonably up-to-date...
As a workaround you can use the Create constructor which is only available for named dynamic arrays (which your TObjectArray is):
I did not know about that, but I rewrote it with a custom function
Any news on FPC 3.2?
Some progress with the major blockers in the last weeks. No news about schedule.
The difference between the unreleased FIXES_3_2 branch and real releases is mostly just packaging. I would simply use a FIXES3_2 snapshot if I were you.
IMO more frequent releases with less changes would be better for new features to get adopted.+1
The Lazarus/FPC community could create a Linux distribution that is the "reference" platform for lazarus/FPC development.
[...]I understand the building process itself requires effort because there are so many platforms, OSs and CPUs to support. In that case the release should be built for the most popular platforms only. [...]I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.
I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.
I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.Otto, you misunderstood the issue badly. Different Linux distributions are not the issue here. Most Linux users have a x86-64 CPU. One single FPC release build covers them all. Remember, FPC is a compiler with only few external dependencies.
I understand the building process itself requires effort because there are so many platforms, OSs and CPUs to support. In that case the release should be built for the most popular platforms only.
The more parts of the project are covered by continuous maintainers that also check and use the fixes branch continuously, then something might change. Something like Lacak does with fcl-db.
Just thinking up unachievable targets won't change anything, you must also come up with a manageable path to it.
Actually release building has become better (as in less risky) over the years, but the complexity of the project has gone up and the members time has gotten less, so I understand that users sometimes get the wrong impression.
A rc1 will be released very shortly. Final Release date is to be determined, but probably not that soon.
The difference between the unreleased FIXES_3_2 branch and real releases is mostly just packaging. I would simply use a FIXES3_2 snapshot if I were you.
PS/ I read the thread... I think one of the problem is that the compiler, RTL and packages are all packaged together. May be if they were separated, at least packages, that may allow to make updates and maintenance of each part more agile?
To remove all questions fpc team need to keep the roadmap up to date, not as it is always he only misleading. Оr don't do it at all
Usually it is targets like Debian and OS X that hold up. So that will never work.Is LLVM now a requirement? That complicates things surely.
It is also not entirely static, e.g. Joost built many linux targets using docker containers this time around. He is also building RPMs for a long time, and those are usually on time. My FreeBSD was usually also on time, but with the recent LLVM transitions I have massive problems (and only FreeBSD11 will be released)
A mutual misunderstanding is always possible.I proposed this suggestion because having a reference platform managed by the same community would accelerate the release of the "stable" version of FPC for that platform. All of us developers could then verify the operation on the same common platform.Otto, you misunderstood the issue badly. Different Linux distributions are not the issue here. Most Linux users have a x86-64 CPU. One single FPC release build covers them all. Remember, FPC is a compiler with only few external dependencies.
Copied from Overview in https://freepascal.org/ :
"Free Pascal is a 32, 64 and 16 bit professional Pascal compiler. It can target many processor architectures: Intel x86 (including 8086), AMD64/x86-64, PowerPC, PowerPC64, SPARC, ARM, AArch64, MIPS and the JVM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/iPhoneSimulator/Darwin, DOS (16 and 32 bit), Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, Nintendo Wii, Android, AIX and AROS. Additionally, support for the Motorola 68k architecture is available in the development versions."
[...]
[...]I have never said that support for other platforms should be removed, the purpose would be to have a test environment ready to use and already configured to be used just for this purpose.
Maybe you confuse FPC with Lazarus / LCL which must deal with GUI libraries.
Creating a reference platform for FPC, maintained by FPC developers? Uhhh, C'mon!
What CPU would it support? What OS? Would FPC developers create a new OS? Should support for all other CPU / OS combinations be dropped?
If you announced FPC 3.2 release today, Arch and Manjaro would build and provide packages within a week or so. Other distros would provide it in their next release. Many people would be happy and FPC maintainers would not need to build anything.
Is an installer needed for MacOS necessarily? I don't know, I don't have a Mac.
And to come back to release management: preparing 3.2 has taken an unusal amount of time as there was a time where the branch has essentially been barren for quite some time without any real reason. So if we avoid that in the future all should be good again. And more frequent major releases than once every two years is unrealistic.
But if no one knows the plan than everyone makes their own plan which is fine but then no one can jump in to help.
Personally I like a fixed released cylce like twice a year. Then every fixes that are ready can be included even if it is just a few. Who cares, version numbers don't cost anything.
No, like I said I'm not yet into it that much. I'm trying to understand it though. To be honest, I didn't even know the page existed. Thanks for pointing it out. I put a suggestion in the discussion page to add a link on the main page under community participation.But if no one knows the plan than everyone makes their own plan which is fine but then no one can jump in to help.
I assume you know the release engineering related wiki pages by heart and have done several attempts at building releases? All stuff to make docs and releases for windows and Linux is open, you can just start.
But that is fairly pointless since it is not the plan points that cause the delays but the feedback loops
while (issuesremaining+issuesnew)>0 do begin put_new_issues_in_queue ; mark_fixed_issues; end;
Such moments are for all major points, the initial fixes release branch, the branch of a RC, the building of the releases. It's these that cause the holdups.
No, like I said I'm not yet into it that much. I'm trying to understand it though. To be honest, I didn't even know the page existed. Thanks for pointing it out. I put a suggestion in the discussion page to add a link on the main page under community participation.
This is also looks interesting: https://wiki.lazarus.freepascal.org/Release_Template
QuoteSuch moments are for all major points, the initial fixes release branch, the branch of a RC, the building of the releases. It's these that cause the holdups.
What do you mean by feedback loop? The several testing phases mentioned here?
Where are the problems exactly? Is there anything someone new could help?
What I meant with transparent in my other post is for example a page like this. https://qgis.org/en/site/getinvolved/development/roadmap.html?highlight=release#release-schedule
I know there are more developers for QGIS and they have a lot more releases per year but that it is not the point.
If all tests (for a given platform) run successfully is it not enough to say that it is ready (for the given platform)?
There are may be bugs for some unusual situations not included into tests. Should they stop the release? Or should new test cases be created and added to tests?
I think if all tests are fine, RC1 can be issued for some period. If new errors reported, their test cases possibly should be included into test suite.
What I mean, if you got an issue (email or report) from someone, to fix it you need to test it.
At that time a test case can be created and added to tests suite.
And if developers runs all tests after their changes added, it will show if there was an impact in other places.
What currently is a criteria for "solid / not solid"?
I thought that successful run of the test suit is for that, but you are saying it is not "watertight" so what is a purpose of it?
I see RC1 is available! Excellent news!
What I mean, if you got an issue (email or report) from someone, to fix it you need to test it.
Извиняюсь что на русском, но постараюсь более-менее понятно для всех объяснить.
Linux
CodeTyphon or GetLazarus + fpc 3.3.1 + ZenGL
Error: RunError(211)fpc 3.3.1-> fpc 3.0.4 not Error!!!!
где-то намудрили! Хотели исправить, но видимо что-то другое сделали вместо исправлений. Я надеюсь исправят и мне не придётся на LInux пользоваться разными версиями fpc.
на Windows ошибок нет (not error).
Благодарю за внимание.
Postaraysa ispolzovat fpcupdeluxe dla proezvedinya portativni versiyi FPC i Lazarus.
Zabud pro CodeTyphon et GetLazarus.
Ispolzuy fpcupdeluxe : https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases (https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases).
Udatchi.
BSaidus, благодарю, но это не решает проблемы. Проблема видимо из-за разных сборок как FPC, так и Lazarus.
больше помогает полная очистка и заново переустановка Lazarus и FPC.
PascalDragon, та часть которая показывает ошибку, на английском.
Linux, при использовании FPC 3.3.1 + CodeTyphon (или GetLazarus) + ZenGL выдаётся ошибка
Error: RunError(211)
При таких же данных, только используя FPC 3.0.4 ошибок не выдаётся.
На Windows, оказывается, тоже есть эта ошибка, только там создаётся файл рабочий, а вот из Lazarus не даёт его запустить и невозможно запустить процесс отладки.
Честно говоря, мне уже надоели эти танцы с бубном вокруг Lazarus и FPC, хоть самому занимайся разработкой.
Google translate (english):
BSaidus, thank you, but this does not solve the problem. The problem is probably due to different builds of both FPC and Lazarus.
The full cleaning and reinstallation of Lazarus and FPC helps more.
PascalDragon, the part that shows the error is in English.
Linux, using FPC 3.3.1 + CodeTyphon (or GetLazarus) + ZenGL error
Error: RunError (211)
With the same data, only using FPC 3.0.4 errors are not thrown.
On Windows, it turns out that there is also this error, only a working file is created there, but from Lazarus it does not start it and it is impossible to start the debugging process.
Honestly, I’m already tired of these dances with a tambourine around Lazarus and FPC, at least do the development yourself.
Извиняюсь, даже не подгонял перевод, надеюсь понятно.
Google translate (english):
BSaidus, thank you, but this does not solve the problem. The problem is probably due to different builds of both FPC and Lazarus.
The full cleaning and reinstallation of Lazarus and FPC helps more.
PascalDragon, the part that shows the error is in English.
Linux, using FPC 3.3.1 + CodeTyphon (or GetLazarus) + ZenGL error
Error: RunError (211)
With the same data, only using FPC 3.0.4 errors are not thrown.
On Windows, it turns out that there is also this error, only a working file is created there, but from Lazarus it does not start it and it is impossible to start the debugging process.
Honestly, I’m already tired of these dances with a tambourine around Lazarus and FPC, at least do the development yourself.
Поэтому я приложил использовать fpcupdeluxe .
Тогда сможешь использовать разные версии fpc и Lazarus в портативному состояние.
О packages можешь копировать из codetyphon .
Доверь меня, fpcupdeluxe это лучше способ работает спокоен
This is the general part of the forum, so replies only in English or at least with English translation included. Otherwise use the Russian forum, please.
You did not provide any information about what exactly you're doing. Just saying "RunError (211)" is like saying "My car is broken".
Google translate:
If Lazarus would provide more information when trying to run a program on Linux, I would provide more information. But Lazarus did not provide any information, only: "Error: RunError (211)".
What other information can I attach?
Google translate:
Initially, all information was provided !!! Except how the application was created without LCL.
The system is Linux (but apparently this is also on Windows, it did not initially pay attention)
FPC = 3.3.1 (on Windows with FPC = 3.2 the same problems)
IDE = CodeTyphon or GetLazarus, any other Lazarus !!! Tested on many versions.
development on Linux - Linux, on Windows - Windows (no difference 32 or 64)
the library used is ZenGL (you can also check version 3.12 from Andru) current version 3.20
compilation result = error (application is not created)
if to use FPC = 3.0.4
then the compilation result = no error, the application is created, you can run, you can debug!
I'll try to exclude plug-ins, unsubscribe if there is a result.
I was just hoping that you were already facing a similar problem.No, because I do not use ZenGL, but I am always prepared to run tests for it.
I was just hoping that you were already facing a similar problem.No, because I do not use ZenGL, but I am always prepared to run tests for it.
Note some of the finer details get lost in translation, as my wife (Lithuanian, fluent in Russian) explained.
If Lazarus would provide more information when trying to run a program on Linux, I would provide more information. But Lazarus did not provide any information, only: "Error: RunError (211)".https://www.freepascal.org/docs-html/user/userap4.html
What other information can I attach?
it does not compile on LinuxNot compile? or not run? or even it fails when run?
https://www.freepascal.org/docs-html/user/userap4.html
"Call to abstract method"
When using native methods and critical sections, "cthreads" should be set at the very beginning (very first) module. Otherwise, a conflict arises, accompanied by (RunError 211).
in FPC 3.0.4 - it was not necessary.
What platform?
but on *nix platforms it has always been necessary.
but on *nix platforms it has always been necessary.
No, in FPC <= 3.0.4, there was no need to use it at the beginning (in the launched module), it was enough to indicate in the module which one it is using.
For linux (and other Unixes), the C thread manager can be enabled by inserting the cthreads unit in the program’s unit clause. Without this, threading programs will give an error when started. It is imperative that the unit be inserted as early in the uses clause as possible.