Jump to content
AlekXL

Delphi compiler need to be opensourced

Recommended Posts

Just now, Daniel said:

We startet with the Delphi-compiler and ended with WWII. 😕

Nooo! You can't stop this before it complies to godwin's law 😉

  • Haha 3

Share this post


Link to post
2 hours ago, Stefan Glienke said:

You can't stop this before it complies to godwin's law

At least it already compiles to it.

  • Haha 1

Share this post


Link to post
21 hours ago, Joseph MItzen said:

Meanwhile, the FreePascal crowd has vowed never to accept a patch for type inference. It's generally the smaller the group or less successful the cause that tends to bring out fanaticism.  "The fanatic is one whom, upon forgetting their purpose, redoubles their effort." 

Burn the hereritics!

Seriously, we need to fork fpc..

Share this post


Link to post
13 hours ago, Ugochukwu Mmaduekwe said:

While I feel it is not possible for Delphi to open source it's compiler, I highly doubt there are skilled personnels even willing to invest time to improve it for free.

The bitter truth is that unfortunately the Delphi ecosystem is not as friendly and lively as other languages ecosystem.

A glaring example is the availability of OpenSource libraries to achieve certain operations is no where as vast as that we have in C#, Java or even C++.

The VCL and RTL is a different story though.

1. Any company invested in developing a product written in Delphi and confronting some compiler issue would hire skilled developer to fix it.

2. Be factual, and name the libraries Delphi lacking. And also, Delphi can utilize C/C++ libraries.

10 hours ago, Joseph MItzen said:

The United States is the key country preventing China from extending its reach and enslaving other populaces or taking their territories.

No. US already lost that battle..

Share this post


Link to post
Posted (edited)
On 4/11/2019 at 1:08 AM, Larry Hengen said:

Unfortunately, FMX dies not seem to be as ubiquitous as the VCL.  Perhaps open sourcing that framework would be a catalyst to building a bigger community of third party vendors and developers and keeping pace with all the platforms as they change, but that is another topic.

Perhaps, Embarcadero shouldn't reinvent the wheel , but push VCL to all platforms.. Something like CrossVCL, but also for mobile. By Merlin's sake, buttons are buttons on every platform, as well as listboxes, textboxes, and menus. I guess I need to open another issue on QP, what do you guys think? Or maybe such issue already exists?

And yes, we are on page 3, so if you didn't already vote, please do it

Edited by AlekXL
update
  • Like 1

Share this post


Link to post
2 hours ago, AlekXL said:

Seriously, we need to fork fpc..

NewPascal tried to be such a fork but also died because (I guess) Maciej could not do all by himself and there was nobody else to work on the code. Do you think that another fork could be more successful? Yes I clearly that the FPC compiler development came to a roadblock due to aiming strange goals (I like "More OS/2 support" and "New compiler targets: Support for the i8086-win16 (16-bit Windows) target" as the future plans :classic_mellow:) and THAT is a real problem . Otherwise we could already have a real cross-platform VCL (LCL) combined with a pretty good compiler, while now I just cannot use advanced Delphi libraries (like Grijjy) with FPC and have to use Delphi Linux compiler with its debugging nightmare and no desktop support. And I am honestly afraid that if said Linux desktop is ever implemented it may be FMX-based which means rewriting all UI instead of going the LCL way (one common VCL-compatible layer supported by different widget sets - winapi, gtk, etc).

Share this post


Link to post
4 hours ago, AlekXL said:

Perhaps, Embarcadero shouldn't reinvent the wheel , but push VCL to all platforms..

I think you know that VCL is very closely linked to WinAPI. The special strength of VCL is this depth. 

 

Quote

Something like CrossVCL, but also for mobile.

CrossVCL is available and you can use it. Eugene is fast and has very good support. Mobile is on the evaluation roadmap. What should change through Emba?

Deploying a little WINE with each application has strength and weakness. It's one way, but not the solution for all.

Share this post


Link to post
Posted (edited)
6 hours ago, AlekXL said:

1. Any company invested in developing a product written in Delphi and confronting some compiler issue would hire skilled developer to fix it.

2. Be factual, and name the libraries Delphi lacking. And also, Delphi can utilize C/C++ libraries.

