Leaderboard

This release addresses problems with disabled IDE themes and Delphi 10.2 Tokyo releases below 10.2.3 (and some smaller bugs): https://www.mmx-delphi.de/2018/12/31/bugfix-release-for-mmx-code-explorer/

Consider the following Json data: The array elements are lists of integers, strings and objects. { "message": [ [ 0, "a text" ], [ 1 ], [ 1, { "switch": true } ], [ 2, "text one", "text line two" ] ] } Assume the JsonData const below is filled with the Json above. Using the Json tools from unit REST.Json, I would typically do like this. const JsonData = // see Json data above var Message: TJsonMessage; begin Message := TJson.JsonToObject<TJsonMessage>(JsonData); But - how should TMessageArray be declared to accept the above structure? Is it actually possible? TJsonMessage = class private Fmessage: TMessageArray; public property message: TMessageArray read FMessage write FMessage; end;

Ok, sorry, I read somewhere about a general discussion and up to now, nobody but You knew about record counts. Of course, a few thousand records can't itself be a problem. So I already asked the magic question and one must die a death. Use some of the magic switches already mentioned . Do intelligent initialization instead of swallowing the whole database into memory. At the moment processing seems to be complete opposite to "scaling" design. This includes a restriction right at the beginning. Does abstraction make problems simpler and lead to simple solutions? I don't think so, devide and conquer! Have a look at the details! All the best for 2019 to all forum visitors!

Here is what we usually do: Store logs in a dedicated folder, with proper read policy. -> especially under Unix, all background daemons run with a dedicated user, and the log files have chmod 640 to restrain read access. Always run the logs in Verbose mode, even on production, unless the execution environment is really constrained. (you never know what will happen, and detailed logs is a need for proper investigation, especially on production) -> you need a logging solution which is fast, and can log dozen MB/s with no performance penalty (e.g. our SynLog.pas unit writes in a background thread) Rotate logs to keep history as long as possible -> SynLog.pas has built-in SynLZ-compression of the logs for very fast and efficient rotation Never log passwords, or such sensitive information. -> password are always stored and persisted in salted + hashed form - but when transmitted as parameters, or as settings, they should be encrypted - even a naive encryption may be enough like with a TSynPersistentWithPassword class from SynCommons.pas -> more generally, sensitive information should be handled in memory with strong cryptography, e.g. via our cross-platform CryptDataForCurrentUser() from SynCrypto.pas Have a way to hide unexpected content, when log is automated. -> in mORMot.pas, you can register some sensitive types which parameters will be logged as "***" during SOA automated logging of calls. Ensure all those policies are always setup by default, and on all supported platforms -> today, we should ensure that Linux execution should be not weaker than Windows as a target (and it is easy to make executable safer under Linux) Optionally use a third-party SaaS solution to store your logs in the long term, with proper encryption and search abilities -> like https://livemon.com - server-side written in object pascal 🙂 Most of it is available out-of-the-box in http://mormot.net

Unless you use the external compiler, the compiler runs in the main thread and every time it updates the progress dialog it "pauses" the compilation. IDE Fix Pack reduces the slowdown a little bit by only updating the UI after a certain time interval or a filename change, thus not every "compiled lines" update repaints the UI. There are changes in the 64 bit compiler (e.g. some loop unrolling)

Wiki Article of the Change https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows#cite_note-10 One of out customer had selected that and we started to experience very weird problems and took some time to find out why it misbehaves. None of the application could connect to Firebird SQL server (Ours or third party) successfully. So would be smart to go through all tooling and code with that setting, we never know what M$oft will do with that, will it ever be released or will it soon be default for all. One coder switched this on and started to get weird results, he could not specify what all symptoms, but said that lot of work to be done before that setting can be enabled. Could be smart to Check how your environment, tools and code will behave.