Instrument field operations

Especially when prototyping a new protocol, having a accurate field operation counts is very important.
My proposal would be to add this behind a feature flag, adding a globally accessible stats counter that is then updated.
Ideally, by turning on the instrumentation flag, the user would be able to transparently instrument their code with no changes required.

You'd typically count curve operations plus FFTs.
You could've curve+field forks or wrapper types, which achieved this.  If you only want curve operations, then you could check out https://github.com/paritytech/arkworks-extensions
If you opnly want curve operations, then you could integrate this approch with different benchmarking tools.

For my particular use-case, curve operations and FFTs are not too relevant. I really would just want to be able to count the number of field additions, multiplications and divisions.
I assume that, once that is done the common infrastructure could be extended to other functionalities.
Possibly we could decorate methods which should (optionally) be instrumented with some derive_macro which writes to a common (global, thread safe, possibly slow) counter. Then, on the counter itself we can implement some aggregation for better user functionality.

Above, we targeted the expensive operations above, without changing the fields, but..
It's likely easier to just count field operations, either cargo patch in your fork of ark-ff, or else simply fork the curve with one commit that sustitutes your ark-ff.


Show logged-in user's name in token input

Related to https://github.com/refined-github/refined-github/issues/6000#issuecomment-1556136109
Screenshot

ٍSome longer usernames and names may not fit next to the token input box.

I see space for about 35 characters, if someone has a username that long they're seeing it wrapping/clipping/causing issues all over the interface already.

and even then, it's already very close to the limit:

No, I mean that I had implemented show-names, which would show @its-miroma (Miroma)

Ah yes, that part should be removed. show-names doesn't show your own username either for example.

I like it!

Thank you Miroma!

I forgot to mention this: it lacks support for GitHub Enterprise and it will break for GHE users. Can you add it? It looks like this:
https://github.com/refined-github/refined-github/blob/eb1d1af666dfd5de3cf783728b47dfd22fa0e746/source/options.tsx#L62-L66


Zip-RS extract.rs example absolute extraction paths

The examples/extract.rs script does not protect against files being extracted to arbitrary directories outside the current directory. Whilst it appears some effort is made to prevent path traversal from zip entry filenames containing ../ (in sanitize_filename), this does not protect against entry filenames with absolute paths.
For example, a zip entry with a filename of /tmp/outfile will be extracted to /tmp/outfile instead of ./tmp/outfile. See zip_3_absolute_directory.zip for an example of this.
Whilst this is not an issue with the zip-rs library itself, having an insecure example which other developers may copy is less than ideal.

Thanks! This was indeed an issue I was trying to avoid. Should be fixed now.


Use poetry-core instead of poetry

This may unblock release 0.49.0 (#70), because it may provide Poetry 1.2 already, which is needed for serving dependency groups, which got recently introduced into pyproject.toml of Wetterdienst, using https://github.com/earthobservations/wetterdienst/commit/0920548871d.
This patch implements the suggestion by @xylar at https://github.com/conda-forge/wetterdienst-feedstock/pull/70#issuecomment-1329708542. Thank you!

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Converged to #70, closing.


Searching with compound nouns

Hi, I'm a native german speaker and want to use Loupe for a german project. As you may know the german language uses many compound nouns. But as I'm testing this library I discovered that the search does behave a little bit strange in this regards.
Example code:
<?php

use Loupe\Loupe\Configuration;
use Loupe\Loupe\Loupe;
use Loupe\Loupe\LoupeFactory;
use Loupe\Loupe\SearchParameters;

require_once(__DIR__ . '/vendor/autoload.php');

$configuration = Configuration::create()
    ->withPrimaryKey('id')
    ->withSearchableAttributes(['Title'])
    ->withLanguages(['de'])
;

$loupeFactory = new LoupeFactory();
$loupe = $loupeFactory->create(__DIR__ . '/loupe', $configuration);
$loupe->addDocument([
    'id' => 1,
    'Title' => html_entity_decode('Das ist eine Datenbankreplikation'),
]);

$searchParameters = SearchParameters::create()
    ->withQuery('replikation')
    ->withAttributesToSearchOn(['Title'])
    ->withAttributesToHighlight(['Title'])
;
$results = $loupe->search($searchParameters);

var_dump($results->getHits());

Expected result:
array(1) {...}

Actual result:
array(0) {
}

When searching for something thats not at the start of the word it will not be found. So in this case for "replikation". Is this behavior intended? Is it possible to configure something to support this?

Hey, thanks for giving Loupe a try - I'm German native too 😊
This is intended, yes. Loupe is a prefix search, like MeiliSearch and probably other engines. So it will never find words that only contain replikation. If you need that, Loupe is not the right tool for you. I'm not planning on making this configurable because it would be a tremendous amount of work and require a completely different engine.
It's also documented: https://github.com/loupe-php/loupe/blob/main/docs/configuration.md#minimum-length-for-prefix-search 😊


How to use two 2d lidars in cartographer 2d?

Do I need to create a node to merge two 2d lidars, if so, How ? Or Does cartographer offer some interfaces ? Any suggestion?

when using cartographer_ros you can subscribe directly to the different lidar topics.
When creating the configuration file use the option:
options {
   (...)
   num_laser_scans = 2
   (...)
}

Cartographer will the subscribe to scan_1 and scan_2 topics which you can remap to the correct topics in your setup.
The reference for the different options can be found here.

when using cartographer_ros you can subscribe directly to the different lidar topics.
When creating the configuration file use the option:
options {
   (...)
   num_laser_scans = 2
   (...)
}

Cartographer will the subscribe to scan_1 and scan_2 topics which you can remap to the correct topics in your setup.
The reference for the different options can be found here.

Great! THX a lot!

@tulku @esteve @SirVer I am sorry to disturb you, But I have encountered some difficulty and have no ideas. I change "num_laser_scans = 2" and publish "scan_1" and "scan_2", publish the tf. However, cartographer doesn't work as well as only one lidar.
Here's some info.

setting1:

        result:

        log:

log1.txt
setting2:

        result:

        log:

log2.txt
Here is my .lua file:
cuutuu.lua.txt
My Rosbag is here: https://pan.baidu.com/s/1ijQWyv3_mmNARvDmg9PbYw  CODE: gmpu
THANKS for your advices.

From your comments I understand that when using a single lidar cartographer is able to produce a better motion estimation from consecutive scans and when using 2 lidars, cartographer is failing to produce that estimation.
I noticed that you don't have an odometry source nor IMU, so cartographer has no other sensor to create the motion estimation.
I'm also working with multiple lidars and I have the same problem. However, when using an odometry source works better.
I would double check that the lidar poses are correct (if there is some overlap on the scans, that they match properly) and then keep playing with both the ceres scan matcher and the correlative scan matcher until you get a better result.
Let me know if you find values that make this work properly :)

From your comments I understand that when using a single lidar cartographer is able to produce a better motion estimation from consecutive scans and when using 2 lidars, cartographer is failing to produce that estimation.
I noticed that you don't have an odometry source nor IMU, so cartographer has no other sensor to create the motion estimation.
I'm also working with multiple lidars and I have the same problem. However, when using an odometry source works better.
I would double check that the lidar poses are correct (if there is some overlap on the scans, that they match properly) and then keep playing with both the ceres scan matcher and the correlative scan matcher until you get a better result.
Let me know if you find values that make this work properly :)

I use the IMU and get somehow better result, but still doesn't work properly. Then I merge two lidars data myself and feed into the cartographer, the result is much better. But it is strange that if the robot is static, the TF between /map and /laser may moving. I have a doubt that if two lidars need the  synchronization of timestamp? Maybe the "imu_raw" needs to be smoothed using imu_tools? Any ideas?

Interesting observation that making one lidar message before works better. That reminded me of the setting:
TRAJECTORY_BUILDER_2D.num_accumulated_range_data = N.

I did some quick tests with that, setting to the number of lidars in case cartographer needs to build one scan out of all, but did not have good results. You might want to give it a try.
When disabling odom and imu and using multiple lidars, the localization is moving a lot, so /map to /lidar will change because the robot pose will change, which is in between that transform. And I see the same here. And that's because cartographer's scan matcher is given very wrong results.
It might be that there are some conditions that the scans should have in order to work directly. Unfortunately I don't know them yet. We will find out though :)


New attributes & functionality for locate models

This PR:

resolves #267
resolves #282
resolves #283
resolves #285
resolves #286
resolves #287
starts a cleans up and standardization of docstrings (this will continue in future PRs)
starts a cleanup and debugging of doctests (this will continue in future PRs)

xref #295 needs attention in the short term.


logo

Hi. I am a graphic designer. I volunteer to design a logo for open source projects. I can design it for you to use it in the readme file. What dou you say?

Thanks, we're all set logo-wise.


add cub w/ package config install

Notes

this is a CUDA *.cuh header-only lib where the install stage simply copies the header tree.
this release is hosted here https://github.com/headupinclouds/cub
needs  https://github.com/hunter-packages/cub (see https://github.com/ruslo/hunter/issues/1157)

Testing would require a CUDA setup w/ nvcc toolchain (Possible TODO)

Thanks.
I've found cub keeps deleting history and removing release commits, which is annoying for checking out Caffe.
Do you know if we can just use the latest version of Cub for all versions of Caffe and Tensorflow?

Do you know if we can just use the latest version of Cub for all versions of Caffe and Tensorflow?

I'm not sure.  I guess we can try and see.  I think finding some CI options for testing this GPGPU/CUDA stuff will be needed.
TODO: grpc, boringssl, lmdv, sync, re2, snappy, jemalloc

needs https://github.com/hunter-packages/cub

