darnocian

Ok. I was just hoping for some sort of example, as the SameValue/isZero is a generalised approach. So back to the original post, I guess we can just take it that there are some issues with the new version of the compiler, and will need to log some issues with QP once it is back again.

I'm still interested to know more about any alternatives to using epsilon for comparison. I've only seen subtle variations on the same theme, and always keen to learn something new.

Sorry. A bit late to answer now... .a files is a normally a C static library. In C are essentially a container around compiled .o files. There is no point to distribute .a files, unless someone is going to link against it. Typically static libraries are only useful during dev for users of libraries, and not so much for applications as they would get linked in. Your main deliverables from an app perspective would be the executable along with any shared libraries (dlls/so/dylib). Nothing stopping you from shipping anything you want of course. With shared library, the developer using the shared lib just needs to know the directory and filename, and then reference the library and functions appropriately as required. The main thing is that it is clear what platform is used and being able to distinguish 32/64bit. There is no universal convention from what I'm aware of. If you are using Delphi, use the Delphi convention... it is clear enough. <platform>/<configuration>. although, if you are only going to ship release builds, just do <platform>

mainly on what solution thinks is acceptable. These are all tools. we can choose to use what we want, but just need to know the limitations.

It isn't all about you. I'm just sharing. Glad you know.

The rationale for it is when it comes to rounding due to the way the float is represented with limited bits... there will be to mismatches. You may be lucky, and comparison may work, but the epsilon comparison approach is a failsafe method to cater for rounding issues in the process of various calculations. Here is a simple example. procedure Test; var d: double; d2: double; diff: double; v, v2: double; begin d := 1.0000002; d2 := 1.0000001; v := 0.0000001; v2 := 0.0000001; diff := d - d2; // 9.99999998363421e-08 assert(v = v2); // values do match assert(diff <> v); // doesn't match because of rounding assert(SameValue(diff, v)); end; above done on win32. I aligned the numbers on purpose... if we do the math, we can see v should be d-d2. v = v2 is true.... then noddy calculation, we have diff = d-d2... and diff <> v, but SameValue with the epsilon shows with the given precision, we assume the numbers to be the same.

What do you mean by useless? Just not liking the specific implementation?

I was looking at docs: https://docwiki.embarcadero.com/Libraries/Athens/en/System.Extended I'm not a fan of the type being so different between platforms. My memory is still 64kb, so am relying too much on ChatGPT these days 😉 There is float32 and float64... maybe making a few more types indicating how many bits can also help make the size a bit more obvious.

Floating point is always fun. Math.IsZero has 3 overloads for different types - extended, double, single With a simple test app on Delphi 12: program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.Math, System.SysUtils; procedure Test; var e: extended; d: double; s: single; te, td, ts: boolean; begin e := 3.5527136788055E-15; d := 3.5527136788055E-15; s := 3.5527136788055E-15; te := iszero(e); td := iszero(d); ts := iszero(s); end; begin try Test; except on e: Exception do Writeln(e.ClassName, ': ', e.Message); end; end. On Win32, I was surprised that 'te' is false. On Win64, the values are as expected. Something to note for those that don't know. In Win64, 'extended' is 64bit like 'double', where on Win32 it is 80bit. I didn't check between versions, but is the resolution the same? Squirrelled away on line 5290 in System.Math, there is: const FuzzFactor = 1000; SingleResolution = 1E-7 * FuzzFactor; DoubleResolution = 1E-15 * FuzzFactor; {$IFDEF EXTENDEDHAS10BYTES} ExtendedResolution = 1E-19 * FuzzFactor; {$ELSE !EXTENDEDHAS10BYTES} ExtendedResolution = DoubleResolution; {$ENDIF !EXTENDEDHAS10BYTES} IMO I think those consts should probably be variables and in the interface section so they can be overridden if required. It does look like something buggy happening with the 'Extended' type on win32... I played with SameValue and Compare( which uses SameValue), which didn't look bad. SameValue/Compare take an Epsilon (the resolution). Stepping through IsZero, what I spotted in the debugger: if Epsilon = 0 then Epsilon := ExtendedResolution; After the assignment to Epsilon, Epsilon was 0 and not 1e-16. On 64bit, Epsilon becomes 1e-12. So something funky with the codegen? I recall some changes to FP operations in the new compiler, but I can't recall offhand.

If you want to export for other languages, a DLL project is what you want. when you switch platform the project will generate a so, etc. You just need to add the exports. Note that symbols may be exported differently on different platforms. E.g. there may be an _ in front of names when importing… best way to validate is to dump exports on the shared object once it is created.i haven’t tested android recently, but did Linux.

