[pull] master from walkframe:master - #21
Open
pull[bot] wants to merge 88 commits into
Open
Conversation
v3: Declarative constraint engine, forward check, and FNV-1a hash sorter
Three deviations from Microsoft PICT's documented model syntax
(pict/doc/pict.md), fixed in both the TypeScript and Python ports:
1. Numeric IN sets rejected. `IN {512, 1024}` — the value form used in
PICT's own documentation — threw "Unexpected token in array" because
the set parser only accepted string tokens. Now numeric elements are
accepted (TS + Python).
2. LIKE treated regex metacharacters as special (TS only). `LIKE "4.8*"`
matched "4x8.1" because `.` was passed through to the regex verbatim.
All metacharacters are now escaped, then only `*` and `?` are restored
as wildcards. (Python already used re.escape and was correct.)
3. Sub-model order was mandatory. `{ A, B }` without `@ N` was rejected
and treated as a constraint. Per spec the order is optional and, when
omitted, defaults to the global order (/o). The order is now optional
and resolved to the global strength at generation time.
Tests updated/added on both sides. Full suites green
(TS: 179 passing, Python: 68 passing).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds comment classification to the PICT parser. Each maximal run of `#` lines becomes a CommentBlock, classified as either a field description (attached to the parameter directly below it, no blank line between) or freestanding documentation (separated by a blank line, or sitting above a constraint / non-parameter line). - `classifyComments()` in parse.ts is the single source of truth, reused for prompt assembly and editor syntax highlighting. - `CommentBlock` type and `classifyComments` are exported from the package. - `PictModel.comments` exposes the classified blocks. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…antics
Adds regression tests on both ports for the spec-conformance fixes:
- numeric and float IN sets (`IN {512, 1024}`, `IN {2.5, 3}`)
- LIKE treats non-wildcard chars (e.g. `.`) as literals
- LIKE `?`/`*` wildcard matching
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- IN accepts numeric sets (e.g. IN {512, 1024}), not just strings
- Sub-model `@ N` order is optional and defaults to the global order
- Clarify LIKE treats non-wildcard characters as literals
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fix(pict): spec-conformance fixes + comment classification
Minor release: PICT spec-conformance fixes (numeric IN sets, LIKE literal matching, optional sub-model order) plus comment classification. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )