Recent

Author Topic: NewPascal plans, Generics.Collections and FPC trunk  (Read 50073 times)

valdir.marcos

  • Hero Member
  • *****
  • Posts: 1106
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #45 on: May 09, 2018, 10:54:33 am »
I was thinking of solutions similar to:
https://jenkins.io/
https://travis-ci.org/
https://www.gocd.org/

To easy and improve environments such as:

Ok, so for development of applications WITH Lazarus and FPC, not development ON lazarus and fpc.

Lazarus ran Jenkins for a while, iirc  if after a commit there was no new commit in 5 minutes or so.

Personally, I think it is more stuff for teams than for single developers. Getting deep into these systems also takes time, and for one machine administered by one person a few simple scripts are easier. At least IMHO.

Of course it probably it is less of a problem if you already use some of the techniques, but I don't maintain any LAMP or alternatives (webservers, web serverside scripting languages, and I haven't touched Java seriously in a decade), both experience or maintenance, so for me that would be all extra burdens just to use one of these packages and or develop plugins for them.

Afaik Lacak who does a lot of SQLDB work, has an own testsuite.
I understand and respect you point of view.
The solution I was talking about was meant for teams, from small through big ones.

hnb

  • Sr. Member
  • ****
  • Posts: 270
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #46 on: May 09, 2018, 11:03:41 am »
I was thinking of solutions similar to:
https://jenkins.io/
https://travis-ci.org/
https://www.gocd.org/

the part of work is ready in NewPascal and in my personal repositories. The tests and fresh releases are uploaded automatically.

The Michael said that CI is almost impossible to fully integration with FPC. IIRC he said that CI can't be used for generation of documentation and he need to do some things manually. If I am wrong please someone to correct me. In my opinion such thing should be also possible with CI, but maybe there is some problem which I am not aware of (I didn't trying to use CI for FPC documentation).
Checkout NewPascal initiative and donate beer - ready to use tuned FPC compiler + Lazarus for mORMot project

best regards,
Maciej Izak

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #47 on: May 09, 2018, 11:11:21 am »
The Michael said that CI is almost impossible to fully integration with FPC. IIRC he said that CI can't be used for generation of documentation and he need to do some things manually. If I am wrong please someone to correct me. In my opinion such thing should be also possible with CI, but maybe there is some problem which I am not aware of (I didn't trying to use CI for FPC documentation).

Why not? Technically speaking CI servers just run scripts!
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

hnb

  • Sr. Member
  • ****
  • Posts: 270
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #48 on: May 09, 2018, 11:17:52 am »
Why not? Technically speaking CI servers just run scripts!

I said similar thing but Michael was in opposition to the idea, he allows me to doing this but was not much optimistic. You should ask Michael, I have no idea why this is impossible (or so hard). I will say it again : I was not trying this yet, so maybe there is some problem.
Checkout NewPascal initiative and donate beer - ready to use tuned FPC compiler + Lazarus for mORMot project

best regards,
Maciej Izak

x2nie

  • Hero Member
  • *****
  • Posts: 515
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #49 on: May 09, 2018, 11:42:29 am »
wait, gurus....


This discussion has given me a bigbang headache because I couldn't catch what really we are talking about.
Before going more further, so please,
1. what is "NewPascal" meaning?  (I visit the link and found nothing about technical advantage upon fpc)
Is it a brand new pascal dialect compiler (like PicPas doing) ?
2. What is the "modern" things which NewPascal provides?
3. In which situation NewPascal will beat better than fpc/trunk can do?

What I understood is: Mormot will deadly depend on NewPascal, but I don't know the detail reason.
 :-*
---correct me if I wrong
« Last Edit: May 09, 2018, 11:44:46 am by x2nie »
When you were logged in, you can see attachments.
Lazarus Github @ UbuntuCinnamon-v22.04.1 + LinuxMintDebianEdition5

Thaddy

  • Hero Member
  • *****
  • Posts: 16653
  • Kallstadt seems a good place to evict Trump to.
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #50 on: May 09, 2018, 11:50:31 am »
wait, gurus....


This discussion has given me a bigbang headache because I couldn't catch what really we are talking about.
Before going more further, so please,
1. what is "NewPascal" meaning?  (I visit the link and found nothing about technical advantage upon fpc)
Is it a brand new pascal dialect compiler (like PicPas doing) ?
It is a fork. With a focus on Delphi syntax (which is good imho)
Quote
2. What is the "modern" things which NewPascal provides?
Not many, yet. If any at the moment.
Quote
3. In which situation NewPascal will beat better than fpc/trunk can do?

