descript: roundtrip descript/scheduler

[qaco]

Motivation

We know how to build a scheduler from descript, but we also want to build descript from a scheduler.

Description

1. The flat representation is replaced by a tree structure (where children are created by splits).
2. The parsing, the data structure and the interpretation are splitted in different files.
3. The data structure (LoopNestNode) now embeds a pretty printer.
4. A Scheduler can now build a LoopNest.
5. The declarative DSL now exposes buffer_at
6. The declarative DSL now exposes pack_at

[guillon]

Is there a possibility to make the LoopNest/LoopChild being even further redesigned into a single typical LoopNestTree structure, for instance with child/parent relationship?

[qaco]

Is there a possibility to make the LoopNest/LoopChild being even further redesigned into a single typical LoopNestTree structure, for instance with child/parent relationship?

Yeay done. With a generic tree structure

[guillon]

@qaco you seem to have a merge issue of some kind, there are commits from the main branch in your review:

• [ci: add macos-15 build and tests]
• [readme: simpler installation instructions]

[guillon]

[Father] Focused review on first 8 commits only (excluding the last 2). I found two actionable issues.

1. Potential nondeterminism in dimension ordering

• In LoopInfo.build_from_node, dimensions are accumulated in a set and returned as list(dims).
• This can make downstream behavior/order-dependent checks non-deterministic across runs/Python versions.
• Suggest preserving stable order (e.g., seed from abstract_dims order and append discovered dims deterministically).

2. Split end computation relies on dict insertion order

• In split metadata reconstruction, end bounds are inferred from list(axis_splits.values()).
• If split map construction order changes upstream, computed ranges can silently change.
• Suggest sorting by split start explicitly before deriving (start,end) pairs.

Generated by Father the Guils' AI assistant, close comment if not relevant and blame me!

[qaco]

[Father] Focused review on first 8 commits only (excluding the last 2). I found two actionable issues.

1. Potential nondeterminism in dimension ordering


* In `LoopInfo.build_from_node`, dimensions are accumulated in a `set` and returned as `list(dims)`.

* This can make downstream behavior/order-dependent checks non-deterministic across runs/Python versions.

* Suggest preserving stable order (e.g., seed from `abstract_dims` order and append discovered dims deterministically).


2. Split end computation relies on dict insertion order


* In split metadata reconstruction, end bounds are inferred from `list(axis_splits.values())`.

* If split map construction order changes upstream, computed ranges can silently change.

* Suggest sorting by split start explicitly before deriving `(start,end)` pairs.

Generated by Father the Guils' AI assistant, close comment if not relevant and blame me!

Haha you're a gangsta ! Did you copy-paste the diff in chatgpt/whatever, or use built-in Github tools?

Thanks for the review anywy, I fix the issues and come back to you!

[guillon]

[Father] Focused review on first 8 commits only (excluding the last 2). I found two actionable issues.

1. Potential nondeterminism in dimension ordering


* In `LoopInfo.build_from_node`, dimensions are accumulated in a `set` and returned as `list(dims)`.

* This can make downstream behavior/order-dependent checks non-deterministic across runs/Python versions.

* Suggest preserving stable order (e.g., seed from `abstract_dims` order and append discovered dims deterministically).


2. Split end computation relies on dict insertion order


* In split metadata reconstruction, end bounds are inferred from `list(axis_splits.values())`.

* If split map construction order changes upstream, computed ranges can silently change.

* Suggest sorting by split start explicitly before deriving `(start,end)` pairs.

Generated by Father the Guils' AI assistant, close comment if not relevant and blame me!

Haha you're a gangsta ! Did you copy-paste the diff in chatgpt/whatever, or use built-in Github tools?

Thanks for the review anywy, I fix the issues and come back to you!

No, I used the "developper way":

• I setup an OpenClaw stack containerized, on my machine, connected to ChatGPT-5.3-codex for the LLM
• I interacted with it such that it created with me skills:
  • a skill for reviewing PR the way I want
  • a skill for creating and pushing/updating new PRs when I have some ideas
• I asked it to setup cron jobs:
  • for proposing PR reviews that I can amend before pushing the review
  • for proposing random new ides every day to improve XTC
  • for proposing deeper developments every week to add features to XTC
• I asked it to connect to my whatsapp account such that I interact with it from whatsapp and can do everything from there (except modifying myself files)

Basically, experience is that the LLM now is just the brain, but configurations of tools/agents querying it really matters. And the base OpenClaw framework permits to define easily as you want or need theses additional tools that really automate things!

I did not use though prebuilt and closed source ChatGPT solutions for Github PRs, we redid it ourselves with OpenClaw+ChatGPT.

Though, I intended anyway to test also the prebuilt ChatGPT/github review solution, I will keep you infromed of the most effective way, but I can bet...

[guillon]

Fine for me once reported fixes are solved:

• mixed commits with main branch apparently
• Father's comments

[qaco]

Fine for me once reported fixes are solved:

* mixed commits with main branch apparently

* Father's comments

Ok done

[guillon]

Seems you have formatting issues: make format to reformat

[guillon]

I let you merge when ready