The nREPL server bound its loopback socket through libc process symbols,
which don't carry the socket entry points on Windows — they live in
ws2_32.dll and aren't in joltc.exe's export table, so --nrepl-server died
with "no entry for socket". Load ws2_32 before the foreign bindings there,
call WSAStartup once, and use Winsock's closesocket and int-typed
recv/send. Also fix SOL_SOCKET/SO_REUSEADDR, which the old macos-only
check got wrong on Windows.
Bake a version string into the self-contained binary at build time (from
$JOLT_VERSION, else git describe) and expose it via jolt.host/jolt-version:
--version / -V print it, and it shows in --help, the repl banner, and the
nREPL startup line. Dev runs off bin/joltc read it from git describe.
Add -e to the help output.
The built joltc.exe exited 3 (msvcrt abort) with no output on the -e smoke.
Link -static so the exe carries no libwinpthread/libgcc/lz4 DLL deps (needed
for distribution regardless), and add an ntldd + direct-run debug step.
zuo's install target shells the unix installsh through cmd and dies. The
build tree already has everything: scheme.exe (boot files beside it, where
the Windows kernel looks), and scheme.h/libkernel.a/boots into a csv dir
that JOLT_CHEZ_CSV points the jolt build at.
The Windows PATH step embedded real newlines in its printf strings, which
broke the block scalar and invalidated the whole workflow file (the push
run failed at parse; workflow_dispatch refused). The wrappers are plain
echo pairs now.
Adds a windows-latest job to the release matrix: MSYS2/MinGW-w64 toolchain,
Chez 10.4.1 built from source (ta6nt), the same build-joltc flow, packaged
as a zip of joltc.exe. The whole job runs in the msys2 shell so cc/xxd/paths
behave; the produced binary is a plain Windows executable.
Platform seams: bld-nt? with the winsock/COM/registry link set, no -rdynamic
under MinGW, GetModuleFileName as the launcher's self-path on _WIN32, and
built binaries (joltc itself and jolt-build outputs) normalize to a .exe
suffix. workflow_dispatch added so the matrix can be dry-run without tagging;
the release upload step only fires on tags.
For #205.
byte/short/int/long/char silently wrapped or passed out-of-range values
through; the JVM range-checks (RT.byteCast family). One checked-cast
helper now carries the ranges: a double range-checks ITSELF before
truncating ((byte 1.1) is 1, (byte 127.000001) throws), NaN casts to 0,
ratios and bigdecs truncate, a non-number is CCE, and the throw carries
the JVM message. float range-checks against Float/MAX_VALUE. The
unchecked-* casts now genuinely wrap and sign-fold ((unchecked-byte 200)
is -56 — the old bit-and lost the sign) with doubles saturating like
Java's conversions; unchecked-long/int are host natives. double/float of
a bigdec convert instead of crashing. The no-single-float residue stays
accepted (SPEC.md).
Also fixes#290: a binary built by the SELF-CONTAINED joltc died with
'variable var-deref is not bound' when a namespace loaded at runtime.
The in-process build compiled flat.ss against a clean copy-environment,
which orphans every top-level define in locations the binary's runtime
eval can't see. It now compiles against the default interaction
environment (defines land in the real symbol cells, same as the legacy
fresh-Chez path) and a generated prologue pre-binds each kernel name the
runtime redefines to its kernel value, so the earliest boot reads match
the legacy path's primitive references. requiring-resolve is implemented
(the issue's dynamic-require pattern), and the release workflow smokes a
runtime require in a built binary.
Cast namespaces byte/short/int/long/char now fully clean; cts baseline
5805 -> 5857 pass, 67 baselined namespaces. 7 JVM-certified corpus rows.
The macos-13 Intel runner no longer gets allocated, so the x86_64-macos release
job queues forever. Ship prebuilt binaries for x86_64-linux and aarch64-macos;
Intel Macs build from source. The install script now says so instead of 404ing
on a missing asset.
`joltc build` inlines the runtime (host/chez/rt.ss and everything it loads, the
seed, compile-eval, loader, ffi, the vendored irregex) into each app binary by
reading those files off disk. That works from a jolt checkout but not from the
installed self-contained binary, which has no source tree:
joltc build -m app.core
=> Exception in call-with-input-file: failed for host/chez/rt.ss: no such file
build-joltc now bakes the exact transitive closure of files the build inlines
into the binary as embedded resources (keyed by the path the `(load "…")` forms
use), and build.ss/dce.ss read runtime source through bld-source-string, which
takes the embedded copy when present and falls back to disk otherwise. So the
same joltc builds apps both from a checkout and standalone.
The release workflow now smoke-tests a self-contained build (compile a tiny app
from an isolated dir, run it) — this is exactly what shipped broken, so it now
gates the release. buildsmoke/shakesmoke/staticnativesmoke unchanged and green.
Build tooling only — no re-mint, no runtime change.
On a pushed v* tag, build the self-contained joltc (make joltc-release) for
x86_64-linux, x86_64-macos, and aarch64-macos, package each as a tar.gz plus a
SHA256, and attach them to the GitHub Release. Linux builds Chez from source like
tests.yml (the apt package lacks the kernel dev files build-joltc cc-links
against); macOS uses Homebrew chezscheme, which ships chez and the csv kernel
files. No notarization, matching dirge — macOS tarball users de-quarantine once
or install via a Homebrew tap.
The Homebrew tap update job is a separate follow-on; this covers building and
publishing the release assets.
