pure/core/module.c, branch masterVerified execution runtime unifying state, persistence, and replication.
http://git.yeowoo.org/pure/atom?h=master2026-10-19T08:58:47ZThe modules an app ran are freed (research 115's next step): every app's module a Loaded with holds (each snapshot of it, each request read with it); one replaced is retired and freed on the apps thread once no app runs it, every connection thread has begun a pass since (woken for it), and nothing holds it; who keeps a module to ask later whether it is the same asks its serial (core: PureModule.serial, a reader's module_serial, pure_snapshot_module, pure_snapshot_release says it freed; serve: routes, groups, links, bindings, queries, the published snapshot), as an address may come back; a link binds under its receiver's lock, a link naming an input under binding_lock; 030's memory.py: 4,000 changes 0 bytes a change (was 19,284), 4,100 freed; stress.py: readers, view workers, push streams and a body across changes, 586 of 600 loads at a freed module's address, every answer right, ASan 1,000 changes clean; a push group that looked while its app resumed missed the new snapshot (published before the app took requests) and waited for its next save: woken again once it takes them (server_view_workers had failed once under load)2026-10-19T08:58:47Zeunhhunecpition205@gmail.com2026-10-19T08:58:47Zurn:sha1:b8e6a2e5b8fc64ec47adfbe583b8a27200cc5a2eA list value of numbers copied whole (140's LIST_VALUE review, no new opcode, no change to what a module means): nest() made every list value item by item into a new tree (64 ns an item, 250 ns a copy fixed); an event's list in FLAT arrays, not keyed, its cells numbers, bools and integers, is now copied column by column (pure_list_copied: 600 items 38,268 to 985 ns, 60 items 3,926 to 324); UAX #14's nine lists a line 6,917 to 6,445 ns a code point (-6.8%, the same instructions); JSON tree's, HTTP's and inflate's (trees: texts or lists in their records, or few) as they were; copied_lists in test-module (random lists against item by item, then each changed apart; trees, keys and texts not copied so)2026-10-19T06:59:15Zeunhhunecpition205@gmail.com2026-10-19T06:59:15Zurn:sha1:1c1133ce8258dad367aad3b7c8eee0083aecf772CONCAT with an empty side gives the other as it is, uncopied (values do not change), so a bytes state joined while empty (HTTP's pending + packet.data) no longer copies the packet: HTTP a packet at a time 288 to 270 ns a byte at the same instructions, as the old app (270.0); counts: b48 against b47 knapsack without batches -0.42%, join -0.16%, BFS with batches -0.12%, the rest within 0.03%; the bank's queries (s47 and s48 in turns, six each) in_credit -0.34%, field -0.34%, found -0.22%, per_branch -0.20%, large -0.18%, ranks -0.13%, none the same, the seven answers the same bytes2026-10-19T04:16:07Zeunhhunecpition205@gmail.com2026-10-19T04:16:07Zurn:sha1:5df2e814937e32a54c77c1ded66b5124e6017cfc028's bytes alone as a state, made: module state type 6 read as a text state flagged PURE_TEXT_BYTES in state_flags (so serve's same_states compares it for queries and replaces), its TEXT_LOAD giving bytes and its TEXT_SET taking them, a cursor's ops on it refused (anchor in bytes) and an anchor in it refused at load; one store file text-NAME, the values record marking each bytes state (kind 7, its name, 8 zero bytes), a text state's file that is no UTF-8 its initial value when marked and store_error when not (as before); a replace carrying bytes to a text only when its draft is UTF-8, else opening the store's draft anew; pure-run shows a bytes state's hex; unit test bytes_states (seven starts from a store: 0xff and 0x00 kept, bytes to text to bytes to text with no UTF-8 and with it; three replaces; four refused); counts: b47 against b46 BFS with batches +0.12%, the rest within 0.001%; the bank's queries (s45 and s47 in turns, six each, bytes compared among them) in_credit -0.31%, per_branch -0.18%, ranks -0.11%, the rest within 0.01%, the seven answers the same bytes; Pure, Vega and aup checks green; 008, 0282026-10-19T03:42:05Zeunhhunecpition205@gmail.com2026-10-19T03:42:05Zurn:sha1:6596533b0d5fe10f3cab028d7fa69a40e5416ecdBytes compared (140's decision point: DNS and HTTP both met it): TEXT_COMPARE's argument takes PURE_COMPARE_BYTES (bit 8) beside its relation, its two then bytes (UTF-8 asked of neither), as CONCAT's argument says bytes; verified as A_ORDER (a relation, and the bit), the executor relating by the argument's relation alone; the JIT, the tier and the batch executor leave TEXT_COMPARE to the executor as before; unit test bytes_compared: eight relations of a constant's bytes, none, 0xff and 'A' (0xff after 'A', a longer after its first byte), four refused (the bit on texts, no bit on bytes, a text with bytes, a relation past NE); counts: b46 against b45 the same on all five works, with and without batches; 0082026-10-19T02:56:43Zeunhhunecpition205@gmail.com2026-10-19T02:56:43Zurn:sha1:1034ff06b1a5742f332365d7069f41db78642c87027's 5c: money as i64 minor units shown by .Nd: NUM_TEXT's decimal form takes digits (bits 20-24 as FIXED's), an integer's last N digits written after a point (1234 at two is 12.34, -5 -0.05, 0 0.00; width and zeros after the sign), verification allowing digits on FIXED and DECIMAL alone; unit test: ten rows of formats_and_held (-2^63 at two, 25 digits, a number's whole 1234, its 12.5 a limit); TPC-C's money i64 cents and its rates ten-thousandths (tables, messages, load, the transactions), SQLite's INTEGER columns and int64 bindings alike, the comparison now exact (no 1e-9 tolerance): after 20,000 transactions every row of every table the same (grouped SQLite too) and 3.3.2 holding on both; counts: b45 against b44 BFS without batches +0.09%, the rest within 0.001%; the bank's queries (s44 and s45 in turns, six each) in_credit -0.59%, per_branch -0.34%, ranks -0.20%, the rest within 0.01%, the seven answers the same bytes; 008 (NUM_TEXT's digits, a message row's i64 cells), 027 and 0922026-10-19T00:53:40Zeunhhunecpition205@gmail.com2026-10-19T00:53:40Zurn:sha1:defb2cf06a9b5db9429ca368d8c2af127a5c9c3d027's 5b: an i64 sum exact: its items gathered in a 128-bit integer and only the result checked against the range (overflow past it), so a sum past the range midway and back in it at the end is the answer and an i64 sum's order is none of its business; the batch executor's folds are numbers' lanes alone, summed in the items' order, as before; 008's FOLD says so; counts: b44 against b43 within 0.04% (BFS without batches -0.03%); the bank's queries (s43 and s44 in turns, six each) per_branch -1.32% (all six below s43's lowest: a larger Fold lays the number sum's loop otherwise), in_credit -0.72%, ranks -0.26%, the rest within 0.01%, the seven queries' answers the same bytes on both; 008 and 0272026-10-19T00:31:39Zeunhhunecpition205@gmail.com2026-10-19T00:31:39Zurn:sha1:809a83a5764ec0f0c84b96c43a20cfb906eee031027's stage 5 designed and 5a made: two numbers (number, binary64, the default of literals and of counts, positions, lengths and u32 fields, whole to 2^53 exactly; i64 the exact integers past it, bits and money, never mixed, moved by number() and i64() when exact), / a number's division, // the floored quotient, i64 folds exact (only the result in range, so in any order), number folds in order unless the batch executor's 2^53 test says any order is exact, money as i64 minor units shown by .Nd, a replace carrying number, bool and i64 when exact; 5a: opcode FLOORDIV (95, 96 now): a number's floored quotient as Python's float //, exactly (a less its floored remainder, divided, to the nearest whole; a zero signed as a / b; by zero divide), a new opcode so the JIT, the tier and the batch executor leave it to the executor; unit test floor_division (7 // 2, -7 // 2, 7 // -2, 1 // 0.1 = 9, 0 // -3 = -0, 1e300 // 7, by zero); counts: b43 against b42 within 0.001% but BFS without batches -0.09%; the bank's queries (s42 and s43 in turns, six each) -0.20% to 0.00%; 008 and 0272026-10-19T00:13:07Zeunhhunecpition205@gmail.com2026-10-19T00:13:07Zurn:sha1:b79f627af433a63f8f42869b124f5ef344a49352027's 4f-4: loops nested to any depth: the load counts a module's deepest nesting (nesting), a run keeping PURE_MODULE_NESTING (8) on its stack as before and a module nesting deeper running in the executor that calls, its loops in its app's room (PureApp.deep, grown to it), so run()'s hot path is as it was; the JIT compiles modules nesting 8 at most; a function's nesting counted without a cap (u32), its frame sized to it; unit test: 40 loops nested, run to their end (2^20 rounds) and stopped by the work budget (2^40), 8 still on the stack; counts: b42 against b41 with batches BFS -0.12%, without BFS +0.09%, the rest within 0.001%; the bank's queries (s41 and s42 in turns, six each) in_credit +1.04%, per_branch +0.60%, ranks +0.36%, the rest within 0.01% (their spread: the bank has no functions, so none runs the changed executor, and s42's in_credit is within s41's own earlier six); 008 and 0272026-10-18T23:40:55Zeunhhunecpition205@gmail.com2026-10-18T23:40:55Zurn:sha1:e9f53dc8a56ddca0855213da4355f39a69306c07027's 4f-3b: no fixed count of records or of their fields in all: the header's u16s alone (16 and 128 before); a stored list's record graph (PureLayout) holds a few records itself and more on the heap, 256 at most (an image numbers them in a byte), an image or a checkpoint not written then without room for it; a record's 16 fields kept, the list engine's width (a leaf's columns, a run's columns and narrow cells, the arrays' and packs' columns), to be widened with the lists' shapes sized to their fields; unit tests: 20 records of 10 fields (200 in all), an item of the last appended; a stored list whose six records each hold a list of the next saved and read back after a restart (its graph on the heap); counts: b41 against b40 with batches BFS +0.12%, without BFS -0.09%, the rest within 0.001%; the bank's queries (s40 and s41 in turns, six each) within 0.09% (the first three's in_credit +1.16% its spread: 2.75% between runs of one build); 008 and 0272026-10-18T23:16:56Zeunhhunecpition205@gmail.com2026-10-18T23:16:56Zurn:sha1:3cc6bc3d8a1d8827519decbf7e084e89110c93f9