ludic/changes
Orkuncakilkaya c10abd9f9f feat(jobs): real OS threads - Job.parallel_for, fn name, thread-safe Sync
- `fn name` names a top-level function as a value (E_FNREF, lowers to @fn_<name>); the worker
  entry point for Job.parallel_for, which checks it takes (int, pointer-like) and returns void.
- runtime/native/threads.ll (pthreads) and threads_win.ll (Win32 SRWLOCK/CONDITION_VARIABLE): a
  pool of one worker per core but one, parked between batches; every thread claims chunks by
  compare-and-swap. Linked only into programs that use Job/Promise/Sync, by `ludicc -o`,
  `ludic build` and the test suite's build helper.
- Sync.* is real: native mutexes, atomics as cmpxchg retry loops (neither clang takes atomicrw,
  the PC's rejects seq_consistent), mutex-guarded channels, Sync.cpu_count from the OS.
- spawn/despawn on a pool thread stop the program with a located panic.
- examples/library/threads.ludic and its test; docs for fn, Job.parallel_for, Job.is_worker.
- Reseeded (bootstrap-cfree: out.ll == seed.ll). 141/141 on macOS; jobs, threads and the guard
  pass on Windows from the reseeded Windows seed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 13:52:22 +03:00
..
os-threads.md feat(jobs): real OS threads - Job.parallel_for, fn name, thread-safe Sync 2026-09-15 13:52:22 +03:00
README.md refactor(cli)!: split the contributor tool out of the ludic CLI 2026-09-05 23:15:12 +03:00

Changesets

A changeset is one small Markdown file describing a single user-facing change, dropped in this directory. ludic-dev release consumes every changeset here into a new CHANGELOG.md section, bumps VERSION, and deletes the consumed files.

Format

bump: minor
type: feat
One or more lines describing the change, in the past-agnostic imperative used in
the changelog. Markdown is fine.
  • bump: — major, minor, or patch (SemVer). The release version is bumped by the highest level among the pending changesets (unless ludic-dev release <level> overrides it).
  • type: — the Conventional Commit type (feat, fix, perf, docs, …). It decides which group the change lands in: feat → Features, fix → Fixes, perf → Performance, and so on, in that order. A type with no known heading gets one named after itself.

Writing the body

The body is markdown and reaches the changelog as markdown: it becomes one list item, with continuation lines indented to stay inside it. Nested bullets, blank lines between paragraphs and inline code all survive.

bump: minor
type: feat
**Tiled map support** — load and draw Tiled maps.

- **TMX/TSX** — the XML formats, decoded to the same intermediate as JSON.
- **Collision** — the `collision` layer projects onto the engine tilemap.

Lead with the thing that changed, not with the mechanism. A reader scanning the release should be able to stop after your first clause.

Adding one

Create a file with a short, unique name, e.g. changes/regex-namespace.md. Any filename works except this README.md, which the release step always skips.

Preview how the next release will read before cutting it — this writes nothing:

ludic-dev release --dry-run