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.

Delphi can already use Xcode 15. The biggest issue at the moment is debugging with iOS 17 (or higher) devices, which is a problem regardless of Xcode version. Debugging on devices with iOS 16.x still works using Xcode 15. A secondary issue is this one: a problem if your app needs to link to 3rd party binaries that were built with Xcode 14 or higher.

@Dave Nottage Thanks for giving hope and pointing to the right direction, as always As expected. simply starting and debugging an iOS 16.7.5 device with SDK 17.4 fails, with the following message: Starting the Debug Build without debugger ( Ctrl+Shift+F9 ) works well, start and seems OK so far. After a few more steps, I could really debug again on XCode 15.3 + iOS Device 16.7.5 + iOS SDK 17.4. Edit: Worth to mention: Running on MacBook Pro Intel: MacosOS Sonoma 14.4.1; Parallels Desktop 19.3.0 Here is the whole process is documented: I hope that can help another poor guy, who is getting crazy from the mysterious Apple moves.

Edit the internal build configuration and add __BuilderGUI to Conditions.

Aside from that, did you get anything from reading the post? (I don't have a compiler in my head, and I figured if I didn't show the declarations then someone would ding me on that.)

Perhaps I'm beating a dead horse here, but I'm going to go out on a limb and guess you're fairly new to the programming game, based on this statement. Please allow me to fill in some blanks for you. An "INI file" has a particular structure to it, and it's not dependent on the filename or its extension. Whomever wrote your code originally decided to use the INI file format to store the data, and also decided to use a .cfg extension on the filename. These are totally arbitrary choices. Back when INI files were first used, they did all tend to have .ini file extensions, but it's unnecessary. DOS introduced the use of "standard" file extensions and INI files were one such standard usage. Windows followed suit, as it as built on top of DOS. (CP/M probably also used INI files.) Today, most people would choose a JSON file structure for a config file format. It would NOT be named .json nor .ini, but .cfg could very well be used. Linux employs a LOT of config files, and they may be .config (NOT 'xyz.config' but just .config), xyz.conf, or even xyz.cf. Some are in a loose INI format, some are CSV, some are JSON, and many are whatever format the author decided to use. My point here is that you're thinking that a "configuration file" is always going to use some standard format -- that's simply not the case. There's no standard way to interpret a file with a .cfg extension. But most files with a .ini extension are very likely to use the INI file format. Putting JSON data in a file with a .ini extension would be deceptive. And I'd say most files that contain JSON data do not use a .json file extension; it's just not a common practice. (When DOS came along, file extensions were not used very much in other environments other than as 'hints' of sorts. But DOS used them to make it easier to know what a given file contained. So a .INI file always employed an INI file format; likewise, files with .txt, .doc, .ws, .wp, .obj, .lib, .exe, .com, and other extensions all had the same types of contents and could be opened with a specific tool. But .tmp is one that's used for any kind of temporary file, regardless of what the format of data in them might be.) Linux does not make any assumptions about what format the data in a file might be based on given its file extension. Mac is based on Unix, and does not care either. On the other hand, Windows itself does. People who write apps with Delphi ... not always. So use the file extension as a guide towards what the internal file format might be, but don't bet your life on it.

I "hope" that I have a world record with a fantastic 2 minutes and 51 seconds to show the standard action list (for your sanity, you can fast forward most of the video): https://we.tl/t-iC5uIavpK7 This was done without a safety net using Delphi 12 patch 1 in a VM with plenty of memory, disk space and processing power. Can someone beat me ? 😎 Embarcadero employees and/or Delphi enthusiasts are free to use that video, should they care to file a report. I've already spent way too much time on this to even bother looking for, registering to, and learning how to properly use the latest usable web site to report this problem. Meanwhile, I sincerely hope that I've added all the standard actions that I need in my app to avoid opening this dialog again 🤞

It just looks like the easiest to implement, but most of the time it turns out to be the hardest to get it done right. Another approach is to wrap the code into some TThread.ForceQueue construct. F.i. a loop calling Applicaton.ProcessMessages can be refactored like this: procedure DoAllTheThings; begin DoSomething; while DoWeNeedToWait do Application.ProcessMessages; DoWhatEverIsNecessary; end; Refactored: procedure DoAllTheThings; begin DoSomething; DoTheRest; end; procedure DoTheRest; begin if DoWeNeedToWait then TThread.ForceQueue(nil, DoTheRest) else DoWhatEverIsNecessary; end; All the code is still executed in the main thread, but there is no loop blocking anything.

The way Swift works is that you can declare value with either the keyword let or the keyword var. If you use let the value cannot be changed. But the expression you assign to a let value can be anything available at that point.