1. Invest enough to cover the cost of further development and improvements to the compiler? At what gain? It's not like the Delphi ecosystem is really booming.

 

2. An example of such are Cryptographic Libraries and please don't tell me that Delphi can utilize C/C++ libraries because you and I know how unfriendly that can be (especially finding already compiled libraries for other platforms other than windows) coupled with the problem of distributing the extra binary files.

Using C++ libraries was ok at a time when Delphi was Windows only but please we are in the Cross Platform era now. 

 

And please do note that I am referring to free OpenSource maintained libraries not closed source sharewares.

Edited by Ugochukwu Mmaduekwe

Share this post


Link to post
5 hours ago, Alexander Elagin said:

NewPascal tried to be such a fork but also died because (I guess) Maciej could not do all by himself and there was nobody else to work on the code. Do you think that another fork could be more successful?

Do I need to repeat myself? "One must try"... It's not what we believe in, it's what we do. Yes, there are some hardcore developers here, we need to build up a team, and we need to figure out practical steps to do. Those who are prominent should pledge that they will contribute.. As for plan.. Let me suggest one, for discussion.

 

[0.  take newpascal and merge with latest trunk]

1. merge (3-way) with attributes patch, it's most recent

2. merge either with [blaise/closures] or Kevroletin patch

3. figure out about inline vars and type inference

 

Do we need to take step 0? Share your opinion, guys

Quote

Yes I clearly that the FPC compiler development came to a roadblock due to aiming strange goals (I like "More OS/2 support" and "New compiler targets: Support for the i8086-win16 (16-bit Windows) target" as the future plans :classic_mellow:) and THAT is a real problem . Otherwise we could already have a real cross-platform VCL (LCL) combined with a pretty good compiler, while now I just cannot use advanced Delphi libraries (like Grijjy) with FPC and have to use Delphi Linux compiler with its debugging nightmare and no desktop support.

Go senile, probably. Excactly, we must explicitly drop bizzaire platforms. Lets not stretch thin.

0. Delphi compatibility is paramount

1. In fact, at start we should focus only on two- WIntel, and AndroArm.

2. Those who need linux, must do it themself  and test their patches not on linux, but ensure also, that those won't break 2 major platforms. Or they full-refund pay.

3. Those who need an Apple platforms, need to contibute [and pay]. Obviously those minor platforms are targeted for gain

4. We need to redistribute binaries for pre-build Lazarus+NewPascal. Newest beta-releases need to be adopted easily. Lazy developers are good substitution  for lab rats.

Quote

And I am honestly afraid that if said Linux desktop is ever implemented it may be FMX-based which means rewriting all UI instead of going the LCL way (one common VCL-compatible layer supported by different widget sets - winapi, gtk, etc). 

Yes, the LCL is the way to go, until we figure out if there are any better ways.

Share this post


Link to post
4 hours ago, RonaldK said:

CrossVCL is available and you can use it. Eugene is fast and has very good support. Mobile is on the evaluation roadmap. What should change through Emba?

Deploying a little WINE with each application has strength and weakness. It's one way, but not the solution for all. 

They should buy it, probably.

Share this post


Link to post

All of this is basically a fantasy.  The odds that EMBT/Idera would consider doing it, are slim to none, IMO.

  • Like 1

Share this post


Link to post
Guest
6 minutes ago, Lars Fosdal said:

All of this is basically a fantasy.  The odds that EMBT/Idera would consider doing it, are slim to none, IMO.

Well, Emba has an eye on MS and Visual Studio and C#. 

 

They port libraries from C# (Newtonsoft.Json, TPL, ...),

provide a community edititon like Visual Studio (CE is the Pro Version for both),

and I bet they already had discussed that internally (Delphi-based Delphi-compiler and open-source it).

 

IMHO the main problem for Emba is the Delphi-based Delphi-Compiler and not open-source it when it is done

Share this post


Link to post
Posted (edited)
15 minutes ago, Lars Fosdal said:

All of this is basically a fantasy.  The odds that EMBT/Idera would consider doing it, are slim to none, IMO.

Well, I need to repeat myself again, need I? It never gets old.

On 4/8/2019 at 3:53 AM, AlekXL said:

One must try, that's what I believe. If my proposal is to be rejected, so be it, I just need to do my utmost for this or either to happen, and then consider other options.

