Dave Novo

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.

LSP simply does not work well yet in any sort of complex scenario. I wrote to EMB support about certain things not working with LSP mode and worked in Classic mode and they wrote: Although several issues related to the LSP server were included in the Sydney 10.4.2 update, several additional issues remain but are slated to be addressed in a future release or update. Examples of open defects affecting LSP: New LSP does not recognize newly build classes. https://quality.embarcadero.com/browse/RSP-31922 LSP not recognising subtype alias https://quality.embarcadero.com/browse/RSP-33546 LSP doesnt show errors https://quality.embarcadero.com/browse/RSP-33060 The Code Insight using LSP work only for small "hello world" applications. https://quality.embarcadero.com/browse/RSP-33403 Here are a few details which may affect Code Insight/Find Declaration: 1) It only works effectively on the first project in a project group, so if you have a project group with several projects, it is best to open just one project at a time. 2) When you see [Calculating...] it means that the LSP server is working and indexing, it's best to click elsewhere and then try again. 3) if you see an error 'cannot find file XXXXX' even though you are in the file in the IDE, it means the file cannot be found in the index database, so the LSP server still needs time to index it.

We have been using Delphi and VMWare Workstation for a decade at least. We see no difference between performance in the VM or host computer. When performing timing tests of our applications, we see no difference between timing of single threaded applications between running the timing inside the VM and on the native hardware. For multi-threaded code, we have found running on the host machine faster compared to within the vm.

I believe Remobjects Hydra can help you with this. If you go to https://hydra.remobjects.com/hydra/tour.aspx, you can see there is a section "Combining VCL and Firemonkey" .... Hydra provides a solution for this problem by allowing developers to integrate FireMonkey UI seamlessly with their existing VCL applications, or conversely add existing VCL user interfaces into new FireMonkey apps. ...

Hello, I am trying to compile our project in Delphi 10.4.2 for the first time, and the code insight does not work. Ctrl+space or ctrl+shift+space do nothing. If I switch the Code Insight Manager back to Delphi (Classic Code Insight) it works again. I thought the Language Server Protocol was supposed to be better. Is there something I need to do in order to activate it?

per this post, it seems that many of the optimizations from IDEFixPack were ported to Delphi 10.4.2, but not the compileOnly (which is perfect for us BTW). https://blogs.embarcadero.com/delphi-10-4-2-compiler-speed-improvements/

@jbg - thanks for the tip. We are using Seattle for now, but in the process of upgrading to Delphi 10.4. So this will be useful for a bit. Is there somewhere in the project options you can specify extra command line parameters?

@Fr0sT.Brutal The compiler is not 64 bit. The compiler is a 32 bit application that generates 64 bit code. In my initial post I described the problem with the EXE.

@Fr0sT.Brutal - our project is 2.5M LOC approx. The 32 bit compiler gets up to 3GB but does usually complete without running out of memory. But the 64 bit compiler consistently ran out of memory. What you have described is exactly what we have done. to make it work. But we do not need all the EXE from the subprojects.