Done: https://github.com/hunter-packages/cub

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2734
https://travis-ci.org/ingenue/hunter/builds/300145146?utm_source=github_status&utm_medium=notification

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2740
https://travis-ci.org/ingenue/hunter/builds/300191963?utm_source=github_status&utm_medium=notification

Uploading:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2748
https://travis-ci.org/ingenue/hunter/builds/300368470?utm_source=github_status&utm_medium=notification

Follow-up: https://github.com/ruslo/hunter/commit/1b647e09f1d78b2553e4c38a9e5070e4f58d84a9
Released: https://github.com/ruslo/hunter/releases/tag/v0.19.148

Thanks.


KEDA tries to resolve secrets from restricted namespace

Report
I have KEDA up and running using KEDA_RESTRICT_SECRET_ACCESS environment variable which restricts secret access to only KEDA namespace. I have a rather simple ScaleObject (below) which has a target deployment and scale trigger using prometheus as a source. There is no TriggerAuthentication or any other reference to secrets in ScaledObject.
The target deployment (test-deployment) has some environment variables from secrets:
envFrom:
  - secretRef:
      name: test-deployment-89c6h5f565

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: test-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment
  pollingInterval: 30
  minReplicaCount: 2
  maxReplicaCount: 5
  advanced:
    restoreToOriginalReplicaCount: false
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 900
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.prometheus:9090/
      query: max by(test_tasks_queue)(test_tasks_pending_blocked{service="test-deployment", test_tasks_queue="default"})
      threshold: '100'
      activationThreshold: '0'

When I apply the ScaledObject to the cluster it fails to create the HPA resource for ScaledObject because it cannot find the secret what the deployment uses:
keda-operator  error resolving secrets for ScaleTarget: error reading secret ref &SecretEnvSource{LocalObjectReference:LocalObjectReference{Name:test-deployment-89c6h5f565,},Optional:nil,} on namespace default: secret "test-deployment-89c6h5f565" not found

keda-operator  Failed to ensure HPA is correctly created for ScaledObject

However if I allow KEDA to access secrets from all namespaces the ScaledObject and HPA are created succesfully and everything works fine.
Expected Behavior
KEDA should not need to access secrets from the namespace where the scale target is located if there is no reference to a secret in the ScaledObject or TriggerAuthentication is not used.
Actual Behavior
KEDA tries to list/watch/get secrets from the scale target namespace even though usage of secret(s) is not required from ScaledObject.
Steps to Reproduce the Problem

KEDA is installed using helm and the access to secrets is limited using the following parameters in values.yaml

permissions:
  metricServer:
    restrict:
      secret: true
  operator:
    restrict:
      secret: true

ScaledObject (described in the report section) is applied to the cluster
Creation of HPA resource for ScaledObject fails

Logs from KEDA operator
"level":"error","ts":"2023-05-03T10:57:16Z","msg":"Failed to ensure HPA is correctly created for ScaledObject","controller":"scaledobject","controllerGroup":"keda.sh","controllerKind":"ScaledObject","ScaledObject":{"name":"test-scaledobject","namespace":"default"},"namespace":"default","name":"test-scaledobject","reconcil │
eID":"7fc01087-cd26-479e-b31c-567dba2736e1","error":"error resolving secrets for ScaleTarget: error reading secret ref &SecretEnvSource{LocalObjectReference:LocalObjectReference{Name:test-deployment-89c6h5f565,},Optional:nil,} on namespace default: secret \"test-deployment-89c6h5f565\" not found","stacktrace":"github.com/kedacore/keda/v2/contro │
llers/keda.(*ScaledObjectReconciler).Reconcile\n\t/workspace/controllers/keda/scaledobject_controller.go:178\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:122\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconci │
leHandler\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:323\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:274\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).St │
art.func2.2\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:235"}

{"level":"error","ts":"2023-05-03T10:57:16Z","msg":"Reconciler error","controller":"scaledobject","controllerGroup":"keda.sh","controllerKind":"ScaledObject","ScaledObject":{"name":"test-scaledobject","namespace":"default"},"namespace":"default","name":"test-scaledobject","reconcileID":"7fc01087-cd26-479e-b31c-567dba2736e1 │
","error":"error resolving secrets for ScaleTarget: error reading secret ref &SecretEnvSource{LocalObjectReference:LocalObjectReference{Name:test-deployment-89c6h5f565,},Optional:nil,} on namespace default: secret \"test-deployment-89c6h5f565\" not found","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconci │
leHandler\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:329\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:274\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).St │
art.func2.2\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:235"}

KEDA Version
2.10.0
Kubernetes Version
1.24
Platform
Google Cloud
Scaler Details
Prometheus
Anything else?
No response

Hey,
Sure, are you willing to open a PR with the required changes?

@JorTurFer I quickly looked into this issue, and I'm wondering if it could be sufficient to use optional field on the secretRef
envFrom:
  - secretRef:
      name: test-deployment-89c6h5f565
      optional: true

to ignore error when the secret is not found, instead of making code changes.

I'm wondering if it could be sufficient to use optional field on the secretRef

Could be (I'm not sure), but it requires changes in how the workload is deployed and KEDA should be able to handle this security requirement internally, not asking for secrets outside the allowed namespaces. IMO the code should be changed at the end


build fails

I installed npm packages and did the build, but it fails with many error on my windows computer:
....
  74:80  error  Delete `␍`  prettier/prettier
  75:17  error  Delete `␍`  prettier/prettier
  76:25  error  Delete `␍`  prettier/prettier
  77:20  error  Delete `␍`  prettier/prettier
  78:16  error  Delete `␍`  prettier/prettier
  79:17  error  Delete `␍`  prettier/prettier
  80:3   error  Delete `␍`  prettier/prettier

✖ 80 problems (80 errors, 0 warnings)
  80 errors and 0 warnings potentially fixable with the `--fix` option.

 @ ./src/config/proxy.js 26:0-65 30:28-39 31:23-34
 @ ./src/config/index.js
 @ ./node_modules/babel-loader/lib!./node_modules/eslint-loader/dist/cjs.js!./src/app.js
 @ ./src/app.js-exposed

ERROR in ./src/config/index.js
Module Error (from ./node_modules/eslint-loader/dist/cjs.js):

D:\glance\paraview-glance\src\config\index.js
  1:54  error  Delete `␍`  prettier/prettier
  2:1   error  Delete `␍`  prettier/prettier
  3:17  error  Delete `␍`  prettier/prettier
  4:9   error  Delete `␍`  prettier/prettier
  5:3   error  Delete `␍`  prettier/prettier

✖ 5 problems (5 errors, 0 warnings)
  5 errors and 0 warnings potentially fixable with the `--fix` option.

 @ ./src/app.js (./node_modules/babel-loader/lib!./node_modules/eslint-loader/dist/cjs.js!./src/app.js) 18:0-48 49:63-69
 @ ./src/app.js-exposed

ERROR in ./src/config/proxy.js
Module Error (from ./node_modules/eslint-loader/dist/cjs.js):
...

seems a problem of my vs code formatting, not sure why

That's an issue of prettier complaining about CRLF line endings. I will take a look to see if we need to upgrade prettier.
On February 25, 2020 10:55:35 PM UTC, Daniel Zuidinga<EMAIL_ADDRESS>wrote:

seems a problem of my vs code formatting, not sure why
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/Kitware/paraview-glance/issues/299#issuecomment-591117018

Let me know if if things work with master. git should now locally checkout with eol=LF on windows, and I'm enforcing LF line endings in prettier.

hmm no:

Hi,
I had to delete my old directory and re-clone the repository, and then
everything worked perfect!  Thanks!
On Wed, Feb 26, 2020 at 1:21 PM Daniel Zuidinga<EMAIL_ADDRESS>wrote:

hmm no:
[image: image]
https://user-images.githubusercontent.com/1972209/75374754-1f023600-58cd-11ea-96c3-8ce04599573a.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Kitware/paraview-glance/issues/299?email_source=notifications&email_token=AACEJLY5QHCUWH6UBZZKZLTRE2XJFA5CNFSM4K3U6MNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENBKFHY#issuecomment-591569567,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACEJL43NAEBWHWC5RWH7J3RE2XJFANCNFSM4K3U6MNA
.

--
Stephen R. Aylward, Ph.D.
Senior Director of Strategic Initiatives
Kitware: Advancing the frontiers of understanding
by developing innovative open-source software platforms
and integrating them into research, processes, and products.

I created a new one and did reformating a js file in VS code.

when executing the linting suggesting in VS Code it reformats to compilable format btw. but not with arbirtrary line break in my js

I think this beautify plugin does cause the wrong formatting: https://marketplace.visualstudio.com/items?itemName=HookyQR.beautify
disabling it solved it for me

:tada: This issue has been resolved in version 4.6.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix(GUI): make sure progress button is always rounded

At the moment the progress button which has slightly rounded corners allows the __bar to overflow. This causes the corners to become angular again which looks weird. I set the button's overflow to hidden to fix this issue.
I wasn't able to test whether this fixes the issue for sure because I wasn't able to make the development dependencies work on my machine, but it should work.

I wasn't able to test whether this fixes the issue for sure because I wasn't able to make the development dependencies work on my machine, but it should work.

Oh :/ Which one of them didn't work?

Tests are failing because the compiled sass isn't committed; you should be able to just run make sass and commit the result as well and it should be fine :)

Also, can you please add Change-Type: patch to the bottom of your commit message? We use that for versioning, changelog generation and such (details in the commit guidelines)

I've compiled the styles now but probably messed up a few things, so my commit is now duplicated ...

I should have fixed everything now.
Thanks for the help @jhermsmeier, much to learn I still have about Git.

Yep, looks good – gave it a test run, and the corners do stay round :)
Thanks for fixing this, good catch!

