Leaderboard

New TeeBI demo, one line of code calls the Google Gemini api and imports the results into normal TeeBI structures. These data then can be simple visualized or queried. The idea is to add more AI agents (ChatGPT etc) transparently in the near future. https://github.com/Steema/TeeBI/tree/master/demos/3rd_party/AI uses BI.AI, BI.DataItem; procedure TForm_AI_Demo.Button1Click(Sender: TObject); var Data1 : TDataItem; begin // One line of code, call Gemini and get a data structure: Data1:=TBIAI.From('your key', 'Give me the list of the highest 10 mountains by elevation in csv format, just the list', TBIAI.GoogleGemini); // Visualize it: BIGrid1.Data:=Data1; // in the grid BIChart1.Data:=Data1; // in the chart end;

No, you should use separate units for each form and keep the {$R *.dfm} directive in each. The * makes it match with the unit name and the IDE will keep unit and form file names in synch. Please refrain from packing multiple forms into one unit. Otherwise you will most likely flood this forum with questions about the problems you get, while the correct answer will always be: Don't do that!

Thanks to the help of @Keesver and @pmcgee I now have quickjs-ng building with MINGW in WSL for Win32 and Win64. It would have been nice to get them building with native windows tooling but alas that's just too hard due to how the project is setup (ifdef hell). My next challenge will be to get his automated on our CI servers (server 2019) which currently do not have wsl installed. I added a windows resource file (winver.rc) so I can set the version number. #include <windows.h> 1 VERSIONINFO FILEVERSION 1,0,0,0 PRODUCTVERSION 1,0,0,0 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x2L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN VALUE "FileDescription", "QuickJS NG" VALUE "FileVersion", "1.0.0.0" VALUE "ProductName", "QuickJS NG" VALUE "Comment", "Compiled by VSoft Technologies Pty Ltd" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END FWIW - this is the makefile I ended up with - just provide the ARCH on the command line, e.g make -f Makefile_win ARCH=64 Makefile_win ARCH ?= 32 ifeq ($(ARCH),32) CC = i686-w64-mingw32-gcc CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" LDFLAGS = -static -shared RC_COMPILER = i686-w64-mingw32-windres --preprocessor=i686-w64-mingw32-gcc --preprocessor-arg=-E --preprocessor-arg=-xc-header --preprocessor-arg=-DRC_INVOKED RC_FLAGS = --target=pe-i386 else CC = x86_64-w64-mingw32-gcc CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" LDFLAGS = -static -shared RC_COMPILER = x86_64-w64-mingw32-windres RC_FLAGS = endif OUT_DIR = Win$(ARCH) RC_FILE = winver.rc RES_FILE = $(OUT_DIR)/winver.o SRC = quickjs.c libunicode.c libregexp.c cutils.c libbf.c quickjs-libc.c OBJS = $(patsubst %.c,$(OUT_DIR)/%.o,$(SRC)) TARGET = $(OUT_DIR)/quickjs-ng$(ARCH).dll all: $(OUT_DIR) $(TARGET) $(OUT_DIR): mkdir -p $(OUT_DIR) $(OUT_DIR)/%.o: %.c | $(OUT_DIR) $(CC) $(CFLAGS) -c $< -o $@ $(RES_FILE): $(RC_FILE) | $(OUT_DIR) $(RC_COMPILER)$(RC_FLAGS) -i $(RC_FILE) -o $(RES_FILE) $(TARGET): $(OBJS) $(RES_FILE) $(CC) $(LDFLAGS) -o $@ $^ clean: rm -rf win$(ARCH) Thanks again for all the help.

Multi-phase extension module initialization has been implemented. See Multi-phase module initialization implemented · pyscripter/python4delphi · Discussion #505 for details. What this means is that you can now create python extension modules with P4D that can be used with sub-interpreters including those created with the new concurrent.interpreters module of python 3.14.

I know... I know... (On the other hand I sold all my Tesla stocks).

If a "host" application is designed to use form classes implemented in dynamically loaded packages the host app has ( should have) no idea how the form classes are named. To make this into a truely modular and extensible application you need a design like the one used by the RAD Studio IDE. The app only knows where it has to look for extension modules to load (a folder or a registry or other configuration store listing the module file names). The modules register the form classes when loaded into a factory class or list implemented in a statically bound package used by host and all form modules. The host app can then enumerate the available forms using this factory to offer the selection to the user, check if such a form has already been created by searching through the Screen.Forms collection by class name, and, if not found, create an instance using a local variable that cannot be accessed from other parts of the app. If a form reference is needed elsewhere it has to be retrieved from Screen.Forms or another list, e.g. (for MDI child forms) the MDI frame form's MDIChildren collection. Doing it this way decouples the modules and even makes it possible to add modules without having to rebuild the host app. If one of the dynamically loaded forms uses a data module it should override the constructor and check for the presence of the DM before calling the inherited constructor and create an instance of the DM if necessary. I have a strict policy of immideately deleting the IDE-created global variables for forms and DMs if these are not part of the host app and are autocreated and live until the app closes. That prevents all manner of problems caused by accessing global references that may not be valid.