The Lazarus team is glad to announce the first release candidate of Lazarus 1.6.

This release was built with FPC 3.0.0.
The previous release Lazarus 1.4.4 was built with FPC 2.6.4.

Here is the list of fixes for Lazarus 1.6:
http://wiki.freepascal.org/Lazarus_1.6_fixes_branch

Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_1.6.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.0.0

The release is available for download on SourceForge: http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 1.6RC1" directory.

Minimum requirements:

Windows:
98, 2k, XP, Vista, 7, 32 or 64bit.
Win98 and WinNT IDE needs FPC 2.6.4 and building with flag -dWIN9XPLATFORM.

FreeBSD/Linux:
gtk 2.8 or qt4.5, 32 or 64bit.

Mac OS X:
10.5 to 10.11, LCL only 32bit, non LCL apps can be 64bit.

The svn tag is
http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_6_RC1

== Why should everybody (including you) test the release candidate? ==

In the past weeks the Lazarus team has stabilized the 1.6 fixes branch. The resulting 1.6RC1 is now stable enough to be used by any one for test purposes.

However many of the fixes and new features that where committed since the release of 1.4 required changes to the code of existing features too. While we have tested those ourself, there may still be problems that only occur with very specific configurations or one project in a million.

Yes, it may be that you are the only person with a project, that will not work in the new IDE. So if you do not test, we can not fix it.

Please do not wait for the final release, in order to test. It may be too late. Once the release is out we will have to be more selective about which fixes can be merged for further 1.6.x releases. So it may be, that we can not merge the fix you require. And then you will miss out on all the new features.

== How to test ==

Download and install the 1.6RC1.
- On Windows you can install as a 2ndary install, that will not affect your current install: http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus
- On other platforms, if you install to a new location you need to use --primary-config-path

In either case you should make backups. (including your primary config)

Open your project in the current Lazarus (1.4.x), and use "Publish Project" from the project menu. This creates a clean copy of your project.

You can then open that copy in the RC1. Please test:
- If you can edit forms in the designer
- rename components / change properties in Object inspector / Add new events
- Add components to form / Move components on form
- Frames, if you use them
- If you can navigate the source code (e.g. jump to implementation)
- Auto completion in source code
- Compile, debug and run
- Anything else you use in your daily work

Mattias

Great !

So there will be a Lazarus release that relies on fpc 3.x.

That means that I now can start the final phase of the "General Service" Widget Type (formerly called "Active NoGUI").

Obviously it will not be in the first 1.6 release, but happily the Lazarus releases are scheduled a lot more often than the fpc releases, so I will not have to wait another three years until the code might be published. But as the interest of the average Lazarus user is on Desktop applications rather than on Services I think there is no hurry, anyway. (Sorry, Bo :-( )

At some point of time I would like to have the code included in the svn (or somehow else be generally available for those who might want to use it or help to improve it (Bo ?!?!?! :-) :-) :-) ).

So now I think it's time to ask how to proceed.

Of course I do have a working code base for a first version of the thingy. But how to make it usable ?

AFAIK, the existing Widget Type is selected in the IDE by setting it in "Additions and Overrides" and/or by selecting an appropriate application type when creating a new project.

Of course I can't modify the IDE to support this.

For compiling, the Widget Type is defined by a "$define" value this is adhered to in the source code.

Of course I can't modify the "general" source code of the LCL to have it consider a new Widget Type (by introducing some lines that make it visible)