What I understood is: Mormot will deadly depend on NewPascal, but I don't know the detail reason.
 :-*
---correct me if I wrong
Possibly - but I did not see any real evidence yet - quicker -riskier? -implementation of some more Delphi compatible features, like ARC, anonymous methods (compiler) and extended generics (very good implementation, but also in fpc trunk). None of these are in NewPascal yet, as I understand. (Correct me if I am wrong Maciej)
IMO High risk without the core team. I test it now and then but do not use it. Maciej is a very talented developer, but the ONLY developer for NewPascal's compiler.
I also want a thorough code review to test clean-room. That is not to be critical in any way but to make sure. Do not read any suggestion in that remark.

Thing I most like is default properties for non-array types. (Related to ARC and smart pointers)
« Last Edit: May 09, 2018, 12:09:05 pm by Thaddy »
But I am sure they don't want the Trumps back...

hnb

  • Sr. Member
  • ****
  • Posts: 270
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #51 on: May 09, 2018, 12:12:40 pm »
1. what is "NewPascal" meaning?  (I visit the link and found nothing about technical advantage upon fpc)
Is it a brand new pascal dialect compiler (like PicPas doing) ?
2. What is the "modern" things which NewPascal provides?
3. In which situation NewPascal will beat better than fpc/trunk can do?

What I understood is: Mormot will deadly depend on NewPascal, but I don't know the detail reason.

NewPascal means New(Pascal) ^^. NewPascal sooner or later will be also new mode/dialect for compiler.

When I was part of FPC core almost all stuff was successful ported to FPC trunk including new features, bug fixes and improvements, generally all was merged except "default field" functionality which is used for SmartPointers, ARC objects and Nullable types.

So for now the main/general difference between trunk and NewPascal is Smart Pointers functionality: https://github.com/maciej-izak/PascalSmartPointers

My ban is fresh so there is not much new patches in NewPascal yet, finally I was part of FPC core team and NewPascal was almost fully integrated with FPC core.

With NewPascal you will get all what you have with trunk, but with many additions :
- Ready to use pre-compiled trunk (trunk version for NewPascal is selected to provide as stable trunk as possible without regressions)
- Patches
- New modern features

NewPascal will be better in the situations:
- When you use Generics.Collections library (I am main author so for sure NewPascal version is more actual and more bug free)
- When you use mORMot. Advantage of NewPascal is close cooperation with mORMot, so every change in critical parts of NewPascal (RTL, low level details) are handled in mORMot immediately. FPC trunk is also supported but in some situations update for mORMot may be delayed (and mix of FPC trunk and mORMot may be nonfunctional/full of bugs for some time). mORMot will be compatible with pure trunk, why not? mORMot is freedom of choice.
- When you like to use modern Pascal with more Oxygene like syntax.
- When you like to have faster code - you don't need to use modern syntax, you can still be compatible with FPC trunk but I have ready very important patches for compiler to speed up all code where managed types are used (strings, dynamic arrays, interfaces etc.). The difference with extensive usage of managed types between NewPascal and trunk can be really huge.
Checkout NewPascal initiative and donate beer - ready to use tuned FPC compiler + Lazarus for mORMot project

best regards,
Maciej Izak

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12110
  • FPC developer.
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #52 on: May 09, 2018, 12:19:01 pm »
On one side, everybody agrees that both FPC and Lazarus need more and more volunteers, especially from younger generation to ensure these great projects will have a bright future. But on the other side, sometimes new people aren't very welcome to contribute if this new people doesn't conform to the seniors way of thinking.

Or if they have problems cooperating and functioning in a team with people with different priorities etc. Posting mails like this doesn't help, and I understand there was also some friction in personal mails between Michael and Maciej.

Nobody is happy on how this went down, but the common view on this is simply wrong. Note that when Maciej became committer, there were already some reservations about temper and cooperation with part of core, but due to huge work done, it was given the benefit of the doubt.

However the comparisons with other cases in this thread is systematically wrong, and is usually based on exit mails of frustrated people that had cooperation difficulties, and threw a tantrum when they didn't get their way soon enough, or when core didn't drop everything they were doing and rallied around their opinion. Most never got as far as Maciej did. Often they did even get as far as Maciej before he made core even.

