Lars Fosdal

I always capture the current brush/pen handles, set my own, use them, then restore them to what they were. Oldschool, I guess.

I have a Programs Group containing the projects that I work with on a daily basis. In versions prior to 10.x - sometimes before committing a possibly breaking code change, I would do a build all on that group. There was an older version that also would run out of memory, but eventually that got fixed, but now it seems that error is back. I hadn't really used this for some time, since the build server does it faster than I can, but I was going to benchmark 10.4.2 vs 10.4.1. (Note that the time axis on the charts below are not comparable). 10.4.1 churns through the first 8 projects before it stops on an out of memory error, consuming 3.25Gb. 10.4.2 crashes out hard (IDE goes *poof*) at peak 3.42Gb I wonder what logic it is that governs when the IDE should release generated code or not? Each arrow represents when it starts compiling a project in the project group. Large VCL app, Moderate VCL app, Small VCL app, Small VCL app, Moderate VCL app, Small VCL wrapper around service code, Service without GUI, Small VCL wrapper around service code (OOM). If it had released every time, we would not have this problem. On the bright side, 10.4.2 is a slightly faster compiler. Complaint 1: The IDE should not run out of memory when compiling a project group. Complaint 2: The IDE should - if it runs out - handle it gracefully and not crash out.

I commented on this one. https://quality.embarcadero.com/browse/RSP-32768 https://quality.embarcadero.com/browse/RSP-32792 and 93 are duplicates of that one, it seems.

The IDE is a 32-bit app using the large memory "hack" that allows it to use 3Gb instead of two. See https://cc.embarcadero.com/Item/24309 for an example. @emailx45 The ISLC application you suggest is irrelevant. My laptop has 32 Gb.

@Mike Torrettinni 10.4.2 is a lot better than 10.4.1 in many respects. These are corner cases, and I expect there will be hotfixes. My guess is that 10.5.0 also will have issues that needs to be hotfixed - simply because exposing the IDE and compiler to real world code will uncover things that were not caught in the testing.

I do too, and I don't... There were those that abused that usability to spam threads, simply because it was so easy to do so. But yeah, the old newsgroups were underrated and should have survived and evolved.

@FredS Creating a new VCL project, adding your unit, and without saving the files - hovering over FormKeyDown in the implementation section - the IDE locks up. The LSP does not show any particular activity: The IDE seems to be running in a very tight loop in a single thread doing XML processing? Callstack: 0, msxml6.dll!DllGetActivationFactory+0x36a1a 1, 0x6d6a9a500589a9b8 2, 0xffffffff00000000 3, 0x6d6a9a8a00641f44 4, 0x6d6a9a500588c0c8 5, 0x300000000 6, msxml6.dll!DllGetActivationFactory+0x36a1a (No unwind info) 7, msxml6.dll+0x79a8a (No unwind info) 8, msxml6.dll+0x791cb (No unwind info) 9, msxml6.dll+0x6002b (No unwind info) 10, msxml6.dll+0x3f4c0 (No unwind info) 11, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 12, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 13, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 14, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 15, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 16, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 17, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 18, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 19, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 20, xmlrtl270.bpl!XmlXmldocTXMLNode_Release$qqsv+0xe (No unwind info) 21, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 22, rtl270.bpl!SystemClassesTInterfaceList$bdtr$qqrv+0x13 (No unwind info) 23, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 24, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 25, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 26, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 27, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 28, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 29, xmlrtl270.bpl!XmlXmldocTXMLNode_Release$qqsv+0xe (No unwind info) 30, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 31, rtl270.bpl!SystemClassesTInterfaceList$bdtr$qqrv+0x13 (No unwind info) 32, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 33, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 34, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 35, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 36, rtl270.bpl!SystemFinalizeRecord$qqrpvt1+0x111 (No unwind info) 37, rtl270.bpl!SystemTObjectCleanupInstance$qqrv+0x21 (No unwind info) 38, xmlrtl270.bpl!XmlXmldocTXMLNode_Release$qqsv+0xe (No unwind info) 39, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 40, xmlrtl270.bpl!XmlXmldocTXMLDocument$bdtr$qqrv+0x6f (No unwind info) 41, xmlrtl270.bpl!XmlXmldocTXMLDocument_Release$qqsv+0x33 (No unwind info) 42, rtl270.bpl!SystemIntfClear$qqrr44System%DelphiInterface$17SystemIInterface%+0x13 (No unwind info) 43, IDELSP270.bpl!BaselspserverTLSPServerLSPServerCharEncoding$qqrp14SystemTObjectx20SystemUnicodeStringp22SystemClassesTStream+0xbd8 (No unwind info) 44, vcl270.bpl!VclFormsTApplicationIdle$qqrrx6tagMSG+0x13b (No unwind info) 45, vcl270.bpl!VclFormsTApplicationHandleMessage$qqrv+0x1c (No unwind info) 46, bds.exe!_dbk_fcall_wrapper+0x1234ad (No unwind info) 47, kernel32.dll!BaseThreadInitThunk+0x19 (No unwind info) 48, ntdll.dll!RtlGetAppContainerNamedObjectPath+0xe4 (No unwind info) 49, ntdll.dll!RtlGetAppContainerNamedObjectPath+0xb4 (No unwind info)

