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

[Lazarus] "NoGui" or "Service Application"

[Michael Schnell]

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.

As requested (and decent indeed), I  herewith start a new thread and 
will answer tomorrow.


Thank for caring,

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

[Lazarus] Phasing out support for Windows 98 and Windows ME

[Bart]

Dear Lazarus users,

The Lazarus team has decided to finally phase out support for the
Windows 9x platform.

Reasons for doing so are:
1) The platform is not supported anymore by Microsoft.
2) The platform is hardly in use anymore.
3) The new 3.0 series compiler does not support this platform anymore.
4) There is only 1 maintainer of the Windows 9x code base.
5) Cleaning up the Win32 widgetset code will make it easier to
maintain and less prone to bugs.

The phasing out wil take place in 2 stages:

Stage 1.
Starting with the upcoming Lazarus 1.6 there will be no more active
development in the code that was specifically written for dealing with
the Window 9x platform.

However, patches (when supplied in the bugtracker) for bugs in this
code can still be applied to the 1.6 fixes branch.

It may (or may not) be necessary to build your application using the
2.6.4 compiler in order to get a functional Windows 9x application.

Stage 2.
Starting with the 1.7 development branch (AKA trunk) all code that was
specifically written for the Windows 9x platform will be removed from
our codebase.
>From that point on software written with this version (or later) of
Lazarus will most likely either not run at all, or not run as expected
on the Windows 9x platform.

We are aware of the fact that this decision may affect a niche group
of Lazarus users who develop for end-uses that still run Windows 98,
but these can still use the 1.6 branch of Lazarus.

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

[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] How to pass function method to TList.Sort?

[Anthony Walter]

// Drop the TMyClass.

function Compare( Item1, Item2 : Pointer ) : Longint;
begin
   case fIndex of
  0:  Result := some compare of Item1, Item2;// These compares are
implemented in an object from another unit
  1:  Result := another compare of Item1, Item2
   end;
end;

Sort takes a function, not a method. There is a difference. A function
pointer is, well one pointer. A method pointer (function/procedure of
object) is tow pointers 1st pointer) for the function 2nd pointer) for the
object instance
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] How to pass function method to TList.Sort?

[Donald Ziesig]

Hi All!

Is there any way to pass a method function as the Compare parameter to a 
TList or is there a work around for it?


There are generics involved so it won't let me access the static symbol 
table.


As in:

type
  TMyClass = object
 fIndex : Integer;
 List : array of TList;
 function Compare( Item1, Item2 : Pointer) : Longint; // needs 
access to fIndex


 procedure Sort;
  end;

implementation

function TMyClass.Compare( Item1, Item2 : Pointer ) : Longint;
begin
   case fIndex of
  0:  Result := some compare of Item1, Item2;// These compares are 
implemented in an object from another unit

  1:  Result := another compare of Item1, Item2
   end;
end;

procedure TMyClass.Sort;
begin
  fIndex := 0;

  List[fIndex].Sort( @Compare );  // Compilation error, doesn't like 
Compare being "of object"


end;


Thanks,

Don Ziesig


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

Re: [Lazarus] *** SPAM *** How to pass function method to TList.Sort?

[Howard Page-Clark]

On 09/12/2015 20:11, Donald Ziesig wrote:
Is there any way to pass a method function as the Compare parameter to 
a TList or is there a work around for it?

As in:

type
  TMyClass = object
 fIndex : Integer;
 List : array of TList;
 function Compare( Item1, Item2 : Pointer) : Longint; // needs 
access to fIndex


 procedure Sort;
  end;

implementation

function TMyClass.Compare( Item1, Item2 : Pointer ) : Longint;
begin
   case fIndex of
  0:  Result := some compare of Item1, Item2;// These compares are 
implemented in an object from another unit

  1:  Result := another compare of Item1, Item2
   end;
end;

procedure TMyClass.Sort;
begin
  fIndex := 0;
  List[fIndex].Sort( @Compare );  // Compilation error, doesn't like 
Compare being "of object"

end;


It's a dreadful hack, but you could try something like:

type
  TClassListSortCompare = function (Item1, Item2: Pointer): Integer of 
object;


procedure TMyClass.Sort;
var
  objectFunction: TClassListSortCompare;
  regularFunction: TListSortCompare;
begin
  fIndex := 0;
  objectFunction:=@Compare;
  regularFunction:=TListSortCompare(TMethod(objectFunction).Code);
  List[fIndex].Sort( regularFunction );
end;


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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