Dave Novo

Even debugging 64 bit app on the same computer as the IDE is painful. I dont know why you think doing it on another computer would not be exponentially worse.

FWIW I asked if there was a secret registry code that could turn on the "classic compiler" but I did not hear back about it.

We do have too many semi-circular references. We are working on removing them slowly over time, which we thought would improve the compile time as well. But it seems not to improve the compile time very much and it takes tons of time.

This is as known problem on complex projects. We have the same things and sent the logs to EMB. Essentially, the LSP parser is taking too long to compile the code. Because it is taking so long, the LSP parser thinks there is a problem and restarts. This happens over and over again. I was not able to get the logs to EMB before Delphi 11 was in beta and David Millington said they could not fix it in time for Alexandria. We reported the problem in Delphi 10.4.2 but evidently according to David, and now your experience, it still persists in Delphi Alexandria. I was not able to get clarity exactly what about the code (if even there was anything particular) that was making the LSP take so long. You can look on the LSP progress bar and see the progress bar going forever basically. Sometimes it stopped for a brief time, then restarted.

Make the storage data path (TDataStoragePath) a singleton object that initializes itself with the path. All other units that need the path will have to use the unit where TDataStoragePath is defined hence will force TDataStoragePath to initialize first.

Wow, I wish every time I complained about something then a resolution fell out of the sky in 3 days 😀

Thanks for looking up the links. I guess if the bug report is >5 years old about this, I will not hold my breath.

Sure, but then we have to either use a code hook or remember to never use StrToDate and use StrtoDateWrapper (or whatever we call it). It is surprising that these dates formats are not supported. They have been in windows for ages.

Is there another method of conversion that can handle the entirety of the set of formats that windows supports for the current date format?

+1 for someone creating an embedded IDE based on PyScripter to embed into a Delphi application and provide Python editing and execution within your delphi app.

Did anyone else notice that Delphi 10.4.2 always recompiled and re-generates the EXE even if you dont make changes to your source. In Delphi Seattle, if you pressed F9 (run) and you had not made changes to your source, the EXE launched right way, without any compile or link. But in Delphi 10.4.2 (at least for me) it is constantly compiling. On our application, it takes about 1 minute. approx 30 seconds for it to go through the compile cycle and do nothing (i.e. 30 seconds to detect that no dcus need to actually be rebuilt) then 10-20 seconds to build the EXE.

based on @Stefan Glienke tip above, I had a look at the IDE Fix Pack page. Look what I found Fixes (for Delphi 10.3.2) Prevent the IDE from re-compiling the code if you run the application right after you just compiled it. The ErrorInsight parser asking the compiler to get unit symbols invalidated the unit cache even if no actual in-memory compilation took place. Sure enough, If I deactivate Error Insight, then classic mode stops recompiling all the time

I was using classic mode as well, since LSP is pretty useless for complex apps in project groups in particular. In a blank VCL project, If I turn off Classic Code Insight and go back to LSP it stops recompiling every time. I am not sure what MMX has to do with it, in my application, when LSP is on. Note: when I did this test in Delphi Seattle, I did not see this behavior either with IDE Fix Pack or without. I also tried toggling "Save Files when compiling or running" but that did not make a difference. If I turn Classic Code Insight back on and turn off every checkbox on the "Code Insight" page on Editor->Language->Delphi it still re-links every time.

Check your memory. For me, Delphi 10.4.2 consumes more and more memory. Often sitting at 3.2GB. Then it just dissapears.

@Vincent Parrett - It would be curious to see what happens to you with a default VCL application. So far we have that Uwe never gets it, I get it based on MMX and it always happens for you no matter what.

@Vincent Parrett - even stranger. For me, this problem went away when I removed the 3 plugins I showed in the screenshot above. Only when I added MMX back in did the problem start again. I did add the other ones back as well and as long as MMX was not there, the second F9 launched the EXE immediately.

Would it be easier to set up a time that is convenient for you to do a screenshare and you can poke around? I have attached the .reg file. It should be pretty much a default installation, we are just getting Delphi Sydney going. raabe software.reg