Oh, and regarding whatever didn't work with the development dependencies – please feel free to open an issue about it; we'd like the dev setup to be as painless as possible, so if there's something that's confusing about the instructions, or something doesn't work straight up, it'd be good to know so we can fix it or at least update the docs.

@jhermsmeier Ok, I'll do that now.


Cleanup hadoop dependencies in indexing modules

This change removes unnecessary dependencies from indexing modules (indexing-hadoop and indexing-service).

+1 after CI.


Bluetooth: Mesh: Add provisioner support

Introduction
Currently, Zephyr support being provisioned over both PB-GATT and PB-ADV but not being a provisioner. There's a lot of things in common for the provisioner and the device and most of the needed code is already implemented.
The protocol can be found in chapter 5 of the Mesh Profile Specification.
https://www.bluetooth.com/specifications/mesh-specifications/
Problem description
As it stands right now, some other device, typically a phone or computer, must act as a provisioner. The provisioner will hold all the DevKey's and will be the only one that can access the configuration server model for devices.
I can see multiple reasons for wanting to provision new devices from some sort of hub device. For example you might want to provision/configure devices via some web interface or you might want to do it remotely.
Proposed change
I propose to add support for provisioning, starting with PB-ADV, by supporting saving multiple DevKey's and implement the missing parts of the provisioning protocol.
Detailed RFC
I see three main changes that has to be made.

Support for multiple DevKey's

The bt_mesh_net structure currently only has one dev_key so this should probably be made into a list of DevKey's instead. This is similar to the how the AppKey's are handled but instead of a key being mapped to an AppId it will be mapped to a mesh address, ie the primary address of a device.

Add callback for BEACON_TYPE_UNPROVISIONED

The BEACON_TYPE_UNPROVISIONED is currently ignored but since it carries the device UUID which is used in the provisioning process, the application must be able to get this value somehow.

Implement missing provisioning functionality

The API function bt_mesh_provision is currently only used for provisioning the local device so some other API is needed to provision remote devices. This function must have access to the device MAC and UUID.
As stated in the Introduction, there's a lot of things in common for the provisioner and device. One thing that differs though is the initiation of the messages and for example generation of the PROV_DATA message.
Proposed change (Detailed)

Introduce a struct bt_mesh_dev_key that contains a mesh address and the device key for that address.
In struct bt_mesh_net, change u8_t dev_key[16] to an array of struct bt_mesh_dev_key.
Add functions bt_mesh_dev_key_[alloc|del|find] to manage the device keys. Similiar to bt_mesh_app_key.
Change all uses of dev_key to use bt_mesh_dev_key_find first
Change the setting bt/mesh/Net to only contain primary_addr
Add the setting bt/mesh/DevKey/{addr} to contain all device keys

Add a unprovisioned_device callback in the bt_mesh_prov structure

In prov.c

Add a PROVISIONER flag to prov_link.flags
Add a bt_mesh_pb_adv_open_link function that sets the PROVISIONER flag and kick things off
Change link_ack to set LINK_ACTIVE and send the Invite message if PROVISIONER flag is set
Change prov_capabilities to send Start and PubKey messages
Change prov_input_complete to send Confirm message

The functions prov_pub_key, prov_confirm and prov_random are used for both devices and provisioner but the behaviour is a little different. This could be handled by checking the PROVISIONER flag.

Change prov_complete to calculate and add the DevKey for the newly provisioned device

Dependencies
If the settings structure is changed, devices with mesh already configured will have to be re-configured.
Concerns and Unresolved Questions

When capabilities are received from device, how to select the preferred OOB method? Use bt_mesh_prov struct?

There should probably be some config for enabling provisioner support but how should this relate to the current BT_MESH_PROV for example?

Should DevKey's be mapped just to a mesh address or must the UUID be included?

Does it feel messy to mix the provisioning code with the device code in prov.c?

Alternatives
One alternative is to not remove the dev_key from the bt_mesh_net struct but rather add a list that only contains keys for other devices while the local dev_key is left as is. IMHO it seems more consistent to keep them all in the same list.

CC @jhedberg

Generally I agree with with most of what's being proposed here - thanks for creating a formal issue to track it!
Some comments:

The API function bt_mesh_provision is currently only used for provisioning the local device so some other API is needed to provision remote devices. This function must have access to the device MAC and UUID.

The MAC is not needed (or useful), at least not for PB-ADV, since it's perfectly valid for a device to send each PDU using a unique Non-resolvable private address. For PB-GATT (once we get to it) we might need to cache this, but even then we could do it all based on UUID and do a new scan once the app requests to provision a given UUID.

When capabilities are received from device, how to select the preferred OOB method? Use bt_mesh_prov struct?

Yes, that seems reasonable.

There should probably be some config for enabling provisioner support but how should this relate to the current BT_MESH_PROV for example?

Not sure what you mean by "the current BT_MESH_PROV", but provisioner support should definitely be behind a new Kconfig (and possibly some sub-options as well).

Should DevKey's be mapped just to a mesh address or must the UUID be included?

Most provisioners will also want to be configuration clients, so there may be more info we want to track. You also need to decide what makes sense to take care of in the stack and what should be left for the application. In addition to a provisioned node's primary element's address a provisioner also needs to track how many elements it has - this is critical since that way you know which addresses have been assigned so that you don't go assigning the same address to another node.

Does it feel messy to mix the provisioning code with the device code in prov.c?

I'd be open to look at what it'd take to split this into three c-files: one for the common provisioning protocol and two for each of the two possible roles (provisioner and provisionee). Whether do go ahead with this or not depends mostly on how messy a single c-file becomes with all the #ifdefs you'll need to add to make the support compile-time configurable.
I'd also suggest fourth optional step to your list of things to do: support exporting the provisioner database so that multiple provisioners can collaborate by sharing information on provisioned nodes. There's a standard coming from the SIG at some point - if you have access to the Mesh Working Group you might want to look it up.

One other things: our message sending APIs need to be able to specify whether to use the local device key or the remote device key. E.g. configuration server uses the local key, but configuration client uses the remote key.

The MAC is not needed (or useful), at least not for PB-ADV, since it's perfectly valid for a device to send each PDU using a unique non-resolvable private address. For PB-GATT (once we get to it) we might need to cache this, but even then we could do it all based on UUID and do a new scan once the app requests to provision a given UUID.

Yea that's right, I changed the issue to just UUID

Not sure what you mean by "the current BT_MESH_PROV", but provisioner support should definitely be behind a new Kconfig (and possibly some sub-options as well).

He, not really sure myself but I think one thing might be the naming of the configs. Now there is BT_MESH_PROV, BT_MESH_PB_ADV and BT_MESH_PB_GATT and they all relate to being able to be provisioned. Does it make sense to have something like
BT_MESH_DEVICE_PROV, BT_MESH_DEVICE_PB_ADV, BT_MESH_DEVICE_PB_GATT
and
BT_MESH_PROVISIONER, BT_MESH_PROVISIONER_PB_ADV, BT_MESH_PROVISIONER_PB_GATT

Most provisioners will also want to be configuration clients, so there may be more info we want to track. You also need to decide what makes sense to take care of in the stack and what should be left for the application. In addition to a provisioned node's primary element's address a provisioner also needs to track how many elements it has - this is critical since that way you know which addresses have been assigned so that you don't go assigning the same address to another node.

Good point. So after the provisioning is done it is necessary to get the device composition and then save the number of elements for the device. It feels like this should also be saved together with the DevKey for that device so maybe instead of settings bt/mesh/DevKey/{addr} it should be bt/mesh/Device/{addr} where both DevKey and number of elements is saved.
This raises two new questions:

How to get the device composition after provisioning?
What to do if provisioning is ok but reading device composition fails?

Possible solutions:

It seems resonable to use the existing cfg_cli API. A call to bt_mesh_cfg_comp_data_get will block until answer or timeout. The API call to do provisioning could be made into a blocking call that first does provisioning and then uses the cfg_cli API before returning.
Another option would maybe be to provide a function which should be set as the complete callback in bt_mesh_prov.

We could simply treat the node as unprovisioned and not save it even though it actually has access to the network. It won't have any AppKey though.

I'd be open to look at what it'd take to split this into three c-files: one for the common provisioning protocol and two for each of the two possible roles (provisioner and provisionee).

Yea that's what I was thinking as well but I think I'll try and add it to prov.c and see what it looks like.

I'd also suggest fourth optional step to your list of things to do: support exporting the provisioner database so that multiple provisioners can collaborate by sharing information on provisioned nodes. There's a standard coming from the SIG at some point - if you have access to the Mesh Working Group you might want to look it up.

I don't have access to that but it sounds interesting... :)

One other thing: our message sending APIs need to be able to specify whether to use the local device key or the remote device key. E.g. configuration server uses the local key, but configuration client uses the remote key.

What API do you mean? The bt_mesh_model_send?

BT_MESH_DEVICE_PROV, BT_MESH_DEVICE_PB_ADV, BT_MESH_DEVICE_PB_GATT and BT_MESH_PROVISIONER, BT_MESH_PROVISIONER_PB_ADV, BT_MESH_PROVISIONER_PB_GATT

Yes, something like that, but please try to keep existing option names as-is to maintain backward compatibility with apps external to the tree (that may be referencing the existing options).

So after the provisioning is done it is necessary to get the device composition and then save the number of elements for the device

That's not quite true. You're right that the number of elements information is part of the composition data, however you also get this number early on during provisioning through the Provisioning Capabilities PDU (see section <IP_ADDRESS>). It would be bad if the provisioner only found out after provisioning how many unicast addresses the provisioned node actually consumed. The spec is intentionally designed to make it possible to have the provisioner and configuration client as different devices, which would mean that the provisioner must hand over device keys and unicast addresses to the configuration client. In practice however I haven't seen or heard anyone creating such a split yet, i.e. in practice almost all provisioners will also be configuration clients. Either way, we shouldn't necessarily enforce this marriage in Zephyr - i.e. it should be possible to build an app that only does one but not the other.