At least I wouldn't despise myself for never even trying, just others, you know. 

Lars, just please don't sabotage the discussion and the cause, will you?

Besides, we are already considering other options , it's part of the plan.

4 hours ago, RonaldK said:

Deploying a little WINE with each application has strength and weakness. It's one way, but not the solution for all.

Well, FMX already proved it's weakness -- huge executable, slow, buggy, and not compatible with VCL, even there compatibility was possible

Edited by AlekXL
typos

Share this post


Link to post
4 minutes ago, AlekXL said:

 

Well, FMX already proved it's weakness -- huge executable, slow, buggy, and not compatible with VCL, even there compatibility was possible

I can only partly agree to this.

In new projects I use meanwhile 90% FMX, and simply avoid all the buggy parts, by using the essential components only.


Regarding VCL-compatibility, I would love to see this vice versa, maybe make VCL more compatible to FMX.
Indeed a few simple changes could make code much more compatible, but the question is if its worth the efford.

  • Like 1

Share this post


Link to post
28 minutes ago, AlekXL said:

[0.  take newpascal and merge with latest trunk]

1. merge (3-way) with attributes patch, it's most recent

2. merge either with [blaise/closures] or Kevroletin patch

3. figure out about inline vars and type inference

I wonder if Sternas Stefanos (CodeTyphon, you know) considered this option. As far as I can see, his CT bundle uses FPC trunk.

Share this post


Link to post
Posted (edited)
5 minutes ago, Alexander Elagin said:

I wonder if Sternas Stefanos (CodeTyphon, you know) considered this option. As far as I can see, his CT bundle uses FPC trunk.

Unfortunately, the CodeTyphoon team seems more focused on the IDE than the compiler.

Edited by Ugochukwu Mmaduekwe

Share this post


Link to post
Posted (edited)
3 hours ago, Ugochukwu Mmaduekwe said:

An example of such are Cryptographic Libraries

Which algorithm or hash Delphi is lacking?

3 hours ago, Ugochukwu Mmaduekwe said:

don't tell me that Delphi can utilize C/C++ libraries because you and I know how unfriendly that can be (especially finding already compiled libraries for other platforms other than windows) coupled with the problem of distributing the extra binary files

well  C/C++ libs (cross)compilation  is the pain, but unlike python or java, you'll get fastest solution in the end of the day.

Edited by AlekXL

Share this post


Link to post
28 minutes ago, AlekXL said:

Lars, just please don't sabotage the discussion and the cause, will you?

Agreed. There is no need for others to sabotage anything. You are perfectly capable of sabotaging both the proposal and this discussion on your own.

 

  • Like 5

Share this post


Link to post
13 minutes ago, Ugochukwu Mmaduekwe said:

Unfortunately, the CodeTyphoon team seems more focused on the IDE than the compiler. 

Unfortunately, last time I checked CT intentionally broke basic compatibility with Lazarus. For what end, need I ask?

Share this post


Link to post
Just now, Dalija Prasnikar said:

Agreed. There is no need for others to sabotage anything. You are perfectly capable of sabotaging both the proposal and this discussion on your own

Bite me! Do it better, if you can.

Share this post


Link to post
49 minutes ago, AlekXL said:

Which algorithm or hash Delphi is lacking?

Asymmetric Cryptography especially stuffs involving elliptical curves like Edwards curves.

Share this post


Link to post
Posted (edited)
19 minutes ago, Ugochukwu Mmaduekwe said:

Asymmetric Cryptography especially stuffs involving elliptical curves like Edwards curves. 

https://github.com/Xor-el/CryptoLib4Pascal rings any bells?

Quote

Supported signing algorithms 

ECDSA
NONEwithECDSA, SHA-1withECDSA, SHA-224withECDSA, 
SHA-256withECDSA, SHA-384withECDSA, SHA-512withECDSA and RIPEMD160withECDSA

ECSchnorr
SHA-1withECSCHNORRSIPA, SHA-224withECSCHNORRSIPA, SHA-256withECSCHNORRSIPA, SHA-384withECSCHNORRSIPA,
SHA-512withECSCHNORRSIPA, RIPEMD160withECSCHNORRSIPA

isn't it your project?

Edited by AlekXL

Share this post


Link to post
Guest
This topic is now closed to further replies.

×