Lazarus
Announcements => Lazarus => Topic started by: Martin_fr on July 25, 2019, 12:17:38 pm
-
The Lazarus team is glad to announce that:
The release of Lazarus 2.0.4
has been scheduled for the week starting
5th August 2019
This release will be built with FPC 3.0.4.
The previous release Lazarus 2.0.2 was built with FPC 3.0.4 as well.
Here is the list of fixes for Lazarus 2.0.2 (since 2.0.0):
http://wiki.freepascal.org/Lazarus_2.0_fixes_branch
We would invite everyone to provide their feedback to help us improve
this upcoming release. Please let as know in particular:
- Any fixes made to trunk, that you believe should still be merged to
the fixes branch (fixes that are not listed on the above wiki page)
- Any regressions that happened in fixes branch since the last release
- Other urgent matters, you believe we should know before the release.
Please attempt to provide your feedback by: 1st August 2019
More info on our release process can be found at (work in progress):
http://wiki.lazarus.freepascal.org/Lazarus_release_engineering
Information about the previous release:
http://wiki.lazarus.freepascal.org/Lazarus_2.0.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.0.4
The intended minimum requirements for the release will be:
Windows:
2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.
FreeBSD/Linux:
gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.
Mac OS X:
10.5 to 10.12; Carbon (32bit), Cocoa (64bit, beta), qt and qt5
(32 or 64bit).
Just a general notice.
If you are on our mailinglist, please consider replying to the announcement on the mail list.
Messages left on the forum, will have to be forwarded, as not all team members are on the forum.
-
We would invite everyone to provide their feedback to help us improve
this upcoming release. Please let as know in particular:
......
- Other urgent matters, you believe we should know before the release.
https://bugs.freepascal.org/view.php?id=35723
This bug prevents the SystemTrayIcon from working on a Debian or Ubuntu based box that has been upgraded from an older version of the OS. Its Linux only, does not (alone) solve the problem for RedHat systems but does no further harm.
Davo
-
Issue 35696 (https://bugs.freepascal.org/view.php?id=35696), 35452 (https://bugs.freepascal.org/view.php?id=35452), 35465 (https://bugs.freepascal.org/view.php?id=35465), 35467 (https://bugs.freepascal.org/view.php?id=35467), 35466 (https://bugs.freepascal.org/view.php?id=35466), 35451 (https://bugs.freepascal.org/view.php?id=35451), 35173 (https://bugs.freepascal.org/view.php?id=35173), 34415 (https://bugs.freepascal.org/view.php?id=34415), 35512 (https://bugs.freepascal.org/view.php?id=35512), 34759 (https://bugs.freepascal.org/view.php?id=34759), 35694 (https://bugs.freepascal.org/view.php?id=35694)
-
https://bugs.freepascal.org/view.php?id=35723
This bug prevents the SystemTrayIcon from working on a Debian or Ubuntu based box that has been upgraded from an older version of the OS. Its Linux only, does not (alone) solve the problem for RedHat systems but does no further harm.
I am not the gtk maintainer, so the final answer may differ. But it seems to add new functionality, which means it is probably not making fixes branch at all.
-
Just a general notice.
If you are on our mailinglist, please consider replying to the announcement on the mail list.
Messages left on the forum, will have to be forwarded, as not all team members are on the forum.
-
https://bugs.freepascal.org/view.php?id=35723
This bug prevents the SystemTrayIcon from working on a Debian or Ubuntu based box that has been upgraded from an older version of the OS. Its Linux only, does not (alone) solve the problem for RedHat systems but does no further harm.
I am not the gtk maintainer, so the final answer may differ. But it seems to add new functionality, which means it is probably not making fixes branch at all.
Yes, it could be a moot point as to new functionality or not. I'd probably argue its more about preferring an existing functionality over another, also existing functionality. From memory, simplifies the code a touch even !
(no, I'm not on the developer mailing list and probably don't belong there :D )
Thanks Martin
Davo
-
It helps to refer bug numbers with either the subject or the person to whom it is assigned. None of us is going to look at a bugnumber and remember: "right I committed that". It is usually the committer who has to decide if it can get merged.
Haven't gone through all of them, but
0035694: Micropatch of LazMethodList unit
Is basic refactoring (the resulting exe should be roughly the same). So while in this case it could be merged (as it is unlikely to break anything), it does not harm if it is not merged (as it does not fix anything (except read ability).
Similar
0034415: Optimize raise exception in WinControls.inc
Some issues are not yet assigned. Some of them have patches. While I agree that patches are often waiting way to long before at least getting feedback, this is not a topic that we gonna be able to sort out as part of the release management.
I have forwarded the following for the attention of their committers (though I am not sure if all of them are candidates for a merge):
0035696: LazUTF8.SysToUTF8(TFormatSettings) micropatch
0035451: Function DefaultInputDialog creates and free the form without a "try finally" block
0035466: TWin32WSCustomPage.DestroyHandle micropatch
035467: TWindowProcHelper.CalcClipRgn micropatch
0035452: [Patch]Added support for the ofForceShowHidden flag in dialog options for Windows
I am not sure if any of the open/unassigned issue is a regression.
-
(no, I'm not on the developer mailing list and probably don't belong there :D )
I was referring to the public mail list: https://lists.lazarus-ide.org/listinfo/lazarus
This pre-release, last minute check for issues is generally tricky.
We do not want to miss an important fix: new regression, or general bug-fix with low risk of breaking other stuff.
The latter only refers to issues that already have a committed fix. Otherwise we will have a huge list of open issues (that are all important) before each release. And the fact that we are doing a release does not change the manpower we have available. So we unfortunately will not be able to fix every issue just before a release.
Off topic. If replies/discussion are wanted, please open a new thread
Also if you see an issue got fixed and you would like it merged, you can check https://wiki.lazarus.freepascal.org/Lazarus_2.0_fixes_branch
And if it is not there, then ask (preferable on the mail list). You may mention the name of the committer in the subject, along with the issue description, and the mention of it being a fixes-merge request.
Of course it is then up to that committer to decide...
As for getting an assignee for an yet unassigned bug, is more tricky and does not have a general rule. Some parts of the code have a single defined maintainer. They are usually picked up by that person.
The rest has often been worked on by many, or by someone who is no longer available. Or is old code that no one remembers... In each case it means, whoever picks up the issue will need to read up an the existing code first. And that means such issues often wait longer before someone eventually picks them up.
-
Excellent, when you activate the Contrains to use it at the Tfield level in the data module.
This would decrease the code in the developments.
Thanks
-
https://bugs.freepascal.org/view.php?id=35723
This bug prevents the SystemTrayIcon from working on a Debian or Ubuntu based box that has been upgraded from an older version of the OS. Its Linux only, does not (alone) solve the problem for RedHat systems but does no further harm.
I am not the gtk maintainer, so the final answer may differ. But it seems to add new functionality, which means it is probably not making fixes branch at all.
I applied the patch and added it to be merged. It fixes a bug in Ubuntu + its relatives but does not break other Linux systems.
I planned to apply this patch already earlier when I saw it but then I forgot.
Only clear bug fixes should be merged for 2.0.4. There is no reason to merge some minor refactoring commits.
-
Excellent, when you activate the Contrains to use it at the Tfield level in the data module.
I am not sure what this refers to exactly. But new feature requests need to be made via the bugtracker https://bugs.freepascal.org/
If not certain you can open a new thread here on the forum and discuss it first.
-
Since version 2.0, I get a warning about a missing output directory each time when compiling a project. I have already reported this multiple times ("The output directory "D:\" is missing." on each run if the project is saved to disk root (regression) (https://bugs.freepascal.org/view.php?id=34545),
inappropriate "create output directory" message on every compile (https://bugs.freepascal.org/view.php?id=34515), and Release 2.0.0 (https://forum.lazarus.freepascal.org/index.php/topic,44161.msg310582.html#msg310582)).
Steps to reproduce:
- New project, empty form
- Save both to d:\temp
- In project options, set target filename to D:\project1.exe
- Compile -> Warning about missing output directory
I haven't read anything in the fixes list for 2.0 branch, so I assume this annoyance is still present. I would appreciate if this issue could be solved in 2.0.4.
The note about it being fixed with r59951 is wrong. The issue still occurs in the 2.0.2 release.
-
Since version 2.0, I get a warning about a missing output directory each time when compiling a project. I have already reported this multiple times ("The output directory "D:\" is missing." on each run if the project is saved to disk root (regression) (https://bugs.freepascal.org/view.php?id=34545),
Confirmed, re-opend, and pinged the developer in question.
I can see how it went wrong.
Your issue https://bugs.freepascal.org/view.php?id=34515
was deemed a duplicate (retrospective it is NOT a duplicate).
Your issue however misses the clarity of your post. In your issue you write:
I have set the default output directory (target file name) to "Z:\" (i.e. the root of a drive)
However as you now clarify
In project options, set target filename to D:\project1.exe
It is a file in that directory. (Also you clarify the meaning of "output directory"
Without that clarification, there is no (easy) way to distinguish your issue from the "duplicate".
The "none dup" other issue is indeed fixed. And yours was closed by that time.
Afaik you cannot re-open an issue that someone else reported. Since you still had an issue, you could have (after the other issue was resolved):
- reopened your issue (ideally with the updated steps)
- opened a new issue.
- tried to get attention (which you have now done).
Ideally on the mail list, since not all developers are on the forum (this particular thread is monitored and I forward relevant entries, but other threads will not have that forwarding).
-
Lazarus fixed branch currently cannot be compiled since rev. 61639.
Bug 35904. (https://bugs.freepascal.org/view.php?id=35904)
-
Hello,
first of all thank you very much to all those who work behind this magnificent program (without, me feeling lost :)).
I found only a message a little annoying (in my case I have a project with many forms, so a message for each form ..).
This message appears only in "Design Time" when I view the form (it does not happen if the form had already been opened and not yet closed).
I attached a small test to display this problem.
The message already shows the relative information (but I would like to avoid using packages to register the form and actually I didn't try anything about it) but I was wondering if there was a way to disable it through some option on Lazarus or better still avoid it from code (preserving the basic structure as much as possible).
Configuration:
Windows 10 64bit
Lazarus 2.0.2 FPC 3.0.4 64bit
Thanks, any help is welcome
-
To make components palettes in outside libraries - .dll .so
In this case can to easy add/remove palette, less to recompile all Lazarus executable. And make possibly to add more palettes in 32bit lazarus. This to save in some .cfg file, which to manipulate by Package manager.
Thanks
-
Lazarus fixed branch currently cannot be compiled since rev. 61639.
Bug 35904. (https://bugs.freepascal.org/view.php?id=35904)
This bug is fixed with svn revision 61642.
-
https://bugs.freepascal.org/view.php?id=35782
-
In some previous version package ToDoListLaz.lpk was not installed by default. Please ensure that in new version averything will be OK.
P.S. Discussion: https://forum.lazarus.freepascal.org/index.php/topic,45462.0.html
-
I find the release cycle of Lazarus a bit optimistic. I'd rather see a significant slow down.
-
In some previous version package ToDoListLaz.lpk was not installed by default. Please ensure that in new version averything will be OK.
P.S. Discussion: https://forum.lazarus.freepascal.org/index.php/topic,45462.0.html
I know that this package was included in previous versions. But I never used it. It would be interesting to see whether other users did the same. It is not essential for the IDE, therefore I think it is a good idea to removed it from the list of the packages installed by default. The IDE is getting fatter from version to version...
-
pls. let Lazarus lean (or make it leaner).
-
I know that this package was included in previous versions. But I never used it. It would be interesting to see whether other users did the same. It is not essential for the IDE, therefore I think it is a good idea to removed it from the list of the packages installed by default. The IDE is getting fatter from version to version...
I agree. I used to remove it because I never used it. ( I decorate my code with user defined notes, warnings and errors)
But keep it in the repository for fpcdeluxe.
-
I wanted to ask to make it possible to install chm-help via OPM. Or include this feature as an additional option in the standard installer for Windows.
-
I wanted to ask to make it possible to install chm-help via OPM. Or include this feature as an additional option in the standard installer for Windows.
It *is* included. I think it is the last page of the installer, the one with the many checkboxes... One of them says: "Install CHM help"
-
I wanted to ask to make it possible to install chm-help via OPM. Or include this feature as an additional option in the standard installer for Windows.
It *is* included. I think it is the last page of the installer, the one with the many checkboxes... One of them says: "Install CHM help"
If you have a PC (Windowl) on which you never ever installed Lazarus, then IIRC it is pre-selected.
If you change it, the installer then should remember this for your next install. (again IIRC).
The installer stores this in the registry. Lazarus itself does not store stuff in the registry, but the installer does.
Not sure what (if anything) is stored for a 2ndary install.
You can find the inno build file in tools/install/win
If you chose to install the help, it will be in docs/chm
The chm viewer lhelp.exe should be in components\chmhelp\lhelp
-
One of them says: "Install CHM help"
You're right. I forgot about this option because I mainly use Lazarus trunk and compiler trunk
If you chose to install the help, it will be in docs/chm
The chm viewer lhelp.exe should be in components\chmhelp\lhelp
Thank you for reminding.
Does the community have plans to make it possible to install help files via OPM? The fact is that with the "manual" assembly of Lazarus, the help files have to be downloaded from third-party resources and manually added to the ../docs/chm folder.
-
I think OPM can only work with "packages", not with package-less files.
But I think what's more important is that the IDE can handle only the chm files provided. It is not possible to extend the IDE such that it reckognizes other CHM files coming with non-LCL packages. TAChart and fprspreadsheet are packages which are maintained by mayself have a chm file (or a chm file can be created), but there is no way to register these chm files for the IDE so that pressing F1 on the "TChart" identifier, for example, opens the related help page.
Martin, can you comment on this? Maybe I am missing something.
-
Big thanks to the developers! (Otherwise I use fixes 2.0 branch)
So, I know, (Sorokin) RegExpr is a part of the fpc, but present time slightly complicated to use it, as I wrote here (https://forum.lazarus.freepascal.org/index.php/topic,45767.msg327475.html#msg327475) the latest trunk version from the developer site works with UTF8 without any magic.
So the uregexpr solution in fpc 3.2.0 is unnecessary, and complicate to use it, because need utf8<->unicode conversion to use.
-
, the help files have to be downloaded from third-party resources
What third party resources? They are in Lazarus Sourceforge (here: https://sourceforge.net/projects/lazarus/files/Lazarus%20Documentation/Lazarus%202.0.2/ (https://sourceforge.net/projects/lazarus/files/Lazarus%20Documentation/Lazarus%202.0.2/)).
-
But I think what's more important is that the IDE can handle only the chm files provided. It is not possible to extend the IDE such that it reckognizes other CHM files coming with non-LCL packages. TAChart and fprspreadsheet are packages which are maintained by mayself have a chm file (or a chm file can be created), but there is no way to register these chm files for the IDE so that pressing F1 on the "TChart" identifier, for example, opens the related help page.
Martin, can you comment on this? Maybe I am missing something.
I'm also very interested in this, because TDateTimePicker, although installed by default, is outside the LCL package.
Perhaps I'm also missing something, but I don't think that it can be integrated in context-sensitive help system.
-
What third party resources? They are in Lazarus Sourceforge (here: https://sourceforge.net/projects/lazarus/files/Lazarus%20Documentation/Lazarus%202.0.2/ (https://sourceforge.net/projects/lazarus/files/Lazarus%20Documentation/Lazarus%202.0.2/)).
I meant the following: when installing a Lazarus by a regular installer, the help files are already inside it. If you compile Lazarus from the source code, the help files must be downloaded additionally.
I propose to put already compiled actual help files into the repository, from where OPM downloads package files. Just like package files, OPM can unpack them into the ../docs/chm folder, only without installation, as happens with packages.
Can this be done?
-
I meant the following: when installing a Lazarus by a regular installer, the help files are already inside it. If you compile Lazarus from the source code, the help files must be downloaded additionally.
fpcupdeluxe/setup+/include help
-
I meant the following: when installing a Lazarus by a regular installer, the help files are already inside it. If you compile Lazarus from the source code, the help files must be downloaded additionally.
I would have to check, but I do assume that our official source packages contain the sources for building the chm (fpcoc xml files). If you do an svn checkout those sources are included.
So if you build yourself, then you have the option to build the chm too. And that way you will get the most up to date help.
Of course the above is for the lcl and lazarus help. Fpc (rtl, fcl) help files would be part of how you install fpc. Or have -as you indicated - to be downloaded separately.
-
I meant the following: when installing a Lazarus by a regular installer, the help files are already inside it. If you compile Lazarus from the source code, the help files must be downloaded additionally.
I would have to check, but I do assume that our official source packages contain the sources for building the chm (fpcoc xml files). If you do an svn checkout those sources are included.
So if you build yourself, then you have the option to build the chm too. And that way you will get the most up to date help.
That's right, I did it several times: Compile "build_lcl_docs.lpi" (in folder (lazarus)/docs/html and on Windows adjust the path to the fpc binaries in "build_chm.bat" (I create a copy with the correct path to leave the original alone). Then run build_chm.bat on Windows, or build_chm.sh on Linux. Copy the created *.chm files into the (lazarus)/docs/chm folder.
-
@Martin_fr
@wp
Guys, forgive me my obsession. :-[
I know about the ability to manually compile help files from source code. Just as I know about the ability to compile and install a component from a package manually. But, if OPM is used as a "lazy" package installer, then it would not be a bad idea to teach it to compile and install help files from source code.
I do not insist on it. I just suggest considering this idea.
And I sincerely thank the Lazarus team for their great work and wonderful IDE :)
-
In any case, it is a topic for a diff thread.
-
In any case, it is a topic for a diff thread.
ok, I will try to raise this topic in the mailing list when I have a little more free time. Thanks for your time
-
ok, I will try to raise this topic in the mailing list when I have a little more free time. Thanks for your time
Unless you want to jump through hoops the documentation is easiest to compile on *nixes.
I never succeeded in compiling the documentation on Windows for example. And I am no Noob.
Simply gave up and use Linux: works. Then copy to Windows. TeX support on Windows is still lacking I believe.
-
Unless you want to jump through hoops the documentation is easiest to compile on *nixes.
I never succeeded in compiling the documentation on Windows for example. And I am no Noob.
Simply gave up and use Linux: works. Then copy to Windows. TeX support on Windows is still lacking I believe.
This is very strange. I compile fpc and Lazarus, as well as help files mainly on windows. And I never met any problems. But I started this conversation in the hope that it is quite easy to implement. I guess I was wrong. I'm sorry.
-
....
Here is the list of fixes for Lazarus 2.0.2 (since 2.0.0):
http://wiki.freepascal.org/Lazarus_2.0_fixes_branch
....
Wow, thats 174 fixes to Cocoa alone. Someone has been very busy !
Thanks folks, thanks indeed.
My Mac is 2000Km away, I cannot test it. But its it time to consider dropping the 'beta' status of Cocoa ?
Davo
-
This is very strange. I compile fpc and Lazarus, as well as help files mainly on windows. And I never met any problems. But I started this conversation in the hope that it is quite easy to implement. I guess I was wrong. I'm sorry.
You misunderstood: the help files for Lazarus is not a problem at all, but the REAL documentation of FreePascal itself (user's guide, programmer's guide, reference manual etc) https://freepascal.org/docs.html for the 3.0.4 version.
These are type set in TeX and Windows lacks a proper tool chain for that. (None of what you come up with will work)
I am not interested in help files (short-cut and incomplete documentation), I am interested in the books, that is what they are and the only proper and guiding reference!
Under Linux or macOS/OSX, it is quite straight forward to build them into a pdf or html, but on Windows it is neigh impossible. Not for beginners or Windows centric programmers, though.
A pity so many people confuse the complete real documentation with help files.
And for trunk you need to build those books yourself. Period.
Take note of that.
Thaddy
P.s: the books try to be complete and authoritative. the help files just pop-up - can be a blank page or just the subject - when you press F1 or a combination with F1. F1 does not have a particular helpful experience in my case... The Lazarus help sucks and I am not going to help to improve it. OTOH if something is not clear in the real FPC manuals I take the time to report it and suggest improvements through a bug report.
In its current state Lazarus help is beyond help. If I want to know more, I just grep -nHIiwrF the sources. Works way more informative.
(Lazarus help engineers: "Hey, look! we made F1 and crtl-F1 and even shift-F1 work! We Have Created Help" :o :'( :'( )
-
I am not interested in help files (short-cut and incomplete documentation), I am interested in the books, that is what they are and the only proper and guiding reference!
The books are fantastic, but only for fpc. When people say, there is not enough documentation, then they mean for Lazarus, not for FPC.
The Lazarus help sucks and I am not going to help to improve it.
:(
If I want to know more, I just grep -nHIiwrF the sources. Works way more informative.
(Lazarus help engineers: "Hey, look! we made F1 and crtl-F1 and even shift-F1 work! We Have Created Help"
The help files helped me a lot in understanding the class structures, the descriptions are short, but without them...
I don't come from Delphi so the LCL-basics I all had to learn in the Lazarus environment. If the help files weren't available at that time, I probably wouldn't (=couldn't) have started with Freepascal/Lazarus. I didn't use the help via F1, though. But opened the chm-files manually (Better search support than in LHelp).
So my very thanks to the Lazarus help engineers!
-
These are type set in TeX and Windows lacks a proper tool chain for that. (None of what you come up with will work)
Yes, now I understand what you were talking about ... I will not argue, I know little about the functioning of this mechanism for publishing documents.
I am not interested in help files (short-cut and incomplete documentation), I am interested in the books, that is what they are and the only proper and guiding reference!
I came from Delphi, there is nothing unusual for me to use Lazarus. Therefore, I am more interested in help files with some new features that are not available in Delphi.
I agree with your arguments that my wishes, which I wrote about above, cannot be technically implemented. And I thank you for the clarification.