Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Anthony Walter]

I updated the previously mentioned issue with information from gdb.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Anthony Walter]

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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Ondrej Pokorny]

On 12.12.2015 18:21, Anthony Walter wrote:
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.


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


Ondrej

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Anthony Walter]

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Marco van de Voort]

On Wed, Dec 09, 2015 at 02:31:20PM +, 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 branches at all.

First establish a LTS branch, and more importantly a maintainer/team for it,
then talk commitment from the other teams and synchronized releasing.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Graeme Geldenhuys]

On 2015-12-09 15:27, Mattias Gaertner wrote:
>> >[...]
>> > ! /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
> 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.
> 
>  

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 -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Thu, 10 Dec 2015 10:07:09 +
Mark Morgan Lloyd  wrote:

>[...]
> >> ! /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.
> 
> 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mark Morgan Lloyd]

Mattias Gaertner wrote:

On Wed, 09 Dec 2015 14:31:20 +
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.


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


[...]
! /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


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.


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".


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Thu, 10 Dec 2015 09:24:43 +
Graeme Geldenhuys  wrote:

>[...]
> 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

> 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.

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

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Graeme Geldenhuys]

On 2015-12-10 12:05, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Juha Manninen]

On Wed, Dec 9, 2015 at 5:16 AM, 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.


> 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

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/08/2015 05:49 PM, 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



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/08/2015 05:59 PM, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Juha Manninen]

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

Juha

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/09/2015 11:45 AM, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Luca Olivetti]

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

On Wed, 9 Dec 2015 12:33:08 +0100
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

'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.


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.



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


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Bart]

On 12/9/15, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 9 Dec 2015 14:25:32 +0300
Jamal Gabra  wrote:

>[...]
> 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Jamal Gabra]

>
> 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 against Laz1.5 against Laz1.6RC1

On Wed, Dec 9, 2015 at 2:48 PM, Mattias Gaertner 
wrote:

> On Wed, 9 Dec 2015 14:25:32 +0300
> Jamal Gabra  wrote:
>
> >[...]
> > 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.
>
> 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
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Jamal Gabra]

>
> 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

On Wed, Dec 9, 2015 at 2:17 PM, Michael Schnell  wrote:

> On 12/09/2015 11:45 AM, 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
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Luca Olivetti]

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
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 9 Dec 2015 15:39:54 +0300
Jamal Gabra  wrote:

> >
> > 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 9 Dec 2015 06:30:02 +0300
Jamal Gabra  wrote:

> 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 09 Dec 2015 12:17:55 +0100
Michael Schnell  wrote:

> On 12/09/2015 11:45 AM, 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.

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

 
>[...]
> > NoGUi has already a dedicated mainthread, TThread.Synchronize, 
> > TThread.Queue, Application.ProcessMessages, 
> > Application.QueueAsyncCall. Only SendMessage and TTimer are missing.
>[...]
> In fact I would not like to try to re-use the NoGUI code,

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/09/2015 11:27 AM, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 09 Dec 2015 11:10:36 +0100
Michael Schnell  wrote:

> On 12/08/2015 05:49 PM, 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 ?

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


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 09 Dec 2015 11:08:48 +0100
Michael Schnell  wrote:

> 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?

 
> > 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 ?

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.

 
>[...]
> > 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.

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.


>[...]
> 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.

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


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/09/2015 11:51 AM, Mattias Gaertner wrote:


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.


Coding is done. It works.

I'll Stop talking about it.

-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 9 Dec 2015 12:33:08 +0100
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
> 
> '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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 9 Dec 2015 15:14:23 +0300
Jamal Gabra  wrote:

> >
> > 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 against Laz1.5 against Laz1.6RC1

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Jamal Gabra]

>
> 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

On Wed, Dec 9, 2015 at 3:25 PM, Mattias Gaertner 
wrote:

> On Wed, 9 Dec 2015 15:14:23 +0300
> Jamal Gabra  wrote:
>
> > >
> > > 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 against Laz1.5 against Laz1.6RC1
>
> 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
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Luca Olivetti]

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

On 12/9/15, 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;


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

--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mark Morgan Lloyd]

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?


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Martin Frb]

On 09/12/2015 15:27, Mattias Gaertner wrote:

On Wed, 09 Dec 2015 14:31:20 +
Mark Morgan Lloyd  wrote:

[...]
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?

...

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.


+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).



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Bart]

On 12/9/15, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Juha Manninen]

On Wed, Dec 9, 2015 at 4:31 PM, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Wed, 09 Dec 2015 14:31:20 +
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.

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

>[...]
> ! /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

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
 

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mark Morgan Lloyd]

Mattias Gaertner wrote:

On Wed, 09 Dec 2015 14:31:20 +
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.


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


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.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Luca Olivetti]

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

On 12/9/15, 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.


Right, I mixed the two functions.

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Bart]

On 12/9/15, Mark Morgan Lloyd  wrote:

> 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Juha Manninen]

On Wed, Dec 9, 2015 at 6:41 PM, Mark Morgan Lloyd
 wrote:
> 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mark Morgan Lloyd]

Juha Manninen wrote:

On Wed, Dec 9, 2015 at 6:41 PM, Mark Morgan Lloyd



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.


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.


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
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Tue, 08 Dec 2015 16:44:49 +0100
Michael Schnell  wrote:

>[...]
> 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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/08/2015 05:03 PM, Mattias Gaertner wrote:

On Tue, 08 Dec 2015 16:44:49 +0100
Michael Schnell  wrote:


[...]
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.

Of course you can, it is open source.

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 object at all. 
Right 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




--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Tue, 08 Dec 2015 17:24:46 +0100
Michael Schnell  wrote:

>[...]
> 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/08/2015 04:19 PM, Mattias Gaertner wrote:

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.


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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Tue, 08 Dec 2015 16:44:49 +0100
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.

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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Anthony Walter]

Thanks go out to everyone for their work on Lazarus. I'll test and report
back.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Mattias Gaertner]

On Tue, 08 Dec 2015 17:22:04 +0100
Michael Schnell  wrote:

>[...]
> 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?

 
> 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 object at all. 
> Right 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.

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.


> > 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".

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

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Michael Schnell]

On 12/08/2015 05:09 PM, 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

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Martin Frb]

On 08/12/2015 15:19, Mattias Gaertner wrote:

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.



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


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Jamal Gabra]

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

On Wed, Dec 9, 2015 at 6:16 AM, Anthony Walter  wrote:

> 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
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Release Candidate 1 of Lazarus 1.6

[Anthony Walter]

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus