Lars Fosdal

No, not currently. There has never been a need. The test last night shows that all the test clients remained connected after enabling the 5 second Hello on the server side. That means I can go to the networking guys to ask them to dig a little deeper, unless... there was something in a Windows patch. We don't use timers - but waiting threads. I'll put the TCP level keep-alive in the back of my head for future exploration. @Kas Ob. The apps and servers run in a closed network with a limited number of clients and telegrams. A hello every 5 seconds doesn't add much load, and at this time, I think I will keep it server side as it works well enough. That said - the timeout period is a parameter, so we can increase it if we want to.

Thank you, @Remy Lebeau! I also asked our networking team about any recent changes to the network firewalls and routers. Which is preferable - the client or the server initiating the keep-alive? We did actually start with a server side test today, as it was designed in - but it has been configured off for years. If idle, it will send a "Hello" packet every 5 seconds.

Not in Delphi, for sure.

If it exists, it can be abused.

I also use IfThen a lot - but only for string constants. A ternary operator - or lambdas without the verbosity would have been so nice.

That one was new to me - and it looks pretty brand spanking fresh too. Ver.0.99. Pricing model is a bit simplistic. Needs a team license with source code.

If your main window pops up immediately, you may not need that splash at all. What is it supposed to tell the user? Why not put the db connections in threads? Everything and anything can be asynchronous if you do it right.

Rule #1 was meant to be a joke, but the point is - all that work needs to be done. If you do it before you display the window or after, will matter for the perception of the user. If you are waiting for it to start because it is prepping all the data before showing the first visible hint of running, it is per user perception - slow - or in the worst case if things take long, the user will assume it failed to start. If you first show the window, the user will know it responded and is working. If you show progress information after, the user will know it is still working on something, and people will perceive the "lost time" as less of a nuisance. The total startup time from launch to ready to use, will be the same - but for the user, it will feel faster.

Actually, it does work that way. First the window comes up, then it fills the list.

Why? Because not seeing the application work is easy to confuse with seeing the application not working.

Rule #1 - Don't do shit before your application has loaded and displayed itself. After the initial display, you can show various "Preparing good stuff - % complete" messages and do stuff in threads, allowing basic interaction with the app - such as doing an immediate exit. Speed is mostly about perception.

The magicians at Grijjy made something for iOS and Android. https://github.com/grijjy/JustAddCode/tree/master/ErrorReporting Nothing for MacOS or Linux yet. IMO, basic cross platform stack tracing should come out of the box from EMBT. MadExcept and EurekaLog could still make a living, dealing with more bells and whistles and with the reporting bit.

@Dmitry Arefiev - is there something planned for mitigating this? @BruceTTTT - Check the quality portal and add an issue if it is not already there. Edit: Wait a sec - we are using the MSOLEDBSQL driver - why doesn't it work for you?

I see these characters typically when there is an ANSI vs UTF8 vs UTF8BOM mixup. We prefer to ensure all files are in UTF8BOM format, and set up external tools, such as VS Code, to use that as the default format as well.

IMO, it is crucial for a REST API to not directly reflect the underlying system. The goal should be to ensure that any underlying implementation detail is hidden from the REST API. I would be wary of creating APIs that go 1:1 on the DB structure.

There is a new and improved XML Mapper you could try. Perhaps it addresses your issues? https://blogs.embarcadero.com/update-xml-mapper/

"the entries" could use a litte more context - are you thinking of content on the "Welcomepage"? For me, clicking on a video link in that window, pops up a new separate instance of my default web browser (Chrome), closes it again and then opens an Edge window to play it. Very strange, and somewhat annoying.

I certainly would not mind a Delphi for .NET - but it would need to plug into the rest of the .NET world, and not try to take it on alone. The last time they tried, MS did not play nice, and the other company that did an Object Pascal for .NET - well, they sort of went rogue. There is a lot of Azure and .NET in my future, and I believe that I will have to leave Delphi behind for C#. But - perhaps is Delphi better off as a compiler for native code on x86/x64/ARM64 on various platforms.

I agree! There are many awesome tweaking tips in this post! I really love @Stefan Glienke's approach that strips down the pure Pascal to a minimalistic set of operations.

Well, corner cases apart - it seems that it did?

I don't know, David, which is why I ask.

Nice! My ASM knowledge predates MMX, so this was a learning experience 🙂 How does it measure up speedwise to the others?

I wonder how it would look in assembly if you filled the out buffer with zeros, then swapped out the 1's by going shr/shl on a 64bit register. I guess the potential gain would be eaten by the time required for stuffing the hex data into the register.

I thought the Mac Mini price stayed the same? (Price in NOK)

Windows VMs on the M1 ARM seems to a no-go - but that is no surprise. But - it is a very impressive CPU - Twice the power, and twice the battery time.