@Uwe Raabe - seems like the culprit is MMX. If I deactivate MMX by changing the registry to have a 'dllx' extension (and get a file not found upon loading delphi), it no longer recompiles all the time. Is there a setting in MMX that could be causing this. In the default delphi project I am testing with above, I dont even have MMX open. I just upgraded to the latest MMX 15.0.38.2440 and still the same problem

We have MMX (the latest version), Documentation Inspector and our own set of IDE plugins that just basically remote control SVN

I have made a short video showing this behavior and comparing compiling the same application to Delphi Seattle https://www.dropbox.com/s/kluroxd9554k5sv/always recompile.mp4?dl=0 I did note that even though the EXE is regenerated , the timestamps on the DCU are always the same (i.e. they are not being regenerated) I even see this on a brand new VCL default project. I can record another video to show, but basically, here is the output folder from the first compile close the form and press F9 immediately. It very briefly pull up the screen doing a "compile" and link. Below is the new screenshot. Note the EXE was regenerated, but the DCU stayed the same

For sure its compiling. The compiling dialog is up for at least 30 seconds for us, doing nothing (I presume searching through all the dcus and realizing there is nothing to do) and then the text changes to say its building the EXE, which takes another 30 seconds.

Hello, I have two projects in a project group. When I compile the first one, Delphi uses up about 1.4Gb of RAM. That memory stays allocated even after the compile completes. After the 2nd project compiles I am at about 3.2 GB of ram After the compile is over, that seems to go down to 2.4 GB of RAM used. Not infrequently, after compiling a few times, Delphi 10.4.2 just dissappears, presumably out of memory. This is even after all the latest 10.4.2 patches. DDevExtensions had "Release Compiler Unit cache" but that is not available for Delphi 10.4. I know they ported a bunch of fixes from DDevExtensions/IDE FixPack to Delphi. Does anyone know if this one made it?

Why are you putting CopyData in the stopWatch for the binary search. That is not fair for comparison. You are comparing vs IComparer. That basically calls a function for the comparison, which is very slow compared to an native comparison i.e. int1=int2. So minimizing the comparisons with the binary search in the example above has an outweighed effect compared to a native comparison (i.e. I would expect the linear search would hold its own for longer for a native comparison). Your linear search for duplicates is essentially a sort anyhow, and that offsets the explicit sort you are doing for the binary search. Try sorting and doing the duplicate linear search on the sorted data, that is easy, you just compare adjacent elements.

