Now mi mi broda ti ti gi'e brode ta ta correctly has the sumti places numbered as: 1, 2, 3, 4, 3, 4.

Before, ta ta were numbered 5, 6.

Yes... and I think I see why. I created a third row in that Location tab.

Check out the formula in I3-I4...

...vs the one in I5 and below...

So, SF and Oakland appear to ignore negative percentages, while newly added cities will ignore positive percentages! Both of those seem weird to me, since cases can be either increasing or decreasing?

Interestingly, if I put in a negative percentage for the change in cases from last week to this week, the activity risks go down. But any nonnegative percentage (from 0 to 1000000) produces the same results.

I am also having this issue with a large group. The crawler seemed to stop in the middle for no reason.

Great thank you! Now, when I pretend there's more cases this week, the risk goes up! It's still not super easy to fill in the location info... I guessed 0% for case increase because the website says "cases are stable or decreasing". Though, adjusting that percentage doesn't seem to do much. Is there a better place to find that number?

So I've added a column for myself to the PERSON_RISK_FACTS spreadsheet: (side note: it would be real nice if the main site displayed cases in the week before last, as that's where I'm copying the numbers from)

Also in case it's relevant, I changed some of the person type labels to make it easier for me to use the dropdown:

Then I've entered some activities:

I don't trust these results for a simple reason: if I increase the number of local cases on the PERSON_RISK_FACTS sheet, the risk for each activity goes down. How is that possible?

We seem to be downloading jQuery twice (different versions) in base.html. They shouldn't both be required.

When starting editing, we hide all the siblings of the Edit button, which used to be correct, but some divs got merged and now that includes the "Logout" and "Back" buttons, which probably shouldn't disappear.

Tracking the attendees of past meetings can be messy because there's no foolproof way to match up registrants with participants. Using the lowercased email as a primary key almost always works. However, a big exception is that whoever launched the meeting by clicking "Start meeting" (even if multiple people did this) will be attributed to the email address of the Zoom account owner, and the name also comes from the Zoom account so that doesn't help. The only way to guess how to attribute the time would be to track clicks on the start button, and associate that to logged-in users.

The update-meeting view can handle this error, but the get-meeting view cannot, and just goes to 500 which emails me and doesn't tell the user what happened. That's the desired behavior when the app crashes, but the unknown Zoom meeting error is fairly plausible and should be handled.

The update-meeting view can handle this error, but the get-meeting view cannot, and just goes to 500 which emails me and doesn't tell the user what happened. That's the desired behavior when the app crashes, but the unknown Zoom meeting error is fairly plausible and should be handled.

Most of requirements.txt needs to be specified here.

We seem to be downloading jQuery twice (different versions) in base.html. They shouldn't both be required.

When starting editing, we hide all the siblings of the Edit button, which used to be correct, but some divs got merged and now that includes the "Logout" and "Back" buttons, which probably shouldn't disappear.

Tracking the attendees of past meetings can be messy because there's no foolproof way to match up registrants with participants. Using the lowercased email as a primary key almost always works. However, a big exception is that whoever launched the meeting by clicking "Start meeting" (even if multiple people did this) will be attributed to the email address of the Zoom account owner, and the name also comes from the Zoom account so that doesn't help. The only way to guess how to attribute the time would be to track clicks on the start button, and associate that to logged-in users.

Huh? That's exactly the same error.

It's the global /Library/Preferences, but the file is not listed by pkgutil --files nor is it deleted in the uninstall. But it's listed in the manual uninstallation instructions so maybe I ought to add an explicit delete:.

Great thanks. What do you think about the /Library/Preferences plist?

Hi, VB-Cable is a virtual audio device which can be used as a "cable" to connect one app to another.

** I need help writing the uninstall stanza. I tried uninstall pkgutil: com.vbaudio.vbcable, as you can see, and brew cask uninstall vb-cable claims to run successfully, but it does not delete the files listed by pkgutil --files com.vbaudio.vbcable. Manual uninstallation steps can be found here. I can add that to the formula using :delete but why is :pkgutil not working?

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

After making all changes to a cask, verify:

• [x] brew cask audit --download {{cask_file}} is error-free.
• [x] brew cask style --fix {{cask_file}} reports no offenses.
• [x] There are no open pull requests for the same update.
• [x] The submission is for a stable version or documented exception.

Additionally, if adding a new cask:

• [x] Named the cask according to the token reference.
• [x] brew cask audit --new-cask {{cask_file}} worked successfully.
• [x] brew cask install {{cask_file}} worked successfully.
• [ ] brew cask uninstall {{cask_file}} worked successfully. see above
• [x] Checked the cask was not already refused.
• [x] Checked the cask is submitted to the correct repo.

Most of the examples at serde.rs have example input in JSON or YAML, but a few do not. IMO, they all should, so there's no mystery as to what each example is for. To be honest, I've read the "Deserialize for custom map type" over and over and I have absolutely no idea what it does.

• [x] Structs and enums in JSON
• [x] Enum representations
• [x] Default value for a field
• [x] Struct flattening
• [x] Handwritten generic type bounds
• [ ] Deserialize for custom map type
• [x] Array of values without buffering
• [x] Serialize enum as number
• [x] Serialize fields as camelCase
• [x] Skip serializing field
• [ ] Derive for remote crate
• [ ] Manually deserialize struct
• [ ] Discarding data
• [x] Transcode into another format
• [x] Either string or struct
• [x] Convert error types
• [x] Custom date format

Putting in my vote for $mod. $self is really confusing and sounds like macro-methods or something (and, IMO, should be saved in case we eventually do something along those lines).

The functions __aeabi_unwind_cpp_pr0 etc in backtrace.c have a comment saying they prevent the linking of the same functions in libgcc, but I just get errors about that:

/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/thumb/v7e-m/fpv4-sp/hard/libgcc.a(unwind-arm.o): In function `__aeabi_unwind_cpp_pr0':
unwind-arm.c:(.text+0x760): multiple definition of `__aeabi_unwind_cpp_pr0'
build/backtrace_backtrace.c.o:backtrace.c:(.text.__aeabi_unwind_cpp_pr0+0x0): first defined here
collect2: error: ld returned 1 exit status

I would advocate for the "skipping editions" or more preferably "feature-based editions" model. I think having a cadence for editions will make breaking changes more common[1]. If something is going to be an edition-level change, then you can always use the refrain "OK, let's just wait for the next edition and we can do it anyway".

"But if we accept this, that'll be the only reason to have an edition, and it doesn't seem worth it."

I think this is exactly the consideration that should be made for large RFCs.

[1]: I know the argument is that they aren't really breaking changes because of the opt-in Cargo.toml attribute and automated migration tooling. These are indeed great features of the Rust ecosystem. But it still means that Rust code looks different and means something different to humans, which is a form of breakage.

I think this addresses my concerns from #438. Added one other semi-related question above.

I'm not entirely clear on the USB middleware so this is kind of theoretical. But does sending stuff in three separate process_bytes calls slow things down? I was analyzing some data dumps and found many cases where checksums and line breaks showed up in separate USB reads.