How to get the device composition after provisioning?

We already have a Configuration Client API (which I think you referred to earlier), so this would be the method, I think. Meaning, it would be left to the application. We probably want to create a sample provisioner app under samples/bluetooth which shows this. We can later consider moving something to be part of the stack (perhaps as some sort of library) but I'd first like to see how this all ends up looking.

What to do if provisioning is ok but reading device composition fails?

I'd say that's app-specific, but a sane thing would be to show an error to the user and ask them to reset the node into non-provisioned mode again (hopefully it has some button or similar to do this).

What API do you mean? The bt_mesh_model_send?

Yes.

You're right that the number of elements information is part of the composition data, however you also get this number early on during provisioning through the Provisioning Capabilities PDU (see section <IP_ADDRESS>).

Ah I thought it was a bit weird that it wouldn't be available until after handing out an address but I totally missed that it was already available during provisioning. Like you say then, the configuration client things can be all up to the application.
Regarding the key used when sending, I was thinking that it would be solved by using bt_mesh_dev_key_find(ctx->addr) but I see the problem as even when you send to a remote address with cfg_srv you should still use your local DevKey. Any suggestion for handling this? Maybe adding a flag to bt_mesh_msg_ctx?

Regarding the key used when sending, I was thinking that it would be solved by using bt_mesh_dev_key_find(ctx->addr) but I see the problem as even when you send to a remote address with cfg_srv you should still use your local DevKey. Any suggestion for handling this? Maybe adding a flag to bt_mesh_msg_ctx?

We should do it the way we currently deal with the device key, i.e. a special key index value. Both App and Net Key indices are 12 bits in the spec so we can start counting down from 0xffff for any special values we need, e.g. currently we have the following in include/bluetooth/mesh/access.h:
#define BT_MESH_KEY_UNUSED        0xffff
#define BT_MESH_KEY_DEV           0xfffe

So we'd need a BT_MESH_KEY_DEV_REMOTE and BT_MESH_KEY_DEV_LOCAL. You could keep BT_MESH_KEY_DEV around for backward compatibility but make it a synonym with BT_MESH_KEY_DEV_LOCAL.
One note: I'm off on summer vacation today, so I won't be able to provide much (if any) feedback on this issue for the next several weeks.

So we'd need a BT_MESH_KEY_DEV_REMOTE and BT_MESH_KEY_DEV_LOCAL.

Sounds good.

One note: I'm off on summer vacation today, so I won't be able to provide much (if any) feedback on this issue for the next several weeks.

I think I have what I need to try and get something working. I hope you have a nice vacation!

I have created a pull request so I think the discussion can continue there instead.
https://github.com/zephyrproject-rtos/zephyr/pull/17729

Resolved by #17729 :tada:


#03　(expected ， actual)　 looks like the same,why?

error:

03 - What's Your Name? should complete all tasks Task #2 - don't greet user if name wasn't provided Should display welcoming message if user didn't provide their name:

  AssertionError: If user didn't enter the name (`this.state.name` length is 0), show "Hey there. Enter your name.". See the hint in task's description.
  + expected - actual

  -Hey there. Enter your name
  +Hey there. Enter your name.

looks like the same;why ?
my code ：

render() {
var howdy = "Hello " + this.state.name;
if(this.state.name.length<=0)
howdy ='Hey there. Enter your name';
return (

{howdy}

    <input type="text" name="name" onChange={this.onNameChange} />

);

}

Looks like real bug. You code looks nice and work correctly.
Try solution from hint:
render() {
    var greeting = "Hello " + this.state.name;
    if (this.state.name.length == 0) {
      greeting = "Hey there. Enter your name.";
    }
    return (

{greeting}

        <input type="text" name="name" onChange={this.onNameChange} />

    );
  }

@liuestc well to precise there is a difference between what is expected and what you provide

-Hey there. Enter your name
+Hey there. Enter your name.

Your solution is missing . at the end.


Upgrade bcrypt version for compatibility

The bcrypt version in this package is lagging behind. It has caused compatibility issues, and outright errors when building.
Task
Determine how to upgrade bcrypt in this project. Upgrade the bcrypt version here, or open an upstream PR.
Original report
@radik originally reported the following.
@brylie I could not use latest version of restivus-swagger because of npm-bcrypt version:
➜  app meteor add<EMAIL_ADDRESS> => Errors while adding packages:

While selecting package versions:
error: Conflict: Constraint<EMAIL_ADDRESS>is not satisfied by npm-bcrypt 0.9.2.
Constraints on package "npm-bcrypt":
*<EMAIL_ADDRESS><- top level
*<EMAIL_ADDRESS><- apinf:restivus-swagger 0.3.1
*<EMAIL_ADDRESS><- accounts-password 1.3.4 <- nimble:restivus 0.8.7 <- apinf:restivus-swagger 0.3.1

Here I'm trying to add<EMAIL_ADDRESS>to newly created meteor application.
Could you help me with this?

Check out https://github.com/meteor-rest/restivus-swagger

@brylie Steps to reproduce:
meteor create myapp
cd myapp
meteor add<EMAIL_ADDRESS>
Meteor version: Meteor <IP_ADDRESS>

Cool, thanks for the steps to reproduce. It seems like we can just unpin the dependency versions, and hopefully things will work correctly. It is unclear why the dependencies where pinned in the first place, and it is worth acknowledging the 'Meteor REST' organization seem to be willing to maintain this project in their own namespace.
cc: @bajiat

@brylie Here is your comments about bcrypt:
https://github.com/apinf/restivus-swagger/issues/7#issuecomment-274321112
https://github.com/apinf/restivus-swagger/issues/7#issuecomment-274738931
and seems it was initial place, when bcrypt version is pinned.
Regarding to 'Meteor REST' organization package: 'mrest:restivus-swagger' package has 'mrest:restivus' as dependency, but I'm using 'nimble:restivus'.
I'm a bit confused. Who is maintainer for each of this packages?
As I understood, @kahmali is maintainer of nimble:restivus and @alfredjkwak initially developed apinf:restivus-swagger.
@alfredjkwak Could you clarify the situation? What is the difference between nimble:restivus and 'mrest:restivus'? Heads of this repositories are diverged now.

@radik Some of those Jan 24 PR merges, https://github.com/kahmali/meteor-restivus/commits/devel introduced bug https://github.com/kahmali/meteor-restivus/issues/259 that people seem to have solved by downgrading Restivus.
So simply put, difference is that mrest:restivus misses those latest merged PRs that nimble:restivus has.
There is also discussion about time constraints of @kahmali https://github.com/kahmali/meteor-restivus/issues/233 So I thought to make initiative to build "Meteor REST community" as had idea to build also other package related to Restivus to support "design-first" way of API development in addition to "code-first" that restivus-swagger supports, check out https://swaggerhub.com/blog/api-design/design-first-or-code-first-api-development/
Thought community organization would be good place to host closely related packages to give developers a better user experience, and it would allow teams, group of maintainers, to join & share workload.
When it comes to Restivus, best place currently to discuss about that would though be https://github.com/kahmali/meteor-restivus/issues/233
Haven't yet got answer from @kahmali if there's interest to transfer Restivus under organization. I have though invited & added him as admin to "Meteor REST" fork of Restivus. I am not interested to compete in any way with the fork, just want good experience for restivus-swagger package users.
I think I put gitter chat for Meteor REST for further discussion, it would be better place to have interactive discussion than this.

Meteor REST lobby: https://gitter.im/meteor-rest
Restivus Swagger room: https://gitter.im/meteor-rest/restivus-swagger

Thanks @dcantatore!

@dcantatore I would like to add you to our Atmosphere organization, so you can publish these package updates. What is your Atmosphere username?

@brylie please add myself too https://atmospherejs.com/mauriciovieira/

@mauriciovieira feito.

@brylie  - On atmosphere I'm: dcantato
I should really stick to one or the other username some day.

@dcantatore I added you. As you can see, we have several collaborators. As a guideline moving forward, please have any PR reviewed by a collaborator before merging. This is a basic idea of peer review, so is not specific to your work.

@brylie Thanks for the heads up, I'll be sure to put things into review in the future.


End time is animating when selecting start time

reproduction

set an initial time range of 9AM to 6PM
select start of 9:30AM

result
end time is animating
expected result
no animation for end time

Hi @cedvdb, When an initial value is selected, the possible final values are recalculated and therefore there is an animation because that list has been rebuilt.

@ikicodedev I'm aware of the underlying cause, it's beside the point though. The UX in that aspect could improve in my opinion. I understand that it is not an easy fix too.


Fixed a bug in googlenet.py

Corrected the order of aux1 and aux2.
Please see Issue https://github.com/pytorch/vision/issues/8736 for details.

CI is failing with tons of unrelated failure that are visible on main as well. Landing.

Thanks a lot @NicolasHug 👍 : D


[FEATURE REQ] add a LIVE test for azure-resourcemanager-appcomplianceautomation

https://github.com/Azure/azure-sdk-for-java/tree/main/sdk/appcomplianceautomation/azure-resourcemanager-appcomplianceautomation
context, we will be GA it this month, with TypeSpec and azure-json
Please check if we can add a simple LIVE for this service, if it is fine to create their resource.

The appComplianceAutomation service needs to be used with Microsoft Partner Center, because the offer GUID serves as a unique identifier for marketplace offer in Microsoft Partner Center, and it's the key to connect the compliance report with marketplace offer(s). So it is recommended that the service does not add any live test cases.

got it, close this


