Leaderboard

I have created a new Delphi application called ChatLLM for chatting with Large Language Models (LLMs). Its primary purpose is to act as a coding assistant. Features: Supports both cloud based LLM models (ChatGPT) and local models using Ollama. Supports both the legacy completions and the chat/completions endpoints. The chat is organized around multiple topics. Can save and restore the chat history and settings. Streamlined user interface. Syntax highlighting of code (python and pascal). High-DPI awareness. The application uses standard HTTP client and JSON components from the Delphi RTL and can be easily integrated in other Delphi applications. You do not need an API key to use Ollama models and usage is free. It provides access to a large number of LLM models such as codegemma from Google and codelllama from Meta. The downside is that it may take a long time to get answers, depending on the question, the size of the model and the power of your CPU and GPU. Chat topics The chat is organized around topics. You can create new topics and move back and forth between the topics using the next/previous buttons on the toolbar. When you save the chat all topics are soved and then restored when you next start the application. Questions within a topic are asked in the context of the previous questions and answers of that topic. Screenshots: Settings using gpt-3.5-turbo, which is cheaper and faster than gpt-4: UI: Further prompting: The code is not actually correct (Serialize returns a string) but it is close. If you want to test ChatLLM you can download the executable.

That is probably true, but it isn't wrong in the first place. As real-worlds tend to differ significantly between users, it would be tedious and most likely incomplete what Embarcadero can do about simulating these scenarios and test every and all IDE functionality with it. Usually these real-world problems show up in beta tests, where a bunch of developers test in their own environment, but obviously in this case they didn't. This can be caused by people with multiple libraries installed registering a lot of standard actions just not using standard actions. That is the point where QP reports from normal users come into play. Without anyone complaining about an issue via the official channel there is no trigger to analyze the problem and fix it. I suggest to file a QP report about the visual delay and a separate report about the search/filter box. The request for a busy indicator would be moot when the performance problem is be fixed, which I would favor over that indicator.

The new QP doesn't support voting and I cannot see a benefit in sharing this. Well, sharing allows discovery, and those that are affected can add a comment?

I have been informed that a Quality Portal report about this problem has been filed: https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-742 Please VOTE & SHARE.

I am happily taking that task for you. Can you just list the installed packages accountable for that number of standard actions? I'm not sure if I was able to identify all of them.

There are several QP entries about that. It has been fixed in Delphi 12. It is one of the driving issues for me for moving to D12.

No, this is not possible in Delphi 2007. You can declare typed constants for fixed length arrays, but not dynamic arrays.

Sorry, content remove, I'm talking nonsense

^ I don't have D2007. Your D10+ version works in freepascal using {$mode delphi} and this works in fpc without it : sig2: FileSig = (Offset: 10; arrSig: ($00,$01,$02); );

Isn't the reason that Delphi is good at building GUI apps, at least it was for vcl back in the day. And it's still good for pure Win32 apps.

Why are Delphi developers so obsessed with doing GUI - I assume most software that operates the world is non-GUI stuff. And I also believe that this is typically the software that should be rock solid. The code that crashed Ariane 5 or caused security vulnerabilities in the recent past was hardly some GUI application. And Delphi code is only comparably fast with other languages that are top-tier in that category when you write it in a non-idiomatic way (i.e. pointers) - read some mormot Code if you don't believe me. Just one example: In other languages it does not matter if you are using some indexed-based loop (if that is even allowed) or some for-in/for-each loop - the compiler there knows its stuff and turns it into the fastest code possible while not sacrificing any safety. Sometimes the performance is even better when you are using built-in functions because internally the runtime and/or compiler devs did some incredible work optimizing stuff. Here is just one of the many examples of .NET 7. In Delphi, you almost always pay a cost for every abstraction although the compiler could make it zero-cost - one of the major tasks of modern compilers: enable the developer to write idiomatic and descriptive/declarative code without sacrificing performance.

Hi there, I'm still evaluating the D12.1 version currently, it all looks pretty much OK so far. What I have notices is, that the info.plist now containse more entreies: <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>16.4</string> <key>DTPlatformBuild</key> <string>20E238</string> <key>DTXcodeBuild</key> <string>14E300c</string> <key>DTSDKBuild</key> <string>20E238</string> Al this is understandable, to improve the development tools stability. Only the DTPlatformName wonders me, since I have checked "iPhone & iPdad" for the UIDeviceFamily: Which appears like this: <key>UIDeviceFamily</key> <array> <integer>1</integer> <integer>2</integer> </array> The general conclusion is like this: UIDeviceFamily: Defines the device classes on which the app can be executed. The possible values are: 1: The app is intended for iPhone (and iPod touch). 2: The app is intended for iPad. If both values are specified, the app supports both iPhone and iPad. DTPlatformName and other DT keys: These keys are specifically intended to provide information about the development environment and target platform, including the version of Xcode and iOS SDK used to build the app. They are important for the build and review process in the App Store, but they are not directly affected by the UIDeviceFamily setting. Perhaps this means, that the app should be broadly compatible within the iOS ecosystem, which is relevant during development and later distribution via the App Store. This also seems to fix an known error: https://docwiki.embarcadero.com/Support/en/“ERROR_ITMS-90507:_Missing_Info.plist_value._A_value_for_the_key_'DTPlatformName'_is_required”_when_submitting_an_app_to_the_iOS_App_Store Here some info from another source: https://github.com/godotengine/godot/issues/74154 https://forums.developer.apple.com/forums/thread/111697 What the heck is this DTPlatformName good for, is there any offical documentation about it? Maybe there are there other options too ...

