Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2015-05

Re: FPC roadmap?

14 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Serguei TARASSOV

Thank for answers.
Are some dates planned for 3.0 release ?
Actually, we have some risks : 2.6 is frozen and not supported but 3.0 is not released yet.
I took a little about some non-blocking issues at forum and tracker. The advise was "use 3.0 from trunk".
Then I asked "Do you use 3.0 in production?" and the answer was "No" in general.

In other hand, do any statistics about community exist? I mean, estimated number of users, contributors, their activity... I understand that projects like PHP are more diffused and give more data about their activity but FPC/Lazarus has sufficient mature codebase and history for this kind of information.

Serguei On 31/05/2015 12:00, wrote: > Date: Sat, 30 May 2015 12:00:24 +0200 > From: Jonas Maebe > To: FPC-Pascal users discussions > Subject: Re: [fpc-pascal] FPC roadmap? > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Michael Van Canneyt wrote: >> >The next planned release is 3.0, it will contain better unicode support. > And a bunch of other things:http://wiki.freepascal.org/FPC_New_Features_3.0 > > Things that have been added since then and that will be in the (major) > release coming after that are at > http://wiki.freepascal.org/FPC_New_Features_Trunk (although there will > also be a 3.0.1 "release" with AArch64 support) > > > Jonas
Jonas Maebe
to Serguei TARASSOV
Serguei TARASSOV wrote
Thank for answers. Are some dates planned for 3.0 release ?

No, not yet.

Show quoted text 6 lines
Actually, we have some risks : 2.6 is frozen and not supported but 3.0 is not released yet. I took a little about some non-blocking issues at forum and tracker. The advise was "use 3.0 from trunk". Then I asked "Do you use 3.0 in production?" and the answer was "No" in general.

I would recommend to use 3.0 from fixes_3_0 (or fixes_3_0_ios if you need AArch64 support). I don't think much will still change to that branch before the release.

Show quoted text 5 lines
In other hand, do any statistics about community exist? I mean, estimated number of users, contributors, their activity... I understand that projects like PHP are more diffused and give more data about their activity but FPC/Lazarus has sufficient mature codebase and history for this kind of information.

For contributors, commits etc based on the svn activity, you can have a :
* the entire FPC source tree: https://www.openhub.net/p/freepascalall
* only the FPC compiler: https://www.openhub.net/p/freepascal
* lazarus: https://www.openhub.net/p/lazarus

I'm not aware of any statistics about people using FPC and/or Lazarus.

Jonas

Juha Manninen
to Jonas Maebe
Jonas Maebe wrote
I don't think much will still change to that branch before the release.

Then please release ASAP.

I have one sincere question: Will FPC 3.0 happen this year? Typically from RC1 it takes ~3-4 months to the release. Now we don't have even RC1 in sight.
Say you build RC1 after 2 months, that's August.
3-4 months from that will be November or December, still (barely) in this year.

Sorry I am joining the group asking about schedule but the situation is getting annoying.
More and more often a development version of FPC must be recommended for people because of Unicode, generics and many other improvements. It does not feel right. Fortunately fpcup is now maintained again but it cannot replace an FPC release obviously.

Are there open issues blocking the release? Do you need help with them?

Juha

Michael Van Canneyt
to Juha Manninen
Juha Manninen wrote 19 lines
On Mon, Jun 1, 2015 at 12:17 AM, Jonas Maebe wrote: > I don't think much will still change to that branch before the release. Then please release ASAP. I have one sincere question: Will FPC 3.0 happen this year? Typically from RC1 it takes ~3-4 months to the release. Now we don't have even RC1 in sight. Say you build RC1 after 2 months, that's August. 3-4 months from that will be November or December, still (barely) in this year. Sorry I am joining the group asking about schedule but the situation is getting annoying. More and more often a development version of FPC must be recommended for people because of Unicode, generics and many other improvements. It does not feel right. Fortunately fpcup is now maintained again but it cannot replace an FPC release obviously. Are there open issues blocking the release? Do you need help with them?

The documentation is the only 'blocking' issue.
Maybe for good measure some extra fixes need to be merged.

I have documented the remaining identifiers in the reference documentation, but the new language features still need to be documented; Normally, the biggest part can be done tomorrow and the day after.

After that (as in: as of monday) as far as I am concerned, RC1 may be built.

Michael.

Juha Manninen
to Michael Van Canneyt
Michael Van Canneyt wrote
After that (as in: as of monday) as far as I am concerned, RC1 may be built.

That would be sooner than I expected. Cool! Thanks in advance.

Juha

Jonas Maebe
to Maciej Izak
Maciej Izak wrote
any chance to release FPC 3.0 with Generics.Collections library?

No, FPC 3.0 was already feature frozen around September last year.

