Vincent Parrett

Not really - more a case of trying to better understand it so I can have an informed opinion. My experiences with ai so far - Delphi/c# meh - typescript/react/nextjs useful for prototyping or simple things. I'm about to dive into web design (looking to redevelop my website) to see if it can help.

I've been playing with AI lately - if you can't beat them then join them 😢 My experiences are that the AI tools out there right now do not work that well for Delphi - they suffer far too much from library hallucinations (generate great code, if only the library existed!). I gave up and focused on some other projects/ideas On the other hand, if you want to create a React or NextJs application - they will do an amazing job. The main thing is to provide a good context to start with, use the AI to generate a Product Requirements Document - refine that before you have it start coding (and tell it not to start coding till you are ready). I'm still learning all this - but I was able to take a simple saas idea and spit out a working prototype in a day. I probably won't use the prototype - it generated Nodejs/Express/React code even though I told it it use asp dotnet for the backend - I'll recode it using some existing dotnet backend code (since nodejs is single threaded and I have background tasks) and iterate on the prototype front end React code. I will say the whole prompting experience is like looking over the shoulder of a junior dev - spending a day to get them to do a weeks worth of work. 2 steps forwards, 1 step back, over and over - it can be both exhilerating and friustrating at the same time. That 1 day chewed through my $25 Replit credit - so be prepared to spend. Will be trying claude code next - I have tried replit and bolt.new (good for web) so far, along with various others for basic chat stuff.

I would try using MadExcept or Eurekalog for capturing unhandled exceptions - in my experience they produce far more reliable and useful information than JCL.

I ended up using c# for the project - https://www.finalbuilder.com/signotaur - delphi just lacked the technologies I wanted to use for the project and I didn't want to spend so much time just getting the plumbing working.

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.

@Keesver thanks, this looks promising. Another dev was able to get it compiling with CBuilder Win64x - however my immediate need is Win32 - any idea what changes need to be made to get quickjs-ng compiling for Win32? I'm also keen to take some changes from https://github.com/koush/quickjs to enable debugging at some point.

Yes, ActiveScripting has been abandoned by Microsoft - which would be fine if they just made sure it continued to work for a while, but they recently completely broke it - https://www.finalbuilder.com/resources/blogs/finalbuilder-and-automise-on-windows-11-24h2 We have a ton of existing javascript, as do our customers (each action has events customers can write scripts on), so it's not simply a a case of swapping out scripting languages. I did look at p4d a while ago but ran into issues - I don't remember the specifics (something around threading - finalbuilder is multi threaded). It's on my todo list to look at again when time permits. We currently have iron python support, but have been telling customers not to use it for some time due to memory issues. Swapping that out for for P4D might sound like a no brainer but Iron Python allows people to use .net framework classes. What ever happens, we're going to have some unhappy customers. Tech debt sucks!

I'm looking to replace MS ActiveScripting in FinalBuilder.

Kindof - there are a bunch of "forks" of quickjs out there - QuickJS-Windows-Build is one - but it's very out of date and I couldn't get it to build.

Hi All I'm looking at getting QuickJS working in Delphi. Sadly my C skills are not at the level needed to get anything to build in CBuilder or Visual Studio these days - it's not the same language I used 30+ years ago. There are a bunch of forks of this project, and I am pretty sure I have tried them all but have yet to get a completely successful build - probably because I don't know what I am doing. Ideally I'd like to be able to generate Win32/Win64 object files that I can link into delphi, or if that isn't feasible then a dll that I can load. Prefer C++ Builder but failing that Visual Studo 2022 is also an option. The C code apears to be written for GCC and supports Win32 via MINGW. I am willing to sponsor someone to work on this if needed. DM me if interested. Timeframe is asap!

Interesting, similar to my old library (except that I handle stderr) - I will have to study it further as I have been considering using job objects since seeing a talk on them at DelphiSummit (I have looked at them in the past but never implemented them).

I'm also using a 4K buffer, but in my testing a larger buffer size makes no discernible difference to performance.

@Kas Ob. not sure what hardware he is using but on my 5900X ssd system I am seeing 16-17s for both his library and mine.

This is interesting - I have my own process library that uses IOCP for reading stdout/stderr and I thought it was fast (it's a lot faster than my old library that uses threads) - but in a quick test your library has pretty much identical performance. That makes me consider switching to overlapped io and avoiding the extra complexity with IOCP. My approach is similar to yours, my library does not convert stdout to strings by default. It was inspired by this library, which has a nice abstraction over the IO side of things. https://github.com/Tyrrrz/CliWrap Not sure if I will end up publishing my lib, I have become rather disallusioned with the whole open source side of things - but that's another story.

Intercepting functions for unit testing is a terrible idea. A better option would be to create abstractions and a concrete implementation (ie actually calls UuidCreate), that abstraction can be easily mocked using Delphi Mocks or Spring4D for uinit tests. The same applies to code that relies on things like Now or NowUTC - e.g - https://github.com/VSoftTechnologies/VSoft.System.TimeProvider