Leaderboard

That is only an issue for library authors that need to target a range of past versions which is the vast minority of Delphi users. Most migrate to a new version, start using that and never have to run their code through previous versions. Type inference for inline variables is a really nice thing - no need to explicitly decare the type just to tell the compiler (yes, if you name your variable properly the type is irrelevant for understanding the code, ask programmers from other languages that have this feature for a long time). Also often enough you have to add units to a uses clause just to declare a variable of a type that is the return of a method of some other type being used - with type inference that becomes unnecessary.

There have been few bugs around inline variables, but for using inline variables in day to day code, probably the greatest problem was non functional code completion and code navigation. They would also break Error Insight, but that thing is all kinds of broken, so having one more way to break it is not critical. Besides, Error Insight itself is not critical feature. On the other hand, one permanent pitfall lies in inline variables combined with type inference and reference counted classes as explained in my blog post https://dalijap.blogspot.com/2019/03/inline-variables-type-inference-and.html

%s is yet a string so it's somewhere normal Try FormatDateTime('dd.mm.yyyy',value) or declare your fields, set your date field displayformat property to 'dd.mm.yyyy' and use displaytext in customformat

I've also seen compile time issues where you must specify the type T of the iterator for a TArray<T>.

Hi there, usually VmWare provides install procedure very nicely: download Macos installer .app from AppStore, then create new VM and drop it into. This works on some Mac, but seems not to work on all Mac's, for some reasons only Apple knows. I had such case with an older MacBook Pro, and wanted to describe the procedure below. After some search in the Web I found a nice article about same issue with Mojave, so I took this as base. Since I'M on Catalina, I had to make some changes. Here are the steps in compressed form: Create VmWare Macos guest from ISO (Catalina) Web : Search "Update Macos Catalina" (or the OS you'll want), to find the right entry in the AppStore AppStore: Download "Install Macos Catalina.app" from AppStore. After download: Cancel the auto-start of installation on the host. Host : /Applications not always usable, as this is a special protected folder. Move "Install Macos Catalina.app" from /Applications to /Documents folder. VmWare : Select “Apple OS X” and then select “macOS 10.15” and Continue. VmWare : Choose “Create a new virtual disk” and continue. Either Finish or Customise Settings of the virtual machine. (e.g. 4 CPU, RAM 4GB, no 3D acceleration, Use full retina display, HD 60GB, etc.) The VM is prepared now, its needed to create a OSX Catalina ISO file. Host : Prepare a OSX Catalina ISO file from the installer. Terminal : Create a temporary virtual disk file in your tmp directory. hdiutil create -o /tmp/Catalina.cdr -size 12000m -layout SPUD -fs HFS+J Wait until finished created: /tmp/Catalina.cdr.dmg Terminal : When done, attach and mount the virtual disk hdiutil attach /tmp/Catalina.cdr.dmg -noverify -mountpoint /Volumes/install_build Wait until finished /dev/disk3 Apple_partition_scheme /dev/disk3s1 Apple_partition_map /dev/disk3s2 Apple_HFS /Volumes/install_build Terminal: [Optional] Check all available mountpoints diskutil list Host : Rename the installer, to be compatible with the following scripts, e.g. by Finder. ren "~/Documents/Install Macos Catalina.app" ~/Documents/MacosInstaller.app Installer is available now under the path: ~/Documents/macOsInstall.app Terminal : Extract and create an installable image from the download (with elevated rights). sudo ~/Documents/macOsInstall.app/Contents/Resources/createinstallmedia --volume /Volumes/install_build Wait until finished Password: Ready to start. To continue we need to erase the volume at /Volumes/install_build. If you wish to continue type (Y) then press return: y Erasing disk: 0%... 10%... 20%... 30%... 100% Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100% Making disk bootable... Copying boot files... Install media now available at "/Volumes/Install macOS Catalina" Terminal : Move the contents of the virtual disk into a .dmg file on your desktop mv /tmp/Catalina.cdr.dmg ~/Documents/InstallSystem.dmg Terminal : Detach the virtual disk (installer) hdiutil detach /Volumes/Install\ macOS\ Catalina Wait until finished "disk2" ejected. Termnal : Convert the newly created “InstallSystem.dmg” into an .iso file. hdiutil convert ~/Documents/InstallSystem.dmg -format UDTO -o ~/Documents/InstallSystem.iso Wait until finished Driver Descriptor Map (DDM : 0) read … Apple (Apple_partition_map : 1) read … (Apple_Free : 2) read … disk image (Apple_HFS : 3) read … .............................................................................. Time: 1m 39.113s Speed: 121.1M Byte/s Reduction: 0.0 % created: /Users/Rollo/Documents/InstallSystem.iso.cdr Host : Change the filetype of the file “InstallSystem.iso.cdr” in your documents, e.g. with Finder. Select the file and hit enter, now rename the file to “InstallSystem.iso” (with prompt); Select “Use .iso” VMware : In virtual machine manager right click the newly created VM (see above). Choose settings. VMware : Choose “CD/DVD (SATA)” Next GoTO the pull-down menu and browse to the “InstallSystem.iso” file just created. Check “CD/DVD (SATA)” connect checkbox VMware : Boot the new machine and follow Apple installation instructions. These steps worked well for me, and are maybe useful for somebody else too. Maybe in the new VmWare installer provide the Drag'n'Drop for all images flawlessly, in the future, and this won't be necessary any more.

You are right: FastMM5 challenged me... and since no one responded to my offer about helping it run on FPC/Linux, and also since I wanted something Open Source but not so restrictive, I created https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.fpcx64mm.pas which is GPL/LGPL and MPL. So you can use it with closed software. It uses the same core algorithms than FastMM4. I like it so much, and missed it so much in FPC... 🙂 I was involved in ScaleMM2, and a per-thread arena for small blocks didn't convince me: it tends to consume too much RAM when you have a lot of threads in your process. Note that a threadvar is what the FPC standard MM uses. I wanted to take the best of FastMM4 (which is very proven, stable and efficient), but drive it a little further in terms of multi-threading and code quality. FastMM4 asm is 32-bit oriented, its x86_64 version was sometimes not very optimized for this target - just see its abuse of globals, not knowledge of micro-op fusion or CPU cache lines and locks, and sparse use of registers. Also focusing on a single compiler and a single CPU, with not all the features of FastMM4 in pascal mode, helped fpcx64mm appear in two days only. Last but not least, I spent a lot of time this last year in x86_64 assembly, so I know which patterns are expected to be faster. The huge regression test suite of mORMot helps having a proven benchmark - much more aggressive and realistic than microbenchmarks (like string concatenation in threads, or even the FastCode benchmark) on which most other MM relies for measurement. When the regression tests are more than twice faster than with the FPC standard MM on Linux - as @ttomas reported - then we are talking. It runs a lot of different scenarios, with more than 43,000,000 individual tests, and several kind of HTTP/TCP servers on the loopback, running in-memory or SQLite databases, processing JSON everywhere, with multiple client threads stressing it. When I run the test on my Linux machine, I have only a few (less than a dozen) system Linux nanosleeps (better than Windows sleep) , and less than 2 ms waiting during a 1 minute of heavy tests - and only for Freemem. I really don't like the microbenchmarks used for testing MM. Like the one published in this forum. For instance IntelTBB is very fast for such benchmarks, but it doesn't release its memory as it should, and it is unusable in practice. I guess that some user code, not written with performance in mind, and e.g. abusing of str := str+'something' patterns would also be more than twice faster. And if your code has to reallocate huge buffers (>256KB) in a loop, using mremap on Linux may make a huge performance boost since no data would be copied at all - Linux mremap() is much better than what Windows or BSD offer! Yes, huge memory blocks are resized by the Linux Kernel by reaffecting its TLB redirection tables, without copying any memory. No need to use AVX512 if you don't copy anything! And plain SSE2 (with non-volatile mov for big buffers) is good enough to saturate the HW memory bandwidth - and faster than ERMS in practice. IMHO there was no need to change the data structures like FastMM5 did - I just tuned/fixed most of its predecessor FastMM4 asm, reserved some additional slots for the smaller blocks (<=80 bytes are now triplets), implemented a safe and efficient spinning, implement some internal instrumentation to catch multi-threading bottlenecks, and then Getmem didn't suffer from contention any more! I knew than FastMM4 plus some tweaks could be faster than anything else - perhaps even FastMM5.

Don't think of the problem as how to write the code effectively given the data structure. Think of the problem as choosing a combination of data structure and algorithm to solve your problem. In other words, ask about the underlying problem, and be prepared to consider a variety of other data structures, which in concert with the right algorithm might perform best.

I received a pre-release sales offer today which names it 10.4 Sydney and provides discount codes for Delphi and C++ Builder so I'm hoping the 10.4 release date is coming "soon". https://github.com/ideasawakened/DelphiKB/wiki/D27.SYDNEY.10.4.0.0 Time to GetExcited! I always look forward to a new version of Delphi to play with!

YES, exactly that! However many Delphi developers have a troubled past where often "new" things turned out to be broken, caused problems or were simply not thought through entirely and just slapped onto existing things like duck tape. Like using attributes like [ref] in addition to the existing keyword const just because of the fear to introduce new keywords or introducing inline variables (that had many bugs) without the entire tooling understanding them and stopping to work. So many people are in the mindset of "don't touch it so you can't break it" and "fix the existing bugs before adding new broken stuff"

No feature freeze until Delphi Antarctica

The most significant issue is that Set8087CW and SetMXCSR are not threadsafe. It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state. I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. Doc is here https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current. Of course, that does not necessarily apply for everyone, and I can understand the cost perspective for a one-man shop - but for a corporate developer that is continuously developing internal systems, it is a no-brainer to stay current. You get the fixes, you get the support, and since we do relatively frequent releases, we do the testing anyway. Rio -> 10.4 will mean a lot of work on the FMX side - but on the bright side - you can finally stop having to think about two memory models when you write code for cross-platform. That dual model has actually been a roadblock for cross-platform for us. We did not want to spend time on that duality.

When given the option to upgrade: Upgrade. Every single version. The individual steps between versions are not that big. We will most likely not be facing a brute like the Unicode disaster (in my eyes) like back in the day. @David Schwartz: I seriously have to wonder, what needs to be done between Tokyo and Rio. In my (albeit not very broad) experience there should be nothing to do at all, except when using FMX, but then FMX forces to update anyway. Sherlock

As a single developer, I sometimes rewrite my projects to newer technologies without a significant improvement just to keep myself up-to-date. But I can't understand why business decides to rewrite a working and tested project written on "good old lang A" from scratch using a "brand new shining lang B". Especially considering that "lang A" is pretty alive and developing. Geek coders sometimes tend to rewrite things just because existing stuff uses a language, libs or even a license they dislike but a company with customers shouldn't be such geek.