2.0 2019-02-05
1.8.6 2018-08-01
1.8.4 2018-05-21
1.8.2 2018-03-01
1.8 2017-12-05
1.6.4 2017-03-01
1.6.2 2016-11-15
1.6 2016-02-18
1.4.4 2015-10-05
1.4.2 2015-07-14
1.4 2015-04-20
1.2.6 2014-10-12
1.2.4 2014-06-15
1.2.2 2014-04-21
1.2.0 2014-03-01
1.0.14 2013-11-15
1.0.12 2013-08-24
1.0.10 2013-03-26
1.0.8 2013-03-01
1.0.6 2013-02-01
1.0.4 2012-10-05
1.0.2 2012-09-29
1.0.0 2012-08-28 So we used to have a 2 to 3 month cycle before.
1.8.6 2018-08-01
The tags in mantis are created in advance. They always go one step further. This is so bug-targets can be set for future releases.1.8.6 2018-08-01
Was there actually a 1.8.6 release? I thought we only got up to 1.8.4 before 2.0?
I am aware that the ones at sourceforge are outdated.
I am trying to find out how my chm viewer can be made to show the version (I seem to only have the file date)
lcl and lazutils were rebuild before the release was made https://svn.freepascal.org/svn/lazarus/binaries
And the installer seems to have the same version of files.
<p>For example, if the LCL version is 1.2.4.6, lcl_fullversion will be 1020406</p>I downloaded the separate zip file with Doc. It is in fact at version '1.8.5.0'. So that's good. But not having them in the installer isn't.And that number appears at text, in the same location as the 1.2.4.6?
The version example in the help text is not automatically updated.
From the file docs/xml/lcl/lclversion.xml (that is one of the source file from which the help is build)Code: [Select]<p>For example, if the LCL version is 1.2.4.6, lcl_fullversion will be 1020406</p>
That is the text that goes into the help. Even for trunk. It is still correct. It is an example, so it does not have to be the current version.
The 1.0.12 is in the same file, as is 0.9.25QuoteI downloaded the separate zip file with Doc. It is in fact at version '1.8.5.0'. So that's good. But not having them in the installer isn't.And that number appears at text, in the same location as the 1.2.4.6?
lcl_version
LCL version string
Declaration
Source position: lclversion.pas line 46
const lcl_version = laz_version;
Description
Contains the LCL version string, e.g. 1.0.12.
lcl_version
LCL version string
Declaration
Source position: lclversion.pas line 40
const lcl_version = '1.8.5.0';
Description
Contains the LCL version string, e.g. 1.0.12.
String type have memory limitation (its internal length variable is 4 bytes wide) even on 64-bit systems.
I would like to see this HighDPI scaling bug of the Lazarus IDE fixed ..This is not related to Lazarus 2.0.2 release but I answer here anyway ...
0035231: High DPI - value "DesignTimePPI" is different between *.lfm file and Object Inspector
related with
0034841: AnchorDocking: Loading layouts does not consider HighDPI scaling
String type have memory limitation (its internal length variable is 4 bytes wide) even on 64-bit systems.
This is not related to Lazarus 2.0.2 release but I answer here anyway ...I will test this tonight. And then report.
Did you test the patch uploaded by Ondrej? Does it help? If it does, can you improve it so a project would not get saved always?
I made 7 bug reports regarding the Cocoa IDE in December. Some were major usability issues, like contextual menus not working, the inability to delete a control once placed on a form, etc. Six are still listed as "new". I'm hoping these can be addressed before the release.If you provide patches now, it may be possible to merge them.
If you provide patches now, it may be possible to merge them.
But hurry up, changes should also be tested before they go into a release.
Quick reminder:
...
And when that team member has spare free time (between his job and personal live) he/she will work on it.
...
The person may be away for some weeks, or busy otherwise.
...
This announcement/thread is not going to change this dynamics.
...
This is not related to Lazarus 2.0.2 release but I answer here anyway ...I will test this tonight. And then report.
Did you test the patch uploaded by Ondrej? Does it help?
If it does, can you improve it so a project would not get saved always?
This is more difficult. I can try next week.Yes they are! :-)
But sourcefilemanager.pas and related units are a lot of code to read and understand ..
I merged 60906.Thanks!
Regarding the docs thing people had been talking about earlier, is there interest in having them built more often? I do it myself quite often (on Windows, actually, with TexLive and Git Bash) and don't find it very difficult or time consuming, so I'd be happy to volunteer in that regard.
I am very interested! At least the chms.
I am very interested! At least the chms.
I did a fresh build of the CHMs and made a zip with the same files the release one comes with:
https://drive.google.com/open?id=1hbCR6zhPsfVLBC7K--Y0IFUrbW4YQH11 (https://drive.google.com/open?id=1hbCR6zhPsfVLBC7K--Y0IFUrbW4YQH11)
Note that the above is based on trunk everything (i.e. the FPC sources and Lazarus sources scanned for the docs were themselves the latest SVN revisions, not just the doc content files.)
PATH=C:\lazarus-trunk_fpc304\fpc\3.0.4\bin\i386-win32\;%PATH%
build_lcl_docs.exe --outfmt chm --fpcdocs ../chmI did a fresh build of the CHMs and made a zip with the same files the release one comes with:
Lots of thanks, Akira.
I create Lazarus chm files by the script "build_chm" in folder "docs/html" - I'm on Windows, therefore, I use "build_chm.bat". These things must be done frist for this to work:
- Load "build_lcl_docs.lpi" into Lazarus and compile it.
- Modify the line "PATH=..." of the script to point the PATH variable to the folder which contains fpdoc.exe (this should be the same as fpc.exe).
- Add "--fpcdocs ../chm" to the "build_lcl_docs" command line so that the created chm files are copied to the right folder automatically. Otherwise the chm files (and xct crossreference files) will appear in the folder of the script, i.e. in "docs/html" and must be copied manually.
This is the script, which is working for me:Code: [Select]PATH=C:\lazarus-trunk_fpc304\fpc\3.0.4\bin\i386-win32\;%PATH%
build_lcl_docs.exe --outfmt chm --fpcdocs ../chm
Note that the script aborts when the xml files contain an error. The xml files before r60922, for example, contained an xml error in lazunicode.xml (line 245, the "<>" in "Length(fCurrent)<>aCount." had to be replaced by "<>")
Note also that build_lcl_docs does not add "private" docs to the chm. (There is an option for fpdoc to include the "private" section, but I did not find a way how to invoke this in build_lcl).
Building the Lazarus help takes a few minutes, therefore, be patient.
This is the script, which is working for me:Code: [Select]PATH=C:\lazarus-trunk_fpc304\fpc\3.0.4\bin\i386-win32\;%PATH%
build_lcl_docs.exe --outfmt chm --fpcdocs ../chm
Note also that build_lcl_docs does not add "private" docs to the chm. (There is an option for fpdoc to include the "private" section, but I did not find a way how to invoke this in build_lcl).
Building the Lazarus help takes a few minutes, therefore, be patient.
Did you test the patch uploaded by Ondrej? Does it help? If it does, can you improve it so a project would not get saved always?I don't know why Your project gets saved always, with this patch.
Would you mind sharing the steps you used to generate the chms? I've been stumbling around trying to do the same with the updated fpdoc xml files. No luck so far...
mkdir ./tmp && cp ./fpdoc.cst ./fpdoc.css && make all FPCDIR="../fpcsrc" FPCSRCDIR="../fpcsrc" HTMLFMT=chm CSSFILE="./fpdoc.css" && ./fixdocs.sh-Hope that it works!Would you mind sharing the steps you used to generate the chms? I've been stumbling around trying to do the same with the updated fpdoc xml files. No luck so far...
To put it as simply as possible (again, I'm on Windows):
-Install TexLive
-Ensure that the main TexLive bin directory (with like a million DLLs and executables) is in your path
-Ensure that the FPC bin directory is also in your path
-Install Git for Windows
-From an elevated git-bash.exe command prompt, change directories to where you've checked out the fpcdocs SVN
-Assuming the "fpcdocs" folder is side-by-side with your "fpcsrc" folder, do:Code: [Select]mkdir ./tmp && cp ./fpdoc.cst ./fpdoc.css && make all FPCDIR="../fpcsrc" FPCSRCDIR="../fpcsrc" HTMLFMT=chm CSSFILE="./fpdoc.css" && ./fixdocs.sh-Hope that it works!
I might be forgetting something, but that's the gist of it. There might also have been a couple of FPC sources I actually had to modify in some way and rebuild beforehand to make them not-just-for-Linux, but I can't remember at the moment. I'll check tonight.
Not going near anything that involves LateX. ;)
According the help screen in build_lcl_docs.lpr, you can use --arg to pass arguments to fpdoc. I think it has to be passed to build_lcl_docs.lpr using the --arg "show-private=true" switch. Not sure about the formatting though until I try it.Yes, any idea would be appreciated, no matter how I write it I always get "Ignoring unknown option..."
It seems like it would be a lot simpler to just use an fpdoc project file.I don't know. Yes with fpdoc you have better control of the parameters, but you must write every parameter in an xml project file which otherwise is correctly set by build_lcl_docs. Well, at least now I have a working fpdoc project for TAChart which I uploaded today (folder (lazarus trunk)/components/tachart/fpdpc/chm).
Thanks for that. But I was mainly interested in LCL and LazUtils - which you covered earlier.
LCL and LazUtils online (SourceForge) are at version 0.9.3.
LCL and LazUtils online (SourceForge) are at version 0.9.3.
That has been remedied.
FPC => 3.0.4
Lazarus => trunk
cocoa: shrink focus rect by one pixel from far sides
cocoa: update the focused item status of a table raw. Only show it as focused, if it's selected and the control itself is focused. #32051
cocoa: adding detection if a combobox is showing a popup window
cocoa: adding track area of readonly items, so they can be refreshed automatically as mouse moves around
cocoa: do not call DrawItem for readonly dropdown if no item is not selected. #21791
cocoa: support for using DrawItem when drawing a read-only combobox. #21791
Not going near anything that involves LateX. ;)
Yeah, LateX is for masochist (pun intended :D ) *
* Not intended to be taken seriously! :)
Maybe something in your local config... It rebuilds fine for me.
Btw, are there really no backslashes in the path? Or did that happen copy and paste?
Btw, are there really no backslashes in the path? Or did that happen copy and paste?This is not a copy / paste error. There are really no separators.
What if you start with an empty config?Thanks for the advice. But I tried to delete all settings (AppData\Local\lazarus). Made a clean install. Does not help.
Please report as a bug.OK. I reported a bug. The number is 0035384.
Could it be, that you have another "make.exe" in your path?
C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG "@C:\Users\User\AppData\Local\lazarus\idemake.cfg" -dx86_64 lazarus.pp@C:UsersUserAppDataLocallazarusidemake.cfg -dx86_64Fpc must have seen the @, because that makes it tread this as a file to be read.Is your user-account is called "User"?Yes, user-account called "User".
(Does 2.0.0 still work/rebuild on your PC?)
Can you open a cmd.exe
And then run the above command from there?
If it fails at -va
c:\lazarus\ide>C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG "@C:\Users\User\AppData\Local\lazarus\idemake.cfg" -dx86_64 lazarus.pp
Hint: (11030) Start of reading config file C:\lazarus\fpc\3.0.4\bin\x86_64-win64\fpc.cfg
Hint: (11031) End of reading config file C:\lazarus\fpc\3.0.4\bin\x86_64-win64\fpc.cfg
Hint: (11030) Start of reading config file C:\Users\User\AppData\Local\lazarus\idemake.cfg
Hint: (11031) End of reading config file C:\Users\User\AppData\Local\lazarus\idemake.cfg
Free Pascal Compiler version 3.0.4 [2019/04/13] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
(1002) Target OS: Win64 for x64
(3104) Compiling lazarus.pp
c:\lazarus\ide\lazarus.pp(115,20) Warning: (5044) Symbol "MainFormOnTaskBar" is not portable
(9022) Compiling resource C:\lazarus\units\x86_64-win64\win32\lazarus.obj
(9015) Linking ..\lazarus.exe
(1008) 261 lines compiled, 8.0 sec, 14273984 bytes code, 875044 bytes data
(1021) 1 warning(s) issued
(1022) 4 hint(s) issued
Run: make.exe -version
I get: GNU Make 3.80
for 2.0.2 and 2.0.0
I can’t completely delete all the "path" to make. This is likely to make inoperable many programs (Altera Quartus Prime, Atollic TrueStudio, etc).
But in version 2.0.0 and below this bug was missing. Therefore, I believe that this can be considered an error in version 2.0.2, and not an error in the system.
Probably, I found where the cause of the bug.
In the environment variable "Path" I have the values "c:\MinGW\MSYS\1.0\bin" and "C:\msys64\usr\bin".
If "c:\MinGW\MSYS\1.0\bin" is above "C:\msys64\usr\bin", then the bug manifests, otherwise it does not.
But in version 2.0.0 and below this bug was missing. Therefore, I believe that this can be considered an error in version 2.0.2, and not an error in the system.
Are you saying that you installed 2.0 after you had already installed both of these versions of MinGW?Yes it is.
Were your earlier versions of Lazarus also 64-bit, or rather 32-bit?All previous versions on this system were also x64.
In my case, it wasn't make.exe. It was something else in the Cygwin environment. Removing cygwin from my path allowed it to build successfully. And no, it was not make.exe- there wasn't one in Cygwin. I haven't pinpointed the exact cause yet. But removing Cygwin was enough.It seems that on my system the cause was not make.exe. Just like you.
The use of "/" instead of the "\" is also surprising. But this does not cause an error.The majority of platforms supported by FPC use / as path separator. Furthermore it is transparent: both / and \ can be used.
You should not be surprised at all :DI considered that the "/" is used only for Unix-like systems. Windows usually uses a backslash. But it seems that the "/" also works well for Windows.
ide/buildlazdialog.pas | 13 +++++++++++--
diff --git a/ide/buildlazdialog.pas b/ide/buildlazdialog.pas
index 3b560fb937..5c3e562fec 100644
--- a/ide/buildlazdialog.pas
+++ b/ide/buildlazdialog.pas
@@ -58,7 +58,7 @@ uses
CodeToolManager, DefineTemplates,
// IDEIntf
LazIDEIntf, IDEMsgIntf, IDEHelpIntf, IDEImagesIntf, IDEWindowIntf, IDEDialogs,
- PackageIntf, IDEExternToolIntf,
+ PackageIntf, IDEExternToolIntf, BaseIDEIntf,
// IDE
LazarusIDEStrConsts, TransferMacros, LazConf, DialogProcs,
MainBar, EnvironmentOpts,
@@ -419,6 +419,9 @@ var
IdeBuildMode: TIdeBuildMode;
s: String;
DefaultTargetFilename: String;
+ {$IFDEF WINDOWS}
+ env: TStringList;
+ {$ENDIF}
begin
// Get target files and directories.
Result:=mrCancel;
@@ -437,8 +440,14 @@ begin
EnvironmentOverrides.Values['LCL_PLATFORM']:=LCLPlatformDirNames[Profile.TargetPlatform];
EnvironmentOverrides.Values['LANG']:= 'en_US';
s:=EnvironmentOptions.GetParsedCompilerFilename;
- if s<>'' then
+ if s<>'' then begin
EnvironmentOverrides.Values['PP']:=s;
+ {$IFDEF WINDOWS}
+ env := EnvironmentAsStringList;
+ EnvironmentOverrides.Values['PATH']:= ExtractFileDir(s) + ';' + env.Values['PATH'];
+ env.Free;
+ {$ENDIF}
+ end;
Executable:=EnvironmentOptions.GetParsedMakeFilename;
if (Executable<>'') and (not FileExistsUTF8(Executable)) then
Could either of you test the following patch (with your original environment)?Unfortunately, your patch did not fix the bug. I got the same error: "Fatal: Unable to open file C:UsersUserAppDataLocallazarusidemake.cfg -dx86_64".
c:\MinGW\MSYS\1.0\bi\sh.exe -c C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG \@C:\Users\User\AppData\Local\lazarus\idemake.cfg\ -dx86_64 lazarus.pp
Version 2.0.0 does not use sh.exe at all. Any idea why version 2.0.2 uses sh.exe? And why do double quotes become backslashes?So I am opting out. (unless make can be given an argument to force it to the internal shell)Anyway, thanks for your help. Removing a shell from a path is in most cases an acceptable solution. I think this solution can be advised to those who face a similar problem.