I think it’s not uncommon for a drug treating some condition with some symptom to have a potential side effect that worsens that symptom. When you start playing with some set of receptors, it’s possible something goes too far or, for whatever reason, not far enough and now we’re worse off
See: antidepressants can increase suicidal ideation, cannabis (used for nausea) can cause nausea at higher doses, etc.
> I think it’s not uncommon for a drug treating some condition with some symptom to have a potential side effect that worsens that symptom.
I think you're making the error of conflating probabilities here. It's not uncommon for drugs to have uncommon side effects, but those side effects are still uncommon. Every once in a while benadryl makes a person paradoxically excited, but most people who take benadryl get sleepy.
As an occasional user, can confirm that motion sickness pills (e.g. Cinnarizine, one of the most used in the British Navy) make dizzy, some more than other, and that it’s still much better overall than not taking them.
Language is a symbolic system. From an absolute or spiritual standpoint, meaning transcends pure linguistic probabilities. Language itself emerges as a limited medium for the expression of consciousness and abstract thought. Indeed, to say meaning arises purely from language (as probability alone) or, to deny language influences meaning entirely are both overly simplistic extremes.
"When he to whom one speaks does not understand, and he who speaks himself does not understand, that is metaphysics." - Voltaire
Like I said in another comment, I can think of a dozen statistical and computational methods where if you give me a text and its synthesis I can find a strong probabilistic link between the two.
"Not everything that counts can be counted, and not everything that can be counted counts." - Someone.
Statistical correlation between text and synthesis undoubtedly exists, but capturing correlation does not imply you've encapsulated meaning itself. My point is precisely that: meaning isn't confined entirely within what we can statistically measure, though it may still be illuminated by it.
... meaning is not always impacted by the specificity or sensitivity of language while sometimes indeed exclusively captured by it, although the exclusivity is more of a time-dependent thing as one could imagine a silent, theatrical piece that captures the very same meaning but the 'phantasiac' is probably constructing the scene(s) out of words ... but then again ... there either was, is or will be at least one Savant to whom this does not apply ... and maybe 'some' deaf and blind person, too ...
Might be a little bit of both but nothing you said there contradicts the original point--opening up iMessage integration to arbitrary bluetooth connections is a bad idea. It blows open access to all your messages...who knows, maybe even the e2ee keys. Law enforcement would have a brand new frictionless way into all your messages
I don’t think Apple would ever expose the encryption keys to your messages. Nobody would want it anyway: why reimplement the protocol when you actually just want to send and receive messages? And I fail to see why it would be frictionless for law enforcement, as they’d need to have access to your device.
It is... but basically it need to remember which groups are sync'd. For example if you use an extra, you have to keep track of it constantly because sync thrashes around between states all the time unless you play close and tedious attention. At least I haven't figured out how to make it remember which extras are "active".
uv sync --extra gpu
uv add matplotlib # the sync this runs undoes the --extra gpu
uv sync # oops also undoes all the --extra
What you have to do to avoid this is to remember to use --no-sync all the time and then meticulously manually sync while remembering all the extras that I do actually currently want:
uv sync --extra gpu --extra foo --extra bar
uv add --no-sync matplotlib
uv sync --extra gpu --extra foo --extra bar
It's just so... tedious and kludgy. It needs an "extras.lock" or "sync.lock" or something. I would love it if someone tells me I'm wrong and missing something obvious in the docs.
Thank you! That's good to know. Unfortunately it doesn't seem to work for "extras". There may be some target other than sync.include-groups but I haven't found it yet.
What I am struggling with is what you get after following the Configuring Accelerators With Optional Dependencies example:
Part of what that does is set up rules that prevent simultaneously installing cpu and gpu versions (which isn't possible). If you use the optional dependencies example pyproject.toml then this is what happens:
$ uv sync --extra cpu --extra cu124
Using CPython 3.12.7
Creating virtual environment at: .venv
Resolved 32 packages in 1.65s
error: Extras `cpu` and `cu124` are incompatible with the declared conflicts: {`project[cpu]`, `project[cu124]`}
And if you remove the declared conflict, then uv ends up with two incompatible sources to install the same packages from
uv sync --extra cpu --extra cu124
error: Requirements contain conflicting indexes for package `torch` in all marker environments:
- https://download.pytorch.org/whl/cpu
- https://download.pytorch.org/whl/cu124
After your comment I initially thought that perhaps the extras might be rewritten as group dependencies somehow to use the ~/.config/uv/config.toml but according to the docs group dependencies are not allowed to have conflicts with each other and must be installable simultaneously (makes sense since there is an --all-groups flag). That is you must be able to install all group dependencies simultaneously.
See: antidepressants can increase suicidal ideation, cannabis (used for nausea) can cause nausea at higher doses, etc.