Hi All, Just a quick announcement that a new version 1.7.5 of the Sempare Template Engine is now available. Sempare Template Engine for Delphi allows for flexible dynamic text generation. It can be used for generating email, html, source code, xml, configuration, etc. Integrations have been done with a number of web frameworks such as: Indy, WebBroker, Horse, DelphiMVCFramework, mORMot, ... Please check out the project, and 'star' it on github. https://github.com/sempare/sempare-delphi-template-engine From v1.7.5 FIX: Improved JSON (System.JSON) support FIX: Refactor RTTI deref methods From v1.7.4 (released last week) NEW: Assignment can now be done using both Pascal (:=) and C (=) operators. This is a flexibility feature to support users. NEW: default(value, default) method. Default is returned when IsEmpty(value) is true. NEW: domid(record_or_class [, context:str] ) NEW: pascal-like ternary: <% greet := true; print( 'hello' if greet else 'bye' ) %> FIX: refactor old C-like ternary <% print(greet? 'hello':'bye' ) %> FIX: some of the language constructs required open and close brackets. These are now optional. Close bracket will be forced when the open bracket is used. FIX: semi colons can be used more liberally within the script blocks, even with empty statements. <% print('hello'); ; ; ; print('world') ; %> Regards, Conrad

That is also why I called it my 'wish list'. 😉 I agree with stability. In my list, I'm not sure if 'improve' is actually a 'feature' or a 'fix'. Depends on interpretation, and I guess the underlying implementation complexity that we are not aware of. However, I'd like a major version number to actually include features, with minor versions including minor feature/improvements, and patches. It looks like they have started on the C++ side of things... that is promising. It is hard evolving a product, especially a language, with the being any knocks. Sometimes you get close, but we've seen, it can be a challenge. How do we found out how to get the message about reinvestment to the powers that be? Unfortunately, there needs to be lobbying power, and that means numbers. strike strike strike 😉 Jokes aside.. It is still an amazing product... we all wish it were better, faster... and hope that we can get new generations of developers to be as enthused about it as we are.

Yeah, it is a bit annoying though... We can't always change a 3rd party library that we want to inspect via rtti. there are always workarounds... ;(

my wish list for Delphi 13 (although probably too long!) IDE - continued LSP enhancements (it is gradually getting better, but I'm still having issues...) - support for auto completion of anonymous methods .... e.g. var func : TFunc<integer> := { Ctrl+Space here and the rest expands } function : integer begin end; - support that could 'suggest units to include' when you start using something that is not already referenced. - support to handle multiple monitors... when I place it on one monitor, between startup, edit and debug, I'd like it to stay in the same place, without resizing, or jumping about. - code formatter! please! object pascal: - improved type inference on generics ... IMO there are scenarios where the compiler forces you to specify a type when I think it can be inferred from a parameter type, or even a return type. Delphi doesn't ever try to match return types generally at present. ;( - traits - essentially compile time generics/interfaces .... so you program to a trait, and anything that matches (interface, record, class) that matches the methods, fields, properties etc could work with it. This could remove a lot of repetition in very similar code (which is what generics is all about) - interface improvements (possibly an alternative away from COM compatibility which is what probably gives us the restrictions we currently have) ... - improved generics - e.g. 1. generic functions (already mentioned by Lars) 2. allowing for constants to be passed as generic parameters could be useful. Could allow for meta programming like in C++ 3. when using methods in an implementation of a unit, from within a generic method, the compiler forces you to declare the method again in the interface section. I hate exposing things that shouldn't have to be public. - compile time constants from expressions that may be the result of function calls. e.g. const PI :double = calcPI(); - constraints on attributes e.g. so we can localise their usage to methods, parameters, types, etc... - an improved case statement supporting match criteria - a short inline lambda (syntactic sugar - shorter form of anonymous method). e,g, var add1 := lambda (y:integer): y+1; var two := add1(1); - improved helpers / partial classes - somehow supporting multiple with conflict resolution - magic functions to identify filename, function, line no. This could be useful for use with loggers, but could bloat code if not used cautiously. Some things can be done with map files and 3rd parties, but would be nicer to have stack traces, etc accessible as part of the normal RTL. my wishlist is possibly too big ;(

Say in serialisation, you construct offsets relative to a certain address (say the start of the first record), and in deserialisation in another process, you convert back to pointers again. The key to it being useful is the layout and relative addressing.