Chinese Association: AI-assisted Red/Rebol Tool

Since I've been making inflammatory comments here recently, nobody can reasonably claim I've disappeared.

But I have also been doing some actual coding.

I’ve returned to the Rebol family for a real project: replacing the increasingly unmanageable membership spreadsheet of a 100-year-old New Zealand Chinese association. Here's the repository:

https://gitlab.com/Zhaoshirong/tja-membership (Current checkpoint: 0.1.35)

The current client is written in Red/View, with Oldes R3 beginning to act as a local asynchronous service layer. Behind it are AWS Cognito/API Gateway/Lambda and Aurora PostgreSQL.

What has made this particularly interesting is that I’m building it with substantial AI assistance. I’m using AI much more like a very fast pair programmer than as an application generator: I still decide the data model, architecture and behaviour, while it helps inspect code, propose patches, chase Red/View peculiarities, write SQL migrations, and keep track of the interactions between Red, R3, Python, PostgreSQL and AWS.

I started with a generic prompt for Rebol/Red Development, but then have a specific one I made for this project:

Today’s amusement was adding a small API/database trace window. We had a Gender field in PostgreSQL, the client thought it supported it, and yet it kept coming back wrong. The trace immediately showed that the deployed Lambda was returning the old JSON structure. After updating it, the trace showed:

GET .../people/112

"sexCode": "MALE"

Problem isolated across PostgreSQL → Lambda → JSON → Red.

I’ve also rediscovered some very Rebol-ish lessons. A one-second invisible View face is my application heartbeat. When Aurora wakes from auto-pause, a synchronous HTTPS write stops the heartbeat, making the blocking-I/O problem wonderfully visible. That has pushed me toward using Oldes R3 as an asynchronous localhost broker.

So after all these years I seem to have ended up with:

Red/View + Rebol3 + PostgreSQL + AWS + AI + a sleeping database.

And the heartbeat is still running.

1 Like

Oh, I forgot to mention that I chose Red/View for the GUI and Oldes' r3 for the httpd server because my plan is to migrate completely to Oldes' r3 once he has a working GUI. And currently although I was able to bring up a window with some coloured boxes, that was about it.

1 Like

8 posts were split to a new topic: Brian Gripes About Graham's Chinese Thing

Given that I can not justify the full kit, I am versioning the state of the AI and its state files are now being named tja-chatgpt-gosseyn-state-datestamp.

It's a little joke between me and gpt.

This was too slow. I now use chatgpt+ to prompt Claude code with a filesystem mcp that is looking much faster.

Hi Graham,

a bit late to the game, but your post somehow made my day. Half year ago, I needed to create some SW support to my wife and here photo business. She had something like 20+ schools, classes, anonymous children (GDPR) and we needed to organise things cleverly and also introduce a secondary business ....

First I draw some sketches on paper, meaning mainly the process. And then I have started "coding" and hit the wall - how do I interface Smugmug with their old REST API? I have used paid GPT and free Gemini.

My initial experience (programming some Elecfreaks carts for my son), was a similar experience to yours. I have e.g. instructed AI to not change the code, just adapt this or that aspect. And often I have ended up with a completly different version. With my Smug endeavor, I was kind of stricted, in a better comfort - my feeling was, I am instructing bots to what I want. I also refused some artificial function splits, etc., because I wanted to stay pragmatic - returning to code in 6 months, adn still have good immediate understanding of the concepts. And of course, I am not that far with AI, as you are - skill files, etc.

So what I have learned along the way? First thing is - let's take what we have got and find some way of working. Prototyped GUI for the voucher generation in VID, Draw, Rich-text, scrapping it at maybe 80% of functionality, and replacing it by Red driven html generation. Deep dive to R/S write code, to understand construction of a POST body and prevent Red from hard crashes. Implemented QR code wrapper, finishing full Smug API support, being able to create galleries, uploading over 2K photos, including QR vouchers, etc.

And as I have faced a problem with the blocking behaviour of Red, I created simple "tasking" system, called Jobber and decided to separate it from the code as a module. The principle is easy - folder with job files, carrying a basic state .job .run .done .fail. Strict rule one file can be owned only by one running worker. Wrapping Windows tasklist, launcing predefined number of workers.

So - wish you a great journey creating your new system, even if teporarily glued using multiple technologies ....

Hi Pekr

Long time no see. Your english has improved immeasurably since you first arrived on the mailing list and Altme!

AI is a lot better for me for dealing with Amazon, database, sql etc.

It is not that good at View/Vid and it's painful to watch. What might take a few seconds of my time takes 100s - 1000s of Claude's tokens. But Chatgpt assures me that Claude code will get better as it gets to understand the red and red/view code base.

So, I have faith and let it grind away running testing with snapshots everything it does anything on the screen. Spooky! But we don't have Saphirion's test harness for the gui so we live with what we have.

Kind regards,

Thanks Graham for your kind and warming words, appreciated. Now back to Red - you surely remember that I tended to be quite vocal, or even radical, in the past. Even with Red, I was once marked as a "troll", so nowadays I try not to favor or downplay systems just for amusement :slightly_smiling_face:

While I, and many others in the community, were critical about the lack of Red developments for many years, the situation has changed quite radically in the last half a year. We can see the first unofficial 64-bit View release for Mac and Apple Silicon. Francois is doing great work there. View got tons of fixes, even on Linux.

And last but not least - View now has a headless test suite, where tests can run against a dedicated test GUI backend, with no display/windowing system required.

REBOL [
	Title:   "Builds and runs the headless View/VID tests (test GUI backend)"
	File: 	 %run-view-headless-tests.r
	Author:  "Red test suite"
	License: "BSD-3 - https://github.com/red/red/blob/master/BSD-3-License.txt"
	Purpose: {
		Runs the View/VID unit tests that target the headless `test` GUI
		backend (Config: [GUI-engine: 'test]). No display required, so these
		run on any platform / CI without a windowing system.

		The tests are *interpreted*: %view-headless-interpreter.red is compiled
		once per run (so it always picks up the current sources), then every
		test file is run through that binary. This avoids the cost of a full
		per-test compilation.

		Runs standalone (rebol -qws tests/run-view-headless-tests.r --batch)
		or inside a parent run: %run-all.r and %../run-all-tests.r `do` this
		script from their own quick-test session, and the groups below then
		join the parent's totals, log file and exit code. In a parent run the
		whole suite is reported as a single `view-headless` summary line
		(per-file details still go to the log file); standalone runs keep the
		per-file report.
	}
]

Ah, well that changes our approach now. We can use this first and then use the Windows debugging as final resort.

Cheers