Spaces:
Running
Running
Commit History
-
Load a bundled example into the form instead of running it
The example buttons posted a job description straight to /run, so a user saw a report without seeing what produced it. One "Load example" button now fills the form with the example: the reference, one row per condition with its reads, and the options it runs with. The run is left for the user to start, so any of it can be changed first. The run button is disabled until the form holds a reference, at least one condition, a name for every condition, treated reads in every condition, and a value for every required option. The tooltip of the button names what is missing. A condition is no longer dropped in the page for want of treated reads, so an incomplete one reaches the server and is reported. The multi-reference example is three references of the Ribonanza PDB library, each with a 2A3 and a DMS condition and the matched no-modification background. It replaces one condition of 6000 sparse references that named neither its chemistry nor a background. The page titles name the page, th…6d5917c
-
Submit the form and the examples as one JSON job description to /run
The /run endpoint takes a multipart request whose "job" field holds a JSON job description. The description names the reference, the name and read files of each condition by role, and the options in the settings file format. A file reference is either "uploads/<part>", which names a file part of the request, or "examples/<path>", which names a bundled example file. job_description.py checks the description, and app.py stages both kinds of reference through the same code. The form builds the job description in the browser and posts it with the chosen files. Each bundled example is a job.json file that the page and scripts/smoke.sh post unchanged. The /run-example endpoint, the server-side form parsing, and the separate example settings files are removed. The settings check now rejects a fractional value for an integer option, because it is the only validation of options. The single-reference example now holds the rool120 plasmidsaurus pilot data as four conditions: hepes-2A3, hepes-DM…83f9087 -
Save each run's settings and load a settings file into the form
The option layer now builds one mapping that holds every exposed option's value for a run. A form submission and a settings file are two sources for it, and the command line and the saved file are two renderings of it, so the record and the run cannot disagree. A required option with no submitted value and no default now raises there, and the run is refused. This replaces the fallback to the first choice, which decided the alignment preset of every example run by the order cmuts prints its choices. Each bundled example carries a settings.json naming the preset it wants. Every job directory holds a settings.json with all the options the run used and the cmuts that ran it. The results page offers the file, and the zip download holds it. The Options card takes a settings file. The page sends it to /settings, which checks every name and value against the option dumps, and writes the fields it answers with into the controls. A refused file changes nothing, and a loaded value opens the se…4756cc5
-
Rebuild the space on the cmuts 2 command line
The option form derives from each subcommand's --dump-options, the pipeline runs as subprocess calls to cmuts align, hmm, sub, div, norm, and csv, and each results page proxies a live cmuts plot server. The Sync HF Space workflow deploys main to Hugging Face, and the pin workflow in DasLab/cmuts keeps the Dockerfile's CMUTS_SHA current. The previous space lives on the v1 branch.3b54ff3