How to proceed ? `

-Michael

Of course you can, it is open source.

You can either extend the nogui widgetset and send us the patch. Or you can start your own widgetset.
Either by creating your own "LCL" package, e.g. "MSLCL" or by extending the LCL.
Depends on how you want to maintain/promote it.

Mattias

That's a straw man argument. Every single revision of FPC is published. Many projects use and/or support FPC 2.7+ since several years.

Mattias

Yep.

But it might be a lot of work just finding out what to do and it might be dangerous that something not obviously related is broken.

You can either extend the nogui widgetset and send us the patch. Or you can start your own widgetset.

I need to start a new widget type (i.e. a new interface unit), as the working mechanism is rather different from all existing widget types.

There is no arch or OS dependent code, it just does calls to the fpc RTL.

Either by creating your own "LCL" package, e.g. "MSLCL" or by extending the LCL.

If it's possible to distribute it in a package, I don't now I don't see how a package would be able to have the IDA allow for selecting a new application type and/or to allow for selecting a widget type in "Additions and Overrides", but if there is a documentation on how to create such a package this could be a good way.

Depends on how you want to maintain/promote it.

I don't have a preference on that.

In the end, I want to allow users to be able to create a "General Service Application" in the IDE when starting a project and to modify the widget type of an existing project to be a "General Service Application".

Moreover I would like to allow others to help improving the code by providing patches to be included in some svn. (But I can't manage an svn
- I already failed several times trying.)

-Michael

Mattias Gaertner wrote

That's a straw man argument. Every single revision of FPC is published. Many projects use and/or support FPC 2.7+ since several years.

The code relies on TThread.Queue.

The first released version of fpc that (hopefully) has TThread.Queue is 3.0.

A Lazarus user who wants to use the Widget Type should not be forced to use a not yet released version of fpc.

-Michael

[...] A Lazarus user who wants to use the Widget Type should not be forced to use a not yet released version of fpc.

As I said, that's a straw man. I bet in 3 years from now you will find a distro without an official FPC 3.

Mattias

[...] But it might be a lot of work just finding out what to do and it might be dangerous that something not obviously related is broken.

Send patches and people can help.

> You can either extend the nogui widgetset and send us the patch. > Or you can start your own widgetset. I need to start a new widget type (i.e. a new interface unit), as the working mechanism is rather different from all existing widget types.

For example?

A new application type requires a design time package. The widgetype list comes from the simple list, but a user can set any value. If you extend the LCL it will be more comfortable for the user.

What's the difference between a "General Service Application" and a "Service Application"?

Mattias

Thanks go out to everyone for their work on Lazarus. I'll test and report back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151208/d479a775/attachment.html>

checksums on our website
http://www.lazarus-ide.org/index.php?page=checksums#1_6_0RC1

Mattias,

I was looking through my mail trying to find the patch Ondrej created for dotted namespace code completion in CodeTools but I can't find it. has that been accepted into this release?

Also, I created a fix for tray icons on Unity (TTrayIcon plain doesn't work on it), but it would seem a report was never created even though Unity has been out for more than five years. I don't know if anyone has applied a version of my fix it to svn, but what I came up with is located here:

https://github.com/sysrpl/Lazarus.UnityAppIndicators -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151208/20ba5f75/attachment.html>

Many thanks Laz Team.

Keep up the good work.

I do have one observation though, Laz1.4.4 (fixes) and Laz Trunk 1.5 were a bit faster and the generated exe was ~300kb smaller than the one from 1.6.

PS: Please do not treat this as a complain of any kind, this is just an observation, in case it makes any difference.

On Win 8 - 32bit.

Regards,

Jamal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151209/07844444/attachment.html>

Mattias Gaertner wrote

For example?

TTimer is implemented using the timeout in checksynchronize().

Application QueuAsyncCall is implemented using TThread.Queue.

A new application type requires a design time package.

That means after installing the package, the application type is selectable from the list of possible application types ? Choosing that application type will set the appropriate defines for compiling the sources ? Correct ?

Where can I find documentation on this ?

The widgetype list comes from the simple list, but a user can set any value. If you extend the LCL it will be more comfortable for the user.

Of course I would like that finally the most comfortable option is offered to a potential user.

What's the difference between a "General Service Application" and a "Service Application"?

I chose the name "General Service Application" rather than the former suggested name "active NoGui", as I think that is more understandable for users that might need it.

It is "General" because the code is independent of CPU arch and OS. So it (hopefully) will run on Windows, any Linux, and the new Windows IOT. (I don't have MAC, OS2, BSD, Android ect, but if fpc application run it should work) (AFAIK, fpc does not yet provide support for Win IOT on ARM)

It is "Service" because it does not attach to any GUI library. So it will run on a headless Linux and on Win IOT (which in fact is a headless Windows 10).

it is "Application" because it (hopefully) supports the Event programming paradigm, including a dedicated mainthread, TTimer, TThread.Synchronize, TThread.Queue, Application.ProcessMessages, Application.QueueAsyncCall, SendMessage from a worker thread to the main threads to be received via "procedure .... message" etc, working in the same way as a Windows or Linux-GUI application, without the user needing to bother about the infrastructure that manages the event queuing.

-Michael

Mattias Gaertner wrote

As I said, that's a straw man. I bet in 3 years from now you will find a distro without an official FPC 3.

Meaning I should wait another three years ?

No real problem with me.

-Michael

Michael Schnell, please don't hijack this RC1 thread for your General Service Application thing.
Open a new thread for it.

Juha

Anthony Walter wrote

I was looking through my mail trying to find the patch Ondrej created for dotted namespace code completion in CodeTools but I can't find it. has that been accepted into this release?

No need to look for patches. Look for commit history instead. Ondrej now has commit rights and fixed many things in codetools related to dotted namespace.

It was discussed in mailing list :
http://comments.gmane.org/gmane.comp.ide.lazarus.general/83274 I understood it was not ready. You added sentences like "Just remove the KDE check and it should be good to go."
Then Zeljko promised to implement it in Lazarus but apparently he was busy.

So, could you please provide a patch that fully works in your tests. Preferably open a bug report for it. Tracking the potential problems becomes easier then.
I can apply it then but I cannot promise to include it in Lazarus 1.6. This is a change that can cause regressions and must be tested well.

Juha

On 12/08/2015 05:59 PM, Mattias Gaertner wrote: > For example? TTimer is implemented using the timeout in checksynchronize().

Looks perfectly fitting for the NoGUI widgetset to me.

Application QueuAsyncCall is implemented using TThread.Queue.

What is wrong with the current implementation?

Yes.

Where can I find documentation on this ?

Many concepts are explained here:
http://wiki.lazarus.freepascal.org/Extending_the_IDE

Lazarus contains several examples of such design time packages. Maybe instantfpclaz.lpk is a good start.

Since FPC/Lazarus is cross platform, it usually works the other way round. For instance "Windows Service Application" for platform dependent, just "Service Application" for cross platform.

NoGUi has already a dedicated mainthread, TThread.Synchronize, TThread.Queue, Application.ProcessMessages, Application.QueueAsyncCall. Only SendMessage and TTimer are missing.

Mattias

Meaning your argument is flawed, because it can be prolonged to infinity.
Don't wait for releases. Start coding now and tell your users what FPC version is needed.

No real problem with me.

I feared so.

Mattias

1.6 is the former 1.5.
Do you mean LCL 1.6 applications compiled with FPC 2.6.4 are smaller and faster than compiled with FPC 3.0?

Mattias

Mattias Gaertner wrote

> Application QueuAsyncCall is implemented using TThread.Queue. What is wrong with the current implementation?

Nothing. But it uses another Queue. Queue handling needs OS calls for waiting. I want to avoid to do any OS Calls so I simply use what the RTL offers for exactly this purpose.

Many concepts are explained here: http://wiki.lazarus.freepascal.org/Extending_the_IDE Lazarus contains several examples of such design time packages. Maybe instantfpclaz.lpk is a good start.

Thanks !

I will tale a look.

Since FPC/Lazarus is cross platform, it usually works the other way round. For instance "Windows Service Application" for platform dependent, just "Service Application" for cross platform.

I have no problem with choosing a different name. If you say just "Service Application" is OK, it's absolutely fine with me.

NoGUi has already a dedicated mainthread, TThread.Synchronize, TThread.Queue, Application.ProcessMessages, Application.QueueAsyncCall. Only SendMessage and TTimer are missing.

I started working on the "active NoGui" project years ago, as at that time there was a chance that I would need to use it (But I could not talk my colleagues into the fpc/Lazarus direction.)

Bo seems to have done some testing for his NoGUI project but seemingly what he found was not up to his needs. (I found similar requests every few month in the mailing lists, but seldom somebody instated so strongly on finding exactly something that closely resembled my old project.) .

So it might - or might not - be viable to publish it by decently integrating it in the Lazarus environment.

In fact I would not like to try to re-use the NoGUI code, especially as I seem to remember that I read about several shortcomings of same (I did not yet check myself). Is there a documentation on what exactly NoGUI is supposed to provide ?

(I suppose this "Service Application" might replace "noGUI", but of course same should stay in place for legacy projects. )

-Michael

Juha Manninen wrote

Michael Schnell, please don't hijack this RC1 thread for your General

Ooops I did it again. :-(

You are absolutely correct (I got carried away by the answers I got, I intended to provoke just a Yes or a No)

I'll stop answering here.

Thanks,
-Michael

Coding is done. It works.

I'll Stop talking about it.

-Michael

Do you mean LCL 1.6 applications compiled with FPC 2.6.4 are smaller and faster than compiled with FPC 3.0?

I am sorry for not been specific enough.
I was using Laz1.4.4 (fixes) & 1.5 with fpc3.0.1

I meant with the above mentioned versions, normal compile and run, would generate smaller exe and faster.

Regards,

Jamal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151209/5d99b279/attachment.html>

El 08/12/15 a les 16:19, Mattias Gaertner ha escrit:

== Why should everybody (including you) test the release candidate? == In the past weeks the Lazarus team has stabilized the 1.6 fixes branch. The resulting 1.6RC1 is now stable enough to be used by any one for test purposes.

....

this isn't a lazarus bug but most probably a problem with fpc: ExpandUnCFileNameUTF8 (which in turns calls SystUtils.ExpandUNCFileName) returns '\' when called with

'D:\testfpc\15044_videowall\servidor\..\datos\'

(with fpc 2.6.4 it returned '\\local\Datos\15044_videowall\datos\')

I's *not* the '..' that's confusing it, it's the mapped drive.

Bye

Do you mean apps compiled with 1.4.4 and FPC 2.6.4 are faster and smaller than 1.6 with FPC 3.0.1?
Or do you mean there is a difference between 1.5 and 1.6 compiled with 3.0.1?

Mattias

Or do you mean there is a difference between 1.5 and 1.6 compiled with 3.0.1?

Exactly. I do not compare against earlier versions. Instead I compared Laz1.4.4&fpc3.0.1 against Laz1.5&fpc3.0.1 against Laz1.6RC1&fpc3.0.0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151209/da29c46f/attachment-0001.html>

Please test SystUtils.ExpandUNCFileName. If this function does it wrong, create a FPC bug report.
If only ExpandUnCFileNameUTF8 does it wrong, please create a Lazarus bug report.

Mattias

What revision of 1.5 do you mean?
1.5 was renamed to 1.6. So the only difference is FPC 3.0.0 and FPC 3.0.1, right?

1.6 has more code than 1.4.4. Smart linking and WPO should remove most of it.

About "faster": You need to give more information what and how you tested.

Mattias

About "faster": You need to give more information what and how you tested.

I just compared one project with 1.4.4/3.0.1 | 1.5/3.0.1 against 1.6/3.0.0 and the time it took was noticeable.
I tested by compiling same project, also by rebuilding lazarus, all under same conditions, and it was very clear to notice the difference.

I do not have benchmarks for that, it is simple observation, I might be wrong though.
But I should do more testing and get back to you with more info.

Regards,

Jamal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151209/48112374/attachment.html>

Please take a look at the NoGUI widgetset. It does not use another Queue.

What code? It only contains the basic methods to let it compile. Any LCL interface must have at least that.

especially as I seem to remember that I read about several shortcomings of same (I did not yet check myself). Is there a documentation on what exactly NoGUI is supposed to provide ?

The NoGUI allows to compile a LCL application without a GUI. It has a few lines of code to connect the RTL.

(I suppose this "Service Application" might replace "noGUI", but of course same should stay in place for legacy projects. )

I guess implementing TTimer and SendMessage only needs a few hundred lines. I see no problem adding that to the NoGUI widgetset.

Mattias

El 09/12/15 a les 13:21, Mattias Gaertner ha escrit:

Well, since ExpandUNCFileNameUTF8 only calls Sysutils.ExpandUNCFilename the bug is in fpc. I will file a bug report for it.

Bye

Do you mean compilation speed?
There should be no noticeable difference between 1.5/3.0.1 and 1.6/3.0.0.

What revision of 1.5?

But I should do more testing and get back to you with more info.

Yes, please.

Mattias

Luca Olivetti wrote

this isn't a lazarus bug but most probably a problem with fpc: ExpandUnCFileNameUTF8 (which in turns calls SystUtils.ExpandUNCFileName) returns '\' when called with

That's odd, because this is the implementation:

function ExpandUNCFileNameUTF8(const FileName: string): string;
begin
  Result:=SysUtils.ExpandUNCFileName(Filename);
end;

Bart

El 09/12/15 a les 13:53, Bart ha escrit:

Yes, most probably the bug is in fpc, but note that lazarus 1.4.x had its own implementation instead of relying on sysutils. I just checked that sysutils.expanduncfilename gives the "correct" result with fpc2.6.4 and the wrong one with fpc 3.0.0. OTOH lazarus 1.4.x would resolve the '..', i.e. 'c:\windows\..\' was translated to 'c:\' (that's what I used it for), while fpc doesn't.

Bye

Michael Schnell wrote

Obviously it will not be in the first 1.6 release, but happily the Lazarus releases are scheduled a lot more often than the fpc releases, so I will not have to wait another three years until the code might be published.

Quite frankly I feel that the Lazarus version numbering is progressing faster than is reasonable, and that it would be highly desirable to have a "Long Term Support" v2.0.x or even 3.0.x which could be presented to people outside the project as a robust version to use with FPC 3.0.x.

It's not at all easy to explain to an outsider- for example a Delphi refugee- that if he wants some version of Lazarus for a particular feature he'll then need an unrelated FPC version as the compiler:

! /usr/local/bin/lazarus-0.9.24+2.2.4
! /usr/local/bin/lazarus-0.9.26+2.2.4
! /usr/local/bin/lazarus-0.9.28+2.4.0
! /usr/local/bin/lazarus-0.9.30+2.4.4
! /usr/local/bin/lazarus-1.0.0+2.4.4
! /usr/local/bin/lazarus-1.0.0+2.6.0
! /usr/local/bin/lazarus-1.0.8+2.6.2
! /usr/local/bin/lazarus-1.0.14+2.6.4
! /usr/local/bin/lazarus-1.2.6+2.6.4
! /usr/local/bin/lazarus-1.4.2+3.0.0

Industry doctrine has it that v3 of a piece of software is usually a sweet spot, and while I'm a very junior member of this community I really feel that we should be trying to hit it.

Alternatively, Turbo Pascal v3 was recognised as one of the "greats" of early PC software (I remember when the company I worked with sold what they knew was the last copy they could get), and Delphi v2 was groundbreaking because it was the first Win-32 version (i.e. to run on an OS with decent preemptive multitasking etc.).

How about a stable Lazarus v2.0.x, with as many bugs and development quirks as possible worked out of it, based on FPC 3.0.x and with a support commitment from both teams?

Or with the number of exciting things that the core developers have on the boil, is promoting the project to outsiders simply irrelevant these days?

Do you think version is progressing too fast or do you think it should progress faster towards 2.0?

Yes.

! /usr/local/bin/lazarus-1.4.2+3.0.0

1.4.2 used FPC 2.6.4.
1.6 will be the first release with FPC 3.0.

[...] How about a stable Lazarus v2.0.x, with as many bugs and development quirks as possible worked out of it, based on FPC 3.0.x and with a support commitment from both teams?

Every day some bugs are fixed. In the last two years the bug tracker had over 8000 reports, notes and fixes.
If you want to increase the rate of bug fixing you are welcome to help.
At the moment we have two branches, the development and the fixes branch.
If you want to maintain a third branch with longer life, you can volunteer to maintain it. Note that building all release binaries and uploading them takes some hours. If you have a build farm you can automate a lot of things. I can help you set it up.

[...]

Mattias

...

+1
man power is the main issue. Building and testing.

Then a set of rules how to decide what to merge to lts.

As for the version number, I dont see any relation between 2.0 and lts. it can same as good be based on 1.4 (if you want 2.6.4 continued), or on 1.6 (once 1.8 or 2.0 is out).

Mark Morgan Lloyd wrote

Quite frankly I feel that the Lazarus version numbering is progressing faster than is reasonable, and that it would be highly desirable to have a "Long Term Support" v2.0.x or even 3.0.x which could be presented to people outside the project as a robust version to use with FPC 3.0.x.

Uhhh...
Until now people have complained about release cycle being too slow, and quite rightfully so.
Now you complain that it is too fast. We can never please everybody apparently ...

A "Long Term Support" version in a development tool project with limited development resources makes no sense because the tool can be updated so easily by anybody. A server Linux distro is a different thing.
Still, as Mattias wrote you can volunteer to maintain a "Long Term Support" version if you consider it important.

It's not at all easy to explain to an outsider- for example a Delphi refugee- that if he wants some version of Lazarus for a particular feature he'll then need an unrelated FPC version as the compiler:

Your idea of a longer release cycle would make things worse. This issue went upside-down in your thoughts for some reason. We are releasing soon after FPC so that users get the latest compiler. If we waited longer (as you suggested) then people would indeed "need an unrelated FPC version as the compiler".

Industry doctrine has it that v3 of a piece of software is usually a sweet spot, and while I'm a very junior member of this community I really feel that we should be trying to hit it.

That is pure psychology. Not based on technical merits.

How about a stable Lazarus v2.0.x, with as many bugs and development quirks as possible worked out of it, based on FPC 3.0.x and with a support commitment from both teams?

Now you ask the mythical "development teams" to do more work than they already do.
This is open source. Anybody who contributes bug fixes is a "developer". You can also fix bugs and improve quality. Your comments imply that the quality is now poor. I don't agree.

Or with the number of exciting things that the core developers have on the boil, is promoting the project to outsiders simply irrelevant these days?

I don't know what you mean. There are still essential pieces missing from Lazarus. Of course they must be implemented. Do you mean it should be left in an unfinished state?

Juha

Luca Olivetti wrote

Yes, most probably the bug is in fpc, but note that lazarus 1.4.x had its own implementation instead of relying on sysutils.

No, it did not.
It also called SysUtils.ExpandUncFilename().

Your bugreport says that it also translated C:\Windows\..\ into C:\. This is done by ExpandFilenameUtf8 (which indead has it's own implementation in LazFileUtils unit and calls ResolveDots which actually does that job).

So, your memory serves you wrong I guess.

Bart

El 09/12/15 a les 17:07, Bart ha escrit:

Right, I mixed the two functions.

Bye

In the interest of making the least amount of work for anybody, my suggestion would be to proceed at the current rate towards 2.0.0, but to make sure that this is still compatible with FPC 3.0.0. After that try to slow down the Lazarus numerical progression a bit by using "hundredths" more.

And I'm afraid that I'm not volunteering for anything right now: I've got my hands more than a little full to the extent that I'm finding it difficult to test FPC and Lazarus on some of the odder systems I have around here as often as I'd like.

All will remain 3.0.0 compatible until 3.0.4 comes out, at which time we only support 3.0.2 and 3.0.4 (and trunk) at the next release.

Maintaining more compiler versions tends to get to you into ifdef hell rather quickly.

Having support for codepage aware strings by default justifies going from 1.4.x to 1.6.x IMO.

Bart

I think the backwards compatibility of LCL is the most important detail. A Long Term Support version of the IDE itself does not make much sense.
The compatibility of LCL has been good. Or maybe it had problems which I don't know about.
FPC 3.0 + codepage aware strings + our new UTF-8 system however breaks certain code that depends on system codepages, but it also improves things a lot. This kind of changes are necessary sometimes. I don't understand how a slower release cycle would improve it.

Juha

In fairness, I didn't say a slower release cycle, I said more use of the "hundredths" digits so that once Lazarus is at (say) 2.0.0 it doesn't appear to move away from it so quickly.

Mark Morgan Lloyd wrote

Quite frankly I feel that the Lazarus version numbering is progressing faster than is reasonable, and that it would be highly desirable to have a "Long Term Support" v2.0.x or even 3.0.x which could be presented to people outside the project as a robust version to use with FPC 3.0.x.

I don't think it is wise to commit to some golden version LTS version if there is no experience with LTS establish a LTS branch, and more importantly a maintainer/team for it, then talk commitment from the other teams and synchronized releasing.

If not already, this info needs to be placed somewhere on the Wiki. Lazarus doesn't supply installers (lazarus + fpc) for all supported OSes. Also OSes that do support package managers are not always up to date etc. Personally I stall Lazarus and FPC separate. Maybe there are others like me. In such a case, knowing what FPC release to use with each Lazarus release would be useful.

Regards,
- Graeme -

Those are tested combinations. 1.4.2 (which was the latest 1.4.x when I did the work) works reliably with 3.0.0, and is the first workable combination if you want to avoid the trunk/development revisions.

I'm prepared to say to people "you're going to have to build something from source, but it's no big deal". I'm not prepared to say to them "you're going to have to build from bleeding-edge sources, and there's a risk they won't work".

True for Unix like OS.
Not so true for Windows.

I'm glad that it works for your tests, but in general the safe advice is 1.4.2 with FPC 2.6.4.

I'm prepared to say to people "you're going to have to build something from source, but it's no big deal". I'm not prepared to say to them "you're going to have to build from bleeding-edge sources, and there's a risk they won't work".

Then you should say to people: use the released combinations (e.g. 1.4.2 with FPC 2.6.4).

Mattias

[...] If not already, this info needs to be placed somewhere on the Wiki.

I added the release history here:
http://wiki.lazarus.freepascal.org/Version_Numbering

I guess you mean the zip releases on sourceforge. I added a note to the sourceforge README.txt.

Mattias

Mattias Gaertner wrote

I guess you mean the zip releases on sourceforge. I added a note to the sourceforge README.txt.

Thanks for that.

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

I don't know if this has been reported, but on several Lazarus installations I get a "Division by zero" exception when using the "Manage desktops" dialog, located under the "Tools -> Desktops ..." menu. On some systems the error is reported as a floating point exception and crashes Lazarus badly.

On my configuration I have anchordockingdsgn installed, but the problem may affect multiple window layout users as well.

To generate the exception:

Open "Manage desktops" dialog.
Press the export button.
Save layout as a new name.
Close the "Manage desktops" dialog.

I receive the error at this point one a few systems on Lazarus trunk and have had this issue for months now. I build Lazarus fresh from trunk often, so I assume this error affects the latest release candidate as well. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151212/e16b71b4/attachment.html>

I cannot reproduce (without anchordocking installed). Please report in mantis and add backtrace.

Ondrej

I am not sure how to backtrace on mantis, but here is the bug report I submitted. Maybe you can 1.6 RC tag it for me.

http://bugs.freepascal.org/view.php?id=29178
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151212/22622591/attachment.html>

I updated the previously mentioned issue with information from gdb. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151213/926d26cc/attachment.html>