hmm. Was looking promising all the way through step 6. Carthage build ran. But step 7 build failed. Are you supposed to build from Loop or from the workspace? I ran from the workspace. Building from Loop works, but I'm not sure that proves anything unless I make changes to frameworks and see whether they are incorporated? and, is it necessary to re-run
carthage build after changing framework code? if so, almost no time saving. OK so I will try changing something in a framework and see whether it updates without reruning carthage build
should the workspace look like that?
Any ideas around what settings to look at if I am accurately entering carbs but ICE is not showing them all absorbed? Sorry, I’m struggling a little with understanding how to properly use ICE and when I should be editing carbs and absorption time if my original entry was not accurate.
I feel like my ISF and CR are fairly accurate and I do use autotune regularly with very little variation in its recommendations.
@sethgagnon to me the explanation that matches your facts, especially if you take as a given the accuracy of your other ratios, is a slightly higher than necessary basal around mealtimes. But you may feel your basals are also quite well calibrated - in which case, it could be just a small error across all the parameters. IMHO editing the entry ex post for small differences is probably not worth it. Between the added robustness that comes from dynamic carb absorption and retrospective correction, and the inherent challenges and imprecisions of the disease, ex post carb entry editing might just be a time consuming distraction.
@ps2 and @jeremybarnum I am still unclear about making a proper workspace. The part that I don’t understand is that if I want to add in LoopKit’s project file in a way that I can modify it, do I drag that in from the Carthage/Checkouts/LoopKit folder as per the instructions you posted? I don’t see how this is a good idea because that folder is over-written all the time on every carthage update, and so any changes I make will get blown away. I think I need to have my own LoopKit folder branch clone somewhere else, and drag that project file into the workspace inside of the Loop project. And then set the Cartfile in the Loop folder to either draw from that checkout locally or through github. Is this true?
And you don’t drag, use Add from the menu, for the frameworks in checkouts for their .xcproj files
specifically, the predictions are so different.
mathwise, the 96 prediction makes more sense to me…a little IOB and trending down. I forgot to pull an issue report.
wondering if there’s a difference in timing on those displays?
@Kdisimone thanks - this is great to hash out. @ps2’s said you don’t manually do a carthage update/build, that it is handled by Xcode - and I am not sure if Xcode does update vs build since it does it behind the scenes. It may do both, depending on if it sees any dependency added. And my fear is that if it does an update, any code that I am editing that came from a Checkouts folder will be blown away.
@rsilvers129 you can see the Carthage script executed by Xcode by clicking on Cartfile target in Xcode, then open Build Carthage Dependencies. The script is not doing
update or build, but bootstrap instead. carthage bootstrap is similar to update but it's working on Cartfile.resolved as opposed to Cartfile.
@dm61 Thanks. Can I edit from the source in Checkouts in Xcode then without carthage bootstrap reading resolved and sucking in new copies and over-writing my modified code? And how would the edited code stay under source control being in that folder that is a sub-folder of whatever Loop branch I am working on? I still can’t grok.
You have seen this: https://github.com/LoopKit/Loop/wiki/XcodeWorkspace ?
Yes. And I can get it to build, but it doesn’t address why code changes are safe. How can one work from Checkouts and expect their code to not be erased? How does the code in Checkouts stay under git control so I can maintain versions that are unique from Loop’s branch? How does one do a git commit within a Checkouts folder? Won’t that commit be assigned to the Loop parent’s folder branch?
BTW, I managed to stay pretty flat today even though I ate 311 grams of carb, 91 grams of fat and 87 grams of protein. And I ran 6 miles. I did this by using Loop-FPU (LoopKit/Loop#702) to handle the carb+fat+protein, and then I manually simulated the exercise mode that is not yet implemented where basal rate goes to 1/5 normal, carb ratio goes to 5x normal, and ISF goes to 5x normal (https://github.com/LoopKit/Loop/issues/593).
See what they say in this tutorial: https://www.raywenderlich.com/416-carthage-tutorial-getting-started The front part is pretty basic, but then there is a section on Build Artifacts that explains how
--use-submodules option adds each dependency in the Checkouts folder to your Git repository as a submodule, meaning you can change the dependencies’ source, and commit and push those changes elsewhere without fear of an overwrite.
@rsilvers129 Do the Cartfiles in your project point to GitHub, or to your local directories? You want the latter if you’re going to be editing files there. Or, if your local files have your own GitHub repos set as upstream , you could make sure to always push your local changes to GitHub before building each time.
I have it all set up so that the Loop sub-modules come from my personal github repos. I edit local versions of them, and push them back to github. The reason I like it that way is because then if anyone else build my branch of Loop, it will automatically draw my version of LoopKit into their Checkouts folder.
@rsilvers129 The setup you describe makes sense to me. So then I think the key to not having your local changes overwritten is to make sure that they get pushed to GitHub before you build (if you're using the checkouts directory as your local repo and editing there). But it seems like it would be cleaner and safer to have your local git repo outside that tree, push all changes to GitHub, and then let carthage pull them back into its checkout.
But maybe I'm not fully understanding your question.
Still having trouble with pixel alignment/antialiasing for the prediction path and the labels, but it's a start.