Show offence ID on check your answers and full referral pages

Context
HPTs currently have no way of knowing which index offence a referral belongs to and are having to ask the CPP, therefore, we want to show the offence ID on the referral page under the 'sentence information' section.
To achieve this we are adding the offence ID to the response of the first page of the 'sentence information' task. As there is no way to change the offence ID without starting a new referral, we hide the "change" action on the check your answers page.
This isn't an ideal solution as it doesn't follow the conventions of the other form pages, but here is some rationale:

Offence ID is fetched by the server without the need for user input. We only ask the user to choose an offence ID if more than one offence is retrieved from the API. This means making a TaskListPage for offence ID non-trivial and would require a different approach to what we have now. Given there are limited dev days left on CAS3, taking on this work isn't feasible.

I thought about adding a new type of TaskListPage which wouldn't be visible to the user, but changing the existing domain model for this one instance felt a bit premature, and would still be a good chunk of work.

The solution in this commit is a hack but is fairly non-invasive and easy to change in the future.

Let me know if this is something you've encountered in CAS1/CAS2. Alternative solutions are welcome!

Changes in this PR
Screenshots of UI changes
Before

After

Release checklist
Release process documentation.
Pre-merge checklist

[ ] Are any changes required to dependent services for this change to work?
(eg. CAS API)
[ ] Have they been released to production already?

Post-merge checklist

[ ] Manually approve
release to test
[ ] Manually approve
release to preprod
[ ] Manually approve
release to prod

Looks good, thanks!

My one criticism would be that it doesn't look like the new functionality in the checkYourAnswers utils file is unit-tested.

Good spot, thanks @richpjames


Welcome message on new site

I just spun up a new Playbook (Drupal 9.2.0-dev) and upon visiting the resulting Drupal site for the first time was greeted with this:

This is not a node, it's static text inweb/core/themes/olivero/templates/includes/get-started.html.twig.
This is very friendly, but it's about Drupal, not Islandora. I know Islandora 8/9 is all about "getting off the island" but I wonder if having an Islandora-specific page that replaces this one would enhance the evaluator (or newbie) experience.

I don't mind tracking this down and making it happen. :-)

OK, just going to add the description of what I've done prior to me pushing a pull request. Basically the functionality is inside of islandora/islandora. I've added a couple of twig files, a new route "welcome", and update hook in the install file to change home over to the new. I'm adding instructions on how to set your own homepage. Just by copying the welcome twig into your theme. I think having it create a copy in the system's default template directory might be useful. Any thoughts before I jump on this?

Pull Request pending review and documentation added.
https://github.com/Islandora/islandora/pull/856
https://github.com/Islandora/documentation/pull/1989/files

Sorry, meant to close PR and not the ticket.

Added a Doc on how to achieve this. https://github.com/Islandora/documentation/pull/2002


Fixed the initialization script to update correctly root and update…

Fixed the initialization script to update correctly root and updated it to /bin/bash.
Fixed the initialization script to to encompass the lockout prb of the socket after the shutdown.
Added the installation of bush to Dockerfile.
Changed the base image to alpine:3.4 for layer compatibility
Changed the data folder from /App to /Data

Please note that I also changed the data folder from /App to /Data

lockout prb of the socket: after the shutdown of the container the socket can remain locked. With this update the socket file is deleted before starting mysqld.

Conflicting files
startup.sh


feat(streaming): correctly implement lookup-union executor

Signed-off-by: Alex Chi<EMAIL_ADDRESS>What's changed and what's your intention?
Basically, what we are doing here is to forward data one input by one input. To avoid blocking upstream channels, we will need to store all data into a local buffer, which caused this part somehow not easy to read. Not sure how to write this in a better way. cc @wangrunji0408 may take a look and shed some light.
Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)
close https://github.com/singularity-data/risingwave/issues/2141

Can we spawn new futures to buffer upstreams? Then the union executor could await these futures sequentially.

Can we spawn new futures to buffer upstreams? Then the union executor could await these futures sequentially.

Nope. Executors need back pressure. If union executors cannot send its data to downstream, it should stop receiving data from upstream.
Also we assume one actor only creates one thread. There should not be un-managed spawned future in actors and executors.

I have a solution that might look better. See 77c40a25.
The key points are:

Use bounded channels as buffers with backpressure.
To avoid blocking upstream, create a future for each input to poll the stream and forward its output to the channel. The executor can then await the channels one by one, which greatly simplifies the code.
Although spawning futures is not allowed, to ensure they are being polled, we can select them on all .await points.

That's cool! I'll cherry-pick that commit to my branch... tomorrow for sure 🤣

Also we assume one actor only creates one thread. There should not be un-managed spawned future in actors and executors.

And I still think spawning futures should be allowed. It wouldn't create new threads, just create a new task.
To avoid dangling futures, we can use smol-style task handle, which will cancel the task on drop, instead of detaching it.
Once all task handles are properly stored somewhere, we can make sure that all tasks are under the control.
In this case, I don't think the executor itself should care whether the upstreams would be blocked or not. If an upstream is not allowed to be blocked by downstream, we should spawn a future to poll it and connect futures using a channel as a buffer. Therefore, no matter what the downstream executor is, the upstream will never be blocked.

LGTM


python312Packages.pyais: 2.6.6 -> 2.7.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.pyais is: Module for decoding and encoding AIS messages (AIVDM/AIVDO)
meta.homepage for python312Packages.pyais is: https://github.com/M0r13n/pyais
meta.changelog for python312Packages.pyais is: https://github.com/M0r13n/pyais/blob/2.7.0/CHANGELOG.txt
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.7.0 with grep in /nix/store/hdh31d7fnxhyr78jjm44mfnay7ha2d25-python3.12-pyais-2.7.0
found 2.7.0 in filename of file in /nix/store/hdh31d7fnxhyr78jjm44mfnay7ha2d25-python3.12-pyais-2.7.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.pyais
python312Packages.pyais

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/hdh31d7fnxhyr78jjm44mfnay7ha2d25-python3.12-pyais-2.7.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.pyais https://github.com/r-ryantm/nixpkgs/archive/cf36aa884c35d75d96105b5c6fa65ad132ceb626.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/cf36aa884c35d75d96105b5c6fa65ad132ceb626#python312Packages.pyais

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hdh31d7fnxhyr78jjm44mfnay7ha2d25-python3.12-pyais-2.7.0
ls -la /nix/store/hdh31d7fnxhyr78jjm44mfnay7ha2d25-python3.12-pyais-2.7.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

python311Packages.pyais
python311Packages.pyais.dist
python312Packages.pyais
python312Packages.pyais.dist

Maintainer pings
cc @fabaff for testing.

Result of nixpkgs-review pr 330668 at 7a98264f run on x86_64-linux 1

2 packages built successfully:

python311Packages.pyais
python312Packages.pyais


feat: where and .length for maps; various small fixes

This PR:

Adds a where clause for maps
Adds a .length for maps to get the number of pairs
Updates convenience functions to take any instead of map[string]any
Provides better error messages

Codecov Report
Base: 73.09% // Head: 74.76% // Increases project coverage by +1.66% :tada:

Coverage data is based on head (20718b9) compared to base (194704c).
Patch coverage: 89.28% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #9      +/-   ##
==========================================
+ Coverage   73.09%   74.76%   +1.66%
==========================================
  Files           7        7
  Lines        1022     1046      +24
==========================================
+ Hits          747      782      +35
+ Misses        212      203       -9
+ Partials       63       61       -2

Impacted Files
Coverage Δ

typecheck.go
78.73% <80.00%> (+6.51%)
:arrow_up:

expr.go
100.00% <100.00%> (ø)