Equipment Slot Manager

I've been thinking I wanted to write a Slot manager.  I'm curious if this is something you think would see as helpful @shawncplus, and if you had any input or thoughts on it.
My reasoning and motivations:

It seems like leaving the slot to a string in each equipment definition could get convoluted with multiple builders over time
I'd ultimately like to have a good base for rolling randomized equipment
Customized equip / un-equip messages, which I'm currently doing in the Wear command.
I'd like different races, classes, effects, or traits to modify a characters slots.

It seems like leaving the slot to a string in each equipment definition

slot is in metadata, it can be any value you want it to be. Items in core don't have a set slot, any item can be placed in any slot. It's up to whatever bundle is calling equip(item, slot) to determine that.
I think you're going to have to describe how you might use it because I'm not exactly  understanding what you mean by your randomizing equipment.
At a glance it seems to me that you may want a class to manage this but I'm not seeing (at least at the moment) why such a class needs to be in core and not just part of your normal library

I'm planning on making a system similar to this as a Ranvier-compatible library/bundle (albeit not in core).
My motivations are similar to yours although I'd also like to use it to simulate body-part-specific wounds, effects, armor systems, and so on in a way that does not have duplicate code all over.
@ratacat let me know if you want to collaborate on that.

Hey @shawncplus !  Ah sorry for the confusion, I wasn't thinking about putting it in Core...I was thinking about writing a Bundle.
@seanohue, I'd love to!  exactly! Lets talk!

@seanohue I actually was planning on writing something for the exact same reasons as you, so I'd love to pitch in if I could. (this is holl0wstar).

Going to move this issue over to the ranviermud repo and label it bundle so we know


language_2 tests f_bounded_quantification2_test and f_bounded_quantification4_test fail to satisfy bounds

I believe both of these tests are erroneous:

tests/language_2/f_bounded_quantification2_test.dart
tests/language_2/f_bounded_quantification4_test.dart

In both cases a type appears in an "extends" clause that is inferred (via instantiate-to-bounds) as a super-bounded type, but super-bounded types aren't allowed in extends clauses.
f_bounded_quantification4_test is simpler so I'll consider it in detail:
import "package:expect/expect.dart";

class A<T extends B<T>> {}

class B<T> extends A {} // (1)

main() {
  Expect.equals("B<B<dynamic>>", new B<B>().runtimeType.toString());
}

According to my reading of https://github.com/dart-lang/sdk/blob/master/docs/language/informal/instantiate-to-bound.md, the type A at (1) should be instantiated to A<B<dynamic>>.  This is a super-bounded type (because it does not satisfy the constraints of A, whereas A<B<Null>> does).  Therefore there should be a compile-time error, since super-bounded types aren't allowed in extends clauses.
f_bounded_quantification2_test is more complex but I believe it has the same problem.
I will soon be making a change to the analyzer to correctly detect this error condition.
@lrhn can you double-check my reasoning here?

True, we cannot have instances whose dynamic type is a superbounded type, because that would compromise the soundness of code which has been compiled under the assumption that the bound is satisfied. So I agree with you that there should be a compile-time error for extends A in the example. I'll take a look at f_bounded_quantification2_test now, and return with a comment on that.

2013! ;-)
Error here, too, maybe in other places as well, but certainly here: implements EntityApi and implements EntitiesApi.

https://dart-review.googlesource.com/c/sdk/+/115779
https://dart-review.googlesource.com/c/sdk/+/115900


[Feature request] Unhide apps

Is your feature request related to a problem? Please describe.
Now, when you hide an app you have restore an Android Flipper Zero app to factory defaults to see all hidden apps again.
Describe the solution you'd like
A list of all hidden apps so you could unhide some of them.

We're not sure if you need it or not - please put 👍 if you need it and 👎 if not


upgrade cmake 3.22.1 to 3.26.0 in prepare-sysroot.sh

What problem does this PR solve?
Issue Number: close #7804
Problem Summary:
What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/check-issue-triage-complete


Fix negative zero for i257 eq gt

Pull Request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[ ] No

Other information

Does this work?

perfect


Proposal: Set go.mod Go language version to oldest supported Go version (1.21 currently)

Currently, our go.mod specifies Go 1.17, meaning that is the oldest version of Go we support and we cannot use language features from newer versions of Go.
Go’s release policy itself is that the most recent 2 major versions are supported (https://go.dev/doc/devel/release#policy), i.e. currently Go 1.21 and Go 1.22.
@dmitshur will file a proposal to update the Go version line in the x repositories to go 1.21, and gopls wants to take a similar step. The main reason is that Go 1.21 introduced forward compatibility and toolchain management (https://go.dev/blog/toolchain), meaning all supported Go versions now support toolchain management.
In light of these developments, Go Protobuf’s Go 1.17 version seems too conservative.
I propose that we set the Go language version in Go Protobuf’s go.mod file to the oldest supported Go version, i.e. currently Go 1.21.
Please let me know ASAP if this would be a big problem for your use-case and why.

@stapelberg, we try to support one add'l release of Go, so we'd appreciate pinning no more recent than Go 1.20, just so we can continue to support Go 1.20 for our own libraries and be able to update to the latest/next release of protobuf-go.
I might also point out that the other major Go libraries, like those in golang.org/x/... all seem to pin 1.18, which a few pinning 1.19. If those packages provide broader support, it seems like it would be valuable for Protobuf to provide the same board support.
Any change you could tweak the recent change to step it back to 1.20 from 1.21?

FWIW, our desire to support one add'l version back mirrors Amazon's support policy with its AWS client libraries for Go: https://github.com/aws/aws-sdk-go-v2?tab=readme-ov-file#go-version-support-policy
I think it is a pretty common stance to want to support one or two prior versions of Go. And since protobuf-go is such a heavily used dependency, it would be a much friendlier stance for projects with dependencies on protobuf (even indirect/transitive) to provide a little more room with regards to the support window.

@jhump Thanks for your comment. I want to address the second paragraph in https://github.com/golang/protobuf/issues/1613#issuecomment-2113378587: the golang.org/x/... modules are only tested with the 2 most recent versions which are supported per Go's policy, not older. Their go directive values are not a good source to infer support from. That directive hasn't been updated regularly to use newer semantics because it has been a manual process thus far, last done holistically in golang/go#60268. As the original issue points out, we plan to work towards automating that process.
The Go project officially supports only the 2 most recent major versions as written down at https://go.dev/doc/devel/release#policy, and it would the Go proposal process would be the best place to suggest a change to that policy. Thanks.

Thanks for your feedback.
@jhump We can consider adding support for one extra deprecated Go version (Go 1.20 in this case) if this really helps large parts of the ecosystem. We wouldn’t want to go back any further than one deprecated version, though.
Before we make that change, can you explain where the motivation comes from, both in the AWS case (do AWS users have trouble updating to newer Go versions?) and in the buf.build case (are your customers actually reliant on deprecated Go versions?), just so that we can better understand and justify this extra work/delay?
Also, can you explain if this situation is expected to improve thanks to the toolchain management features of Go 1.21+, or are you expecting to be perpetually behind the support window?
@perezd No, I don’t think it’s reasonable to treat a language version bump as a breaking change in Go modules. Bumping to v3 will cause incredible ecosystem churn. Ask around among buf.build folks regarding the v1→v2 transition. IIRC, it was someone from buf.build who even asked us to never do a major bump like that ever again.

Since Protobuf is so heavily used by the GCP Go libraries, I would think that page that @perezd linked above would weigh heavily in decisions like this.
Will GCP be okay with updating their policy or with just not pulling in protobuf-go updates for a few months?
I'm not sure how Amazon and GCP landed on these policies. We landed on it just because, in practice, updating the toolchain every 6 months or every year can be painful. While it might usually be painless and drama-free (that's obviously the Go team's intent), there could be other logistics to consider (like if an organization has a monorepo that doesn't support multiple versions of the toolchain, in which case extra testing and coordination is necessary for each update, perhaps from a dedicated developer productivity team). While the updates have recently been very smooth, I certainly remember past Go upgrades that were not (like updating to Go 1.7 and then Go 1.13 at past employer).
The toolchain improvements in Go 1.21 may indeed change our thinking on this. But since we haven't updated our own libraries to that point yet (they all still support Go 1.20), we haven't given it as much thought.

Thanks for the details, folks. I agree that we should align with large users such as the GCP Go libraries.
It might make sense to revisit this once toolchain management is used more in practice. When revisiting, we should first figure out if libraries like GCP Go and AWS can be aligned with Go’s support policy (only 2 versions) before updating Go Protobuf.


Traypublisher: publishing version instance attribute

Is your feature request related to a problem? Please describe.
We need to be able to define specific version on a subset. So we could lock it to only v001 for example.
Describe the solution you'd like
Adding Instance attribute with future version (version above last found) used for publishing. If a user adds manually a version (1) it will override the existing version.
Describe alternatives you've considered
Since it is only simple editorial request, we could add this to subset attributes as it used to be in Standalone publisher. But we would still need to at least show to the user what version it will be published into, so again ideally in instance attributes.
[cuID:OP-4646]

resolved by https://github.com/ynput/OpenPype/pull/5142


[UNR-5750] Add track player mode to gameplay debugger

Description
Add track player mode to gameplay debugger.
Tests
Manual test gym.

tiny pr nit - please link companion engine/gdk prs in the descriptions 🙏

Oh - this will need to increment gdk/engine versions also with the new delegate on the controller


add function to accept Html.ImageGetter

fixes #38

:+1:

I deprecated the old Interfaces and made the Html.ImageGetter the default in 1.8


Throttling based on apache/v1-10-test

Make sure you have checked all steps below.
Jira

[ ] My PR addresses the following Airflow Jira issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-XXX
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a Jira issue.
In case you are proposing a fundamental code change, you need to create an Airflow Improvement Proposal (AIP).
In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Description

[ ] Here are some details about my PR, including screenshots of any UI changes:

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference Jira issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does
If you implement backwards incompatible changes, please leave a note in the Updating.md so we can assign it to a appropriate release

Code Quality

[ ] Passes flake8

Codecov Report

:exclamation: No coverage uploaded for pull request base (v1-10-test@aea9531). Click here to learn what that means.
The diff coverage is 95.31%.

@@              Coverage Diff              @@
##             v1-10-test     #195   +/-   ##
=============================================
  Coverage              ?   76.66%
=============================================
  Files                 ?      509
  Lines                 ?    34392
  Branches              ?        0
=============================================
  Hits                  ?    26366
  Misses                ?     8026
  Partials              ?        0

Impacted Files
Coverage Δ

airflow/bin/cli.py
62.59% <ø> (ø)

airflow/contrib/hooks/gcp_vision_hook.py
91.98% <100%> (ø)

airflow/www/utils.py
83.06% <100%> (ø)

...rflow/contrib/hooks/gcp_video_intelligence_hook.py
71.42% <100%> (ø)

airflow/contrib/hooks/gcp_speech_to_text_hook.py
81.25% <100%> (ø)

airflow/contrib/hooks/gcp_natural_language_hook.py
92.5% <100%> (ø)

airflow/models/dagrun.py
96.46% <100%> (ø)

airflow/contrib/hooks/gcp_translate_hook.py
71.42% <100%> (ø)

airflow/contrib/hooks/gcp_text_to_speech_hook.py
80% <100%> (ø)

airflow/www_rbac/decorators.py
74.5% <100%> (ø)

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aea9531...fe8a0c1. Read the comment docs.


MPI Benchmark json file with cumulative timing and IO

I executed acoustic benchmark with 20 MPI processes and operator Forward ran in 22.90 s.
But each rank generates it's own json file (all generated json files have the same content), line below:
{
    "timestamp": "2020-05-15T043236",
    "meta": {},
    "timings": {
        "section0": {
            "gflopss": 90.69606466220392,
            "oi": 34.961945414101685,
            "timings":<PHONE_NUMBER>9999996
        },
        "section1": {
            "gflopss": 0.1710404425835923,
            "oi": 21.125,
            "timings": 0.001897000000000009
        },
        "section2": {
            "gflopss": 12.967484899349396,
            "oi":<PHONE_NUMBER>6666669,
            "timings": 14.365808999999993
        }
    }
}

So, I have 20 json files with exactly the same content (Why redundancy?).
In section0, the timings is 443.5 s and oi is 34.9, which is comulative for all 20 processes.

Isn't this fixed @jaimesouza

@mloubout It isn't yet. I am working on a PR to fix that.

This issue can be now closed as PR #1295 is merged/


Include native dependencies for RPM and DEB

It would be great if the target rules for the build would include the per-runtime native dependencies for inclusion in the RPM and DEB files. @davidfowl agrees that figuring out the dependencies is far too hard, but until dotnet core includes a list of dependencies in its target files, it would be great if this tool would do it.
I’ll be happy to put that together if you assign the bug to me.

@clemensv There's a default list of dependencies for RPM here:
https://github.com/qmfrederik/dotnet-packaging/blob/35c55a82c8594b341cecdd075328f7e60091c112/Packaging.Targets/build/Packaging.Targets.targets#L46-L82
and for DEB files here:
https://github.com/qmfrederik/dotnet-packaging/blob/35c55a82c8594b341cecdd075328f7e60091c112/Packaging.Targets/build/Packaging.Targets.targets#L132-L153
with the idea being that:

If you have a framework-dependent app, you'll end up with a dependency on the framework
If you have a self-contained app, you'll end up with a dependency on the framework dependencies

There's a couple of flaws in the logic that I know of:

This doesn't account for apps that depend on ASP.NET Core
You'll end up with a dependency on dotnet-runtime-.x.y on ARM64, but Microsoft doesn't provide ARM64 packages for the .NET runtime

So yeah, happy to take any PRs that improve this scenario :)