In this case it is fairly unique.

Quote
This Maciej's case is the latest example, but I've seen similar cases since I joined FPC/Lazarus.

Maciej's case is different, because he made committer and actually functioned quite alright for quite a while. People usually grow significantly when they do that, also in cooperation perspective. The only somewhat similar case is Almindor aka Ales Katona in the 2005-2008 timeframe.

He was terribly noisy and radical as early user and bugreporter, but as he grew older and made core he adapted. Parts of fcl-web and LNet are still his. His exit however was more related to changes in his personal life (graduation and marriage). Lnet became only part of FPC after he left.

Quote
On one side, everybody knows that we need to get popular so this project could attract both volunteers and fundings, especially from younger generation.

It wouldn't hurt, certainly.

Quote
But on the other side, I don't see much effort has been done to overcome this problem.

The problem is that most people wait for commitment from an overworked core or some revolution and then throw a tantrum when it doesn't happen. Things take time, and significant commitment and persistent.

The list is numerous fcl-web, fcl-db (multiple people actually Sebastian Michael Joost Lacak), fpreport half of packages is from people that came and wanted to add but did cooperate.

Maciej also belongs to that list because rtl-generics is there, nevermind what happened after or what will happen in the future. And that is just FPC, there are also his contributions to Lazarus

Quote
The core devs barely think about it, because they mostly think about the technical things.

They have seen 50 such initiatives stumble because the people starting it burned out. They all start too hot and expect change and uptake on a too short timescale and get frustrated. Paradoxically some of those effort succeed later building on those initially failed initiatives. Sometimes by the same person, older and wiser, sometimes by somebody else, and sometimes because it slowly evaluates to become mature enough to be maintained by core and patch submitters.

Quote
I don't blame them because it's their focus and concern, but if nobody would tackle and handle these non-technical problems, then we'll getting nowhere.

Plans are not the problem. The manpower to do them is. And the radicals usually burn out before their goals are met. Even partially.

Quote
We'll be forever a niché in software development. Nobody cares about Pascal but a bunch of old people who still maintaining their projects in their niché market.

It is possible that remains the case. Most languages are pushed by giga large enterprises. Even with sometimes-paid committers you might not be able to duplicate that.

I think it is better to focus on some uses where strengths lie, than to spread the resources too thin trying to duplicate things in popular fields where you never be considered an equal anyway. Or at least find a clear different angle than just "Pascal".