Open IDE, and select File | New | Windows VCL Application - Delphi Update: Problem went away when deleting an expired license. Reported as: https://quality.embarcadero.com/browse/RSP-33104

I wonder though - if it would be accepted as an IDE addon in GetIt 😛

Does a Clean and Build help? If not, you should create a QP issue.

Please note that we started with just a single sub-forum for the C++Builder guys because we had no idea how many there are and how many questions there would be. We can divide up in more subforums if the usage dictates it.

/off-topic, but 10.3 and prior versions used to flicker like hell when AD pushed its policy settings. Fortunately, this has improved with the later versions.

That is where they included it, since GetIt can update components between IDE releases.

Repeating the same question doesn't really help. Please don't do that. Since you did not specify the nature of your issue, it is hard for people to answer. https://www.quickreport.co.uk/ carries the latest versions of QuickReports for the various versions of Delphi and C++Builder.

Quite a bit can be found in the wayback machine. I agree, though. It was a strange thing to do. I guess they are really trying hard to shave off costs.

https://developer.arm.com/documentation/dui0473/m/arm-and-thumb-instructions/yield It was added in V6.

Lots of good stuff to be discovered here.

The equivalent of x86 PAUSE on ARM would be YIELD. Perhaps there is no ARM version of YieldProcessor because the ASM block only is usable under x86?

I am not always putting huge strings into constants, but when I am testing a parser I am. Except - Delphi does NOT like string literals longer than 255 chars. It is probably logical, but still annoying. var s: string; begin s := 'string that is 750 chars long'; // compiler barfs with [dcc32 Error] E2056 String literals may have at most 255 elements s := '250 chars' + '250 chars' + '250 chars'; // ok /rant

Name them and shame them into adherence! I am only half-kidding...

@emailx45 It is great that you are enthusiastic and helpful - but - the wrong kind of help is not really helpful, is it? I guess you missed the "/rant" in my original post, as well as the comment about "logical, but annoying", and the explicit reference to string literals. I also clearly stated WHY I wanted a longer string literal; and @Angus Robertson provided another example of when this limit is a challenge. Yet you post a completely irrelevant suggestion that AnsiString is the answer to the problem. My advice: - Study posts until you are sure you understand the context - Avoid applying your own opinion as one of the Embarcadero engineers - Avoid what-about-ism - Avoid characterizing the desires of others as insane - Avoid posting bullshit comments not relevant to the discussion Fun fact: The line length limit in the Delphi IDE is 4096 chars.

I think you are right about the swap issue. Yet another problem has surfaced. I am glad I didn't spring for the Mini. The Register: Doctor, I think I have an HDMI: Apple starts investigating M1 Mac Mini graphics issues. https://go.theregister.com/feed/www.theregister.com/2021/02/22/apple_starts_investigating_m1_mac/

True. Normally you would for readability, but splitting involves a manual operation that carries a risk of mangling the content. Yes, it is a compiler limit, but when you can split and add up a huge string "manually", it is annoying that the compiler can't hide this for you. /rant ended

So, @emailx45 - show me a code example of how you fill an ansistring using a single string literal longer than 255 chars in the source code. Not from a loop, concatenation, string resource, file, form resource, or copied from the clipboard at runtime.

That was what I suspected.