david berneda

The FastDateTime repository has been tested with RAD 13.0 Florence, all fine, similar speed gains than 10.1 Rio. I've added an indentical Firemonkey FMX test project to benchmark all the non-Windows platforms. https://github.com/davidberneda/FastDateTime

One of the hidden new features in RAD 13 is the TeeChart (VCL and FMX) "Lite" free version has been upgraded from 2021 to 2025.

https://steema.com/entry/634

Oops I have to re-test and benchmark that old code with the latest RTL, to make sure its still vaiid and worth it. About fast code, I'm interested in sse or avx speedups of array sum and min max, without cpu detection overheads

Ah nice catch ! I personally like to abuse of blank lines, so I quickly see the problem because after the doX; my eyes expect a blank line. Also blank line after each end; (except if the next line is also an end; )

😂 I can quickly identify code not written by me when I see a minor formatting difference. Even 20 years later 😂

Announcing the availability of the latest TeeChart VCL/FMX 2025.45 release with full RAD Studio 13 Florence (RX/DX/CX) support: steema.com/entry/634 #delphi #RADStudio13 #developers #programming #Delphi13 #charts #development #charting

Manual formatting for me is the best way to make sure the code is well done, calmly, as a final double-check there are no big bugs or something missing. I'd never do auto format, a headache to configure the many ways format can be done.

CPascal is another approach, it calls and generates LLVM from Pascal code. Ternary conditional is done C-style using "?" https://github.com/tinyBigGAMES/CPascal

If it can be of any help, case/switch In my "pet language" allows expressions at each case item. I choose the reserved keyword "when" just for fun, it can be another keyword in one second. https://github.com/davidberneda/Vidi // When. Multiple "ifs" (switch, case) num ::= 5 Console.PutLine(num) when num { < 3 { num:=123 } 4 { num:=456 } // is num equal to 4? <>6 { Console.PutLine('num is not six') } // otherwise else { num *= 7 - 1 } } Console.PutLine(num) // Works with any type when Name { "Jane" { Console.PutLine('Name is Jane') } "Peter" { Console.PutLine('Name is Peter') } // .Length=3 {} // TODO, use members "." } B : Text := 'b' when 'a'+B { "ab" { Console.PutLine('Text ab') } }

Do you think on using it? It can be useful to people that like to do debug logs.

Yep ! But this is exactly what I was trying to avoid, an inc file that would need to be copied and duplicated because not all units belong to the same projects or products, there is no shared path where to put that inc.

The PASS should only be allowed before reserved words program and library. Its just like if you were passing the params at the command line, before parsing anything. Several compiler params cannot be used inside an inc file. PASS allows everything. Units will still work right they do now, no changes.

And maybe the project uses units from different projects, folders, that do not share a common place where I can have my single unique inc file, thus needing multiple duplicate identical inc files, a nightmare to maintain.

But if I have 100 units I need to include the inc in the all 100 of them. This avoids that.