not by a long shot
but just curious -
my loop cartfile refers entirely to remote repos - both for the standard frameworks and for anything i've customized. So I always assumed that when I ran carthage update, it was downloading those files from the git hub, and building the frameworks somewhere inside the carthage folder in loop or something like that - in other words, that to the extent that I had cloned repos of the frameworks locally that I had used to do modifications, once I pushed those back up, whatever goes on inside those local repos would be irrelevant?
you mean before pushing the local repo of the frameworks back up, you run carthage update inside the local folder - which makes the carthage.resolve file that is uploaded correct?
Interesting
When @ps2 said the workspace thing makes this easier, do you think it includes this sort of thing?
If you look at your cartfile.resolved for the various frameworks, you’ll see different commit SHA for the same “branch” of loopkit calls…so some of your resolved for loopkit resolve to c70d3f5 (which is the right, most current one) and most of the others go to f13026 (an outdated commit from another branch I think…I didn’t look too hard for where it was). So…to keep things as neat and tidy as possible, I run carthage update (or edit the cartfile.resolved) for the frameworks to make sure they are all resolving to the most current commit. Now, this used to be much easier when it was all just one cartfile in rileylink_ios…but now that things are getting distributed more broadly, it’s more headache. So yes, workspace would help this too.
let's see if I can build after this carthage update and if not I'll run it in the frameworks and push those back up and run update again and see
So getting a good Carthage build at least once seems to be sometimes necessary, for reasons I don’t really understand. Be the premise of the workspace setup is that it doesn’t depend on carthage at all. Xcode will build everything and find all the dependencies. It just sometimes has trouble if the Carthage products aren’t in place initially.
Well
I'll see if I can figure out the workspace now...I don't think I can handle going through that again!
fwiw, this page has some good fairly plain language explanations https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md
should I run carthage update in the local framework folders before dragging them in? No harm I guess?
or it really shouldn't matter?
anyway let me just try.
well, now dragging is nice. I always took the long way uphill and used the menus. just tried it. lol
had to still use menu for those
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.