Does anyone have the trick for recompiling Delphi source in Delphi Sydney (10.4.2)? We had this working well in Delphi Seattle. We just copied the Delphi source unit to our path, and made sure the default compiler directives were at the top. With the usual caveat that you can only change the implementation code, not the interface. This is documented well in https://stackoverflow.com/questions/10470943/how-to-recompile-modifications-to-vcl-source-file-menus-pas However, for Delphi Sydney it does not work for me. Just create a blank VCL forms application Copy System.Classes.pas to the folder with your unit1.pas and compile. It will fail with [dcc32 Fatal Error] System.Classes.pas(21328): F2051 Unit Vcl.ExtCtrls was compiled with a different version of System.Classes.TCollectionEnumerator.GetCurrent if you press Ctrl+O+O you get the directives I list below. Even if you paste these to the top of your modified System.Classes.pas it still will not compile with the same error. Does anyone know the compiler directives you are supposed to use to recompile the delphi source for Delphi Sydney? {$A8,B-,C+,D+,E-,F-,G+,H+,I+,J-,K-,L+,M-,N-,O+,P+,Q-,R-,S-,T-,U-,V+,W-,X+,Y+,Z1} {$MINSTACKSIZE $00004000} {$MAXSTACKSIZE $00100000} {$IMAGEBASE $00400000} {$APPTYPE GUI} {$WARN SYMBOL_DEPRECATED ON} {$WARN SYMBOL_LIBRARY ON} {$WARN SYMBOL_PLATFORM ON} {$WARN SYMBOL_EXPERIMENTAL ON} {$WARN UNIT_LIBRARY ON} {$WARN UNIT_PLATFORM ON} {$WARN UNIT_DEPRECATED ON} {$WARN UNIT_EXPERIMENTAL ON} {$WARN HRESULT_COMPAT ON} {$WARN HIDING_MEMBER ON} {$WARN HIDDEN_VIRTUAL ON} {$WARN GARBAGE ON} {$WARN BOUNDS_ERROR ON} {$WARN ZERO_NIL_COMPAT ON} {$WARN STRING_CONST_TRUNCED ON} {$WARN FOR_LOOP_VAR_VARPAR ON} {$WARN TYPED_CONST_VARPAR ON} {$WARN ASG_TO_TYPED_CONST ON} {$WARN CASE_LABEL_RANGE ON} {$WARN FOR_VARIABLE ON} {$WARN CONSTRUCTING_ABSTRACT ON} {$WARN COMPARISON_FALSE ON} {$WARN COMPARISON_TRUE ON} {$WARN COMPARING_SIGNED_UNSIGNED ON} {$WARN COMBINING_SIGNED_UNSIGNED ON} {$WARN UNSUPPORTED_CONSTRUCT ON} {$WARN FILE_OPEN ON} {$WARN FILE_OPEN_UNITSRC ON} {$WARN BAD_GLOBAL_SYMBOL ON} {$WARN DUPLICATE_CTOR_DTOR ON} {$WARN INVALID_DIRECTIVE ON} {$WARN PACKAGE_NO_LINK ON} {$WARN PACKAGED_THREADVAR ON} {$WARN IMPLICIT_IMPORT ON} {$WARN HPPEMIT_IGNORED ON} {$WARN NO_RETVAL ON} {$WARN USE_BEFORE_DEF ON} {$WARN FOR_LOOP_VAR_UNDEF ON} {$WARN UNIT_NAME_MISMATCH ON} {$WARN NO_CFG_FILE_FOUND ON} {$WARN IMPLICIT_VARIANTS ON} {$WARN UNICODE_TO_LOCALE ON} {$WARN LOCALE_TO_UNICODE ON} {$WARN IMAGEBASE_MULTIPLE ON} {$WARN SUSPICIOUS_TYPECAST ON} {$WARN PRIVATE_PROPACCESSOR ON} {$WARN UNSAFE_TYPE OFF} {$WARN UNSAFE_CODE OFF} {$WARN UNSAFE_CAST OFF} {$WARN OPTION_TRUNCATED ON} {$WARN WIDECHAR_REDUCED ON} {$WARN DUPLICATES_IGNORED ON} {$WARN UNIT_INIT_SEQ ON} {$WARN LOCAL_PINVOKE ON} {$WARN MESSAGE_DIRECTIVE ON} {$WARN TYPEINFO_IMPLICITLY_ADDED ON} {$WARN RLINK_WARNING ON} {$WARN IMPLICIT_STRING_CAST ON} {$WARN IMPLICIT_STRING_CAST_LOSS ON} {$WARN EXPLICIT_STRING_CAST OFF} {$WARN EXPLICIT_STRING_CAST_LOSS OFF} {$WARN CVT_WCHAR_TO_ACHAR ON} {$WARN CVT_NARROWING_STRING_LOST ON} {$WARN CVT_ACHAR_TO_WCHAR ON} {$WARN CVT_WIDENING_STRING_LOST ON} {$WARN NON_PORTABLE_TYPECAST ON} {$WARN XML_WHITESPACE_NOT_ALLOWED ON} {$WARN XML_UNKNOWN_ENTITY ON} {$WARN XML_INVALID_NAME_START ON} {$WARN XML_INVALID_NAME ON} {$WARN XML_EXPECTED_CHARACTER ON} {$WARN XML_CREF_NO_RESOLVE ON} {$WARN XML_NO_PARM ON} {$WARN XML_NO_MATCHING_PARM ON} {$WARN IMMUTABLE_STRINGS OFF}

@Stefan Glienke - thank you so much. We never encountered this before in Delphi Seattle. In Delphi Seattle we managed to recompile System.Classes System.IOUtils System.SysUtils WinApi.GDIApi.pas DAta.Win.ADoDb and did not need to pull in other units that we did not need. I guess EMB has increased their use of inlining/generics over the years.