Spaces:
Running
Running
Commit History
-
fix(storage): do not require server-side copy for example corpora
Loading the full CAMEL corpus 500'd on the lab's deployment. The cause is not ours: R2 CopyObject is unavailable on that bucket, answering NoSuchKey for an object head_object resolves in the same session and with both CopySource forms. The dev account copies the identical 38 MB file without complaint, so this varies by account and cannot be relied on. The server-side copy was only ever an optimisation - it avoids reading 38 MB back out through the app per visitor. The caller has already downloaded the file to parse it, so the fallback is to upload that local copy: one upload, no extra fetch, and it works on any S3-compatible backend. Verified against the lab's bucket, where it now succeeds and leaves the master object intact. Note for whoever adds the next deployment: dev and prod are separate Cloudflare accounts, so the master file needs uploading once per account with scripts/upload_example_corpus.py. The catalogue only stores the key. Co-Authored-By: Claude Opus 5 (1M context) <n…82c5ea2 -
fix(ui): sample data picker is a dropdown with an info button
Choosing which corpus to run is a choice between mutually exclusive options, so it is a dropdown rather than a stack of rows: adding a dataset later costs one more option instead of another block of Step 1, and the panel stays one line tall whatever the catalogue holds. The per-entry About link becomes a single circular info button sized to the other controls, so it reads as part of the row rather than a glyph dropped into it. The dialog it opens now carries the CAMEL mark beside the name; the logo belongs there, on the dataset being described, and not in the picker, which lists several corpora and would imply they share a source. The selected entry keeps its one-line summary under the row, and an entry this instance cannot run is disabled in the dropdown, labelled "unavailable here", with the reason underneath. Drops the now-unused .samples-list, .sample-row, .sample-text, .sample-name, .sample-meta and .sample-actions rules rather than leaving them behind. Co-Authored-By: Claude …69aff04 -
fix(ui): sample data as a small entry point under the upload row
The PI's framing for CAMEL is a small "use sample data" call to action: from it a visitor sees the two available sizes, and can read about the data if they want to. The dropdown row did the opposite - it sat above the upload control and read as the first thing to do. Step 1 is now upload first. Under the row, one muted line ("No data of your own? Use sample data") expands in place into a two-row list: name, size, language, a one-line fit note, About, Use. About opens the provenance dialog (description, text column, preprocessing, citation, dataset link), which carries its own Use button so a reader can decide from there; Escape and the backdrop close it. The panel closes once a corpus is loaded, and the Corpus select echoes the sample's name rather than its filename. Sizes an instance cannot run stay listed with the reason and a disabled Use. Picking a size already in the project selects that copy instead of copying the corpus again, so a second click cannot duplicate 38 MB in the bu…0b5c981 -
fix(ui): one compact corpus row instead of two large cards
Three problems with the first cut, all fair. CAMEL appeared twice, as two "corpora". It is one dataset in two sizes, so the sizes are now options in a single dropdown and it reads as one dataset. It was badged DEFAULT, which overstates it. The PI asked for CAMEL to be "available and ready-to-use"; that is a starting point, not a claim that this is THE corpus. The field is renamed default -> preselected, it decides ordering and what loads first, and nothing is badged. The two expanded cards took most of Step 1 and pushed the upload control below the fold, which is the wrong hierarchy: most researchers bring their own data. Step 1 is now one labelled row - dropdown, info button, action - and the provenance (description, text column, preprocessing, citation, dataset link) moved into a modal behind the info button, where it is one click away without occupying the step. Also: the listing now knows this instance's row ceiling. The full corpus is 57,174 rows against a deployed CCR_MAX_ROW…bb4c28d -
feat(corpus): offer the full CAMEL corpus from R2, raise the row ceiling
Follows spec 0010, which shipped only a 999-text sample because the full corpus could not be ingested. CCR_MAX_ROWS goes to 100,000, which was the code default all along; the three docs that variously claimed 20,000 and 50,000 are corrected to agree with it and with each other. That removes the ceiling that made the 57,174-row corpus un-ingestible. The full corpus is served from R2 under examples/, not the repo: 38 MB would ride in the Docker image and the Space repo on every deploy. It is deliberately NOT fetched from Hugging Face at runtime - that dataset returns 401, so fetching it would mean shipping lab credentials in a public app. scripts/upload_example_corpus.py puts it there and prints the row count the catalogue entry has to declare. Selection downloads the master once to parse, then makes the user's copy with a server-side copy_object, so 38 MB does not travel back out through the application for every visitor. Verified against the live bucket: 7.0s fetch, 0.7s parse of 57…88b1ea9 -
feat(corpus): CAMEL as a built-in example corpus [spec 0010]
PI request from 2026-08-19: make the lab's CAMEL corpus the example data on the site so visitors can try CCR without uploading anything. Corpus details from Aliah 2026-09-06. Step 1 now offers an example corpus above the upload control. One click loads it, selects the declared text column, and the run proceeds through the normal ingest path, so nothing downstream changes. The citation and a link to the full dataset sit on the card, and a run on an example writes a corpus_source block into its metadata carrying the citation, source URL and preprocessing note: results produced on someone else's corpus have to stay attributable in the same file as the scores. Ships a 999-text SAMPLE rather than the full corpus, because the full one cannot be the bundled default: 57,174 rows exceeds CCR_MAX_ROWS (50,000 on both deployments) so ingest would refuse it outright, 38 MB against a 156 KB sample_data would ride in the Docker image and the Space repo, and a demo has to finish in seconds on 2 vCP…3a1d713