RonaldK

47 minutes ago, nozz said:

I would bet most Delphi users hold a license for the Professional edition so I kinda understand why they would gate Linux support. It's a good short term business decision but it also means less bugs will be reported and it will take longer for the platform to mature.

One reason could have been the new RAD server. 

20 minutes ago, David Heffernan said:

What kind of business model is it to take money of your customers and then spend it on developing functionality that is not useful to the majority of your customers?

The lonely wish that Delphi once again becomes a bright light in the forefront, not just chasing after the story.

This long running behind makes more and more the feeling that at some point the compiler will not come anymore

and the part for Android, iOS and macOS will end at some point.

I am of the opinion that if you go the way of the different platforms, then with full force ... or not at all.

This half-dead is not a business model.

15 minutes ago, Markus Kinzler said:

Because the macOS 64-Bit version scheduled for 10.3 is still missing.

It's re-scheduled to 10.3.x. 
I would assume it's included in the next Service Pack before the release of the 10.4.

15 hours ago, Remy Lebeau said:

...  There has been NO announcement from Embarcadero since August 2018 about how they plan to address the Android 64bit issue.  There has been NO announcement of a new Delphi version in the works to include a 64bit Android compiler.

It's on the roadmap for 10.4.x (Mid 2019)
https://community.idera.com/developer-tools/b/blog/posts/rad-studio-august-2018-roadmap

But you're right. 

It's hard to believe that Emba will deliver on time.

There is another nice "Enterprise feature" in the Linux compiler (still open):

Linux x64 compiler produce very bloated code.

https://quality.embarcadero.com/browse/RSP-17724

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.

1 hour ago, RDPasqua said:

... then will ask to Sergey to do a FMX similar layer over it, for windows, osx, android and ios.

... or do you mean Eugene (the father of FMX)?

I dont think that an open source Compiler or another Compiler makes it better. 

The current weakness of Delphi is the lack of a good development team behind Delphi.
In my view, the step away from the own development team was a fatal mistake.

10 minutes ago, Dalija Prasnikar said:

Core issue is in LLVM https://bugs.llvm.org/show_bug.cgi?id=1269 

 

While in theory it would be possible to address this issue from Delphi side, it is probably as hard as solving it on LLVM side for the similar reasons. 

Well, back to the title of this thread. Isn't LLVM open source and thus problems will be fixed better and faster? 

Shared Memory:

https://stackoverflow.com/questions/5646202/sharing-data-array-between-two-applications-in-delphi

7 hours ago, Tom F said:

One other comment: if EMB fails to deliver in a timely manner a viable version that allows us to create 64 bit Mac apps, we'll be really, REALLY unhappy  that we'll be unable to ship our product. 

If Apple keep their update frequency, the non 32Bit macOS will touch the ground in Sept. this year.

The 64Bit macOS compiler is shifted to version 10.3.x.  

Rio was released at 21.Nov. 2018. It took 3 month to release service pack 1 for "only" some bug fixes.

If you look back to the other deadlines for Delphi: Like iOS 64 Bit, Android API level,  ...

It's hard to believe that the new macOS compiler will be available in time.

29 minutes ago, Markus Kinzler said:

And starting september Google also askes for 64 Bit native apps (ndk).

Yes, but you can run existing/old 32 bit apps.

I fear that you cant do this on the next macOS.
Any company with 32 bit only, will get out of business on this platform.

8 minutes ago, Uwe Raabe said:

The road map mentions 10.3.x, so I guess we can expect at  least a 10.3.2 in the next months.

The roadmaps before planned this for Tokyo, then Rio, then Rio service pack 1. 

Now it's officially 10.3.x, not directly 10.3.2. Just Matthias mention this.

It's hard to believe that it will be available in time and Firemonkey will fully work with the new compiler. 

Is there any time frame for 10.3.2?
When Apple keep there release date cycle of macOS, we can except, that the new macOS without 32Bit support will be in Sept. this year.
 

What about 64Bit compiler for macOS?

Wasn't that scheduled for Rio Service Pack 1?

1 hour ago, John Kouraklis said:

I know how to get the used memory for a process (.exe file) but how do I handle a procedure?

If the procedures works sequential, set flags while entering and leaving the procedure and ask the MemoryManager from a TThread how many memory is currently used.

Are you using the new Skins/Themes in the IDE?

It's better when you disable it?