negative_insulin: add version compatible with Loop next-dev#79
negative_insulin: add version compatible with Loop next-dev#79bjorkert wants to merge 3 commits into
Conversation
Updated codeThe location in Loop/Loop.xcodeproj/project.pbxproj where Preferences.swift line is inserted for basal_lock and where NegativeInsulinDamperSelectionView.swift line is inserted for negative_insulin were too close together. The lines in the negative_insulin/nextdev_negative_insulin.patch file were modified to shift the insertion of NegativeInsulinDamperSelectionView.swift a few lines earlier in the pxbproj file and reduce the number of comparison lines to avoid the location where basal_lock makes a change. The basal_lock/nextdev_basal_lock.patch was similarly modified to reducs the number of comparison lines to avoid the location where negative_insulin makes a change. TestThe application and removal of basal_lock and negative_insulin are now independent. |
marionbarker
left a comment
There was a problem hiding this comment.
Approved by code review and test. Added a few tweaks to deconflict basal lock and negative insulin damper.
Request @bjorkert review this again.
|
Approved, LGTM |

The existing
negative_insulinpatches do not apply to the Loopnext-devbranch, so the customization shows as incompatible.On next-dev the glucose-prediction pipeline (including
DoseMathand the insulin model) moved into the standaloneLoopAlgorithmSwift package, which no longer depends on LoopKit. The original approach — adoseEndparameter onDoseStore.getGlucoseEffects, the LoopKit insulin-model changes,LoopState.negativeInsulinDamper, etc. — no longer applies.nextdev_negative_insulin.patchkeeps the same behavior with a smaller, retargeted change: the damper coefficient is computed inLoopDataManagerand threaded into the algorithm as an optionalAlgorithmInput.negativeInsulinDamper, with the damping applied insideLoopAlgorithm.generatePrediction.The Negative Insulin Damper is an opt-in Algorithm Experiment, off by default. With it off the coefficient is
niland the algorithm behaves exactly as stock.Test
Requires LoopWorkspace on the Loop
next-devbranch. No lnl-scripts change is needed; onlyPATCH_BRANCHis overridden.reset command
This command resets the branch to default state.
apply