It's been a while since the last road map.
It's been a while since the last road map.
Until the powers that be provide us a new one - what feature(s) would you like to see in the next Delphi city?
Some of my whimsical desires include...
- More fixes for known issues
- Proper High DPI management built into VCL (multi DPI image lists, etc) and a proper overhaul for the IDE to rid it of scaling issues
- RTL performance improvements for generics and multithreaded memory management
- A default out-of-the box cross-platform exception stack tracer with API for plugging in enhanced custom stack tracers, information providers and logging mechanisms
- Code generation improvements utilising more modern CPU features
- Beacon/IoT support for VCL/Windows platform
Until the powers that be provide us a new one - what feature(s) would you like to see in the next Delphi city?
Some of my whimsical desires include...
- More fixes for known issues
- Proper High DPI management built into VCL (multi DPI image lists, etc) and a proper overhaul for the IDE to rid it of scaling issues
- RTL performance improvements for generics and multithreaded memory management
- A default out-of-the box cross-platform exception stack tracer with API for plugging in enhanced custom stack tracers, information providers and logging mechanisms
- Code generation improvements utilising more modern CPU features
- Beacon/IoT support for VCL/Windows platform
I'd like to see an AppMethod exe for Mac entirely based on cross-platform code :)
ReplyDeleteI'd like to see threadsafe Set8087CW and SetMXCSR, and a change to the handling of external exceptions to no longer modifies 8087CW and MXCSR.
ReplyDelete64 bit IDE :-)
ReplyDelete+1 for the high DPI management
ReplyDeleteLess new bugs, fixing existing ones.
ReplyDeleteI'd be happy with high dpi and much more stable IDE(the only thing that actually makes one productive from the whole package IMO)
ReplyDeleteHigh performance datasnap?
ReplyDelete- High DPI VCL
ReplyDelete- New code gen (via compiler switch): SSE...etc.
- Up to date modernized VCL (paths, regions, PDF, PS, etc)
... and finally
ReplyDelete-Linux + Webbroker
I'll dream big:
ReplyDelete- Vastly improved type deduction for generic type parameters.
- Lambda keyword/syntax for short anonymous methods.
- New generic constraint "enumerable", so I could use "for..in" inside my generic methods on instances of the generic type.
Asbjørn Heid I don't think that there should be any need for an enumerable constraint. The existing class constraint should be enough. So this really should compile:
ReplyDeletetype
TMyClass = class
private
type
TEnumerator = record
private
FCurrent: Integer;
public
property Current: Integer read FCurrent;
function MoveNext: Boolean;
end;
public
function GetEnumerator: TEnumerator;
end;
TMyGeneric = class
public
procedure Foo(Instance: T);
end;
{ TMyClass.TEnumerator }
function TMyClass.TEnumerator.MoveNext: Boolean;
begin
end;
{ TMyClass }
function TMyClass.GetEnumerator: TEnumerator;
begin
end;
{ TMyGeneric }
procedure TMyGeneric.Foo(Instance: T);
var
i: Integer;
begin
for i in Instance do
;
end;
But it does not. It fails with
[dcc32 Error] Project36.dpr(41): E2430 for-in statement cannot operate on collection type 'T'
On the other hand if the loop is written like this:
for i in TMyClass(Instance) do
Then all is sweetness and light.
An enumerable constraint would likely not fit into the existing generics design. The reason being that the compiler does the compilation on the generic type rather than the specializations. Now, if you had an enumerable constraint, that would not fit because GetEnumerator can be implemented in many different ways. Each specialized type might implement it differently.
Ref. Generics - I would like to specify Enumeration as constraint so that I could use enumeration functions like Ord(T(Item)) and define internal types like Set of T and use set operators;
ReplyDelete+Lars Why not ord(Item)?
ReplyDeleteDavid Heffernan But that would not allow me to pass a record or interface instance, both which can satisfy the enumerable condition, nor arrays.
ReplyDeleteThe compiler currently does duck-typing-style lookups for this, so I'm thinking it should/may be possible to plug the machinery which determines if some type T supports enumeration into the generic constraint verification routine.
Lars Fosdal In general I long for user-definable constraints, but I'm trying to be half-way realistic here :)
David Heffernan Because you can't do Ord on a variable of type T as it is not constrained to an enumerated type - similar to the way you can't do T.Create on a T that is not constrained to a class with a parameterless constructor.
ReplyDeleteThat said: There are workarounds - but it's a bit kludgey: Example:
[TestFixture]
TestConstantEnumToStrings = class
private
protected
function TestConstantEnumToStrings.TestEnumToString(const Method: TEnumToStringFunc; Language: String): Boolean;
type
PointerOfT = ^T;
var
EnumAsString: String;
CaseResult: Boolean;
ix: Integer;
TI: PTypeInfo;
fx,tx: Integer;
begin
Result := True;
TI := TypeInfo(T);
Assert.IsTrue(TI.Kind = tkEnumeration, 'Type passed is not an enumeration');
fx := TI.TypeData.MinValue;
tx := TI.TypeData.MaxValue;
for ix := fx to tx
do begin
EnumAsString := Method(PointerOfT(@ix)^, Language);
CaseResult := Pos('ToString not implemented for language', EnumAsString) <= 0;
if not CaseResult
then TDUnitX.CurrentRunner.Log(TLogLevel.Error, EnumAsString);
Result := Result and CaseResult;
end;
Assert.IsTrue(Result, 'Type ' +String(TI.Name) + ' is missing ToString value(s) for language "'+Language+'"');
end;
More compiler checks. E.g. NameOf(property)
ReplyDeleteLars Fosdal Once you had the constraint, you would not need to cast, right? After all, you said:
ReplyDelete"so that I could use enumeration functions like Ord(T(Item))"
Asbjørn Heid That's my point. Whilst the duck-typing implementation of for .. in works with concrete types, I cannot see it working with generics, given the current implementation. The compiler compiles the generic code, rather than the specialized code. As I understand it.
ReplyDeleteFurther improvements of FMX performance.
ReplyDeleteNicholas Ring What would be the benefit of a 64 bit IDE? I personally don't care whether it is 32 or 64 bit, so long as it works.
ReplyDelete/sub
ReplyDeleteDavid Heffernan I agree that it is likely not a trivial addition. But there has been many cases where I had longed for this, so I'll put it out there :)
ReplyDelete1. Continued FMX improvements and fixes
ReplyDelete2. Ability to write console apps on Linux
David Heffernan Right - If T was constrained to an enumerated type, the associated type declarations, functions and operators would work. Typo, I guess: "so that I could use enumerated type functions like" would be more appropriate. Ord, Low, High, Pred, Succ only works for enumerated types. Technically, Low/High works for arrays too - but that is an "overload".
ReplyDeleteIf a 64-bit IDE would work better with a 64-bit debugger, I am all for it.
ReplyDeleteMy wishes:
ReplyDelete- More updates/fixes, less upgrades (making it easier to keep 3rd party components usable for a longer time)
- 64bit IDE (=easier development with 64bit only OCXs like AutoDesk components)
- consistent UI for all IDE elements and dialogs (please support VCL styles and don't reinvent the wheel for the IDE styling = dogfooding your own UI controls and techniques)
- unbundling of 3rd party components/tools and make them available via GetIt
- better copy protection (=faster startup, no sudden IDE shutdown due to false piracy detection)
- floating licenses (use Delphi on any machine with your EDN account - e.g. for testing in different OS VMs)
Smaller executables, faster performance.
ReplyDeleteDavid Heffernan Why 64 bit IDE you ask? Because Emb did a patch job to get over the out of memory issues that are affecting people on a daily, if not hourly bases.
ReplyDelete2GB was fine until a few years ago. How much time do you think before 4GB isn't enough?
Because applications aren't getting smaller and the amount of memory the compiler needs isn't decreasing.
Because the IDE is growing with functionality, either built in, or via its plug-in mechanism, and I doubt any of that doesn't use extra memory (IDE Fix Pack might be the only exception here).
Do you think that the Windows platform will be 32 bit application compatible forever?
If the IDE goes to multiple platforms, do you think it will be 32 bit still or, as most OSes now days are 64 bit, 64 bit?
So many reasons for a 64 bit IDE :-D
Real db controls in FM instead of having to use livebindings
ReplyDelete/sub
ReplyDeleteExtended "with" syntax, like that:
ReplyDeletewith A: SomeParam, B: AnotherParam do
begin
A.SomeProp := B.SomeProp;
A.DoSomething;
end;
Nicholas Ring If 64 bit IDE isn't needed then why bother? If x-plat IDE isn't needed, why bother. On the other hand, if some design time aspects need third party libs that only exist in 64 bit form, then that's a different matter.
ReplyDeleteDavid Heffernan But a 64 bit IDE is required for the reasons I mentioned. And Embarcadero knows it! Why else would they put work arounds such as external compiling and enabling large aware address mode? Because of memory issues. If you aren't hitting these problems, then all the best to you! For me, I can be a lot more productive if the IDE had more memory to use.
ReplyDeleteQuestion: Why did Delphi 2 go to 32 bit when Delphi 1 was only 16 bit?
One good thing about the 32-bit IDE: Emba is forced to keep the memory usage low! For real!? Stupid idea!
ReplyDeleteNicholas Ring I think Embarcadero are best placed to know how to implement their product. Maybe 64 bit IDE is needed, but we can't really know for sure. I always hate it when my clients tell me that I've implemented something the wrong way, and of course they don't have the full picture to make such comments.
ReplyDeleteWhat I'd like to see though is for the IDE to be less dependent on weird and wacky third party code, like the J# stuff. I think if they could get clean pure 100% Delphi code then it would be easier for them to do things like 64 bit, x-plat and so on. Of course x-plat would be a huge step because IDE is built on VCL.
Of course, that last paragraph was me doing what I hate my customers doing, so take with pinch of salt!
David Heffernan I can function with a 32-bit IDE, but eventually, we do need to leave 32-behind. 64 bit CAN address 16 exabytes of memory, even though it's not practical. My windows PC has 32 gb memory, but 32 bits can only address 4gb (maybe less).
ReplyDelete+Phillip As I keep saying, if the user sees no benefit, what's the point. I for one don't want Emba to spend time on something that brings no benefit. That would be at the expense of some other development.
ReplyDeleteAgain, if a 64 bit IDE has significant benefits, so be it.
Shouldn't we let Emba decide? Aren't they best placed?
David Heffernan I'm not saying that they need to do it now, but perhaps in the future? Maybe when we move to 128 bit machines?
ReplyDeleteAnyway, I'm sure Emba know what they are doing. They'll not take on this task unless there's a good reason to do so.
ReplyDeleteDavid Heffernan
ReplyDelete>Anyway, I'm sure Emba know what they are doing.
I am sure they do but not to what the user base wants and a company needs to listen to their user base for what they need. If not, they will fail.
Examples that come to mind are:
* Change of the license to stop the Professional version from having any database access (they soon reverted that, didn't they)
* IDE memory issues (either external MSBuild or the large address aware, and they sure pull out the stops for the later)
>They'll not take on this task unless there's a good reason to do so.
64 IDE is a nature progression from large address aware, and now they have (hopefully) identified all the locations within the IDE where it needs to be touched to get it there.
But what you say is true. They will not take on this task unless there is benefit for them to do so. However, the question that Lars Fosdal asked was:
what feature(s) would you like to see in the next Delphi city?
And a 64 bit IDE is what I (and others going by the +1s) would like to see. The likelihood of actually seeing it, I guess, would be close to zero in reality but it doesn't mean it isn't a feature that I would like to see.
Nicholas Ring I don't understand your logic. Let's assume, for the moment, that there's no benefit to the users of a 64 bit IDE. If you knew that, you'd still like Embarcadero to spend significant development resource on that to the detriment of something else?
ReplyDeleteDavid Heffernan I don't understand why you are still arguing? Just because it won't benefit you, doesn't mean it won't benefit others.
ReplyDeleteBut to follow your example, do you mean like FireMonkey? I have no interest in FireMonkey, or cross platform compiling and because of it other things have not been addressed. But I do see the benefit to others for it.
I will repeat, Lars Fosdal asked:
what feature(s) would you like to see in the next Delphi city?
I took this a a rhetorical question and I answered it with what I would like to see. I have answered your question on what benefits it would bring, yet you still don't like the answer - why?
Nicholas Ring I don't understand your logic. You are arguing that you might want Embarcadero to spend development resources on features that would be of no benefit to anybody.
ReplyDeleteI clearly understand that not all features are useful to all users. As a software developer I know that well with my own users. However, you seem to be arguing in favour of adding features that would be useful to nobody.
Note that I'm not claiming that 64 bit would be useful to nobody. Just that it could conceivably be useful to nobody. And given that possibility, and given that I'm aware of no evidence that 64 bit IDE brings any benefits, I don't see how anybody could take the stance that you are taking.
David Heffernan Just because you aren't aware what 64 bit IDE would bring doesn't mean that there isn't any. Maybe you should stop complaining/arguing about a person's opinion and think about the possibilities.
ReplyDeleteSome possibilities that could be done (and trust me when I say that it is my imagination that is stopping me):
* Compile Group projects which contain large projects,
* 3rd party (IDE plug-in) refactoring tools (would require a fair bit of memory to handle large projects)
* plug-in to communication with 64 bit processes (64 bit applications are becoming the norm)
I am sure that others could think of other features that could be done within the larger memory...
+Nicholas It's not the details. It's the principle. I don't understand why you would argue for a development to be done irrespective of whether or not its beneficial.
ReplyDeleteSuppose that all the things you mention could be achieved with 32 bit IDE. You'd still like to see a 64 bit one for the sake of it? I don't believe that.
David Heffernan
ReplyDelete>Suppose that all the things you mention could be achieved with 32 bit IDE.
No it can't. The main project at work falls over regularly (at least once per hour!) due to out of memory issues (it is on XE but it is 32 bit). Maybe Seattle would improve this but it would only be a matter of time before it starts again...
+Nicholas By all accounts Seattle solves the problem.
ReplyDeleteWhen you ask for a 64 bit IDE what you mean is an IDE that is stable and can operate without exhausting memory. You really don't care how Emba do that, so long as it works.
But my argument is all about the principle. On the premise that a 32 bit IDE works as well as. 64 bit IDE in all regards, surely you would not want Emba to spend their resources on a 64 bit IDE.
David Heffernan No, Seattle is delaying the problem (as did external MSBuild).
ReplyDeleteNo, I didn't mean that. I would like 64 bit IDE so I can have more memory to play with. It isn't just the IDE, it is also the plugins I want to run too, and they also use memory.
Exactly my point, you are arguing against my answer, for a question that is based on people's opinion.
+Nicholas We are talking at cross purposes. I'm making a conceptual point. Which you don't seem to appreciate. Never mind.
ReplyDeleteDavid Heffernan I didn't appreciate it because it wasn't in the spirit of the question (IMO). If I interpret the question incorrectly, then I do apologize to everyone here and special to Lars Fosdal for making a mess of his question.
ReplyDeleteIf I thought the question was serious and that Emb would actually act upon it, then my answer would have been different, as a 64 bit IDE would be a while off (as the changes in Seattle for memory would be enough for Emb to work on other priority issues).
If I wanted to be totally out of the park, I would love a compiler that compiles to C=64 - That would be freaking awesome! Practical, no but still awesome!
Who installs a 32-bit OS on their development workstation these days? Why run a 32-bit IDE on a 64-bit OS, if you can have a 64-bit IDE? Seattle still only uses between 1/8 and 1/10 of my available memory.
ReplyDelete+Lars You also fall into the trap of asking for implementation rather than functionality. Almost every single request for 64 bit IDE is of that nature.
ReplyDeleteDavid Heffernan With the implementation comes the functionality... But you seem to be missing that point
ReplyDeleteDavid Heffernan That's no trap, but evolution.
ReplyDeleteLars Fosdal Nobody here seems to understand me. Never mind.
ReplyDeleteDavid Heffernan - It appears you think it is not worth the effort, as the memory issues we have can be solved in 32-bit for now. This is mostly true, but in the grapevine there are mumblings about compilation of very large projects (1M+ lines) slowing to a crawl in #10Seattle . Also - if memory is not a limited resource, the IDE can be more liberal with internal data structures and caching and as such - in theory - improve performance. Again - not revolutionary, but evolutionary.
ReplyDeleteThe current 32-bit IDE/Compiler appear to be locked to using one core, and really doesn't utilize our powerful CPUs.Perhaps this can be remedied in 32-bit, but more threads = more memory requirements. Personally, I would love a better compiler, but we know that the LLVM compiler introduces a performance penalty - which in theory could be alleviated by background compilation and linking.
I do not know if there is a practical limit to the number of threads - but there seems to be a limit under 32-bit (which does not exist in 64-bit) since WOW64 allocates an extra 512K 64-bit stack per thread. https://msdn.microsoft.com/en-us/library/windows/desktop/aa384219(v=vs.85).aspx
Lars Fosdal No, I've never said that it's not worth the effort. Let's see if I can state my point one more time so that people can understand it.
ReplyDeleteDo I care how my tools are implemented? No.
Do I care if my tools work? Yes.
If my tools don't work well, do I want them improved? Yes.
So, rather than asking for a 64 bit IDE, what I think people are really asking for is an IDE that is more robust. If the best way to achieve that is to switch to a 64 bit process, so be it. But for its own sake, a 64 bit IDE has absolutely no value to me over a 32 bit IDE.
I don't think anyone anyone in the thread would ask for a move to 64-bit, if they didn't think it would add value - or make it possible to add value - beyond just "bittedness" and more memory. We have received a 32-bit version that is more robust - stability-wise, but it has not improved when it comes to being future-robust.
ReplyDeleteIf time and effort was not an issue - they should ideally be dogfooding a cross platform IDE. I bet that would do wonders for FireMonkey, but it would also take a lot of effort.
For me, bittedness is just the start. That equates to more memory available to the process. This equates to big and better plug-ins, which means a better IDE environment, which means more enjoyable programming/being more productive...
ReplyDeleteWhat is the equation: Speed, Correctness, and Memory - pick any two.
It seems that I cannot make my point clearly. Never mind.
ReplyDelete
ReplyDeleteDavid Heffernan What is your problem? As far as I can see, you have singled out my 64 bit IDE suggestion, while others have suggests that would fit the same category which you have left without a comment.
I have tried over and over to explain why I think a 64 bit IDE would be a good thing but you have not acknowledged them in any manner, yet I have acknowledge your perspective on the matter, even if I think it is out of place in the context of the question that was put forward.
So I will ask again, what is your problem?
Nicholas Ring I've explained it many times now. I'm not going to repeat myself again.
ReplyDeleteDavid Heffernan I raised a number of points in my last comment and yet you barely addressed one of them. If that is the future of things to come, please do not comment.
ReplyDeleteNicholas Ring I don't agree with that statement at all.
ReplyDeleteDavid Heffernan And now I have to ask why... Please just go away. You are being childish now.
ReplyDeleteNicholas Ring It's not appropriate to insult people and be abusive. Please refrain.
ReplyDeleteDavid Heffernan But being childish is ok? While calling you childish might be considered an insult, it was not abusive. If I was going to be abusive to you, you would know it. :-P
ReplyDeleteNow, please go away.
+Nicholas Your conduct is out of order.
ReplyDeleteDavid Heffernan Flag me then :) Bye
ReplyDeleteIt looks like that a person in this thread has pushed me to my limits, all because they couldn't explain themselves.
ReplyDeleteI do apologise to all in this thread for my last few comments and I will try to refrain from letting idiots get the better of me in the future.
FWIW, Visual Studio is 32bit. They do however have a 64bit version of their C++ compiler, which is indeed needed in some cases as the 32bit compiler can run out of address space compiling some projects.
ReplyDeleteLoading up a multi-project solution with roughly 600-800kloc of C++ code, opening dozens of files across multiple projects VS2013 itself consumes about 140MB memory. That's with Qt though, so no form designer in VS as such, just code.
Building one of the projects in release mode takes roughly 1-2 GB of memory, but the build tools are run as separate processes.
However, before they rewrote their IntelliSense "engine" (their version of Code Insight), IntelliSense would frequently stop working on this solution due to running out of address space...
So, to sum it all up... Can a 32bit IDE be effective and robust? I'd say VS tells us that yes it can. However there's no denying that some things are easier to solve, or will be much faster, by going 64bit.
That said, 32bit or 64bit IDE is an implementation detail. I agree with David Heffernan that it's better to focus on the end goals rather than on the implementation details.
However I also agree with Nicholas Ring that a 64bit IDE will most likely open up some doors that we don't even know about yet.
Just 5 cents: When someone appears to not understand your sentiment, it's not necessarily the receiving end that is the problem. The challenge with all internet discussion is reaching across - and expressing oneself in such a way that the message is clear. Cultural, linguistic and experience/educational gaps are as much of a challenge for the writer, as they are for the reader. Adapt and overcome, please?
ReplyDelete+Lars I don't understand that comment, and I also don't understand why it seems to be permissible to insult others here.
ReplyDeleteI ask myself that very same question every day. Passive aggressiveness is still aggressiveness.
ReplyDeleteLars Fosdal I don't see any passive aggressiveness. So it's fine to be insulting and abusive here, and to call people names?
ReplyDeleteSurely people can express different views and opinions without resorting to that?
David Heffernan If there was name calling and grave insults, I would ask people to tone it down. When there is disagreement and heated debate - and the opponents clearly are talking past each other - I'd first ask them to cool down, then ask them to explain more clearly. Then again, I'd expect most grown men to be able to handle being called childish, or otherwise be directly or indirectly implied to be lacking in cognitive faculties without getting all riled up.
ReplyDeleteThis seems to be the status:- You say it doesn't matter if the IDE is 32- or 64-bit as long as it meets your development requirements, and you say that moving to a 64-bit IDE for the sake of 64-bitness is unnecessary.
"But my argument is all about the principle. On the premise that a 32 bit IDE works as well as. 64 bit IDE in all regards, surely you would not want Emba to spend their resources on a 64 bit IDE."
"So, rather than asking for a 64 bit IDE, what I think people are really asking for is an IDE that is more robust. If the best way to achieve that is to switch to a 64 bit process, so be it. But for its own sake, a 64 bit IDE has absolutely no value to me over a 32 bit IDE."
Some of our comments say that we believe moving to a 64-bit environment would be beneficial (and name some reasons), which you effectively dismiss as a valid argument, and then comment about making a conceptual point, that we don't understand, that you cannot make your point clearly, that you already have explained, and that you won't do it again - and for Nicholas Ring you did so without addressing his points.
I guess he got a bit frustrated, but I don't need to make excuses for him as he is perfectly capable of expressing himself clearly. I'll stop commenting the person to person relationships here. You two sort it out.
As for 64-bit or not. I am for, not for the sake of it, but because I think it is a necessary move.
Lars Fosdal Well, I don't think it's acceptable to call somebody else here an "idiot". You seem to think that it's fine to do that. I disagree very strongly with you.
ReplyDeleteLars Fosdal As for the second part of that comment, I can't see any contradiction in my arguments. Early in the thread, and from multiple people, I've seen a plain request for a 64 bit IDE. My point was, and always has been, that a desire for a 64 bit IDE should be driven by the benefits that brings. That was the point that I was arguing.
ReplyDeleteTo me it seems quite simple. If the best way to implement a desirable feature is to move to a 64 bit IDE, and if the cost of doing so is outweighted by the benefit to the users, then let's have a 64 bit IDE. If it's cheaper to implement the desirable features in the existing 32 bit IDE, then leave it as 32 bit.
And my final point is that I believe that Embarcadero are best placed to evaluate these trade offs. So I feel that it is most productive for users to request functionality. Or to explain the problems that they face with the product, and ask Embarcadero to consider ways to address those problems. I do feel that the developer of a product is generally in the best position to determine how best to implement new functionality.
David Heffernan A point that noone disagrees with, as far as I can tell. So... why are we arguing?
ReplyDeleteDavid Heffernan I didn't not call anyone here an idiot. I said (copy and paste):
ReplyDelete"I do apologise to all in this thread for my last few comments and I will try to refrain from letting idiots get the better of me in the future."
If you took this to be directed to person(s) here, then I do apologise for any misinterpretation that occurred.
Ref "idiot". I missed that comment. I don't think it is appropriate, but as insults go - I have been called a lot worse.
ReplyDeleteLinux console apps & services
ReplyDelete