msohn

Wow, I think my bullshit-meter just broke. Their marketing sounds like a non-technical managers dream.

I'd love to learn more about this. Does that mean that passing the variables as arguments to local routines would generate more efficient code?

I've seen the problem for a long time, I'd guess since around D7. But with DevExpress installed it takes less than 10 seconds to show (D11.2 with rather slow equipment), so it never really bothered me enough to report this. Since action registration allows you to specify a class descending from TDataModule for default properties and images, it might make a big difference if and how a 3rd party uses that feature. Who knows, maybe the relevant data modules are created multiple times every time the dialog is shown.

Thank you for letting me tick off an item from my bucket list. I'm sure googling for similar quotes from you would bring up quite a few hits, so I'll take it the timeframe isn't actually that large. Forget the (obviously not real) code, I'll stand by my advice that it's best to aim for code which works with and without FP exceptions - how to achieve that will vary depending on your requirements. What if the host isn't even aware that your DLL is involved or that it has such a contract? Or other parties are involved which you have no control over (again shell extensions, printer drivers etc.) Unless you have full control over where your code is run, this is impossible to enforce. How can you make this work in a thread-safe manner? Now to get back to some real code, I'd love to hear your opinion on the following fragment (sorry, insert code popup again didn't work): function MyFloatingPointAPI: Double; cdecl; begin try Result:= ComplexCalculation; except on E: EInvalidOp do Result:= NAN; on E: EZeroDivide do Result:= INF; on E: Exception do ...log, handle, whatever end; end; If you properly document that NAN and INF are possible results of your API, this should work fine both with and without FP exceptions without introducing much of a performance hit, right?

From my experience, you could never really rely on floating point exceptions. If your code is in a DLL, the host process might change the exception mask. If your code is in the EXE, a loaded DLL might unexpectedly change the exception mask. This can even be caused by showing a common dialog (think Open/Save dialogs) because that will cause Shell extension DLLs to be loaded into your process. Or an ActiveX, an in-process COM client and so on. In the end, you should make your code work both ways and check floating point calculation results with IsNAN and IsInfinity, e.g. try F:= <some floating point calculation> except on E: EInvalidOp do F:= NAN; on E: EZeroDivide do F:= INF; end; if IsNAN(F) then <handle InvalidOp> if IsInfinity(F) then <handle zero divide>

I can't tell you which Xcode version is required for the PA-Server of Delphi 12. But here's what I did to make any* PA-Server work with any* Xcode (* well within bounds naturally, I made PAServer of Delphi 11.2 work with Xcode 15.3). Make a copy of PAServer-xyz.app (I used ~/Developer, i.e. below my home directory) In Terminal, remove the signature with "codesign --remove-signature PAServer-xyz.app" cd into "PAServer-xyz.app/Contents/MacOS/lldb/lib/python3.<whatever>" change the symbolic link Python to point to your Xcodes current python: "sudo ln -hfs /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/Current/Python3 Python" run the modified PAServer (sign it again with your own certificate if desired) The "Current" in that Xcode path is a handy symbolic link - and makes me wonder why PAServer doesn't make use of it.

I've been using TypeInfo.SetEnumProp for that - works for all Enums that are published properties. It basically is SetOrdProp with GetEnumValue shown by Dalija, so saves you figuring out the enum size.

Not only unicode. Everything below space and above 127, i.e. ASCII minus the non-printable ones. System.Classes.ObjectBinaryToText.ConvertValue has all the - not so glory - details. I'm surprised you're not used to encountering those - assuming Scandinavian background. I see those fairly often in DFMs because of German umlauts - for projects not designed in English.

Since your post actually made me start doing a Delphi binding, allow me a shameless plug: https://github.com/modersohn/delphi-tree-sitter I'm still busy covering queries, but it should be a matter of days before I've covered these as well. And yeah - I too would very much love to see how you did the querying. And I've noticed that tree-sitter-pascal in its current form could not handle some sources I threw at it - but I didn't yet actually figure out what caused this, too busy getting the basics done.

I'm trying to write a Delphi binding for tree-sitter over on GitHub and am struggling with calling this C API: typedef struct TSNode { //content doesn't really matter here } TSNode; typedef struct TSPoint { uint32_t row; uint32_t column; } TSPoint; TSPoint ts_node_end_point(TSNode self); On Win64 SizeOf(TSNode) = SizeOf(Pointer) this works just fine. On Win32 it crashes. According to the Language Guide 64bit Integer function results are returned in EDX:EAX. So I have tried declaring the method as returning Int64 and hard-casting that to my TSPoint record: {$IFDEF WIN32} function ts_node_end_point(self: TSNode): Int64; cdecl; external ModuleName; {$ELSE} function ts_node_end_point(self: TSNode): TSPoint; cdecl; external ModuleName; {$ENDIF} function TTSNodeHelper.EndPoint: TTSPoint; begin {$IFDEF WIN32} Result:= TTSPoint(ts_node_end_point(Self)); {$ELSE} Result:= ts_node_end_point(Self); {$ENDIF} end; This solves the crash, but it seems rather a coincident that it's working partially (row seems to be right, column is off and the similar ts_node_start_point API is completely off). Is there even a way to call this API reliably on Win32?

Regarding the alignment: I initially thought the same thing, but even with an explicit {$ALIGN 8} the record size is still 8. About the missing cdecl: man, I can't believe I made such a silly mistake! Thanks for having a look and spotting this - that does indeed fix it and now the workaround via Int64 is working - wonderful! It's not the first time and I'm sure it won't be the last: thanks for your help, I very much appreciate it!

Thanks for the links and confirming that my thinking wasn't totally off. TSPoint only contains two UInt32 so AFAICS it is always 8 bytes in size, regardless of packed or $A settings: TSPoint = record row: UInt32; column: UInt32; end; (sorry for the missing formatting, it just wouldn't insert anything using the insert code popup; worked fine for the initial post) Also, the column isn't totally random, it's just that 1 or 2 bits are set in addition. And to make things worse, the identical API ts_node_start_point does not return anything in EDX:EAX, i.e. when stepping over the call, both registers remain unchanged. The 2nd stackoverflow link has an answer from David Heffernan stating that Delphi is the compiler being wrong here in that it does not follow the ABI. I'm afraid that makes it not very likely to convince other developers to change their API. FWIW all the necessary code is on GitHub (https://github.com/modersohn/delphi-tree-sitter), for the binding I started and for the DLL as well (linked from my repo).