GateLabR 1.6.2

GateLabR 1.6.2

GatingSet

• A GatingSet whose gates differ between samples opens with each sample's own gates. 1.6.1 read the hierarchy from the first sample only, so the app gated every sample with the first sample's gates and "Save to GatingSet" wrote them over every sample's own.
• "Save to GatingSet" writes in place: an unchanged node is left as it was, a changed gate is set only on the samples whose gate changed, a renamed population renames its node, and a new population is added with each sample's own gate. 1.6.1 removed every node and wrote the app's tree back. gatelabGatingSet() writes the same way.
• Nodes the app never held (an OR, a node on a FlowJo calibration-table channel, a NOT of an AND, a node of fixed indices, a node added in R since launch) survive a save unchanged and are named in the save report. 1.6.1 removed them.
• A workspace a 1.6.1 session saved on a GatingSet with tailored gates holds the first sample's gates; the launch note names the affected nodes and how to reopen from the object's own gates.

Embedded core

• GateLab 0.9.3 (GateLab-dev ec0c0c6). The agent link now connects only to a relay on this computer (127.0.0.1, localhost or [::1]). The 0.9.0 to 0.9.2 cores, embedded since 1.6.0, connected on load to a relay on any host named by ?agent= in the page address, and that relay could read the tab's data and change its gates. launchGatingApp(agent = TRUE) connects as before.

Tested

• testthat 2,225 expectations, 0 failures; host parity 23 of 23 on the served build.
• A GatingSet parsed from FlowRepository FR-FCM-Z2V4 (three samples): app counts equal flowWorkspace's on 114 of 114 node-sample pairs before the save, none changed by the save, 117 of 117 after it. On 1.6.1 the same save changed 21 of 114.