interpreter.go
73.35% <100.00%> (+2.12%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Jumbotron does not work at all.

These were removed in bootstrap 5.

Added a mock-jumbotron to mimic the previous bootstrap version.


Search through posts.

It would be rather annoying to not be able to search through the posts.

https://github.com/christian-fei/Simple-Jekyll-Search

http://mathayward.com/jekyll-search/


Is it possible to do incremental learning ?

Hi,
I would like to keep training a model that finish training on old data with new data,
the issue is that the vocabularies of src and trg languages will change.
Is it possible to do that?
And if yes, how should  I add the new data? should I run preprocess.py again on the new data and then the train.py?
Thanks

It's not possible to pick up training if your vocabulary has changed without making some code modifications- this is because the input/output embedding layers won't have trained your new vocabulary. I would suggest: use BPE and maintain the same BPE codes for your old/new data, then train with a set vocabulary that's equal to the # of BPE tokens you have. Then there is no mismatch. You need to preprocess both datasets of course.
Hope that helps!


RN-152 Added constants and exported functions needed for creating GMs on mobile

Mostly adds some exported functions, but also changes the return type of createGroupChannel so that we can handle it the same as createDirectChannel. This will need a followup PR in the platform repo to handle these correctly
Ticket Link
https://mattermost.atlassian.net/browse/RN-152
Checklist

Updated unit tests

@hmhealey if your confident you can merge this PR


Add documentation for Box2D extension

Changes
Adds a new documentation page for the Box2D extension. It explains how to use most of the blocks and provides one example.
Tests
Webpage tested on Edge 113.

Considering throwing one of these together for local storage

Considering throwing one of these together for local storage

I've already been working on that one.


adding redirects for consciousnesshackingSF/SV

When we deploy this, we need to change the slug of consciousnesshackingsf to chsf and consciousnesshackingsv to chsv

I'm going to wait to merge this until our next push, that way we are less likely to forget to make the slug change after push.

Merging now and doing the change at the same time


Add replay feature

This PR adds a great feature to Cookiecutter! :smile_cat:
Users can now replay their previous invocation without being prompted for input again by adding --replay on the cli or setting the according kwarg when using the api. This feature is comes in handy if you want to create a new project from an updated template. Cookiecutter now dumps a json  to ~/.cookiecutter_replay/ when you call it (it overwrites per name).
[raphael@hackebook ~]$ tree .cookiecutter_replay/
.cookiecutter_replay/
├── cookiecutter-django.json
└── cookiedozer.git.json

Cookiecutter uses these replay files if you pass the aforementioned cli option.
@ionelmc and I had a chat on this feature at EuroPython, so I decided to spend some time on it.
Note: I am going to update this PR in the upcoming days with an according section in our advanced usage docs.
Please let me know your thoughts! Any feedback is welcome :bow:

Current coverage is 97.02%

Merging #501 into master will increase coverage by +0.29% as of 04314d8

@@            master    #501   diff @@
======================================
  Files           12      13     +1
  Stmts          459     503    +44
  Branches         0       0
  Methods          0       0
======================================
+ Hit            444     488    +44
  Partial          0       0
  Missed          15      15

Review entire Coverage Diff as of 04314d8

Uncovered Suggestions

+0.59% via ...okiecutter/compat.py#70...72
+0.59% via ...okiecutter/compat.py#61...63
+0.59% via ...okiecutter/compat.py#49...51
See 4 more...

Powered by Codecov. Updated on successful CI builds.

Whoa! :cake:
Do I understand the changes correctly, to regenerate a project you run cookiecutter --replay project-name?

First you run Cookiecutter as you are used  to:
cookiecutter https://github.com/pytest-dev/cookiecutter-pytest-plugin.git

If you wish to use the template again without going through the variables you add the according option:
cookiecutter https://github.com/pytest-dev/cookiecutter-pytest-plugin.git --replay
```
I'll write a brief guide for the docs soon :smiley:

How do I regenerate a project that was generated some time ago (certainly not the last project)?

Well if you don't have a replay file.... you could add it yourself :smiling_imp:
See https://github.com/hackebrot/cookiecutter/blob/add-replay-feature/tests/test-replay/cookiedozer_load.json

I mean, how does cookiecutter https://github.com/pytest-dev/cookiecutter-pytest-plugin.git --replay know what project to replay?
Maybe I just need to wait on the docs. Or read more code :grin:

https://github.com/audreyr/cookiecutter/pull/501/files#diff-15d53d64fa153c578d1489460db0a98aR96

Anyone up for a review? @ionelmc @audreyr @pydanny @michaeljoseph

I like how this separates as much of possible of the new functionality into new areas of code, rather than spiking the whole project. I'm testing it on cookiecutter-django, as that has gotten to be a rather sophisticated template.

What is missing is documentation, otherwise methinks this is complete and would be an awesome feature for 1.1.0.

Thank you for your review and feedback @pydanny! :bow:
I was actually about to write the docs when I discovered #502. I'll update this PR later on! :smile_cat:

Docs done :triumph:

I went through this in detail too. It looks fantastic. Amazing work @hackebrot!

Thank you @audreyr! :blush:


fix(http.js): ignore aws:443 calls

:tada: This PR is included in version 1.84.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add support for using yowasp when yosys is not available.

While YosysHQ's OSS CAD Suite distribution is readily available it can be somewhat overwhelming to install for beginners.
To make it easier for readers of our gateware tutorials this PR adds support to LUNA for using YoWASP's WASM-based packages for Yosys and NextPNR if there aren't any other Amaranth-supported toolchains available.
The logic works as follows:

Check if platform has all required tools with platform.has_required_tools(). If it has, do nothing further and continue to the build.
Otherwise, start by setting the problem count to 0 and then:
Check if the following Python modules can be imported, incrementing the problem count if it cannot.

yowasp_yosys
yowasp_nextpnr-<target> where <target> is obtained from platform.required_tools.

Check if the tool binaries are abailable on the system PATH:

If it is found, set the environment variable for TOOL_NAME to yowasp-tool-name so that Amaranth will use the YoWASP binary instead of he Yosys binary.
Otherwise, increment the problem count.

If the problem count is zero, return and continue to the build.
If the problem count is non-zero output a helpful message and continue to the build anyway. (The build could still succeed anyway if someone is using a strange or unusual toolchain.)

Nice!
You could further make this more robust by using {sys.executable} -m yowasp_yosys instead of yowasp-yosys. Now it does not depend on PATH at all, and works when launched out of a virtualenv that is not activated.


[CT-1072] Snapshot "Invalid empty identifier" error

Describe the bug
I'm trying to create a snapshot and I get this error from dbt:
Database Error in snapshot shipment_snapshot (snapshots/shipment_snapshot.sql)
Syntax error: Invalid empty identifier at [5:34]
Steps To Reproduce
Create a snapshot like this:
{% snapshot shipment_snapshot %}
{{
    config(
      target_schema='sales_v2',
      strategy='timestamp',
      unique_key='id',
      updated_at='_fivetran_synced',
      invalidate_hard_deletes=True,
    )
}}

select * from {{ source('sales', 'shipment') }}

The one perhaps slightly odd thing about this is the target and the destination schemas are different.
The exact schema of the table probably doesn't matter as I tried it on 12 different tables.
Expected behavior
The snapshot worked the first time and populates data, but fails on all following attempts with the above error.
Screenshots and log output
I captured this SQL in Bigquery, which is obviously invalid and the source of the empty identifier error.
drop view
if exists stage..stage.sales_v2.shipment_snapshot__dbt_tmp``
System information
The output of dbt --version:
Running with dbt=1.1.0
The operating system you're using:
Linux-5.10.0-16-cloud-amd64-x86_64-with-glibc2.2.5
The output of python --version:
3.8.13
Additional context
That is all.

Hi @brooks-j, thanks for the detailed info.
I wasn't able to reproduce the issue, with dbt-bigquery 1.1.0, core 1.1.2.
Can you please confirm I have the setup right:
On the BigQuery side:

schema/dataset : sales

table: shipment

schema/dataset: sales_v2

table:  shipment_snapshot

On the dbt side:

A source, sales.shipment - Would you mind sharing your source yml declaration by the way?
A snapshot, shipment_snapshot reading from source('sales','shipment')

I have a project with just that, and no problem to dbt run, snapshot or build.
Looking at the logs, what's happening is dbt is generating a temporary view to refresh the snapshot, running a merge on that view, then removing the view. That temporary view is created on the destination schema (sales_v2) for you, so I'm not sure the drop view message you highlighted is relevant here.

You need to run it twice.  The first time works, the second time doesn't.  Did you run the snapshot twice?  The drop view is relevant as this is the source of the "Invalid empty identifier" error and the drop view statement is obviously incorrect.
stage..stage.sales_v2.shipment_snapshot__dbt_tmp
This has five elements between the dots, and Bigquery (along with other DBs I know) only supports three.  Also note the "..", or empty identifier, which is exactly the error dbt is producing.
The shipment_snapshot code can be found above.
Here is the landing.yaml for the shipment table.
- name: shipment
    columns:
      - name: id
      - name: _fivetran_synced
      - name: blood_glucose_check_frequency_c
      - name: blood_pressure_check_frequency_c
      - name: contact_c
      - name: created_by_id
      - name: created_date
      - name: enrollment_c
      - name: enrollment_document_set_c
      - name: follow_up_visit_c
      - name: follow_up_visit_other_c
      - name: is_closed_send_starter_kit_c
      - name: is_deleted
      - name: last_activity_date
      - name: last_modified_by_id
      - name: last_modified_date
      - name: name
      - name: onboarding_code_c
      - name: original_case_send_starter_kit_id_c
      - name: owner_id
      - name: patient_requires_bp_cuff_c
      - name: patient_requires_xl_bp_cuff_c
      - name: patient_requires_xl_scale_c
      - name: scale_id_c
      - name: shipping_city_c
      - name: shipping_postal_code_c
      - name: shipping_state_code_c
      - name: shipping_street_1_c
      - name: shipping_street_2_c
      - name: system_modstamp
      - name: tracking_number_shipping_c
      - name: unformatted_address_c

I'm wondering if this couldn't be a difference in version on dbt-bigquery and not core. My output of dbt --version looks like the following:
Core:
  - installed: 1.1.2
  - latest:    1.2.1 - Update available!

  Your version of dbt-core is out of date!
  You can find instructions for upgrading here:
  https://docs.getdbt.com/docs/installation

Plugins:
  - bigquery: 1.1.0 - Update available!

On my side, here's the drop command that's get generated (\logs\dbt.log\), even if I run dbt snapshot 10 times:
drop table if exists `dbt-project`.`dbt_dataset`.`snapshot_records__dbt_tmp`

Also, are you using dbt-external-tables here?

In the our pipfile there this is set:
dbt-bigquery = "~=1.1"
But in our requirements.txt for our tests we set this:
dbt-bigquery~=1.0.0
This is a bit odd.  I'll look into this further.

Hey @brooks-j, any update on that one?
I'll close it in the coming days if I don't hear back, you can always re-open later ;)


Switch to using tox for calling json docs update script

My oversight, this fails outside of tox because it doesn't have some of the deps installed.

LGTM


fido2luks: 0.2.19 -> 0.2.20, allow discards

Description of changes
Fido2luks 0.2.20 adds a new option --allow-discards. This PR upgrades fido2luks, and also updates the Nixos module to pass --allow-discards when the corresponding allowDiscards setting is true.
Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Please change commit message from allow discards with fido2luks to fido2luks: pass allow discards option

The second commit is touching the luksroot Nixos module, not the fido2luks package, so maybe I should prefix the commit message with nixos/luksroot: ?

The second commit is touching the luksroot Nixos module, not the fido2luks package, so maybe I should prefix the commit message with nixos/luksroot: ?

Yes, please.

I amended the second commit to add a nixos/luksroot: prefix to the commit message.


samsung s8 return true for not rooted device

i have used rootBeer.isRooted() method it return true for non rooted device  SAMSUNG S8

Can you provide some logs with the filter - "RootBeer"?

In the upcoming release we've removed busybox from the default root checks, this should hopefully fix many of the problems with false positives. I'm closing this issue but please re-open if you get a false positive with 0.0.8 onwards.
Thanks!


Bump up envoy version to v1.17.0

Description:
Update Envoy Proxy version for grpc-web to 1.17.0.
We are using envoy 1.14.1 and some settings will be deprecated.
[2021-08-14 03:04:25.265][8][warning][misc] [source/common/protobuf/utility.cc:198] Using deprecated option 'envoy.api.v2.listener.Filter.config' from file listener_components.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2021-08-14 03:04:25.265][8][warning][misc] [source/common/protobuf/utility.cc:198] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cluster.proto. This configuration will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.

...

[2021-08-14 03:04:25.268][8][warning][misc] [bazel-out/k8-opt/bin/source/extensions/common/_virtual_includes/utility_lib/extensions/common/utility.h:65] Using deprecated extension name 'envoy.http_connection_manager' for 'envoy.filters.network.http_connection_manager'. This name will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2021-08-14 03:04:25.271][8][warning][misc] [bazel-out/k8-opt/bin/source/extensions/common/_virtual_includes/utility_lib/extensions/common/utility.h:65] Using deprecated extension name 'envoy.grpc_web' for 'envoy.filters.http.grpc_web'. This name will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2021-08-14 03:04:25.271][8][warning][misc] [bazel-out/k8-opt/bin/source/extensions/common/_virtual_includes/utility_lib/extensions/common/utility.h:65] Using deprecated extension name 'envoy.cors' for 'envoy.filters.http.cors'. This name will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.
[2021-08-14 03:04:25.271][8][warning][misc] [bazel-out/k8-opt/bin/source/extensions/common/_virtual_includes/utility_lib/extensions/common/utility.h:65] Using deprecated extension name 'envoy.router' for 'envoy.filters.http.router'. This name will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated for details.

grpc-web updated envoy version to 1.17.0 in Jan of this year.
Why:

Keep our code up to date.

I'm interested in this issue. Can I work on it?
latest version of Envoy is 1.19.0. So should I update it to 1.19.0 instead of 1.17.0?

@blurfx Sure.
The version tested by grpc-web was 1.17.0. If possible, it would be ok to update to 1.19.0.
https://github.com/grpc/grpc-web/commit/6b046c2fabc67c7a0bdbd7640ef82ce704ad1846


Add support for multiple more parameterization concepts, but make it a QA to select which ones users want

Related https://github.com/konveyor/move2kube/issues/137


Traefik cannot connect to containers on other servers in rancher HA environment

What version of Traefik are you using (traefik version)?
v.1.2.0-rc2
What is your environment & configuration (arguments, toml...)?
traefik docker with --web --rancher --rancher.domain --rancher.accesskey --rancher.secretkey as stack in rancher
rancher in HA and running agents on all multiple servers
What did you do?
load balancing containers
What did you expect to see?
able to access the container
What did you see instead?
I can only access to the container when it is on the same server as traefik, but when the container is not on the same server, it can't access.
but the ip register on traefik dashboard without issues.
Can someone test this scenario as well? thanks.

Could you please paste the log output when running in debug mode (set the --debug switch)? Thanks.

I find out is actually the ipsec on rancher server goes into a state where I can't ping the internal ip of the other servers. I don't think is a problem now. thanks


docs: Defaulting

This Proposal fills a gap between KubeVirt as Runtime and Higher level management, like proposed in #272. Without the necessity for asynchronous specification updates, we come much closer to the meaning of a Pod specification in Kubernetes, but most important, this allows decoupling administrative tasks completely from the runtime (the need to run VMs, to get a full VM spec), when manipulating VM Specs.

In PR 287, we make a distinction between expansion and defaulting. https://github.com/kubevirt/kubevirt/pull/287
In this PR it appears expansion and defaulting are just referred to as defaulting. I'm a little confused by the terminology.

@davidvossel While there can be other admission controllers (https://kubernetes.io/docs/admin/admission-controllers/) later (e.g. flavours, presets, ...), and they all do some expansion, this one would be the first controller, which expands the spec.
Some thoughts about differences to #287:

This is purely about runtime
In the context of the VM POST/PUT call, this defaulting would be the first admission controller we have . In that context it gives you a fully, with defaults populated spec, as the direct response from the creation of the VM in the runtime.
The dedicated REST endpoint would allow this or more admission controller to expand the config without the need to run it.

Does that answer why this defaulting talks about expansion?

@davidvossel While there can be other admission controllers (https://kubernetes.io/docs/admin/admission-controllers/) later (e.g. flavours, presets, ...), and they all do some expansion, this one would be the first controller, which expands the spec.

Does that answer why this defaulting talks about expansion? I didn't have the time to properly look into #287. It was added after this one.

expansion in #287 is defined as the process of adding required dependencies to the spec. Defaulting is defined as adding a default device for something in the spec.
In this pull request, I'm not seeing consistent language used based on the definitions in #287.  Defaulting and expansion appear to be separate concepts, but this PR appears to be wrapping the "expansion" process into "defaulting".  Our terminology here is confusing. (maybe it's just me?)

@davidvossel

One issue I'm encountering with this proposal is that I understand the concepts of what is being proposed here, but the mechanics of exactly what objects are being worked on are not obvious to me.

This proposal only knows about VMs, I will try to better describe it, but the two options talk about VMs exclusively. The VirtualMachineConfig in #272 is not part of the runtime (will probably not even be in the same git repo). It is not clear to me what #287 tries to achieve (if it tries to solve things for the runtime or for the external VM store). At the current stage the config is an alternative to storing your VMs for instance in git. The VM config/VM store is more comparable to helm or the service-catalog.

I have now a better understanding about the terminology in #287 and will try to incorporate it here, to make it better understandable where this admission controller would fit in in a set of additional admission controllers.

Added implementation details, and explain how this admission-controller would work in a stack of admission controllers.

Removed the more advanced use case, and added additional descriptions. It should now be more focused and easier to understand why it is there. Please have another look.

@fabiand
Thx for the detailed feedback.

But I'm concerned about the how - In previous proposals we clarified that the cluster level VM API must not (directly) contain host specific resources, and thus we decided that the cluster level VM representation can not be equal to the libvirt domain XML, it can not even be a true subset.
This and some hints in the proposal (i.e. to ignore certain fields, or use dummy values, to map back certain abstractions) raises my concerns that using libvirt for defaulting is the right approach.

I really think that "abstractions" on the VM spec, which are front end configurations, should be expanded/filled by admission controllers before they ever reach etcd. Like with Pods. I would prefer if we only delay the resolution for backend configurations (network, disk). There it makes sense to delay it until the host is involved.
I am open for not using libvirt for this. The main reason is, that at the end always libvirt does this, and we need to cope with things filled values by libvirt in every scenario anyway. At the end, if you put the right admission controllers before this admission controller, it will change exactly nothing on a VM.

I rather wonder if we can not address the problems individually.
I.e. we could work out a way to be able to achieve a 1:1 mapping between VM API and domxml devices to support the hotplug case. It sounds as if the ordering of the devices is more important than their addresses, this might help to find a solution.

We can aim for such simplifications where possible, but in the end this always only works good, when you restrict the user. If you want to allow things like, for device A the user sets the addresses, but not for device B, then the result is not as clear, since libvirt (or our defaulter) would have to take that into account.

And if we look at the defaulting part of the proposal, then I do not see any way how we could leverage the proposed mechanism to take i.e. values from libosinfo into account to produce OS tuned hardware configurations. IOW I'd rather like to see on the cluster level that we workout a mechanism which has sane defaults, but can also take informations from sources like libosinfo to create specific tuned hardware configurations. And here I think that we need logic like virt-manager has.

Yes, it is not aiming  for that. A libosinfo admission controller would be invoked before this one. Every libosinfo/preset/virt-xml/... layer will need to be constructed in a way, that it produces reasonable domain xmls, which libvirt would always expand/fill/default in the end. No matter if we have it on the cluster too.

Btw: I'd still assume that the libvirt defaulting will still happen to some degree on the node, transparently to kubevirt.

Yes, and we should aim for that this only happens in a way that we don't have to propagate it to the VM status for most cases. Anyway, values set there should never change what the Guest OS can see (to simplify for users how to use KubeVirt, not because it is not possible), if they are also part of the VM Specification.

And if we look at the defaulting part of the proposal, then I do not see any way how we could leverage the proposed mechanism to take i.e. values from libosinfo into account to produce OS tuned hardware configurations

Just because I have read this confusion now more than once from different people (probably also because of my lack to express everything properly): This libvirt admission controller here, really is just the last admission controller invoked in a row of possible admission controllers. It shall only do in a synchronous way on a post for the frontend VM configuration, what otherwise the host libvirt would inevitably do.

I am open for not using libvirt for this. The main reason is, that at the end always libvirt does this, and we need to cope with things filled values by libvirt in every scenario anyway. At the end, if you put the right admission controllers before this admission controller, it will change exactly nothing on a VM.

"changing nothing on a VM" depends on what we represent in the VM object. I.e. if we do not represent bus addresses, then defaulting performed by libvirt might not even influence the VM API representation.
And it's a question if we want to expose bus addresses. I had the impression that they might not be needed, as long as we can still identify devices.

This libvirt admission controller here, really is just the last admission controller invoked in a row of possible admission controllers. It shall only do synchronous on a post for the frontend VM configuration, what otherwise the host libvirt would inevitably do.

And after all this talks, I'm now wondering if we need this last defaulting on the cluster level.
IIUIC then this proposal - in the end - would be limited to default addresses and models and missing device dependencies.
For the addresses - It sounds (when speaking to @michalskrivanek and @berrange) that they might not be needed to be exposed on the cluster level.
For models and device dependencies - If they are not specified, then we need a VM API / cluster level logic to default them in an informed way, which is tuned towards the VM API.
And if we have this cluster level VM API aware defaulting mechanism, then I do not see a strong reason for this libvirt based approach on the cluster level, because it defaults fields which are not represented (addresses) or fields which should be defaulted by another component anyway (models and device deps).
My take away is that we need to think about what we want to expose in the VM API. Then we'll see what we need to extend. I also see that there is agreement that we need defaulting on the cluster level, and that there will be defaultin gon the node level which is not (necessarily) propagated back.
As said earlier - for the hot-plugging case I could imagine that we find a different solution to have a stable device order and adressing, which does not involve to expose the addresses on the VM API.

Sure, if nothing which libvirt can default for the front-end configuration, is exposed or needs to be propagated back, it does not make sense to have it.

For the addresses - It sounds (when speaking to @michalskrivanek and @berrange) that they might not be needed to be exposed on the cluster level.

@fabiand is there anymore information you can provide here about that conversation?
@rmohr  It's possible we've taken too broad of an approach by calling this "libvirt" defaulting. Maybe we should just figure out exactly what the bare minimum amount of information is we need to fill into a VM spec for us to be able to migrate something like Windows. From there we'd build a defaulting admission controller that begins injecting just those parts.

For the addresses - It sounds (when speaking to @michalskrivanek and @berrange) that they might not be needed to be exposed on the cluster level.
@fabiand is there anymore information you can provide here about that conversation?

The main outcome of this discussions was that the ordering and identity/addressability of devices is important, but that addresses are not necessarily needed for this.
There should be some more talks to really get all the details.

Closing this according to the previous comments.

You can close it. But that was not the outcome. The outcome was that it might be possible. It is not yet clear how that influences our spec. @michalskrivanek you promised to look into this?

If it is not possible we will need something like this, no matter if libvirt does it or not.

yep. can we add #needsresearch label perhaps?

#370 can now be used to track different pieces of the problem.


fix(events-backend): passes unparsed request body to validators

Hey, I just made a Pull Request!

This is in efforts to fix #26708. It passes the raw request body to validator functions to do correct signature validation.
I'm not sure the best way to test this, does anyone know the best way to test local changes on a backstage instance?
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Another point:
The signature validator for GitHub from @backstage/plugins-events-backend-module-github executes
JSON.stringify(request.body)

which would stringify the "raw body".
Maybe, something like a raw body additionally would make more sense. Even as bytes vs string.
Changing body from object to string (despite being of type unknown) would be a breaking change.
A change add the current consumers of this information seems required. With the raw body, you could limit it to those where it is relevant.

Another point: The signature validator for GitHub from @backstage/plugins-events-backend-module-github executes
JSON.stringify(request.body)

which would stringify the "raw body".
Maybe, something like a raw body additionally would make more sense. Even as bytes vs string. Changing body from object to string (despite being of type unknown) would be a breaking change.
A change add the current consumers of this information seems required. With the raw body, you could limit it to those where it is relevant.

Thanks for the look @pjungermann. Yeah this initial try didn't work, I'm forgetting exactly why though.
Is there an easy way to test local changes across a couple of modules? I was getting a bit blocked on easily testing this by actually sending events to a backstage instance with the changes to make sure this works.

When trying your changes locally and seeing the issue with the content types and the default middleware getting applied, I started to take a stab myself to get the raw body. This part was reproducible with the tests.
By now, I found a working setup and I would create a PR with that suggested change. I've added a test with the differences in transmitted JSON string vs parsed and re-stringified JSON based on your issue as well.

When trying your changes locally and seeing the issue with the content types and the default middleware getting applied, I started to take a stab myself to get the raw body. This part was reproducible with the tests.
By now, I found a working setup and I would create a PR with that suggested change. I've added a test with the differences in transmitted JSON string vs parsed and re-stringified JSON based on your issue as well.

Awesome, thanks for jumping in here. I'm going to close this PR in favor of #27121


ChatGPT dosen’t work.

Describe the issue
ChatGPT app doesn’t work. I cann’t login and show the pop up error.
Instructions to reproduce
ChatGPT app doesn’t work. I cann’t login and show the pop up error.

What version of LiveContainer are you using?
2.1.2
Other
No response

ChatGPT has some sort of sideload detection since you can't even login when it is sideloaded. You may need to find a tweak to bypass that detection.


Remove redundant task system message and early return affecting FSPs (fix #192490)

This PR fixes #192490
At the time #168209 fixed #164051_computeTasksForSingleConfig permitted workspaceFolder to be passed undefined. Since https://github.com/microsoft/vscode/commit/42e9acc5a8efae6150f49926221171ca8f93ad54 that is no longer the case, so I have removed what #168209 added, which in any case was incorrect as it adversely impacted FileSystemProviders (their schemas don't have dedicated task systems).

/assign @meganrogge

Thank you @gjsjohnmurray


Update scala-library to 2.13.12

About this PR
📦 Updates org.scala-lang:scala-library from 2.12.18 to 2.13.12
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

💡 Applied Scalafix Migrations

org.scala-lang:{scala-library,scala-compiler,scala-reflect,scalap}:2.13.0 (created no change)

dependency:Collection213Upgrade@org.scala-lang.modules:scala-collection-migrations:2.8.1
Documentation: https://github.com/scala/scala-collection-compat#collection213upgrade

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala-library" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, scalafix-migrations, commit-count:n:2

Closing PR since we are not meant to be updating the major/minor Scala versions, PR to fix this is at https://github.com/sbt/sbt-osgi/pull/110


fix: bump dependencies to avoid vulnerability alerts

This PR contains a few changes to our dependency versions to avoid vulnerability alerts.
I also removed the contents of the .cveignore file since that is no longer needed.
Checklist

[x] npm test passes (tip: npm run lint-fix can correct most style issues)
[x] tests are included
[ ] documentation is changed or added

:tada: This PR is included in version 2.17.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Remote rendering problem] Quest2: only artifacts showing

Describe the problem
On Quest2, once the rendering has started I only see a square with small blocks/artifacts in the area where the model is placed.
I suspect there's a problem with the video feed, but I don't know what. Any insights on what I could try are appreciated.
Here's a videoclip of the problem with the default engine: https://youtube.com/shorts/F59SuC-i54I

Hey @jelmer3000,
sorry to hear you are experiencing some issues with Azure Remote Rendering. To help you out and to reproduce the issue on our side, we need some more details. Can you provide the following information:

Unity Version (I'm assuming you are using Unity)
Unity Render Pipeline (Builtin/Legacy, Universal, HD) and its version
Azure Remote Rendering Version
MSAA settings

Ah, I see you have updated your post and provided a video. Awesome!
I see you are using our Showcase sample. Did you upgrade it to Unity 2021 or later?
Unfortunately, there's a bug in Unitys built-in render pipeline with later Unity versions: Unity Issue Tracker - MSAA is not applied on Quest 2 using Built-In Render Pipeline and Vulkan
That bug creates exactly such artefacts you are seeing.

Hey thanks for looking into this. My main goal is to just get the showcase example to work on a Quest 2.
At first I tried with:

Unity 2021.3.20
Standard Render Pipeline
ARR 1.2.10
4 x AA
Graphics API: tried Vulkan and Auto
Color Space: tried Linear and Gamma
Today I also tried:
Unity 2021.3.20
URP (converted the materials, and used the MRTK conversion tool for upgrading the MRTK shaders).
Using the HybridRenderingPipeline asset from the ARR package, tried with MSAA off and with MSAA 4X.
ARR 1.2.10
Graphics API: Vulkan
Color Space: Linear

In all cases it looks like AA was NOT active, as edges were jerky. And in all cases I got the same video afrtifacts. But is that really related the video issues?
All in all what would you recommend? In the documentation it says that URP is not recommended because of performance reasons. I could upgrade to Unity 2022, or downgrade.. It would be nice if the showcase just works ;)

Thanks, I got it working with 2020.3 and the built-in rendering pipeline.
I also tried 2022.3 but somehow the internet connection wouldn't work there..
It's great that it now works, but it's worrying (for any custom developed app) that I couldn't get it working on recent unity versions with URP.


feat: latest news feed #312

@akashsiddamshetty thank you for the excellent work! 🚀
I will merge this very soon - it is dependency upon NewsFeed items in the backend in order to render anything. I will create a sub task for this work.


Play in different time periods

I think it would be a great feature to allow players to play in different time periods. This is related to #37, but not a solution to it entirely. For example, you could play solely within:

The Middle Ages
PreHistory
20th Century
Industrial Era -> Present
The Renaissance or The Age of (European) Discovery
Classical Era/Antiquity

Based on my experiences and some of the feedback here, I believe this might make the game more approachable by narrowing the period one would need to know about. I think your periods could still be chunked within these periods to create a good spread. Would it make sense to simply divide the periods by 4 equally, or hard-code specific values within those periods?
I'd be happy to make a PR and take this feature on. Despite how bad I am, I think it's a blast and shows a lot of promise. Thank you!

I don't think this is ready for a PR. Whilst the basic idea is easy enough, the difficult part is creating a good UI for different game modes. How that would work and what different game modes should exist requires more though. Plus writing the generation code for different game modes will require a lot of work.

I like the idea though :slightly_smiling_face:


feature.enabled? through API

Double checking here as I could not find a way to verify if a feature is enabled for a user through the API. Is this something you are planning on implementing?

@helaili There isn't an endpoint you can, for example, pass a flipper_id and get a response telling you if that thing is enabled.  If you're curious you could check out how Flipper determines this https://github.com/jnunemaker/flipper/blob/master/lib/flipper/feature.rb#L82.
I don't see the api supporting this in the future and think a project using Flipper could add this as their own custom endpoint.  Curious, how are you consuming the api?  If the app talking to the api is using Flipper you could use the http adapter and use flipper.enabled?(user)  ?

@helaili I agree with @AlexWheeler. The easiest way currently would be to use the http adapter. The key is just to ensure the uri is set like in the tests.
I'm closing this to keep issues tidy, but @AlexWheeler and I are happy to answer more questions here if you have any.

Thanks guys, I've been able to come close to a good solution with your help.
@AlexWheeler, as said in jnunemaker/flipper#246 I'm trying to leverage Flipper from a Node.js app. Therefore I have embedded Flipper in a simpler Rails app and I'm now exposing a REST endpoint to wrap the feature.enabled? code.

@helaili oh neat. I forgot that, sorry. If I were you I would add a single route that passes a flipper_id and returns true/false. I wonder if enough people would find that useful for us to provide a simple rack middleware which does so...
I think the key if you are going to expose this data across platforms is that you either have some sort of authentication/authorization or only expose a read-only endpoint.
Something ala this could work for a read-only endpoint (never executed, just whipped together):
class FlipperEnabledMiddleware
  class FlipperActor
    attr_reader :flipper_id

    def initialize(flipper_id)
      @flipper_id = flipper_id
    end
  end

  def initialize(app, flipper)
    @app = app
    @flipper = flipper
  end

  def call(env)
    request = Rack::Request.new(env)

    if request.path == "/flipper-enabled"
      headers = {"Content-Type" => "application/json"}
      flipper_id = request.params["flipper_id"]
      enabled = if flipper_id.nil? || flipper_id.empty?
        false
      else
        @flipper.enabled?(FlipperActor.new(flipper_id))
      end

      body = JSON.generate({enabled: enabled})
      [200, headers, [body]]
    else
      @app.call(env)
    end
  end
end

use FlipperEnabledMiddleware, SomeApp.flipper

The downside of this is that, without injecting some sort of authentication/authorization in the endpoint, someone could hammer your endpoint with flipper id's to figure out what features exist and who they are enabled for.
Also, FWIW, I plan on re-making flipper for other languages and node is on my list, but I have no idea when I'll actually get time. My big dream is flipper for each language with http adapters that talk to a central API like we currently have and you are attempting to use.


cover_or_fail! macro

This PR adds a cover_or_fail! macro to Kani. This macro has the same functionality as the existing cover! macro, except it causes verification to fail when the outcome is unsatisfiable or unreachable.
Currently, a caller can invoke this macro from anywhere in their code (not just harnesses), which is also true for cover. However, we only analyze reachability starting from a given proof harness (the entry point), so if the cover_or_fail call is contained inside a function that the harness does not call, the verification will succeed even though the call actually is not covered. I'm concerned that this behavior will produce confusing results for users. Specifically, see the test cases inside cover-unreachable-outside-harness-pass (which pass verification) and cover-unreachable-outside-harness-fail (which fail verification). See also the discussion of this issue here. Is this the behavior that we want?
Our options are:

Leave the implementation like this, with clear documentation of the reachability behavior. The benefit of this design is that users can more easily use cover_or_fail throughout their code for debugging.
Add a pass which scans the entire crate for calls to cover_or_fail and makes sure that CBMC marked them all as reachable. This allows using cover_or_fail throughout the codebase and avoids any confusing reachability behavior, but may be slow.
Restrict calls to cover_or_fail to proof harnesses only. This approach solves the reachability issue, since CBMC will see every call to cover_or_fail, but does restrict users--the author of the issue that prompted this PR, for example, wanted to use it outside of a proof harness.

I'm leaning toward #1 or #3, but curious to hear others' thoughts.
Resolves #2792
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Thanks @carolynzech for this! It's nice to finally see a concrete implementation for this feature.
I do have some thoughts about it too. I suppose you know about the very related option --fail-uncoverable which essentially converts all cover! macros into something like this. The proposal was added to the RFC: Cover statement in #2967 but we didn't get to finish the implementation in #2532 (#2967 in particular had a nice discussion based on theoretical implementations of the cover_or_fail! macro 😄 ). This is mostly to say that the cover_or_fail! macro can be implemented in a number of ways, and we won't know which option is the best without user feedback. We can try to guess which one is the best though.
In my opinion, option 3 would restrict too much the usage for the macro to be useful. Option 1 seems fine to me and it's the same we were doing for --fail-uncoverable. But I'm wondering now: Can we do better? Maybe we could something like a mix of options 1 and 2 where (1) we scan the codebase and emit a warning for each cover_or_fail! macro that is going to get sliced away and (2) perform the analysis as it's being proposed in option 1. However, I'm not sure this option would be acceptable if we need to add another compiler pass just for it - it would be a noticeable overhead even when users don't have any cover_or_fail! macros in their code. What do you think?

I suppose you know about the very related option --fail-uncoverable which essentially converts all cover! macros into something like this.

Yes, I did see that. This implementation is subtly different in that it allows users to mix and match cover! with cover_or_fail!, rather than use a flag to force all covers to become failures. That might be nice for debugging if a user just wants to focus on a few failing cover statements at a time, rather than get a wall of output for all of the cover statements. In practice, it's probably not a huge difference, and the command line flag would have the benefit of reducing some of the code duplication between cover/cover_or_fail that we see here.

In my opinion, option 3 would restrict too much the usage for the macro to be useful.

I would tend to agree--it's a less messy solution for sure, but that's moot if it doesn't help users in the first place.

Maybe we could something like a mix of options 1 and 2 where (1) we scan the codebase and emit a warning for each cover_or_fail! macro that is going to get sliced away and (2) perform the analysis as it's being proposed in option 1. However, I'm not sure this option would be acceptable if we need to add another compiler pass just for it - it would be a noticeable overhead even when users don't have any cover_or_fail! macros in their code. What do you think?

If I imagine myself as a user of Kani unfamiliar with the implementation, I would expect that if I put cover_or_fail throughout my code and verification succeeded, Kani found all those statements to be reachable from the harness. My concern is that users won't read the fine print re: slicing and take the successful verification to mean something it doesn't.
However, your performance point is well-taken--we don't expect people to use this macro that often, so doing a whole extra pass just to check for it seems like a waste. Perhaps we flip the order of your proposed steps--by default, we do (2) and do the analysis as proposed in option 1, but offer a --comprehensive flag that will do (1). Additionally, for each cover_or_fail that we do see, if we detect that --comprehensive was not passed, we can emit a warning suggesting it. This of course does not help in the case that no cover statements were detected in the first place, but (hopefully) the user is more likely to notice that anyway. I think this warning would cover the more common human error case where a few cover statements of many were not analyzed and the user doesn't notice.

Perhaps we flip the order of your proposed steps--by default, we do (2) and do the analysis as proposed in option 1, but offer a --comprehensive flag that will do (1). Additionally, for each cover_or_fail that we do see, if we detect that --comprehensive was not passed, we can emit a warning suggesting it. This of course does not help in the case that no cover statements were detected in the first place, but (hopefully) the user is more likely to notice that anyway. I think this warning would cover the more common human error case where a few cover statements of many were not analyzed and the user doesn't notice.

If we are going to have an option that warns about cover_or_fail!s being left out, we might as well error out instead. That will make sure the user notices 😆 In fact, I believe that's the main thing users want out of this feature: if some line of code stops being verified for whatever reason, they want to know. Warnings will likely go unnoticed, so they would not know.
I'd be happy with a feature like that. We need to make sure the reachability caveat is well documented, and I'd probably use a more detailed name for the flag, but the rest sounds good to me.

Closing for now; this feature requires further design discussion.


Fix spelling mistake in some sequences

Some snoRNAs are called Homo sapians should be Homo sapiens. This is an issue from the providing database so we need to fix it when importing. We can also fix it in the database if it would be too much to reimport the database in question.

Tracked this down to GeneCards import having the wrong spelling. Fixed the spelling manually in the database, but I also intend to re-import GeneCards so will keep an eye on this to see if it regresses

This is still fixed in the test site, so should be resolved when the release is made


[Task]: Basic setup for Design System repository

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks

[ ] Rollup set up
[ ] NPM packaging set up
[ ] ESlint configurations
[ ] Yarn workspace configuration
[ ] Babel configurations
[ ] NPM account set up

Closing this issue. All progress will be tracked at https://github.com/appsmithorg/appsmith/issues/14402
cc @albinAppsmith


Fix error when kml descriptions have tags with missing url attribtues.

Hi team,
This PR fixes a small issue where  Cesium throws an unexpected error when trying to load a kml/kmz file containing html tags with a missing url attribute. Example: KML with script/img tag with missing src attribute.
This fix will correctly handle the null values returned from element.getAttribute() calls.
Testing
Before:

Open this public sandcastle link that loads a KMZ file
Observe that data is not rendered on the map
The console also shows the errors

After:

Open this local sandcastle link for this branch
Observe that the data is rendered correctly without errors

Thanks in advance.
Please let me know if I need to make any changes to the PR.
Cheers,
Nanda

Thanks for the pull request @na9da!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

Thanks for the fix @na9da!


Add several CLI tools for sending data to honeycomb.io

Motivation for this change
Adds a few utility CLI tools for exporting data to the honeycomb.io tracing/event ingestion service.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg build honeymarker honeytail honeyvent


Update URL of "SuplaDevice"

Companion to https://github.com/arduino/library-registry/pull/1634

2022/08/03 15:31:59 Loaded 5057 libraries from DB
Changing URL of library SuplaDevice from https://github.com/SUPLA/supla-arduino.git to https://github.com/SUPLA/supla-device.git
Success!

Done!


Support // spec prefix for http(s) shorthand in JS

I propose supporting // as shorthand for http:// or https:// in the JS spec, where the scheme is given by the current page's protocol.
I.e. a URL like https://perf.noms.io/?ds=//demo.noms.io/perf::master/csv-import is equivalent to https://perf.noms.io/?ds=https://demo.noms.io/perf::master/csv-import and likewise http://.../?ds=//demo.noms.io/... is equivalent to http://.../?ds=http://demo.noms.io/....
Rationale:

More convenient than typing http(s) in URLs. Similar to how we don't require the ldb: prefix in the Go SDK.
Automatically consistent http vs https. Chrome doesn't like crossing the schemes.

The spec code would need to ignore this if it's running in Node, of course.
@arv @aboodman opinions?

Seems reasonable to me

Gotta be honest, Im not a fan of these kind of micro-shortcuts. To me, the complexity of having to understand these extra cases doesn't pay for the value of not having to type 'http[s]:', especially since in JS, the common case is that the spec is going to be in a constant somewhere and typed once, not over and over.

the spec is going to be in a constant somewhere and typed once, not over and over

This isn't true in 100% of our web samples: perf, splore, and bar-chart. They all take the DB as a URL param. I am consistently accidentally typing in https instead of http and vice versa, and the failure case is a white screen.
This was actually the motivation for filing this issue, the convenience is a nice side-effect. I expect code that hard-codes its database will look like:
const DB = '//demo.noms.io';
...
let db = location.protocol + DB;

Why not always type https?

I think in any case we should probably hold on this until @ehalpern's stuff is done since that will probably change how we interact with specs on the command line.

Drive by comment - // reminds me of a samba mount, which might be \\ but is sometimes flipped depending on if you are on Microsoft Windows or on a *nix platform.
Not specifically for this reason, but I am mostly against // shorthand for http[s]. It is better to specify exactly what you want than have magic occur. What if http://foo and https://foo are different? Craziness.
I would also stipulate that perf and splore are not normal cases for JavaScript apps.

@mikegray //server.com/ is a valid relative URL. It is commonly used on the web to preserve the protocol.
However, I think @aboodman convinced me that we do not need this extra complication at this point.
@kalman We should make these apps report user visible errors when the input data is not correct.

We should make these apps report user visible errors when the input data is not correct

AFAIK there is no way for an application to catch when chrome blocks a connection due to mismatching http/https schemes.

Why not always type https

Hm ok well if there is no issue (warnings, errors) fetching from https URLs from an http page then yes this would be fine

Fetching https from http always work. The other direction does not work.

AFAIK there is no way for an application to catch when chrome blocks a connection due to mismatching http/https schemes.

I'm pretty sure you get an exception with XHR and rejected promise with fetch.

I'm pretty sure you get an exception with XHR and rejected promise with fetch.

I hope it's plumbed up from the chunk store then.


[CHG] added ShowPropertyPage method to DirectShowDevice class

Hi, I had the necessity to show the native dialog of the DirectShow source filter in the UI, see also:
https://learn.microsoft.com/en-us/windows/win32/directshow/displaying-a-filters-property-pages

Some vendors (like here Blackmagic WDM Capture filter) offer some important settings in those property pages:

I also extended the WPF sample with some buttons and a dropdown to select the source from:

Not sure if this can be merged back to the main repository in terms of coding standard :)

@flat-eric147 Can I separate and merge only the modification of the transcoder option?

@flat-eric147 Can I separate and merge only the modification of the transcoder option?
The current implementation understands that transcoder is always Auto by the following line:
                            BitmapTranscoder.Transcode(
                                pBih->biWidth, pBih->biHeight,
                                pBih->biCompression, YUV2RGBConversionStandard.Auto, true,    // Always `Auto`
                                pImageContainer + pBfh->bfOffBits,
                                pTranscodedImageContainer + pBfhTo->bfOffBits);

I think we need to make minor modifications in various places to get the information from here to the public interface transcodeIfYUV flag. This is being tested in my trial implementation (a0a894f). In the meantime, I will fill in the last piece after I merge your results.

Yes, it  makes sense to expose it to the public interface, but I prefer to leave that work to you as you know better than me what to do and where to do it. I'm also unsure about the performFullRange parameter which was unused before. Please merge whatever you think makes sense, I'm happy with anything you merge back. Let me know if you need anything do to from my side. Thank you!

@flat-eric147 Cherry-picked your YUV transcode fragment and merged extended interface into 295de1575d263001b9a077b0bf6cb5020a2d2e4d . Please verify it and modify when a desirable pattern can be considered.

Option enum type renamed to TranscodeFormats .
In TranscodeFromYUVInternal():

Could it be that the logical decision for each full range/limited range is the other way around? (good if not a problem)
BT.609 did not have one of the range checking, so the enumeration type is not extended either (BT609FullRange is not defined).

transcode.patch
Hi, I attach a patch since I cannot push to the original repository and I don't know how to sync the new branch into my forked repository.

Could it be that the logical decision for each full range/limited range is the other way around? (good if not a problem)

yes, I am unsure how to put that logic, feel free to change it!

BT.609 did not have one of the range checking, so the enumeration type is not extended either (BT609FullRange is not defined).

Just added it. It was there implicitly with the default initial values of the multiplier variables. Made it more explicit and readable now.

Hi, I attach a patch since I cannot push to the original repository and I don't know how to sync the new branch into my forked repository.

You mean you don't know how to make things work with git operation? There are many ways to handle the problem in Git, and this is one of them (this is how I would operate).

Your develop branch is used directly in PR, so you manipulate it.

git checkout develop to check out the local develop branch.
git reset --hard 53cf67a32a6a41c48be293c6238c08d967d9d85e to force a change develop branch position to [CHG] added ...

Commits after that point have already been merged into FlashCap's develop branch.

git rebase flashcap/develop to rebase into FlashCap's develop branch. Here flashcap is the remote name of the FlashCap repository, so use the name you gave there.
git push -f to force push develop branch to your repository.

Now you should have 53cf67a32a6a6a41c48be293c6238c08d967d9d85e changes committed to the latest location (commit ID will change).
After that, you should be able to commit the patch.
If you can't get it to work, let me know and I'll do it here. (I try to leave modifications to the person who wrote the code if there is no reason to do so, since the code belongs to that person ;)

Appreciate the instructions but I failed miserably :) Especially the rebase command did not work, I tried a lot of variations but I always get "invalid upstream". Please use my patch, I don't mind not getting any credit for this ;)

No, problem! I will make it.

Moved #116.


POST requests fail

See https://github.com/datenanfragen/website/issues/1060 and https://github.com/datenanfragen/website/issues/1062.

A POST request causes the following error, which crashes the server (in prod, it is then automatically restarted by pm2):
An unhandled promise rejection occurred: TypeError: Cannot read properties of null (reading 'statusCode')
    at Request._finalize (/home/benni/coding/git-repos/Datenanfragen.de/backend/node_modules/@hapi/hapi/lib/request.js:491:31)
    at Request._reply (/home/benni/coding/git-repos/Datenanfragen.de/backend/node_modules/@hapi/hapi/lib/request.js:428:18)
    at Request._execute (/home/benni/coding/git-repos/Datenanfragen.de/backend/node_modules/@hapi/hapi/lib/request.js:274:14)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Unless I'm missing something, this isn't a problem in our code (the stack trace is entirely in node_modules and our code doesn't contain statusCode anywhere). And since this used to work, I guess the best course of action is to try and update hapi and the associated libraries in the hope that whatever the problem is was fixed upstream.

Updating hapi has solved the problem locally. Not much in the way of breaking changes, either. Only had to change imports from @hapi/joi to joi.
While I'm at it, I'll also update everything else.


[core] add arity 2 to tetrahedron's IFaceAccess and fix face format

Adds the missing arity to tetrahedron's IFaceAccess implementation, and also
fixes the format of faces being returned. Each face needed to be wrapped inside
an additional vector, since face format should be [vertices attribs].

thanks @vl4dimir & apols for the loooong delay. new release imminent at last


Updates bower's main files for gulp plugin usage

Includes all the necessary files so that projects like main-bower-files (for gulp) can grab the dependencies properly.

Closing since it hasn't been touched in a long time and Bower support is planned for removal in the next major release.


Search for ubuntu recommends deprecated image

Expected behavior
When searching for ubuntu, Kitematic should recommend the officially supported and maintained Ubuntu container image.
Actual behavior
While the official ubuntu image is the first one to appear in the "other repositories" list of all ubuntu images, the recommended image is ubuntu-upstart which is according to their readme "this image is officially deprecated (especially now that Upstart is no longer the default init system for Ubuntu) and will receive no further updates. Please adjust your usage accordingly."
Information about the Issue
Kitematic should not recommend deprecated images even though they are official.
Steps to reproduce the behavior

Search for "ubuntu"

We rely on the hub repo owners to provide that information and make no assumptions as to what latest or version x.x.x should be.


Cannot Build CLKey from Contract Hash

Using the casper-client, it is possible to give any hash value the type key, but the Casper JS SDK lacks the ability to build a CLKey object from any given hash.
For example, on line 7 in this shell script, a key argument is defined with the value "hash-b62481085812c4f56027f5fb7f3e5e2f087b14190da8762fb88889e4945178be".
This works properly. Here is a successful deploy as an example (expand the raw data and look under the first argument contract_hash).
Using the Casper JS SDK, however, it appears this cannot be done.
Traditionally, building a CLKey object is done by calling CLValueBuilder.key(), which accepts a parameter of type CLKeyParameters, which is any of the following types:

CLByteArray
CLURef
CLAccountHash
CLPublicKey

Reference: CLKey, CLValueBuilder.key, CLKeyParameters.
Converting the contract hash string above into any of these four types, and then into a CLKey using CLValueBuilder.key(CLKeyParameters) yields different errors, from the inability to unpack the deploy in the Casper Wallet to empty arguments when deployed.
Here is my attempted implementation.
My proposed solution is creating a new class CLContractHash and conforming it to CLKeyParameters.

I think it is doable - consider following test.ts:
import { CLAccountHash, CLValueBuilder } from "casper-js-sdk";

const accountHash = "fa5c933f908608377f451a52791b5d53955d99f7bad2707bd82eef32a893db5a"
const accountHashArr = Uint8Array.from(Buffer.from(accountHash, 'hex'));
const clAccountHash = new CLAccountHash(accountHashArr);
const key = CLValueBuilder.key(clAccountHash);

console.log("\nHere is CLKey:\n", key);

$ ts-node test.ts
@jsonMember on e.StoredValue: cannot resolve specified property constructor at runtime. If the type is not yet defined, for example due to circular references, add '() => ' before it. E.g. @jsonMember(() => Foo)

Here is CLKey:
 t {
  isCLValue: true,
  data: t {
    isCLValue: true,
    data: Uint8Array(32) [
      250, 92, 147,  63, 144, 134,   8,  55,
      127, 69,  26,  82, 121,  27,  93,  83,
      149, 93, 153, 247, 186, 210, 112, 123,
      216, 46, 239,  50, 168, 147, 219,  90
    ]
  }
}

Looking to get a contract hash here, or in the context of the VM, a "Hash" object. Following this pathway gives you an account hash which is typed as an Account. see here.
Working on a CLContractHash implementation

Just looking how CLKey is parsed for contract hash:
https://github.com/casper-ecosystem/casper-js-sdk/blob/e217c4b0e6cb65f60d19db0ae1c25150d2cd2d00/src/lib/CLValue/Key.ts#L49-L57
The idea is that regular byte array is prefixed with variant byte.
So as a workaround we can do it manually:
import { KeyVariant, CLByteArray, CLValueBuilder } from "casper-js-sdk";
import { concat } from '@ethersproject/bytes';

const contractHash = "cb781f66f78a398bf1709c4dac40b3cca17106824ea88ca9daa5b822421c9b57";
const clContractHash = new CLByteArray(
    concat([
        Uint8Array.from([KeyVariant.Hash]),
        Uint8Array.from(Buffer.from(contractHash, 'hex'))
    ])
);
const key = CLValueBuilder.key(clContractHash);

It works, but CLContractHash is definitely missing in the SDK.

Nice solution. In my case, adding Uint8Array.from([KeyVariant.Hash])  added another “01”. It appears to actually be as simple as:
const clContractHash = new CLByteArray(Uint8Array.from(Buffer.from(contractHash, "hex")));
const key = CLValueBuilder.key(clContractHash);

I had previously tried this, but was using TextEncoder instead of Buffer because I was in a React environment, and TextEncoder assumed the text was UTF-8 not hex. Instead, for React, one can actually just use decodeBase16 from Conversions like so:
import { decodeBase16, CLByteArray, CLValueBuilder } from "casper-js-sdk";

const contractHash = "cb781f66f78a398bf1709c4dac40b3cca17106824ea88ca9daa5b822421c9b57";
const clContractHash = new CLByteArray(decodeBase16(contractHash));
const key = CLValueBuilder.key(clContractHash);

Should still implement a CLContractHash though.

hey guys, yeah we will add CLContractHash in upcoming release !


gclient sync -D spews logs about finding the iOS and macOS SDKs from the gclient hook

On https://github.com/flutter/engine/commit/90c4d64d410fa8f3cd640d59b01ceb583d0ad13c
$ gclient sync -D
...
Running hooks:  88% (16/18) Find the iOS device SDKs
________ running 'python3 src/build/config/ios/ios_sdk.py --as-gclient-hook' in '/Users/m/Projects/engine'
2024-03-18 10:20:28.708 xcodebuild[70174:12050158] Requested but did not find extension point with identifier Xcode.DVTDeviceFoundation.Aspect for extension Xcode.IDEiOSSupportCore.Aspect.NBDD of plug-in com.apple.dt.IDE.IDEiOSSupportCore
2024-03-18 10:20:28.711 xcodebuild[70174:12050158] Requested but did not find extension point with identifier DVTProducts.ReleaseChannelNamer for extension DVTProducts.ReleaseChannelNamer.PV of plug-in com.apple.dt.IDEDistributionSupport
/Users/m/Projects/engine/src/flutter/prebuilts/SDKs/iPhoneOS17.4.sdk
2024-03-18 10:20:29.216 xcodebuild[70177:12050186] Requested but did not find extension point with identifier Xcode.DVTDeviceFoundation.Aspect for extension Xcode.IDEiOSSupportCore.Aspect.NBDD of plug-in com.apple.dt.IDE.IDEiOSSupportCore
2024-03-18 10:20:29.217 xcodebuild[70177:12050186] Requested but did not find extension point with identifier DVTProducts.ReleaseChannelNamer for extension DVTProducts.ReleaseChannelNamer.PV of plug-in com.apple.dt.IDEDistributionSupport
/Users/m/Projects/engine/src/flutter/prebuilts/SDKs/iPhoneSimulator17.4.sdk
Running hooks:  94% (17/18) Find the macOS SDK
________ running 'python3 src/build/mac/find_sdk.py --as-gclient-hook 10.14' in '/Users/m/Projects/engine'
2024-03-18 10:20:29.723 xcodebuild[70188:12050264] Requested but did not find extension point with identifier Xcode.DVTDeviceFoundation.Aspect for extension Xcode.IDEiOSSupportCore.Aspect.NBDD of plug-in com.apple.dt.IDE.IDEiOSSupportCore
2024-03-18 10:20:29.724 xcodebuild[70188:12050264] Requested but did not find extension point with identifier DVTProducts.ReleaseChannelNamer for extension DVTProducts.ReleaseChannelNamer.PV of plug-in com.apple.dt.IDEDistributionSupport
/Users/m/Projects/engine/src/flutter/prebuilts/SDKs/MacOSX14.4.sdk
14.4
Running hooks: 100% (18/18), done.

cc @zanderso https://github.com/flutter/engine/pull/50957

I'm not sure how to suppress the output from Xcode, but the prints in ios_sdk.py and find_sdk.py we can definitely suppress when they are passed the --as-gclient-hook flag.


How to get an owned value from AccessGuard?

I want to make a small wrapper function but I get a lifetime error
pub fn get_from_table<'a, 'b, K, V>(
    &self,
    table: TableDefinition<K, V>,
    key: impl std::borrow::Borrow<K::SelfType<'a>>,
) -> Result<Option<<V as ToOwned>::Owned>, redb::Error>
where
    K: redb::Key,
    V: redb::Value + ToOwned,
    <V as redb::Value>::SelfType<'b>: Into<<V as ToOwned>::Owned>,
{
    let transaction = self.store.begin_read()?;
    let table = match transaction.open_table(table) {
        Err(TableError::TableDoesNotExist(_)) => return Ok(None),
        r => r?,
    };

    let Some(guard) = table.get(key)? else {
        return Ok(None);
    };

    Ok(Some(guard.value().into()))
}

Error:
error[E0597]: `guard` does not live long enough
   --> src/storage.rs:152:17
    |
132 |     pub fn get_from_table_2<'a, 'b, K, V>(
    |                                 -- lifetime `'b` defined here
...
148 |         let Some(guard) = table.get(key).map_err(redb::Error::from)? else {
    |                  ----- binding `guard` declared here
...
152 |         Ok(Some(guard.value().into()))
    |                 ^^^^^--------
    |                 |
    |                 borrowed value does not live long enough
    |                 argument requires that `guard` is borrowed for `'b`
153 |     }
    |     - `guard` dropped here while still borrowed

For more information about this error, try `rustc --explain E0597`.

Any tips on resolving lifetime dependencies?

Just had this problem myself and managed to solve it with HRTBs:
fn get<K, V>(db: redb::Database, table: TableDefinition<K, V>, key: K) -> Option<V>
where
    K: Key + for<'a> Borrow<<K as Value>::SelfType<'a>>,
    V: for<'a> Value<SelfType<'a> = V>,
{
    db.begin_read()
        .unwrap()
        .open_table(table)
        .unwrap()
        .get(key)
        .unwrap()
        .map(|guard| guard.value())
}

If I understand correctly, it's because we don't know the name of the lifetime until we call the various database methods. So we have to specify it explicitly with HRTBs so it works with any lifetime.
I also tried to make a small wrapper for the database with a trait to make this all go away. I'm not sure if this good or not though, as this is a bit over my head :smiling_face_with_tear:
Here is the code:
trait Item:
    Value
    + Sized
    + for<'a> Value<SelfType<'a> = Self>
    + for<'a> Borrow<<Self as Value>::SelfType<'a>>
    + 'static
{
    type Id: Key
        + for<'a> Key<SelfType<'a> = Self::Id>
        + for<'a> Borrow<<Self::Id as Value>::SelfType<'a>>
        + Default
        + Copy;

    const TABLE: TableDefinition<'_, Self::Id, Self>;
}

struct Database(redb::Database);

impl Database {
    fn get<T: Item>(&self, id: T::Id) -> Option<T> {
        let read = self.0.begin_read().unwrap();
        let table = read.open_table(T::TABLE).unwrap();
        let v = table.get(id).unwrap();
        v.map(|guard| guard.value())
    }

    fn insert<T: Item>(&self, key: T::Id, value: T) {
        let write = self.0.begin_write().unwrap();
        {
            let mut table = write.open_table(T::TABLE).unwrap();
            table.insert(key, value).unwrap();
        }
        write.commit().unwrap();
    }
}

Hope this helps.

Yes, that helps. I'm not very familiar with HRTBs, it is quite rare, I didn't even think about them. Thank you!


2022.10.13 5th tedtalk meeting (We Can Make COVID-19 the Last Pandemic)

2022.10.13 5th tedtalk meeting
Timetable

19:30 ~ 19:50: Ice Breaking Small talk
19:50 ~ 20:40: Topic talk

Ice Breaking Small talk

250-conversation-starters

Tedtalk

Ted
Youtube

Transcript

click here
00:01
In the year 6 CE, a fire devastated Rome. In response, Emperor Augustus did something that had never been done before in the history of the Empire. He created a permanent team of firefighters who used buckets just like this one. Augustus understood that individuals alone can't protect themselves from fires. They need help from the community. When one person's house is on fire, that creates a risk for everyone else's homes.
00:38
And so what we've had these last few years is like a horrific global fire. The COVID pandemic has killed millions and upended economies, and we want to stop that from happening again. COVID, it's hard to overstate how awful it's been. It's increased the health inequities between the rich and the poor. Survival depended partly on your income, your race, the neighborhood you lived in. And so we should seize this opportunity to create a world where everyone has a chance to live a healthy and productive life. Also a life free from the fear of the next COVID-19.
01:27
When I was on this stage in 2015, I was one of many people who said we weren't ready and we needed to get ready. We didn't. The speech actually was watched by a lot of people. But 90 percent of the views were after it was too late.
01:47
(Laughter)
01:50
So now I hope the need is clear. And of course, we've learned a lot. During this pandemic, a lot of things worked well, a lot of things didn't work well. And so we have all that knowledge to build a prevention system.
02:08
COVID-19 can be the last pandemic if we take the right steps. So how, what are these steps? Well, let's go back and look at what the Romans did. Think about how, over time, we've gotten good at preventing big fires. Fire prevention is kind of this pervasive thing. It's well funded. It's well understood. If an alarm went off right now, everyone here would know we're supposed to calmly gather, go out and wait instructions. We'd know that help would be on the way because we have lots of trained firefighters who practice. The United States alone has 370,000 full-time firefighters, even more than I guessed that number would be. We also have access to water. The United States, for example, has almost nine million fire hydrants. And so that type of investment, that type of practice, that type of system is what we need to stop pandemics.
03:16
Now, often in movies, we'll have pandemics. And I'm always impressed with what takes place. Let's look at an example of this rapid response.
03:26
[Motaba River Valley, Zaire]
03:28
(Helicopter rotors whirring)
03:42
Well, that's quite impressive. We don't need the music, but otherwise we saw exactly what should happen. An outbreak’s detected. Very quickly, literally within days, doctors are dispatched. They have a helicopter to get into exactly ground zero. They go in there, and they’ve got the right tools. And this is what should happen when an outbreak is spotted.
04:09
But we don't have that team, we don't have those resources. And if an outbreak took place in a low-income country, it could be literally months before we started to orchestrate those resources.
04:22
So despite what you see in movies, there is no group of experts standing by to prevent this disaster. So we have to create a new team. I believe we should create what I call the GERM team. Germ stands for Global Epidemic Response and Mobilization. This group is full-time. Their only priority is pandemic prevention. It's made up of a diverse set of specialists with a lot of different realms of expertise: epidemiologists, data scientists, logistics experts. And it's not just scientific and medical knowledge. They also have to have communication and diplomacy skills. The cost of this team is significant. It's over a billion a year to support the 3,000 people who would be on this team. And its mission is to stop outbreaks before they become pandemics. The work would be coordinated by the WHO. They'd be present in many locations around the world, stationed in public health agencies. They'd work closely with the national teams, depending on the income level. They'd have more in the lower-income countries. You know, for example, we could have GERM members say an epidemiologist, working out of the Africa CDC office in Abuja. And a very important thing is that like firefighters, a GERM team would do drills. When you want to have quick response, when you want to make sure you have all the pieces there and you can move very quickly, practice is key. That's how you make sure everyone knows what to do.
06:09
Now, this team, there could be periods where there's no risky outbreak and they can keep their skills strong by working on some of the other infectious diseases, but that would be a second priority. They would work with countries to strengthen their health systems. The health systems are the front line. You need to know if, say, a lot of people show up with a new kind of cough, that’s when GERM needs to look into it and say, is this an outbreak? Is there a new pathogen here? What is the sequence of that? And so for all of this, the first 100 days are key. Viruses spread exponentially. And so if you get in there when the infection rate is fairly small, you can actually stop the spread.
07:02
You know, in this epidemic, if we'd been able to stop it within 100 days, we would have saved over 98 percent of the lives. Now, we did have countries that did a good job. Australia is an example. They orchestrated diagnostic capacity. They came up with distancing policies and quarantine policies. And so their overall death rate per capita will be well less than a 10th of other countries. But we did not, as a world, contain it. And that's what we have to do next time.
07:38
When COVID struck, we were almost like Rome before they had fire buckets and firefighters. We didn't have the people, the systems or the tools we need. Now, with the right investments, we can have a whole new generation of tools, better diagnostics, therapeutics and vaccines. A good example in the diagnostic area is this little machine, this is called the Lumira. We can have these all over the world that can test for any number of diseases. It’s a 10th as expensive as PCR, it’s absolutely as accurate, and it’s simple. So it can be used anywhere. We need other R&D investments. One that I'm very excited about is the idea of a drug that you inhale that blocks you from getting infected. It can be pathogen-independent and trigger your immune system so that you'll be protected. A lot of the tools, the diagnostic tools and those infection-blocking tools are important because they can be staged in advance. Now, we also need vaccines, but we want to stop the outbreak before we have to do a global vaccination campaign. And so vaccines can play a couple of different roles, but not the primary role. We have to invest in more than just that.
08:56
When we look at vaccines, they were the miracle of this epidemic. They saved millions of lives, but they can be far better.  We need vaccines that actually block infections. In this case, there were lots of breakthrough infections. We need vaccines that are broad spectrum, so they work against most of the emerging variants, which we did not have this time. And we also need factories that are standing by so we can build enough vaccines for the entire world within six months and achieve far better equity. The vaccines can also do something that would be super helpful, which is to help us eradicate entire families of viruses. Innovative new vaccines used properly could get rid of the flu family, the coronavirus family. And there's a huge burden of those, even in non-pandemic years, and if we get rid of it, it can never cause a pandemic.
09:59
So I'm talking about investments in three broad areas: Disease monitoring, that's GERM. The R and D tools that are far better. And finally, and the most expensive, is improved health systems. This won't be cheap, but it'll save lives. And even it'll save money in the long run. It's like an insurance policy.
10:23
The cost to prevent the next pandemic will be tens of billions of dollars. But let's compare that to what we just went through. The IMF estimates that COVID has cost nearly 14 trillion dollars. And so we need to spend billions in order to save trillions. And here's the best part of this. Even when we're not having an outbreak, these investments like the Lumira, those new vaccines, they will make people healthier. They'll shrink the gap, the health equity gap, which is gigantic, between rich and poor countries. For example, we can detect more HIV cases and do a better job of treatment. We can reduce deaths from malaria. We can get more people high-quality care. And so this is not just a downer about how to stop things from getting worse, but also a chance to make things better.
11:26
If we take the right steps, we can make COVID-19 the last pandemic, and we can build a healthier, more equitable world for everyone.
11:38
Thank you.
11:39
(Applause) Helen Walters: Thank you so much. I have a few follow-up questions and one is really about the formal status of GERM. So you mentioned this would cost a billion dollars, you mentioned it comes through the WHO, but exactly who's running this, how does this work, how do we make this happen?
12:09
BG: Well, GERM does not exist. It's a proposal I'm putting forward that hopefully over the next year, while the pain of the pandemic is still clear in people's minds, will get a global consensus. The rich-world governments will have to step up like they do with all the aid things and come up with that money. The way the personnel systems works, so that it's under WHO, but a really top-notch team, there will be a lot of debate about how to do that well. So, you know, I'm putting it forward and hopefully within the next year we'll get that consensus.
12:42
HW: Who do you need to pick that up next?
12:44
BG: Well, it's really the rich-world governments. The WHO has this big yearly meeting, the World Health Assembly, and at some point somebody will put forward a resolution and we'll see if the extra resources can be put in for that. After World War II, we did a lot. You know, we created the United Nations, we talked a lot about war. So I'd be stunned, although, you know, so far the action has been less than I would have expected, I'd be stunned if we don't go forward with something pretty close to what I'm laying out there.
13:20
HW: This has been pretty personal for you.  I just wanted to ask, like, how are you managing that?
13:30
BG: Well, it's kind of weird.
13:33
(Laughter)
13:35
(Applause)
13:40
Now, our foundation, the Gates Foundation, is very involved in vaccines, the invention of new vaccines, funding vaccines. And we're very proud that through joint efforts like GAVI, that saved tens of millions of lives.  Who knows? But, you know, hopefully, as the pandemic calms down, people are more rational about, hey, vaccines are a miracle and there's a lot more we can do.
14:33
HW: So the future is in our hands in the present.
14:36
Bill Gates, thank you so much for being here.
14:38
BG: Thank you.
14:39
(Applause)

Topic

Question1
Question2
Question3

Voca

Voca

upend: set or turn (something) on its end or upside down.

The COVID pandemic has killed millions and upended economies

lenient: (of punishment or a person in authority) permissive, merciful, or tolerant. "judges were far too lenient with petty criminals"
downer: a depressant or tranquilizing drug, especially a barbiturate. "during that week I was heavily doped on downers"

Excellent session~! Looking forward to the next one~~!


[WIP] [ROCM] MIOpen contrib for convolution kernels

There are several differences with cudnn contrib:

MIOpen compiles and caches kernel codes during runtime
Compilation happens during mandatory miopenFindConvolutionForwardAlgorithm(...)
miopenFindConvolutionForwardAlgorithm(...) runs a benchmark to find the best algo for the provided input.
To avoid running miopenFindConvolutionForwardAlgorithm on every extern call, I run it once during build time. Workspace is also setup during build time.

I attached a test case which compares miopen output with TVM AMDGPU backend.
$ python test_miopen.py
[22:50:44] src/contrib/miopen/conv_forward.cc:136: 	MIOpen Found 1 fwd algorithms, choosing miopenConvolutionFwdAlgoWinograd
[22:50:44] src/contrib/miopen/conv_forward.cc:139: 		0) miopenConvolutionFwdAlgoWinograd - time: 0.110878 ms, Memory: 0
/home/masa/project/dev/tvm/python/tvm/build_module.py:340: UserWarning: Specified target rocm, but cannot find device code, did you do bind?
  "Specified target %s, but cannot find device code, did you do bind?" % target)
Max abs diff: 4.19617e-05

@adityaatluri

@tqchen Don't merge this yet. I think I found a bug.

@tqchen I fixed my bug. Now MIOpen works with NNVM.
I can run resnet and vgg benchmark with MIOpen kernels.

@tqchen I added "use_miopen" to tvm.target.Target. See my last commit.

@tqchen can you check my change is legit?

@masahi we can update LLVM's option detector to simply skip this option, so it won;t result in a fault

@tqchen Sorry, I found a typo

fixed

try to run test locally, they might have things to do with your change in target

ok, I can reproduce errors locally.
will fix

fixed

@tqchen jenkins is failing on one of the topi unittests.
I can pass test_topi_reduce.py locally.

OK, that one is just fine, sometimes reduction tests fail possibly due to a tie. nd won't do so after retrigger

it's failing again.

Test passed. Ready to merge.