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>
