pure/prototypes/connections, branch masterVerified execution runtime unifying state, persistence, and replication.
http://git.yeowoo.org/pure/atom?h=master2026-10-01T15:40:11ZLook at a wake write's result in the prototype, as fortified builds ask2026-10-01T15:40:11Zeunhhunecpition205@gmail.com2026-10-01T15:40:11Zurn:sha1:1fdf72444cdcf5041022c75ed616a1dcd458175b
Ubuntu's gcc defines _FORTIFY_SOURCE, which marks write's result as one
to use, and a (void) cast does not quiet it: the prototype did not
build there (research 029). Debian's does not define it; the Pi gives
the same error with -D_FORTIFY_SOURCE=3.
Lay Pure out as a core with the parts selected around it2026-09-27T12:14:38Zeunhhunecpition205@gmail.com2026-09-27T12:14:38Zurn:sha1:37d3a1e152707d2da587440c4cea8601b9ef0fd2
The app model, the tree store and the HTTP host lived in
prototypes/connections among the earlier document runtime, the store was
known only by its format's name, and Vega compiled six Pure sources by path.
Now, as the README's principle has it:
core/ runtime, flow and the app model (module*.c), with what the core
asks of storage (state.h, store.h)
store/ the tree store (PURETRE3, PUREREC1)
serve/ pure-serve: HTTP host, outbound delivery, JSON in place
cli/ pure-run, pure-edit-module
A top-level make builds libpure.a (app model and store, for hosts to link)
and the hosts; make check runs the store's and the app model's tests. The
earlier runtime still builds from prototypes/connections against core/ and
store/ (check, check-tree and check-core pass). Design 009 records the rule:
parts by role behind libraries; git repositories split by coupling, so the
store stays here while its contract moves with the core, and Vega stays apart.
Look for new sends newest first, only as far back as they go2026-09-27T07:24:08Zeunhhunecpition205@gmail.com2026-09-27T07:24:08Zurn:sha1:5372d03b5968796515966e2cfc89628d6448f0c1
After each save the owner walked the whole outbox to find the sends
not yet queued, so a receiver long down made every save walk the
backlog. pure_app_outbox_newest visits saved sends newest first, and
the owner stops once every wired output reaches the number it queued
last, then queues what it found in order.
Make an API's answers the app's events (--reply OUTPUT=INPUT)2026-09-27T07:22:21Zeunhhunecpition205@gmail.com2026-09-27T07:22:21Zurn:sha1:ddff7e15d1d0e90a5f5a52fcc93828c8ef0bbd5c
The final answer to each send of a wired output (a 2xx, or a 4xx but
408 and 429) becomes a message event of the given input: fields from
the answer's JSON object by name, other members skipped; a field the
answer lacks from the send's field of that name and type, so the
request's own id is there; a u32 http_status field is the status. It is
applied with the send's number from the wire's source, before the send
is trimmed and in the same save, so an answer that comes again after a
restart (the API repeating itself for the Idempotency-Key) applies once.
Sends that wait for answers go one per request; answers are saved with
the next round, or at once when none waits.
A server that writes an answer in pieces holds the second until the
first is acknowledged, and a delayed acknowledgement stalled every
answer 40 ms: the client now acknowledges at once (TCP_QUICKACK) after
each read. Against a payments API that answers 200 or 402, with the
sender killed (-9) midway, paid and declined orders matched the API's
answers one to one.
Read JSON messages in message-json.c, for requests and answers alike2026-09-27T07:15:05Zeunhhunecpition205@gmail.com2026-09-27T07:15:05Zurn:sha1:25397ebb79fb554f4fa795603ee84d2aede83594
The in-place JSON reader of pure-serve's request bodies moves into its
own file with a small interface (pure_json_message, pure_json_fixed,
pure_json_space), so the delivery client can read an API's answers
with it. It gains a lenient mode for answers: a member that names no
field is skipped, value and all. Requests read as before.
Deliver to https receivers, verifying their certificates (083)2026-09-27T07:12:23Zeunhhunecpition205@gmail.com2026-09-27T07:12:23Zurn:sha1:24a07a0bbfe98924b339f4ffeeaef093e74f73fb
A wire to an https:// URL speaks TLS 1.2 or later through OpenSSL: the
receiver's certificate must chain to the system's CAs (or to the file
--send-ca names) and name its host (SNI and SSL_set1_host, or the IP
address). An untrusted receiver gets nothing: the send stays in the
outbox, the wire logs it and tries again every 10 s. pure-serve now
links libssl and libcrypto.
Deliver an app's saved sends over HTTP, in order and in batches (083)2026-09-27T07:09:40Zeunhhunecpition205@gmail.com2026-09-27T07:09:40Zurn:sha1:5d3a7cefa27f3fe20a9c6991fb044815b38aac01
pure-serve --send OUTPUT=http://host:port/path wires an output: after
every save the owner queues the new sends as JSON (fields and groups)
and a thread per output posts them in order with X-Pure-Source,
X-Pure-Sequence and Idempotency-Key. A 2xx, or a Pure receiver's
refusal, delivers; the owner then trims. 408, 429, 5xx and no answer
are sent again after a pause growing to 10 s, other answers every 10 s:
nothing is dropped. A Pure receiver applies a delivered message with
pure_app_deliver (now taking placed fields) and advertises
X-Pure-Batch: 256; the sender then posts up to that many numbers in a
row as one JSON array (X-Pure-Count), applied in order in one burst
with one save.
Delivery kept up with orders once batched (391 deliveries/s one at a
time; a backlog of 20,000 went at 60k/s). With four clients ordering,
killing the receiver and then the sender (-9) left the receiver's count
and total equal to what the sender saved, five times and under ASan.
Send messages as part of events and apply delivered ones once (078)2026-09-27T06:54:35Zeunhhunecpition205@gmail.com2026-09-27T06:54:35Zurn:sha1:01c87d2c204723905457f225b3113dac82eb0ced
An output (input kind 5) is a message the app sends; SEND (72) takes
an output's field values in order in a handler, lays them out as a
message's payload and keeps it, numbered per output from 1, with the
event's changes: a failed event sent nothing, and a failed save takes
back every send since the last save with its numbers. A host sees only
saved sends (pure_app_outbox) and trims what its receiver has saved
(pure_app_trim, gone with the next save). pure_app_deliver applies a
message from a named source once: a number heard before succeeds
without applying, a refused message counts as heard, a failed save
forgets what it heard.
Sends, numbers and heard numbers are the app's links state, stored
whole in one runtime document (PLK1) with the states, in the same
commit. Outputs follow their names across module changes; a module
that drops or retypes an output with sends left is refused, and a
dropped output's number is kept for when it returns. Killing the
process at every commit stage leaves an event and its send, or a
delivery and its effect, together or neither. pure-serve answers a
post to an output or a timer with 404 no_input.
Choose the connection threads with --threads auto2026-09-27T06:37:44Zeunhhunecpition205@gmail.com2026-09-27T06:37:44Zurn:sha1:78e9ba927d0c6f15e0388c8a5e056d1e82e21e88
One connection thread for each CPU the process may run on (its
affinity, or the online CPUs), less the one the owner of an app with
states takes: three CPUs give two connection threads and the owner.
The default stays one thread.
Gather after a save until a just-answered client has come back2026-09-27T06:37:38Zeunhhunecpition205@gmail.com2026-09-27T06:37:38Zurn:sha1:9b5f7629fdf87bcbaade4b9baa349cddc631c63f
After a round that saved, the owner waited for 100 us without a new
request (1 ms at most) before the next round. Requests that queued up
during the save made that quiet start at once, so the clients just
answered missed the next round; the clients then settled into two
halves taking turns, each save carrying half of them. It showed with
two connection threads: 34 events a round and 15.8-16.0k posts/s with
64 connections, against about 61 and 22-24k/s with one or three. The
quiet now counts only once a request has come after the answers were
handed back: two threads carry 61.6 events a round, 22.9-23.9k/s.