Jonas

Sven Barth
to Jonas Maebe
"Jonas Maebe" wrote 8 lines
Maciej Izak wrote: > > any chance to release FPC 3.0 with Generics.Collections library? No, FPC 3.0 was already feature frozen around September last year.

And as written in the corresponding bug report I'm not really happy with these interface hacks.

Regards,
Sven

Maciej Izak
to Sven Barth
Show quoted text 7 lines
And as written in the corresponding bug report I'm not really happy with these interface hacks. Regards, Sven

So please give any alternative solution (with reasonable efficiency / performance).

Current solution is inspired by you in 2013 :P

2013/5/23 Sven Barth

Show quoted text 6 lines
Why fall back to pointers for something like this if we can use static types?! And if that means that the comparer needs to be implemented for each type, then so be it

My first idea for Generics.Defaults in 2013 was much simpler (and faster than using interfaces), new compiler intrinsic:

  function GetReferenceToValue(Value: T): Pointer;
  function GetValueSize(Value: T): Integer;

Best regards,
Maciej Izak

Maciej Izak
to Michael Van Canneyt: The documentation is the only 'blocking' issue. Maybe for good measure some extra fixes…

Hi,

btw. there is no info about few functions introduced by Generics.Collections patch, as I can see all of my work for RTL is now part of FPC 3.0 compiler ^^ :)

http://bugs.freepascal.org/view.php?id=27206

procedure InitializeArray(p: Pointer; typeInfo: Pointer; elemCount:
NativeUInt);
procedure CopyArray(Dest, Source, TypeInfo: Pointer; Count: NativeInt);
procedure FinalizeArray(P: Pointer; TypeInfo: Pointer; Count: NativeUInt);
procedure DynArrayClear(var A: Pointer; TypeInfo: Pointer);
procedure DynArraySetLength(var a: Pointer; typeInfo: Pointer; dimCnt:
NativeInt; lengthVec: PNativeInt);
function DynArrayIndex(P: Pointer; const Indices: array of NativeInt;
TypInfo: Pointer): Pointer; overload;
function DynArrayIndex(P: Pointer; const Indices: array of Integer;
TypInfo: Pointer): Pointer; overload;
function DynArrayDim(typeInfo: Pointer): Integer;
function DynArraySize(A: Pointer): NativeInt;
function IsDynArrayRectangular(const DynArray: Pointer; typeInfo: Pointer):
Boolean;
function DynArrayBounds(const DynArray: Pointer; typeInfo: Pointer):
TBoundArray;

2015-06-11 16:33 GMT+02:00 Michael Van Canneyt:

Show quoted text 10 lines
The documentation is the only 'blocking' issue. Maybe for good measure some extra fixes need to be merged. I have documented the remaining identifiers in the reference documentation, but the new language features still need to be documented; Normally, the biggest part can be done tomorrow and the day after. After that (as in: as of monday) as far as I am concerned, RC1 may be built.

best regards,
Maciej Izak

Maciej Izak
to Maciej Izak
Show quoted text 6 lines
btw. there is no info about few functions introduced by Generics.Collections patch, as I can see all of my work for RTL is now part of FPC 3.0 compiler ^^ :)

ofc. except generics.* units :)

Michael Van Canneyt
to Maciej Izak: btw. there is no info about few functions introduced by Generics.Collections patch, as I…
Maciej Izak wrote 16 lines
Hi, btw. there is no info about few functions introduced by Generics.Collections patch, as I can see all of my work for RTL is now part of FPC 3.0 compiler ^^ :) http://bugs.freepascal.org/view.php?id=27206 procedure InitializeArray(p: Pointer; typeInfo: Pointer; elemCount: NativeUInt); procedure CopyArray(Dest, Source, TypeInfo: Pointer; Count: NativeInt); procedure FinalizeArray(P: Pointer; TypeInfo: Pointer; Count: NativeUInt); procedure DynArrayClear(var A: Pointer; TypeInfo: Pointer); procedure DynArraySetLength(var a: Pointer; typeInfo: Pointer; dimCnt: NativeInt; lengthVec: PNativeInt); function DynArrayIndex(P: Pointer; const Indices: array of NativeInt; TypInfo: Pointer): Pointer; overload; function DynArrayIndex(P: Pointer; const Indices: array of Integer; TypInfo: Pointer): Pointer; overload; function DynArrayDim(typeInfo: Pointer): Integer; function DynArraySize(A: Pointer): NativeInt; function IsDynArrayRectangular(const DynArray: Pointer; typeInfo: Pointer): Boolean; function DynArrayBounds(const DynArray: Pointer; typeInfo: Pointer): TBoundArray;

These functions have been documented.
All existing identifiers in documented units have been documented.

Michael.