Is there a way to have a variable version number in there because obviously this doesn't work for dotnet-runtime-3.1 now (or any future version).


New project does not work on Safari 9.1

Version
3.0.5
Reproduction link
https://github.com/koendeschacht/vue-cli-safari-error
Node and OS info
developer machine: Node 9.11.2 / Ubutu Mate 17.10, browser machine: El Capitaine with Safari 9.1.3
Steps to reproduce
Checkout project in https://github.com/koendeschacht/vue-cli-safari-error
Run

npm install
npm run serve

Visit localhost:8080 in Safari 9.1.3 on El Capitaine (e.g. using browser stack)
What is expected?
To see the hello-world vue page.
What is actually happening?
Empty page, and the error console shows:
ReferenceError: Can't find variable: Reflect

Started with a new project, using
vue create hello-world
and then modified .browserslistrc to include Safari >=9

Fixed in vue-class-component v6.3.2


No new companions to recruit

By mid late game when my clan renown is growing, I can't find no new companions to recruit, all of them already are serving AI lords.
While I love AI recruiting companions, it's kinda broke at some point. I know we can hire new companions for gold, but it's goddam expensive!! (6 MILLIONS PER COMPANION!?) Maybe the AI companions could be "fired" when their party is destroyed and they go back searching for jobs. Maybe they could offer their services for the player when the AI lord is defeated by the player himself.
Plus: lifestyles progress way too slow, something like 300 days for a single perk. Also, we could have even more types, way great idea.

+1 I can't find any companions and I'm leveling much much faster than i can afford some from the decisions tab.

+1 Same issue. Have to hit up every tavern in Calradia until I'm lucky enough to find a single companion to recruit.


Cannot Handle HTTP 403

Recently one of my following friendica server think user-agent sent by microblog/little-boxes is a bot, and then return HTTP 403 which little-boxes backend cannot handle it.
I quick fix it on my running instance by adding 403 to the line elif resp.status_code in [500, 502, 503]: in backend.py, but I think it's not a right thing to do.