Quote
Now I think I understand why CodeTyphon chose its way. Rather than contributing directly to the project, Sternas (CT's author) simply took the project with him and do it his way so he didn't need to bother with core devs approvals and agreements.

Sternas had never any serious relation or cooperation with core. The project grew from a distro within his company where he combined development versions with his own patched Delphi packages. He had some very doubtful practices like renaming all files, removing or editing copyright messages and not keeping the originals, that made usage of those packages within FPC or Lazarus impossible. There were some attempts to reason with him, but he was unwilling to improve his ways, and that was about it. It was never on any serious level.

Afaik the people working on the lazarus packages repository actually go back to the original packages and merge in CT fixes if necessary, but don't base themselves on CT originals.

Quote
Although he did some nasty things with the licenses, but look… FPC/Laz devs don't mind, even support him.

Not that I know. Most work is duplicate effort which could have been avoided if Sternas had cleaned up his act.

Quote
So, I think Maciej's decision to work on his own FPC fork is correct. As long as he keeps following FPC development and base his work on it, I'll support him.

I think it is unfair to compare Maciej with Sternas. Before he made core, Maciej was already accountable, and during core he improved how he delivered his changes.  Also I see CT more as a distribution with a external packages than a fork. The real work is fairly thin. Newpascal had original new work from the beginning.

A fork is always bad, if only due to the synchronization, but maybe the impact is not too bad long term.

Short term, the impact is horrible. Somewhere in the coming 6-9 months a new major branch must be made for stabilization, and some things could have made it which now won't. This is horrible.

Quote
Maybe it's time for FPC and Lazarus to have a new "competitor" other than Delphi so they will start to be more open minded accepting new ideas from new people.

We were, and accepted Maciej as core as a result of it.

Quote
If Maciej keeps continuing his work and regularly release stable New Pascal with new features that offers something more than the orginal FPC, I'm sure New Pascal would have its own users and fans. Just like CodeTyphon.

For now I consider it a testbed and development snapshot for Mormot, some of which will remain "unstable" for a long term, see above.
« Last Edit: May 10, 2018, 12:43:18 pm by marcov »

Thaddy

  • Hero Member
  • *****
  • Posts: 16653
  • Kallstadt seems a good place to evict Trump to.
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #53 on: May 09, 2018, 12:38:11 pm »
Marco,

Well written.

Tnx.
But I am sure they don't want the Trumps back...

ASBzone

  • Hero Member
  • *****
  • Posts: 717
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #54 on: May 09, 2018, 02:47:16 pm »
Marco,

Well written.

Tnx.

I agree.   :D    And I appreciated the background, too.

I am relatively new to this technical community, but not to technical communities in general.    From the little that I have observed, this community has some seriously skilled persons, and there are almost assuredly going to be personality conflicts in such a gathering.

As the saying goes, "This too shall pass."

Regardless of how everyone feels right now, I would strongly advise the principal players to avoid any unnecessary and potentially hurtful comments -- especially in the short-term.  These things often blow over in time, and as everyone matures or expands their perspectives (I'm not suggesting immaturity on anyone's part -- just referencing how life works), the opportunity to revisit this issue from a different angle might manifest itself.  This is far less likely to occur if the next few days and weeks are spent with recriminations and counterpoints that get posted to the eternal web.

If moving apart and working separately is a good course for now, it will be best done quietly, as there is less ego to retract or subdue later. 

I thank the parties who are trying to get things to cool down, and I appeal to those in the thick of things to move forward cautiously.   I'm not here to take sides, and thankfully I'm new enough that the lack of bias should be obvious (despite Maciej helping me out just yesterday).

I hope it all works out, for everyone involved, regardless of which direction things go from here, and that the Object Pascal community is enriched by it.
-ASB: https://www.BrainWaveCC.com/

Lazarus v3.5.0.0 (2216170cde) / FPC v3.2.3-1387-g3795cadbc8
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 866
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #55 on: May 10, 2018, 11:38:26 am »
NewPascal means New(Pascal) ^^. NewPascal sooner or later will be also new mode/dialect for compiler.
I don't need much. I just need my crazy Delphi code to compile.
Code: Pascal  [Select][+][-]
  1.     ATestCase.AddTestCase(
  2.       'Slice test',
  3.       True,
  4.       function(var ASource:TAbstractPairList<TTestObject, String>):TAbstractPairList<TTestObject, String>
  5.         var Keys:TAbstractList<TTestObject>;
  6.       begin
  7.         CreateKeyObjectKeyRange(ASource).AssignInit(Keys);
  8.         Result := KeyObjectPairListFromKeyList(
  9.           Keys.Slice(1, -2, 2)
  10.         );
  11.         Keys.Detach;
  12.       end,
  13.       ArrayOfKeyObjectPair(
  14.         [1, 2, 3, 4, 5, 6, 7, 8, 9, 10],
  15.         ['j', 'i', 'h', 'g', 'f', 'e', 'd', 'c', 'b', 'a']
  16.       ),
  17.       ArrayOfKeyObjectPair(
  18.         [3, 5, 7],
  19.         ['', '', '']
  20.       )
  21.     );
  22.  
What I want to add, is that it's actually dream of every programmer - to add features directly to compiler in order to make code more simply. I would personally add some meta-programming features to compiler in order to remove some routine code from my projects, that could be automated by compiler, so there would be much less room for errors. Some sort of advanced operator overloading. And also some multiple inheritance improvements, such as "subclass" feature or something. And it's core paradigm of Open Source: if you want something - do it yourself. And I've even tried, cuz I've got tired of 10 years of waiting for Delphi 2009 support. But... I guess, it's too much for me. FPC code has relatively low quality. I mean, it's hard to understand it's structure and there are no docs or good comments. Yeah, here is parser, here are nodes, here is code generator, here is assembler, but... I see whole picture, but it's not enough - I need details. And there is no place, I can get them from.
« Last Edit: May 10, 2018, 12:56:28 pm by Mr.Madguy »
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12110
  • FPC developer.
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #56 on: May 10, 2018, 12:33:32 pm »
For major work and restructures, yes this can take some while. For short patches it is significantly quicker.
For short patches generally it works in this way, but this is not the rule. If no one from core is interested, the patch can wait long time (even short patch).

Yes, all possible.

Quote
If I have ban for trunk without rational reason, I think that my patch can be rejected also without rational reason also my bug report can be simple ignored with malice (what I'm afraid of).

... but don't get paranoid.

Quote
The general fact about redundant work from my side is still valid. Could you explain me the sense of redundant work? Why I am forced to fill bug report for every minor thing instead of working on more fixes?

Spite is not sensible either. If you have minor patches to stuff already in trunk, please commit them.

Let's all cool down, and get some work done.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12110
  • FPC developer.
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #57 on: May 10, 2018, 12:40:51 pm »
The Michael said that CI is almost impossible to fully integration with FPC. IIRC he said that CI can't be used for generation of documentation and he need to do some things manually. If I am wrong please someone to correct me.

Maybe. But those would probably be fairly minimal, and maybe solutions could be found. And even if it were insurmontable, one could leave the docs out of the daily CI, and only run it once every two weeks controlled.

Lazarus documentation is more often than not in a non-compilable state. They require a new file xml to be generated and checked in for every new source file, and the procedure breaks on that. Last try is in 3.0.4 building times.

Another issue is that fpdoc uses fcl-passrc which evolves extremely fast due to pas2js. The CHM generation has problems because of it.

Quote
In my opinion such thing should be also possible with CI, but maybe there is some problem which I am not aware of (I didn't trying to use CI for FPC documentation).

I think it would be possible, but might require work and careful following up a period of a couple of months. Docs never has had much work done outside release periods.  We all do minor spelling fixes, but usually Michael documents new units during a release cycle.

I do have doubts about releasing the CI results though. (iow having daily or even per commit completely built releases)

So it would be tests only, and anything outside the core "fpc" repo mutates so slowly it is a terrible waste of cycles and space IMHO. Let the poor polar bear live!

Trigger full release building every two weeks

But having a jenkins or something else compilng the FPC main repo again would be good. Lazarus ran it for a while with results to the irc channel and that was nice.

For the FPC project I do favor own build tools over complex external packages though. Simply because work in the language that binds us in the project can be done by more people than in an external language.
« Last Edit: May 10, 2018, 12:51:58 pm by marcov »

hnb

  • Sr. Member
  • ****
  • Posts: 270
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #58 on: May 10, 2018, 01:57:47 pm »
I don't need much. I just need my crazy Delphi code to compile.

This should happens soon with NewPascal and maybe with FPC too. :)

What I want to add, is that it's actually dream of every programmer - to add features directly to compiler in order to make code more simply. I would personally add some meta-programming features to compiler in order to remove some routine code from my projects, that could be automated by compiler, so there would be much less room for errors. Some sort of advanced operator overloading. And also some multiple inheritance improvements, such as "subclass" feature or something.

I fully understand this and this is for sure subject of my work. The idea of non existing yet "NewPascal" dialect is strong support for meta programming in very clean "Pascal" way with full assistance of existing dialects and well known RTL. The tools like YACC or boost:spirit library should be replaceable by NewPascal dialect in long term future.
Checkout NewPascal initiative and donate beer - ready to use tuned FPC compiler + Lazarus for mORMot project

best regards,
Maciej Izak

hnb

  • Sr. Member
  • ****
  • Posts: 270
Re: NewPascal plans, Generics.Collections and FPC trunk
« Reply #59 on: May 10, 2018, 02:00:55 pm »
Spite is not sensible either. If you have minor patches to stuff already in trunk, please commit them.

Let's all cool down, and get some work done.

Thanks for professional approach. So do I have full svn access again? I always plays with rules : in trunk you will not find any commit for critical parts of compiler nor for RTL which was not consulted with Sven, Florian, Michael (!) or Jonas (in this context Michael e-mail was real shock for me). There was some small patches for critical parts but only when I was 100% sure that the patch is correct and tested (which was also approved by Florian - so the rules were followed all the time).

For less frustration for both sides would be good to keeps both projects alive. I can continue NewPascal with my ideas and vision but at the same time I see no reason why FPC should not benefit from my work in less "neuralgic" code parts. If the core will change opinions about new features from NewPascal any of feature can be merged back into FPC trunk. IMO this path is beneficial for all. In the worst scenario I will "burn out" (which is not planned by me) but in general FPC will be better.
« Last Edit: May 10, 2018, 02:25:36 pm by hnb »
Checkout NewPascal initiative and donate beer - ready to use tuned FPC compiler + Lazarus for mORMot project

best regards,
Maciej Izak

 

TinyPortal © 2005-2018