Drop-in copy of labdb's API surface from
fivenode/labdb/api/*.prg into app/api/. Single fnode invocation builds
the whole thing (bridge_server + bridge/ + 22 api/*.prg) into one
24 MB Go binary — no Node.js, no FFI, no Apache.
End-to-end smoke test (server.js not running, ctx empty so defaults
fall back) hitting six endpoints all return well-formed JSON via the
bridge layer + path -> Main dispatcher:
GET /api/hello.prg -> {"msg":"hello from PRG","ok":true}
GET /api/admin-stats.prg -> {"active_sessions":0,...}
GET /api/admin-me.prg -> {"ok":true,"user":{...}}
GET /api/sessions-list.prg -> {"sessions":[],"total":0}
GET /api/records-list.prg -> {"records":[],"sessionId":"",...}
POST /api/devices-register -> {"deviceId":"","status":"pending",...}
One small upstream patch was needed: seven .prg files each define
their own STATIC FUNCTION fn_HGet, but Five doesn't yet honour
file-local STATIC scoping for top-level functions — all definitions
land in the same symbol table and collide. Renamed each duplicate to
<file>_fn_hget so they peacefully coexist; the call sites still
reference fn_HGet and Five resolves them against _helpers.prg's
public version (signature-compatible). TODO: revert once Five gains
file-local STATIC FUNCTION scoping.
What's deferred to 1a.4-4: ctx data injection (so endpoints return
real labdb data), static asset embedding (labdb/public/), and a live
LABDB_DSN round-trip to confirm pgrtl in the request path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Lets app/api/foo.prg keep its idiomatic `FUNCTION Main()` shape while
multiple such files compile into one binary. fnode auto-renames each
library file's Main into a unique symbol derived from the basename:
app/api/hello.prg -> HELLO__MAIN
app/api/admin-stats.prg -> ADMIN_STATS__MAIN (hyphen -> underscore)
Three moving parts:
cmd/fnode/main.go
parseOne for every PRG, then rename Main on every file except
the first (the entry). crossFile map updated so the analyzer
treats the renamed symbol as declared.
hbrtl_ext/dispatch/dispatch.go
New HB_FUNC FNODE_CALL(cFuncName) that does VM.FindSymbol +
PushSymbol/Function dance and discards the return value. Same
pattern pgserver's callPRG helper uses internally.
app/bridge_server.prg
BridgeDispatch now derives the symbol name from hReq["path"]
( /api/foo[.prg] -> FOO__MAIN ), invokes FNODE_CALL, and
maps "not found" errors to HTTP 404 (other errors -> 500).
Hardcoded /api/hello and /api/echo handlers replaced by the
path-driven model.
Verified end-to-end with app/api/hello.prg and app/api/admin-stats.prg:
GET /api/hello.prg -> 200 + JSON from HELLO__MAIN
GET /api/hello -> 200 (extension optional)
GET /api/admin-stats.prg?from=2026 -> 200 from ADMIN_STATS__MAIN
with query string echoed
GET /api/nope -> 404 "function not found"
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PG_OPEN(cDsn) -> integer handle, -1 on failure
PG_CLOSE(nH) -> NIL
PG_QUERY(nH, cSQL [, aArgs]) -> array of { col => val } hashes
PG_EXEC (nH, cSQL [, aArgs]) -> rows affected, -1 on error
PG_LAST_ERROR(nH) -> last error string
Backed by github.com/jackc/pgx/v5/pgxpool, which is already in Five's
indirect dep tree (pgserver uses pgproto3 from the same repo). Pool
limits: MaxConns 8, MinConns 1, 5-min idle. Query timeout is capped at
30s so a runaway query can't pin a goroutine forever.
aArgs uses standard Postgres $1/$2/... placeholders — pgx parameter
binding prevents SQL injection. Never concatenate user input into cSQL.
Smoke-tested with app/pg_test.prg: bad DSN returns -1 cleanly (no
panic), the error path prints the expected fallback message, and the
real round-trip path is wired so setting LABDB_DSN to a live database
exercises SELECT + parameter binding + multi-row return without any
further code change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pulls bridge_context.prg, bridge_request.prg, bridge_session.prg, and
bridge_cookie.prg from upstream fivenode into app/bridge/ so the
mod_harbour AP_* surface (AP_METHOD, AP_BODY, AP_ARGS, AP_USERIP,
AP_RPUTS, AP_JSONRESPONSE, AP_SETCONTENTTYPE, ctx_get, ctx_set, ...)
runs unchanged on top of fivenode_go's Go RTL.
bridge_main.prg deliberately omitted — its REQUEST sweep pulls in
TDrMySQL / hbct / hbcurl symbols fivenode_go neither has nor needs.
fivenode_go runs ahead-of-time with the Five compiler, so the
REQUEST trick that keeps fnb-runtime symbols alive isn't required.
One upstream patch was unavoidable: AP_RPUTS / AP_ECHO were variadic
(`( ... )`) and used PValue() to walk caller args. Five's PValue
returns the caller's LOCAL slot (not the actual variadic args, which
aren't copied into locals when declared params is 0), so the body
came back as "1" instead of the JSON payload. Collapsed both to a
single-argument form; every call site in fivenode_go already passes
exactly one value. Patched-out spots are marked with a TODO so we
can revert once Five gains real variadic PValue support.
app/bridge_server.prg ties it all together: starts httpserver on
:8090 with BRIDGEDISPATCH as the handler, hand-translates the Go
request hash into the ctx fields the AP_* layer reads, dispatches by
URL path (hard-coded /api/hello and /api/echo for now — file-name
dispatch lands in 1a.4), and assembles the response from the buffered
AP_* output + ctx_get("status") + ctx_get("headers_out").
Verified end-to-end:
GET /api/hello -> 200 JSON, method/ip echoed
POST /api/echo?lang=ko (16-byte body) -> 200 JSON, body_parsed,
query, user-agent
GET /api/nope -> 404 JSON
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Seven HB_FUNCs that fivenode's bridge_*.prg layer relies on:
_CTX_SET_JSON / _CTX_GET_JSON — per-request context payload
_OUT_APPEND / _OUT_GET / _OUT_CLEAR — response body buffer
_BRIDGE_SET_RESULT / _BRIDGE_GET_RESULT — fast-path response
Crucially per-thread, not process-global like the original C
implementation. fivenode runs single-threaded under N-API so a static
buffer per process was fine; fivenode_go runs one *hbrt.Thread per
HTTP request goroutine, so the state is keyed by *hbrt.Thread in a
sync.Map. The HTTP dispatcher will call CleanupThread once per
request to keep the map bounded (sub-phase 1a.3-3).
Also exposes Go-side helpers (OutputBytes, Result, SetContextJSON,
CleanupThread) so the dispatcher can seed the context and harvest
the response without bouncing back through PRG.
Verified with app/capi_test.prg: all seven functions behave as
expected; combined with the Five hb_jsonDecode byref fix, ctx_get()
now correctly returns hash values rather than the fallback default.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds hbrtl_ext/httpserver — a Five RTL extension that exposes a
single-process HTTP server controlled entirely from PRG.
Wire contract:
HTTP_SERVER_START(cAddr, cHandlerFunc) → blocking; returns NIL or cErr
HTTP_SERVER_STOP() → graceful shutdown
PRG handler signature:
FUNCTION OnRequest( hReq ) -> hResp
hReq: method, path, query, headers (hash), body, remote_addr
hResp: status (default 200), headers (hash), body
Each request runs on its own hbrt.Thread via vm.NewThread(), the same
pattern pgserver uses for connection isolation. Handler panics are
caught and turned into a 500.
The package is wired into fnode's defaultRTL list so any build that
doesn't override --rtl picks it up automatically.
Verified end-to-end with app/echo_server.prg: GET/POST against :8089
return JSON envelopes with the correct method, path, query, body
length, remote_addr, and roundtripped user-agent header.
The mod_harbour-compatible AP_* surface (AP_METHOD, AP_RPUTS,
AP_JSONRESPONSE, etc.) will sit on top of this dispatcher in
sub-phase 1a.3 as PRG, not Go.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* cmd/fnode — build/run CLI that drives Five's compiler packages
(pp, parser, analyzer, gengo) and stitches generated prg_*.go
together with fivenode_go's own hbrtl_ext/* packages in a temp
module. Result is one self-contained Go binary; no FFI, no Node.
* hbrtl_ext/hello — bootstrap RTL extension proving the
blank-import-init() registration path works end-to-end. Exposes
FNODE_HELLO() to PRG.
* app/hello.prg — minimum end-to-end test: calls Date() (Five RTL)
and FNODE_HELLO() (fivenode_go RTL) from the same binary.
Verified: ./fnode build app/hello.prg -o hello_app → 17 MB single
binary that prints both lines. The same pattern will host the
HTTP server, bridge capi helpers, and PostgreSQL client coming
in 1a.2b–1a.4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
