Skip to content

Release: merge release into main - #132

Open
github-actions[bot] wants to merge 191 commits into
mainfrom
release
Open

github-actions[bot] wants to merge 191 commits into
mainfrom
release

Conversation

@github-actions

@github-actions github-actions Bot commented Oct 3, 2026 •

Copy link
Copy Markdown
Contributor

Automated sync of develop (860fbc8) into release. Markdown outside README.md and docs/ subfolders is removed by .github/scripts/release/sync-release.sh.

b-re-w added 24 commits October 3, 2026 18:57
ClassDecl (user-written __slots__ = annotated fields, trivial_init), Is
(identity, e.g. x is None via Const(None, OBJ)), IsExact (type(x) is C),
CheckExact (exact-type proof that deopts, pure-only), FieldGet (slot read
through the member descriptor captured at init; not an effect), FieldSet (an
effect), New (allocate-and-fill for a trivial __init__; not an effect), and
Param.cls/optional for exact-type entry guards. Runtime API for capturing
slots, reading/writing them and allocating fixed objects.

Refs #41
Both measure and interleaved write the HEAD commit of the checkout the
harness ran from (+dirty if tracked files differ), so a number can always be
traced to the code it measured.

Refs #41
Feat: TypedPython fixed-layout classes (N-11)
Docs: Writing rules (no em-dash, uv/ppp/tcl, tone)
@github-actions
github-actions Bot force-pushed the release branch 2 times, most recently from 0b1d1a4 to 81b5451 Compare October 3, 2026 14:26
A stdlib-only job (setup-python, no JDK or Gradle) on develop pushes. The
socket options differ per platform, and the port-takeover and restart tests
are what check them.
What PMP needs to build the fork's GraalVM native-image and Kotlin/Native
paths from its mavenLocal artefacts, whether the upcall table and
PYTHONHOME staging carry over, the first milestone (the notebook E2E in
a macOS native image, offscreen, so no window is needed), and the list
of requests for the fork.

Closes #242
Docs: Investigate the fork's desktop paths on macOS (#191)
The result table said the upcall path needs no reflection registration
while the build log showed 1,822 types registered and the base metadata
registers UpcallTarget. The generated function table needs none; the
upcall bootstrap finds its five FFM entry points by name on that one
class, which is registered by hand. The log line counts the whole
image, JDK and library metadata included.

Closes #244
Docs: Correct the native-image note on reflection registration
… Linux (#238)

Found by the first ubuntu and windows runs:

- push accepted "/abs/escape.py" on Windows, where os.path.isabs is False
  for a rooted path without a drive (Python 3.13+) and the join lands on the
  drive root. Paths now follow the protocol's own rule (relative,
  /-separated, no backslash, colon, empty, . or .. segment) and must resolve
  inside the overlay; the test covers the Windows forms on every OS.
- On Linux, close() left a listener that a thread was blocked accepting on
  in LISTEN, so a restarted agent got EADDRINUSE. stop() now shuts the
  listener down first and joins the accept and connection threads.
- The port-takeover test evaluated socket.SO_REUSEPORT where it does not
  exist (Windows).
Inside a GraalVM native image, the prefix beside the executable is the
fourth packaged source, and stageNativeImagePythonHome copies it there
when pythonBindings.nativeImageDirectory is set.
Library: a native image finds python-multiplatform-home beside its
executable; a JVM ignores a directory beside java and never asks for
the executable; no directory resolves to nothing; the environment
still wins. Plugin: stageNativeImagePythonHome copies the pruned prefix
into the native-image directory after stagePythonHome, and copies
nothing when the directory is unset.
PackagedPythonHome.resolve takes the executable lazily and, inside a
native image only (org.graalvm.nativeimage.imagecode = runtime), uses
<its directory>/python-multiplatform-home when it exists. The plugin's
stageNativeImagePythonHome Sync copies the same pruned prefix there.

Closes #246
Desktop: find and stage PYTHONHOME beside a native-image executable (#246)
The same 20 scenarios run in a GraalVM native image with JAVA_HOME and
PYTHONHOME removed and no libjvm, the prefix, wheel and app beside the
executable; the image takes ui, ui-text and foundation from the fork,
whose main-thread work can go to an AWT-free Dispatchers.Main.
NotebookE2eMain calls the 20 scenarios after their @BeforeTest, with no
JUnit, and prints a summary. notebookE2eJvm runs it on the JVM,
notebookE2eNativeAgent records Compose and skiko's configuration into
src/desktopTest/native-image, notebookE2eNativeCompile builds the image,
and notebookE2eNativeRun requires 20 of 20 with JAVA_HOME and PYTHONHOME
removed and no libjvm. The image's classpath takes the fork's ui,
ui-text and foundation (composeExtended.* in gradle.properties, one
place) and registers a single-thread Dispatchers.Main with no AWT.

Closes #249
Notebook E2E in a macOS GraalVM native image (#191 milestone 1, #249)
…ackages

The notebook-e2e fixture reads the fork's modules from a Maven URL as
well as mavenLocal (composeExtended.repository, credentials from
GITHUB_ACTOR/GITHUB_TOKEN). desktop.yml gets a notebook-e2e-native-image
job, skipped until the repository variable COMPOSE_EXTENDED_VERSION
names a published version. It uses the secret GH_PACKAGES_TOKEN when it
exists and GITHUB_TOKEN otherwise, checks one POM first and fails
naming the secret when the packages cannot be read, then records the
configuration, builds the image and runs it.

Refs #251
CI: Prepare the native-image notebook E2E job for the fork's GitHub Packages (#251)
Feat: Strings, subscripts, iteration and f-strings compile through the interpreter's C API; cost rule (#150)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant