Lars Fosdal

"faster code with managed records" - faster in what way?

10.4 does not overwrite the 10.3 versions in C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ So, First install for 10.3, then install for 10.4 - and apply the fix above.

10.4 has an update to Bookmarks and Navigator. It creates C:\Program Files (x86)\Common Files\ParnassusShared and places ParnassusBookmarks_XSydney.dll ParnassusCoreEditor_XSydney.dll ParnassusNavigator_XSydney.dll So, to cure the 10.3 ailments, copy from C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ to the first mentioned common catalog Bookmarks-1.0\ParnassusBookmarks.dll to ParnassusBookmarks_XRio.dll ParnassusCoreEditor-1.0\ParnassusCoreEditor.dll to ParnassusCoreEditor_XRio.dll Navigator-1.0\ParnassusNavigator.dll to ParnassusNavigator_XRio.dll

I can't believe they fucked it up again...

Have you tried TCamRemote from https://alkenius.no-ip.org/

It just dawned on me that you wrote the Monitor didn't produce any logging for that query. That strongly suggests that it fails in the preprocessing. What type are the parameters, and can there be invalid data passed to the query? Garbage strings, NaNs, invalid pointers, etc?

SQL Server has pretty good diagnostics and logging, so if a query causes it to hang, it should be detectable. I would suggest trying a minimal example with the explicit query through FireDAC, and compare that with the parameterized query. Check parameter by parameter that the value type is correct. That the format is correct (number, date, etc).

I wonder why TChart is not a GetIt thing?

Do you get an error if you allow it to time out when it hangs? When SQL just hangs, the cause can be a deadlock. That means that the table you are trying to update, is busy somehow. The default timeout is typically 30 seconds before a thread is declared the winner and the other threads accessing the table gets a lock error and have to do a retry. This is the reason we in our team do our MSSQL table updates through stored procedures. That allows the procedure to do a try/catch and retry if it fails due to a deadlock. Preventing deadlocks: It is important to avoid "lingering" cursors to reduce the risk of deadlocks. F.x. If you really need a cursor, do a select into a memory temp table, and create the cursor on that temp table. If a complex select or view can safely use "With NoLock" on a table, use it.

Ah, my bad - I didn't notice the MMX context.

In the declaration? I usually end up with a recorded macro since I only rarely want a setter procedure.

Treat console apps like you treat VCL or FMX apps. Keep the actual code in units and have just the skeleton init and run code in the .dpr.

I tested in 10.3.3.

@Scott - Are you on subscription? In that case you can actually join the Beta testing pool and help unearth these problems. My team usually don't move to a new version until Update 1 is out.

Heated discussions that end well - No problem, IMO. Discussing in writing is always difficult. Differences such as cultural background and language can make it easy to trip up and come across the wrong way. As long as we are patient and try to stay positive and on the ball instead of the man - there is hope.

You're asking for immutability ... this is hard to achieve on unmanaged system and specially for Delphi (breaking type-system compatibility). I think placing constants on ROM would be much better as it doesn't require changing the system-type language. What do you think ? I think that I really don't care about the underlying implementation detail. I just want truly constant typed constants. It would allow me to write consistent, readable, reusable code and allow array parameters and typed constant parameters for attributes. A minor performance penalty would be acceptable if that goal could be achieved.

Dude, why do you think I wrote And again - I really don't care about the speed penalty. I just want constants that are actual constants also when typed and that cannot be changed at runtime.

Cut'n paste and RX replace. That said: It is unlikely that I'd have more than a few thousand typed record constants. I.e. The increase in compiler time is for all practical purposes insignificant.

You got the source. Be my guest.

That was for 32-bit 64-bit compiler appears to have a tad longer compile time for typed constants. 1.2s vs 0.9s for string consts, but the margins are so small and the variation so large, that it is hard to say.

Overly simple Compilation Speed Test The attached project has a define. {$define AsTyped} When defined, the Texts record contains 500 typed constants. When not defined, the Texts record contains 500 constant strings. On my rather busy laptop, the compile time varies between 0.8 to 1.3s for both with or without the define. TypedConsts2.dpr

My most common use of typed constants is records containing translation strings. These are used for in-place translation of errors and prompts in JsonRPC responses, instead of the typical translated resource solution you would use in a desktop application. This is done to reduce the cost of lookup, since the same server will be required to respond to requests in multiple languages. It works so well that we've started using the same system for configuring text for grids, etc. - just to simplify the process of adding new content without requiring more translation work in a separate tool. For me, the benefits are that the translations are kept in one place - so it is next to impossible to mistranslate a text, or forget about adding a translation in a specific place when adding a new language and since the texts are in the source code, it is trivial to add new translations. I have hundreds of these typed constants and if they do add compile time, it must be next to nothing, because I can't say that I notice any slowdown in the compilation. My main gripe is that I cannot pass these as parameters to an attribute. Here is a simplified albeit rather contrived example but it illustrates my point. program TypedConsts; {$APPTYPE CONSOLE} {$R *.res} uses System.Classes, System.SysUtils, Vcl.Graphics, Generics.Collections; type TxStyle = record font: string; size: integer; attr: TFontStyles; end; type TextStyle = record const // typed consts within a record to create a pseudo namespace Title: TxStyle = ( font: 'Arial'; size: 12; attr: [fsBold]); Chapter: TxStyle = ( font: 'Arial'; size: 10; attr: [fsBold]); Section: TxStyle = ( font: 'Georgia'; size: 10; attr: [fsBold]); Normal: TxStyle = ( font: 'Arial'; size: 9; attr: [fsBold]); Code: TxStyle = ( font: 'Courier New'; size: 9; attr: []); Hint: TxStyle = ( font: 'Garamond'; size: 8; attr: [fsItalic]); OhNoes: TxStyle = ( font: 'Comic Sans MS'; size: 8; attr: [fsItalic]); end; type FontAttribute = class(TCustomAttribute) Style: TxStyle; constructor Create(const aStyle: TxStyle); overload; constructor Create(const aFont: string; const aSize: Integer; aAttr: TFontStyles); overload; end; type TText = class private FText: String; FStyle: TxStyle; published property Text: String read FText write FText; property Style: TxStyle read FStyle write FStyle; end; TParagraphs = TObjectList<TText>; //{$define UseRec} // Define to use the record format, undefine to use the individual fields // Regardless of defined or not, this does not compile. TDoc = class // would have a method to crawl the type RTTI and initialize the style attributes. private FTitle: TText; FBody: TParagraphs; public {$ifdef UseRec} [Font(TextStyle.Title)] {$else} [Font(TextStyle.Title.font, TextStyle.Title.Size, TextStyle.Title.attr)] {$endif} property Title: TText read FTitle write FTitle; {$ifdef UseRec} [Font(TextStyle.Normal)] {$else} [Font(TextStyle.Normal.font, TextStyle.Normal.Size, TextStyle.Normal.attr)] {$endif} property Body: TParagraphs read FBody write FBody; end; { FontAttribute } constructor FontAttribute.Create(const aStyle: TxStyle); begin Style := aStyle; end; constructor FontAttribute.Create(const aFont: string; const aSize: Integer; aAttr: TFontStyles); begin Style.font := aFont; Style.size := aSize; Style.attr := aAttr; end; begin try { TODO -oUser -cConsole Main : Insert code here } except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

No tool. Just an entry in the registry per text file extension (.pas .dpr .json etc).

qp is down again 😕

For me as purely a Delphi user, the comparison to FPC is irrelevant.