Hey, any idea why Friendica is blocking the user agent? It seems weird to me that they block "unknown" user agent (unless it's a private instance maybe?)
I will try to take a look at Friendica codebase, and on microblog.pub side, when receiving a 403, except giving up, I don't see what else it can do in this case.

I don't know why, may be just only that user put me in black list or something. another following user on the same friendica host do not return 403.
btw, if you think 403 should be handled on the microblog.pub side instead of little-boxes, then please feel free to close this issue.


Add pytest and initial tests

Summary
Setup pytest and add happy path tests. In collaboration with @apkallum.
Changes these areas

[ ] Bugfixes
[X] Feature behavior
[ ] Command line interface
[ ] Configuration options
[ ] Internal architecture
[ ] Archived data layout on disk

Looks good so far, you can use the stdlib to create the temporary directory for the tests: https://docs.python.org/3/library/tempfile.html#tempfile.TemporaryDirectory

@pirate We are using this fixture https://docs.pytest.org/en/latest/tmpdir.html
It creates a temp dir in the same fashion (built-in in pytest).

Cool. Lets setup github actions next to run these tests automatically on pull! (in this same PR)

@pirate Added Github workflow.


Ivanchean/frameworklauncher docs

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ivanchean sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Enable strong-signing using GeoJSON.Net key

This enables assembly signing using the key that was recently added to the main GeoJSON.Net project. Unsigned assemblies cannot be used from signed assemblies, which is a potential roadblock for adoption.

Thanks @jgoz !


Add audio FIFO

I added an audio FIFO to the astiav library to support audio transcoding, such as AAC to Opus and Opus to AAC.

I applied your all requests.

Great! I'll merge the PR and do some minor tweaks to avoid bothering you too much 👍
Let me know whether you need a tag

I need new version tag. Advance thank you.

I've created the v0.19.0 tag 👍


Node statistics not updating while hovering

This is during an ongoing firmware upgrade. Notice how the green arrows are blinking and the firmware update is progressing, but no stats are changing:
https://user-images.githubusercontent.com/17641229/154560803-d0952df8-af02-430f-ac1c-2e5b41e2ef89.mp4

Actually, it never updates...

@AlCalzone Are you running latest from master?

Which browser?


duplicated extension status: Add the same test as for go-verkle

the test fails, because it tests for an agreement with the output of go-verkle, thus demonstrating the problem

Thanks for the PR, currently checking if this deduplication can be introduced after we've produced the proof of absence stems instead of introducing an edge case when collecting the proof of absence stems

I'm getting the following stacktrace after upgrading to that branch:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/gballet/.cargo/git/checkouts/rust-verkle-93a9500a914bcd55/b05a8e9/verkle-trie/src/proof.rs:151:50
stack backtrace:
   0: rust_begin_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:107:14
   2: core::panicking::panic
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:48:5
   3: core::option::Option<T>::unwrap
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/option.rs:746:21
   4: verkle_trie::proof::VerificationHint::decompress
             at /home/gballet/.cargo/git/checkouts/rust-verkle-93a9500a914bcd55/b05a8e9/verkle-trie/src/proof.rs:151:31
   5: verkle_trie::proof::VerkleProof::check
             at /home/gballet/.cargo/git/checkouts/rust-verkle-93a9500a914bcd55/b05a8e9/verkle-trie/src/proof.rs:355:9
   6: verkle_block_sample::main
             at ./src/main.rs:85:24
   7: core::ops::function::FnOnce::call_once
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


#28 feature: admin-license

PR Description
This PR gives admin license to disable and immediately email user in case there is any rule violation occurred
Description of tasks that were expected to be completed
List all the tasks and sub-tasks that were assigned to you Make sure you check every completed task. list them in this style

[ ] disable user account
[ ] emailing user after disable their account
[ ] ......

Description of tasks that were expected to be completed and that are not yet completed

[ ] none

How this may be tested?
This can be tested by changing the status of user we have in our database
Please also list any relevant details for your test configuration.

run npm i to install all required dependencies
run npm run dev
open postman or swagger
update status of user

Screenshots (If appropriate/applicable)
Provide screenshots related to your PR in case it's appropriate and applicable
Please check this Checklist before you submit your PR:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have commented on my code, particularly in hard-to-understand areas
[ ] My code generates no warnings
[ ] There are no vulnerabilities

user email and password can be hidden using .env files.

thank you! it is now modified


Change behavior of deno branch to create 'gluon_data/chrome' in current directory

When running the compiled exe of the deno branch, it creates 'gluon_data/chrome' in the physical path of the developer's project. This behavior is inconvenient when distributing the exe to third parties.
After reviewing the implementation in 'gluon/src/index.js', it was found that the browser's temporary directory is created using fileURLToPath(import.meta.url) and files are placed there. import.meta.url contains the physical path of the project at compile time in the compiled exe. Therefore, the behavior is determined by where the developer clones the gluon project.
I would like to request that 'gluon_data/chrome' be created in the current directory instead.
Here are relevant lines from 'gluon/src/index.js' :
(Line 17)
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

(Line 147)
const ranJsDir = !Deno.args[0] ? __dirname : (Deno.args[0].endsWith('.js') ? dirname(Deno.args[0]) : Deno.args[0]);
const getDataPath = browser => join(ranJsDir, 'gluon_data', browser);

Thank you for your attention to this issue.

Thanks for the report and PR (merged), sorry for the wait. Deno branch has kind of been left but I plan to integrate it into main soon (this month likely).


question about requirements

Hi@aorriaga
Thanks for your sharing!
I used this code but I have a question.What is the statistics in your requirements?Is it statsmodel in python or others?When I used it ,it will raise:
File "video_emotion_color_demo.py", line 1, in
   from statistics import mode
  ImportError: No module named statistics  ###

I found some way,but it didn't work.
Thanks
Lifei

pip install statistics worked for me

@mirceaciu Thank you! I used this method before,but it didn't work.Probably a version question.I will try again.Thank you!


MotionLayout is not compatible with R8 full mode (without proguard rules)

I faced an app crash when using R8 full mode which removes constructors more aggressively.
MotionLayout is using getConstructor() method in the KeyFrames class here :point_down: and it cause the problem.
https://github.com/androidx/constraintlayout/blob/eb540e400fd01d6c4e3f795343a8f548d83aef3f/constraintlayout/constraintlayout/src/main/java/androidx/constraintlayout/motion/widget/KeyFrames.java#L50
The following proguard rule resolves the issue, but I think this should be bundled in consumerProguard by default.
-keepclassmembers class * extends androidx.constraintlayout.motion.widget.Key {
  public <init>();
}

This should be fixed ASAP as since Gradle 8.0 R8 full mode is on per default
https://developer.android.com/build/releases/gradle-plugin

I'm also running into this issue. My KeyFrames do not work - they are ingored, no crashes so far - if R8 full mode is enabled

We will directly link in the future. We will move away from use of Java Reflection APIs.

I had the same issue and I solved the problem by moving <KeyFrame> features to <ConstraintSet>.


Fix some clippy warnings

Thanks! These changes look good, but I'm trying to figure out why I don't see them when I run cargo clippy. cargo clippy --version says 0.1.52 for me; are you maybe using the nightly toolchain?

Yeah. i use nightly rust since some clippy warning are activate by default only on nightly for now.

Makes sense. This is a good lint, hope it makes it to stable soon. Thanks for the PR!


Document Intelligence Error

It is giving error 404 at the end where as it worked with Formrecogniser:
endpoint = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

document_intelligence_client = DocumentIntelligenceClient(
    endpoint=endpoint, credential=AzureKeyCredential(key)
)
folder_path = "C:/Users/MehmoodU/Downloads/Jupyter/proper flow/Oven_jobs/bill/"
all_files = os.listdir(folder_path)
pdf_files = [file for file in all_files if file.endswith('.pdf')]
pp = 0
for pdf_file in pdf_files:
    # Extract the file name without the extension
    pdf_name = os.path.splitext(pdf_file)[0]
    pp = 1 + pp
    print(pp)
    with open("C:/Users/MehmoodU/Downloads/Jupyter/proper flow/Oven_jobs/bill/"+pdf_name+".pdf", "rb") as pdf_file:
        print(pdf_file)
        time.sleep(1)
        poller = document_intelligence_client.begin_analyze_document("prebuilt-invoice", pdf_file)
    invoices = poller.result()
    print(invoices)

The error is as follows:

Hi @ubaidmehmood93 thanks for the feedback, we will get back to you asap.

Hi @ubaidmehmood93 , which region are you using? Can you try with one of the available regions listing here?


Next.js example not working

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
Follow the next.js example in this repo and get a working material-ui+next.js setup
Current Behavior

 DONE  Compiled successfully in 1897ms                                                       11:35:49 AM

Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in. Check your code at _document.js?entry:65.
    in Unknown (created by Container)
    in AppContainer (created by Container)
    in Container (created by App)
    in div (created by App)
    in App
{ Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in. Check the render method of `StatelessComponent`.
    at invariant (/Users/albinekb/Devel/Temp/nextjs/node_modules/fbjs/lib/invariant.js:44:15)
    at ReactCompositeComponentWrapper.instantiateReactComponent [as _instantiateReactComponent] (/Users/albinekb/Devel/Temp/nextjs/node_modules/react-dom/lib/instantiateReactComponent.js:74:56)
    at ReactCompositeComponentWrapper.performInitialMount (/Users/albinekb/Devel/Temp/nextjs/node_modules/react-dom/lib/ReactCompositeComponent.js:366:22)
    at ReactCompositeComponentWrapper.mountComponent (/Users/albinekb/Devel/Temp/nextjs/node_modules/react-dom/lib/ReactCompositeComponent.js:257:21)
    at Object.mountComponent (/Users/albinekb/Devel/Temp/nextjs/node_modules/react-dom/lib/ReactReconciler.js:45:35)
    at ReactCompositeComponentWrapper.performInitialMount (/Users/albinekb/Devel/Temp/nextjs/node_modules/react-dom/lib/ReactCompositeComponent.js:370:34)

Steps to Reproduce (for bugs)

Get this code https://github.com/callemall/material-ui/tree/v1-beta/examples/nextjs
Install it yarn
Run it yarn dev

Thank you so very much @oliviertassinari works like a breeze now ❤

Thanks for raising it :).


Addresses #3/#26, fixes dependencies

This addresses #3 and #26 by implementing vladmandic's suggestion for detecting inpainting (https://github.com/megvii-research/HiDiffusion/issues/3#issuecomment-2075043414), and by adding an optional parameter to support playground models.
It also addresses several typos and missing dependencies, and removes unused dependencies.

I just came here to drop a line that this PR would indeed fix the errors:
Traceback (most recent call last):
  File "/Users/aimeri/projects/personal/promptkouhai/chat/ui/windows/chat_window.py", line 1323, in generate_scene_image
    result = await self.generation_manager.generate(generation_params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/<redacted>.py", line 203, in generate
    images = await self.pipeline.generate(**generation_params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/<redacted>/sdxl_pipeline.py", line 157, in generate
    apply_hidiffusion(pipeline)
  File "/Users/<redacted>/lib/python3.12/site-packages/hidiffusion/hidiffusion.py", line 1961, in apply_hidiffusion
    'is_inpainting_task': 'inpainting' in model.name_or_path,
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument of type 'NoneType' is not iterable

I just applied this patch manually to the file in the conda lib to test it a couple of weeks ago, and it worked so well I forget that I had done that until last night when I started a new conda env and forgot about this fix and my app broke completely. Took me two hours to remember that I had applied some patch at some point, so commenting here now to leave breadcrumbs for future me until this gets merged in.
Thank you @JohnnyStreet for this fix, and @ShenZhang-Shin and team for this library. My main usecase for it is to keep memory consumption under control for SDXL models on a mac, and without hidiffusion I would not be able to build my app.


PDF fails to load in Firefox.

This PDF isn't loading with the builtin pdf.js in Firefox (Build identifier: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0): http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=8F5424CF7B842FD327A1D5E7B19C89F6
Error message: An error occurred while loading the PDF.
PDF.js v2.7.570 (build: f2c7338b0)
message：NetworkError when attempting to fetch resource.
However, it can be opened in Chrome,

This PDF isn't loading with the builtin pdf.js in Firefox (Build identifier: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0): http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=8F5424CF7B842FD327A1D5E7B19C89F6

This is confusing, since the provided link points to a custom version of the PDF.js demo viewer and doesn't actually use the browser built-in PDF Viewer.
Furthermore, opening that link in either Mozilla Firefox or Google Chrome throws an empty-file Error (i.e. The PDF file is empty, i.e. its size is zero bytes.) which suggests that you're trying to load an empty/incorrect PDF document or that the server doesn't return the correct data, neither of which we unfortunately cannot help fix.
Furthermore, it appears that the viewer has been customized in various ways. E.g. some methods seem to be missing on PDFViewerApplication, and somewhere in your code a global PDFJS object is defined (we removed that with the first release from the 2-branch). All-in-all, this makes it very difficult for anyone to tell what might be going wrong.

PDF.js v2.7.570

That version is no longer supported, please find the latest releases at https://mozilla.github.io/pdf.js/getting_started/#download
Finally, when opening an issue, please provide all of the information requested in https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md since as-is this unfortunately isn't really actionable.
Also, it next to impossible to debug a customized viewer like this; please see https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):

If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us in the Matrix room -- keep in mind that just code snippets won't help us troubleshoot the problem.


Assertion macro

Things to consider:

macro name (and whether to use uppercase or lowercase)
format of print() message
whether to use print() if it succeeds
a possible way to disable ASSERT from affecting the executable
a possible way to disable print() when it succeeds

@siddMahen @bonnieweng1T9 @shrey-p
What are your thoughts? Consider the things I listed above and any other things you think of.

Would that be part of the future error handling system?

@brunofalmeida I think this is a great start. More refine can come later, when people actually start using assert. (1) I'm a fan of using upper case for macros, as long as we document it and make people to be consistent.  For (2)-(5), I think what you have right now is good to start. Thanks for writing it up!!

@shrey-p If assert fails, this means we gotta debug our program code, mate. We don't handle errors in this context, at least for now. This whole assertion based testing is a framework for as to make all our existing software are functional and reliable.

As for error handling/ execution for OBC, by all means, sure, we can use a more advanced version of assert along with/ or ISR. But this is not the priority software task yet. At least not for qual.


Poles tiles distortion

I can't solve the poles distortion of my tilemap. Could be related with the projection, or the 3d polygon mesh of the sphere? I may appreciate any help. Thank you.

Also, voting for this bug!


Remove Create/Delete/Update actions from WIT/WILT/WILC controllers

With space templates we might open the possibility to change WITs/WILTs/WILCs soon but that requires different handling and a more sophisticated strategy than just modifying them.
Most of the actions returned a MethodNotAllowed error by default before, so it is safe to remove them. The tests have been refactored to use golden files and sub-tests in all places.
Outsourced from #1148

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1987-1

@kwk snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1987-2

Codecov Report

Merging #1987 into master will increase coverage by 0.18%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1987      +/-   ##
==========================================
+ Coverage    64.7%   64.89%   +0.18%
==========================================
  Files         147      147
  Lines       13825    13624     -201
==========================================
- Hits         8946     8841     -105
+ Misses       4045     3955      -90
+ Partials      834      828       -6

Impacted Files
Coverage Δ

controller/work_item_link_type.go
84.39% <ø> (+25.54%)
:arrow_up:

controller/workitemtype.go
61.26% <ø> (-22.34%)
:arrow_down:

controller/work_item_link_category.go
73.33% <ø> (+25.21%)
:arrow_up:

workitem/workitemtype_repository.go
67.96% <0%> (-4.69%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1f45eef...7b7c181. Read the comment docs.


Fix sorting in mapping constructor context

Purpose
Fixes #33623
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[x] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

type Pet record {|
    string name;
    int 'type;
|};

type Dot record {|
    string name;
    int 'type;
|};

public function main() {
    Pet[] pets = [];
    Dot[] dots = [];

    pets.push({});
    dots.push({});

    PetStore petStore = new;
    petStore.addPets({<cur>});
    petStore.addPet({});
}

class PetStore {

    function addPets(Pet[] pets) {

    }

    function addPet(Pet pet) {

    }
}

Is there a way that we can give priority for the suggestion pets over dots at the cursor in this scenario?

As I understood, at the given cursor position we just suggest the available variables for the mapping constructor. We cannot make a decision to sort the content since what we are trying to add as a parameter is semantically ambiguous in this context. But I think you have a good point here, and we can address this with some other UX, such as with an associated refactoring option - additional text edits. WDYT?

type Pet record {|
    string name;
    int 'type;
|};

type Dot record {|
    string name;
    int 'type;
|};

public function main() {
    Pet[] pets = [];
    Dot[] dots = [];

    pets.push({});
    dots.push({});

    PetStore petStore = new;
    petStore.addPets({<cur>});
    petStore.addPet({});
}

class PetStore {

    function addPets(Pet[] pets) {

    }

    function addPet(Pet pet) {

    }
}

Is there a way that we can give priority for the suggestion pets over dots at the cursor in this scenario?

As I understood, at the given cursor position we just suggest the available variables for the mapping constructor. We cannot make a decision to sort the content since what we are trying to add as a parameter is semantically ambiguous in this context. But I think you have a good point here, and we can address this with some other UX, such as with an associated refactoring option - additional text edits. WDYT?

+1


Write help message when typing just fly

@jwfriese recently started using fly and found it really confusing that it does not just print the help when you execute with no args. Made this a little nicer for new people.
Also, templates have been broken apart but still manage to print errors the same way.
💥

Thank you for the pull request! I think this is a great idea.
The templating seems to cause slight changes in the error outputs, so I am going to merge this without those templating changes.
 $ ./fly -t vbox login -c https://<IP_ADDRESS>:4443/
logging in to team 'main'

could not reach the Concourse server called vbox:

    Get https://<IP_ADDRESS>:4443/api/v1/info: x509: certificate signed by unknown authority

is the targeted Concourse running? better go catch it lol
$ fly -t vbox login -c https://<IP_ADDRESS>:4443/
logging in to team 'main'

could not reach the Concourse server called vbox:

    Get https://<IP_ADDRESS>:4443/api/v1/info: x509: certificate signed by unknown authority

is the targeted Concourse running? better go catch it lol


Allow users to add Semester data when adding Module

Currently, add command only allow users to add module with module code. Let's allow users to add semester details when they add modules too.
Command
add CS1101S s2
However,
add CS1010J s2 throws error as CS1010J is not offered in s2.
Semester code: s1, s2, st1, st2
Rationale

Allow users also to check whether module is offered in the particular semester when they add it into the list
I personally feel that we shouldn't let users add modules first, and then later let users set/change the semester because I think that module semester and module code should be the keys to obtain the other information of the modules. What do y'all think?

Problems faced
Should we also allow users to add modules without the need to specify which semester they are taking? If we allow so, should we set the default semester of the module based on the System date when the module is added by the user?
TODO
[] Test cases
[] Update User Guide

Codecov Report
Base: 28.88% // Head: 30.00% // Increases project coverage by +1.12% :tada:

Coverage data is based on head (3f9cfce) compared to base (cfcfd8f).
Patch coverage: 50.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #85      +/-   ##
============================================
+ Coverage     28.88%   30.00%   +1.12%
- Complexity      312      325      +13
============================================
  Files           123      124       +1
  Lines          3054     3079      +25
  Branches        329      332       +3
============================================
+ Hits            882      924      +42
+ Misses         2087     2067      -20
- Partials         85       88       +3

Impacted Files
Coverage Δ

...java/nus/climods/logic/commands/DeleteCommand.java
8.33% <ø> (ø)

...main/java/nus/climods/logic/parser/ParserUtil.java
48.14% <0.00%> (-13.76%)
:arrow_down:

...ava/nus/climods/logic/parser/AddCommandParser.java
42.85% <25.00%> (-7.15%)
:arrow_down:

...main/java/nus/climods/model/module/UserModule.java
20.00% <53.84%> (+20.00%)
:arrow_up:

...in/java/nus/climods/logic/commands/AddCommand.java
69.23% <100.00%> (+60.89%)
:arrow_up:

...logic/parser/parameters/SemesterTypeParameter.java
100.00% <100.00%> (ø)

...g/openapitools/client/model/ModuleInformation.java
29.47% <0.00%> (+1.05%)
:arrow_up:

...ient/model/ModuleInformationSemesterDataInner.java
25.00% <0.00%> (+2.77%)
:arrow_up:

...nus/climods/model/module/UniqueUserModuleList.java
24.39% <0.00%> (+12.19%)
:arrow_up:

... and 5 more

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.


Redirect to docs.ros.org as appropriate.

Signed-off-by: Chris Lalancette<EMAIL_ADDRESS>This PR redirects all of the pages from the master branch here to https://docs.ros.org , which is the new home of the ROS 2 documentation.  Once this PR is merged (and the https://build.ros.org/job/doc_rosindex/ job gets run), all links of the form https://index.ros.org/doc/ros2/* will redirect to their equivalent pages on https://docs.ros.org.
I've tested out all of the redirection pages that get generated, and as far as I can tell they all work properly.
There are two problems with this PR (though I don't think either is blocking):

Since we don't have the "Crystal" installation instructions on https://docs.ros.org, there is no place to redirect those pages to.  That means they'll continue to be served from https://index.ros.org/doc/ros2, which is untidy. - We've decided to include Crystal instructions so we can redirect all links.  See #1118 which adds it to the list for rolling.
Links to things like the "Tutorials" are hard-coded to the Foxy tutorials.  This isn't ideal, as when a new release comes out we would probably like to have those point to the new release.  Unfortunately, there is already a 'latest' symlink on https://docs.ros.org that points to the latest ROS 1 release, so we can't use that.

Thoughts on what to do about the above two points are welcome.
After we merge this PR, I'll change the default branch from 'master' -> 'rolling', and development will continue from there.

We should definitely update the README in this branch to mention the content is no longer used and go see rolling or the specific version branches.

Yep, excellent point.  I'll rewrite the README.

Related, can we actually delete the content and still have the redirects work? I think that will also decrease confusion.

Unfortunately we can't delete the files completely, otherwise the dictionary key mapping that reredirect uses has nothing to compare against.  One thing we may be able to do is make the files mostly empty, with just a small note saying this is deprecated.  I'll play around with that and see how that works.

All right, I was able to remove all of the content, and I updated the README.md.  The diff is going to be hard to read now, but the most important thing to look at is the conf.py.  Other than that, most of the rest is just removing things and adding :orphan: to the top of every page so that sphinx doesn't complain about it.  Please take another look.

Thanks for the fixups. Using the orphan directive is good too.

Thanks.  I'm going to rebase this to fix the conflicts, then post to Discourse to announce the change.