There is only limited information here: https://docwiki.embarcadero.com/Support/en/“ERROR_ITMS-90507:_Missing_Info.plist_value._A_value_for_the_key_'DTPlatformName'_is_required”_when_submitting_an_app_to_the_iOS_App_Store

I can confirm this problem with a large number of standard actions added by third-party components such as ImageEn, TRichView actions... Very annoying and almost unusable, even for cat and dog owners 😉

I understand that you have concerns regarding the reliability of .NET for projects with long investment horizons. From my experience, it is important to note that support for any given version of .NET typically ends within approximately three years. For instance, long-term support for .NET 8 is scheduled until November 10, 2026. This may not be ideal for projects that require stability over time, considering operating system compatibility and security updates. https://dotnet.microsoft.com/en-us/download/dotnet If you plan to move to production quickly, you will have approximately one year before needing to migrate to the next version. Additionally, it is worth noting that native compilation, such as converting .NET IL to native code using tools like the native AoT c++ copiler, can pose some problems you will not be able to fix like loose all meaningfull stack on a exception. This approach can be problematic given how many NuGet packages and elements of the .NET technology stack rely heavily on reflection. Currently, no UI framework supports Ahead-of-Time (AoT) compilation, and most complex code does not function cross-platform. Moreover, utilizing third-party code can be beneficial, but it often requires significant effort to maintain, and performing risk analysis on such code can be challenging. Additionally, ensuring service level agreements (SLA) when the implementation correctness of the code is uncertain can be difficult. Based on my personal experience managing 22 NuGet packages with over 17 million downloads, maintaining them feels like a full-time job. As a result, we are currently transitioning from .NET to Delphi and creating wrapper classes to interface with the original C# code while ensuring that nothing breaks for my users during the process. If you need more convincing have a look at the security updates, I know as I reported several of them that are still not resolved. You can check out the .NET 8.0 Downloads page. https://dotnet.microsoft.com/en-us/download/dotnet/8.0

Actually, in my case it sometimes is "just because I can". I use Delphi not only to pay my bills, sometimes I just want to have some programming fun, and I imagine I'm not alone. But yes, there are actual reasons to use features in Delphi that are frowned upon by some people, even the discouraged goto.

If you really need to have multiple references to an object, then use interfaces and ARC to manage lifetime. If not, then you will have to invent similar mechanism for managing the lifetime.

Yeah, you are wrong. Such people exist. I am one. Not necessarily. No reason why pointer arithmetic should be faster than, for example, plain indexing of arrays. Again, good compilers are often better than humans. I don't think pointers are used in the RTL especially more than other libraries, and I don't think pointers are used there fore for optimisation and performance. As far as this whole memory safety debate goes, you can't exclude the RTL from it. That code executes in the code that is subject to attack.

The biggest issue with the Delphi code is that it forces heap allocation on you which is the real bottleneck.

Better to use CompilerVersion (and RTLVersion) instead, then you don't need to update the defines every time a new version is released, only when you need to add a new define, eg: {$IF DEFINED(DCC) OR (CompilerVersion < 23)} {$DEFINE EC_DELPHI} {$IFEND} {$IF CompilerVersion >= 20} // Delphi 2009 {$DEFINE EC_UNICODE} {$IFEND} {$IF CompilerVersion >= 34} // Delphi 10.4 {$IF CompilerVersion < 35} {$DEFINE EC_VCL27} {$IFEND} {$DEFINE EC_VCL27_UP} {$IFEND} {$IF CompilerVersion >= 36} // Delphi 12 ... {$IFEND}

Just to end this thread, I finally got my digital certificate, and I'm signing my applications. I kept a false positive version of the product to test signing it. Well it did work. That version wasn't compiled with DEP or SEH, and signing solved the false positive too. Hopefully this thread will help others

This looks like two questions. The first part is not currently possible using Delphi code, since there's no option to use AccessibilityService (there is for a plain Service and JobIntentService) In order to use UssdResponseCallback you need to write Java code, since you need to create a descendant of it (this is otherwise not currently possible in Delphi), and override its methods. You could define a Java interface that the descendant takes as a parameter in its constructor, and uses to redirect the overridden methods, much like I have in the code here: https://github.com/DelphiWorlds/Kastri/tree/master/Java/Base/Connectivity This Java code would need to be compiled into a jar which the Delphi app can consume. You would need to import the Java code into Delphi code. Using the same example above, this is the corresponding Delphi import: https://github.com/DelphiWorlds/Kastri/blob/master/API/DW.Androidapi.JNI.DWNetworkCallback.pas The next step is to construct a class that implements the interface defined earlier. Following the same example, that is TNetworkCallbackDelegate in this unit: https://github.com/DelphiWorlds/Kastri/blob/master/Features/Connectivity/DW.Connectivity.Android.pas You would then create an instance of the "delegate", and pass a reference to that when creating an instance of the descendant. Again following the above example, it would be similar to the code here: https://github.com/DelphiWorlds/Kastri/blob/82da3db3d0a526f6e93a30f3eb1a6c14779399bb/Features/Connectivity/DW.Connectivity.Android.pas#L98