log(engine): support multi-projects/tasks  log

What problem does this PR solve?

Issue Number: close #5608
What is changed and how it works?
Return logger with const fields
Check List
Tests

Unit test

Release note
 `None`.

Codecov Report

Merging #5661 (b60a947) into master (fcea4d5) will increase coverage by 0.5186%.
The diff coverage is 56.7876%.

Flag
Coverage Δ

cdc
61.8534% <62.5664%> (+0.7052%)
:arrow_up:

dm
52.0195% <12.2807%> (-0.0232%)
:arrow_down:

engine
58.6805% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #5661        +/-   ##
================================================
+ Coverage   56.0768%   56.5955%   +0.5186%
================================================
  Files           535        677       +142
  Lines         70143      79008      +8865
================================================
+ Hits          39334      44715      +5381
- Misses        27078      30085      +3007
- Partials       3731       4208       +477

/hold

/unhold

/run-all-tests

/merge


ui-scrollpoint-bottom feature

allows ui-scrollpoint to work from bottom of its target rather than top.

Closing in favour of PR https://github.com/angular-ui/ui-scrollpoint/pull/8 which includes ui-scrollpoint-bottom and percentage-based scrollpoints.


doesn't work with v3 burrow

Hi,
this doesn't work with the new v3 api from Burrow. Is it correct?

Looks like it's currently hard coded against Burrow v2 endpoint: https://github.com/splee/burrower/blob/master/src/main/scala/com/github/splee/burrower/OffsetMonitor.scala#L65

@aaronbannin is right, but there's one more minor compatibility issue. I have patched the code to work with v3 API. Feel free to use my patched version: https://github.com/pikrzysztof/burrower


Restructures around submodules and adds support for root zones

The description on the root module's README needs to be updated. We are no longer assuming that the root zone has already been created.


Use direct path to rake file

Before this, we were relying on the Gem's lib dir being on the $LOAD_PATH, and thus load would find the tasks/doc.rake file. This can break when a different gem also has a tasks/docs.rake file, and it's further up in the load path. Same goes for a Rails app with a tasks/docs.rake file existing. This ensures we get OUR tasks/docs.rake file.

Thanks!


Could you please describe the need for #3 in that issue?
Thanks!


Time filters are not applied to annotation layers of type Line Chart [Legacy]

I have a metric and it's target value (which depends on time). I need to plot them together.
For this I've picked Time-Series line Chart to plot factual values and applied annotation of Time series type to plot target values. The annotation itself is Line Chart [Legacy] plot. The problem is that on the dashboard, when time filters are applied, annotation time-series doesn't change. I've tried to play with "override time range" and "override time grain" options. But nothing works.
How to reproduce the bug

create Time-Series line Chart (plot 1)
create Line Chart [Legacy] (plot 2)
add plot 2 as time-series annotation to plot 1.
Put plot1 into dashboard and try to play with time range/time grain. plot 1 range/aggregation will change, while plot 2 will not

Expected results
I've expected time-series annotation to behave the same why as the "main" plot
Actual results
Described above
Screenshots
Time range annotation (plot 2 in the list above)

"Main" plot (plot 1 in the list above)

How it looks on dashboard. The problem is in red oval

Environment
(please complete the following information):

browser type and version: Chrome Desktop. Version 116.0.5845.140 (Official Build) (arm64)
superset version: 2.1.1
python version: 3.8.18
node.js version: 16
any feature flags active: Dashboard RBAC, Alert-Reports

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any
2023-09-14 14:09:08,689:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,712:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,778:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,790:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,802:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,877:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,892:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,894:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,905:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,990:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:08,999:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,008:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,072:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,094:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,104:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,172:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,182:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,199:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limitis deprecated, please useseries_limitinstead. 2023-09-14 14:09:09,275:WARNING:superset.common.query_object:The fieldtimeseries_limitis deprecated, please useseries_limitinstead. The fieldtimeseries_limit_metricis deprecated, please useseries_limit_metricinstead. 2023-09-14 14:09:09,275:WARNING:superset.common.query_object:The fieldtimeseries_limit_metricis deprecated, please useseries_limit_metricinstead. The fieldseries_limit_metricis already populated, replacing value with contents fromtimeseries_limit_metric. 2023-09-14 14:09:09,275:WARNING:superset.common.query_object:The field series_limit_metricis already populated, replacing value with contents fromtimeseries_limit_metric.
[yes ] I have reproduced the issue with at least the latest released version of superset.
[ yes] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
None

Having the same problem

tried to pass {{from_ddtm}} {{to_ddtm}} as a part of query for a layer it did not help.

Closing this as stale... we've since migrated away from the legacy timeseries chart. I think you can now use the Mixed Series chart to this effect, plotting two line charts together. Hope that works out!


Re-add "inspect" on examples with after: pragma

#3123 removed the inspect button on examples with an àfter:pragma. Instead, we should add it, but allow to choose whetherafter:` is run or not.
Cheers


Prepare for v0.5.0 release

Bump version in pyproject.toml
Update changelog
Add author

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.004%) to 93.538%

Totals

Change from base Build<PHONE_NUMBER>:
-0.004%

Covered Lines:
1766

Relevant Lines:
1888

💛  - Coveralls


Getting 'missing return at end of function' after panic / in dead code

Can't compile a function with no return after panic.
IMHO, adding the 'panic' clause after 'throw' in the following example is a dead code and should be omitted.
package main
import "fmt"

func throw(message string){
	panic(message)
}

func foo(value int) int{
	switch value {
	case 1:
		return 2
	case 3:
		return 4
	}
	throw("Can't do this!")
	//panic("Can't do this!") // uncomment this to compile.
}

func main() {
	fmt.Printf("Hello world: %v", foo(1))

}

expected: code compiles.
got: ./test.go:18: missing return at end of function
version:
go version go1.5.1 darwin/amd64
go version go1.5.1 windows/amd64

Working as intended. The compiler doesn't look into function calls (throw) to determine if a function terminates or not. The spec rules are pretty clear about this.


Can it's support Adreno 650 gpu?

Output of 'strings libarm_compute.so | grep arm_compute_version':
Platform:
Android
Operating System:
11

Problem description:

Hi @Saikatsaha1996
ACL is optimised for both Arm CPUs and GPUs using SIMD technologies. While it could certainly work on devices with support for OpenCL 2.0 you will see the best results using it in conjunction with arm CPUs or GPUs.
The library requires OpenCL1.1 with support of non uniform workgroup sizes or OpenCL2.0.
Please take a look at the latest documentation for more information: https://arm-software.github.io/ComputeLibrary/v21.02/index.xhtml#S3_7_cl_requirements
Hope this helps

Please please can you share any tutorial videos ?..
Actually I don't have knowledge about code c++, jave ,c language but I want to increase my OpenCL gpu performance... My and mobile gpu driver OpenGL ES 3.2 .. but I saw in my device already available OpenCL 2.0 but showing max gpu frequency 1Mhz ... ...

Hi @Saikatsaha1996
I'd suggest first learning C/C++ or python.
Your GPU manufacturer would advice which is the best solution for you (google adreno gpu sdk). ACL is developed for MALI GPUs and not Adreno.
Hope this helps.


[C3] Pin create-cloudflare framework dependencies to specific versions

What this PR solves / how to test:
We've been working off of @latest versions of all the framework scaffolding tools to catch bugs during initial development. As we prepare to launch we need to pin these to specific versions for now to ensure stability.
We'll follow this up sometime in the near future with some work to run the e2e tests against latest versions and bump versions if successful. With this in mind I've stored the versions in a versionMap.json file to make it a little easier to work with from a CI script.
Test by running npm run test:e2e from create-cloudflare.
Author has included the following, where applicable:

[ ] Tests
[ ] Changeset (Changeset guidelines)

Reviewer is to perform the following, as applicable:

Checked for inclusion of relevant tests
Checked for inclusion of a relevant changeset
Checked for creation of associated docs updates
Manually pulled down the changes and spot-tested

I suggest running prettier on this workspace 😃


web_extra_exposed_ports does not work before DDEV v1.20.0

Is there an existing issue for this?

[X] I have searched the existing issues

Run a Diagnostic and Paste Link Here
Running bash [-c /var/folders/t1/4_3n0nwn08912ct79_zh2_h80000gn/T/test_ddev.sh]
OS Information: Darwin macbook-pro.lan 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:35:58 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T6000 arm64
User information: uid=501(c) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)
DDEV version:  ITEM             VALUE
DDEV version     v1.19.3
architecture     arm64
db               drud/ddev-dbserver-mariadb-10.3:v1.19.3
dba              phpmyadmin:5
ddev-ssh-agent   drud/ddev-ssh-agent:v1.19.0
docker           20.10.14
docker-compose   v2.5.1
docker-platform  docker-desktop
mutagen          0.14.0
os               darwin
router           drud/ddev-router:v1.19.3
web              drud/ddev-webserver:v1.19.3-1
======= DDEV global info =========
Global configuration:
instrumentation-opt-in=true
omit-containers=[]
mutagen-enabled=false
nfs-mount-enabled=false
router-bind-all-interfaces=false
internet-detection-timeout-ms=750
disable-http2=false
use-letsencrypt=false
letsencrypt-email=
table-style=default
simple-formatting=false
auto-restart-containers=false
use-hardened-images=false
fail-on-hook-fail=false
required-docker-compose-version=
use-docker-compose-from-path=false
no-bind-mounts=false
======= DOCKER info =========
docker location: lrwxr-xr-x  1 root  wheel  54 Oct  5  2021 /usr/local/bin/docker -> /Applications/Docker.app/Contents/Resources/bin/docker
Docker Desktop Version: Docker Desktop for Mac 4.8.2 build 79419
docker version:
Client:
Cloud integration: v1.0.24
Version:           20.10.14
API version:       1.41
Go version:        go1.16.15
Git commit:        a224086
Built:             Thu Mar 24 01:49:20 2022
OS/Arch:           darwin/arm64
Context:           default
Experimental:      true
Server: Docker Desktop 4.8.2 (79419)
Engine:
Version:          20.10.14
API version:      1.41 (minimum version 1.12)
Go version:       go1.16.15
Git commit:       87a90dc
Built:            Thu Mar 24 01:45:44 2022
OS/Arch:          linux/arm64
Experimental:     false
containerd:
Version:          1.5.11
GitCommit:        3df54a852345ae127d1fa3092b95168e4a88e2f8
runc:
Version:          1.0.3
GitCommit:        v1.0.3-0-gf46b6ba
docker-init:
Version:          0.19.0
GitCommit:        de40ad0
======= Mutagen Info =========
======= Docker Info =========
Docker platform: docker-desktop
Using docker context: default (unix:///var/run/docker.sock)
docker-compose: v2.5.1
Using DOCKER_HOST=unix:///var/run/docker.sock
Docker version: 20.10.14
Able to run simple container that mounts a volume.
Able to use internet inside container.
Docker disk space:
Filesystem                Size      Used Available Use% Mounted on
overlay                  58.4G     16.7G     38.7G  30% /
Container ddev-BJE-Gas-Station-Processor-dba  Removed
Container ddev-BJE-Gas-Station-Processor-web  Removed
Container ddev-BJE-Gas-Station-Processor-db  Removed
Network ddev-bje-gas-station-processor_default  Removed
Project BJE-Gas-Station-Processor has been stopped.
The ddev-ssh-agent container has been removed. When you start it again you will have to use 'ddev auth ssh' to provide key authentication again.
Existing docker containers:
CONTAINER ID   IMAGE                           COMMAND                  CREATED          STATUS                      PORTS     NAMES
8b3c77c3cfa9   drud/ddev-webserver:v1.19.3-1   "sh -c 'df / | awk '…"   58 minutes ago   Exited (0) 58 minutes ago             hopeful_almeida
Creating a new ddev project config in the current directory (/Users/c/tmp/tryddevproject-17366)
Once completed, your configuration will be written to /Users/c/tmp/tryddevproject-17366/.ddev/config.yaml
Found a php codebase at /Users/c/tmp/tryddevproject-17366
Project type has no settings paths configured, so not creating settings file.
Configuration complete. You may now run 'ddev start'.
Network ddev_default created
Starting tryddevproject-17366...
Container ddev-ssh-agent  Started
ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys.

Project type has no settings paths configured, so not creating settings file.
Successfully started tryddevproject-17366
Project can be reached at https://tryddevproject-17366.ddev.site https://<IP_ADDRESS>:49518

curl --fail -I http://tryddevproject-17366.ddev.site
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Wed, 17 Aug 2022 17:01:08 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding

'[' 0 -ne 0 ']'

curl --fail http://tryddevproject-17366.ddev.site
Success accessing database... db via TCP/IP
ddev is working. You will want to delete this project with "ddev delete -Oy tryddevproject-17366"+ '[' 0 -ne 0 ']'

set +x
Thanks for running the diagnostic. It was successful.
Please provide the output of this script in a new gist at gist.github.com
Running ddev launch in 5 seconds

Current Behavior
https://ddev.readthedocs.io/en/latest/users/extend/customization-extendibility/
Above page outlines the behavior of web_extra_exposed_ports.  I have created the following config in my config.yaml at the top-level:
web_extra_exposed_ports:
  -
    name: node
    container_port: 3000
    http_port: 2999
    https_port: 3000

I have a basic node http server running on port 3000 using a post-start hook:
const server = http.createServer(async function(_request, response) {
  const outputString = 'test';
  response.writeHead(200, { "Content-Type": "text/plain" });
  response.end(outputString);
});
server.listen(3000, () => {
  console.log('started');
})

post-start:
- exec-host: ddev exec -s web npm start
Attempting to visit https://{app}.ddev.site:3000 does not return a response from node.  It shows a "This site cannot be reached" error.  I have tried running ddev ssh to ssh into the web container.  From there, I can successfully send a GET request to localhost:3000 which shows the node server is indeed running
curl -X GET "localhost:3000"
returns a successful response.  However, trying to visit the public-facing local site won't work.
Expected Behavior
It should route my request to the node server, as described in the documentation
Steps To Reproduce
No response
Anything else?
No response

Please use the current version of DDEV. Your problem is that you're using DDEV v1.19.3, and this feature was introduced in v1.20.0.
(What I was going to say...)

Can you please say what visit the public-facing local site won't work means? Maybe show curl -I https://<site>.ddev.site:3000 shows, or curl -I http://.ddev.site:2999` return?

Also, could you please clean up your original post... formatting is pretty useless. (the request for ddev debug test is to put it in a gist, but adding it as a file attachment is OK too).

Thank you for the information rfay


add No More NPC plugin

@josancamon19 it displays with weird artifacts in the app, i didnt use any weird characters, maybe u want to look into your text rendering?

(and thanks for merging)


Lock blank after signup

I have signup enabled, and it works correctly, however, after the user submits the built-in email/password signup form, the widget goes blank -- there's no message about whether signup was successful or not, or instructions about what to do next:

Looking at the document elements, it appears that the entire auth0-login-form element is empty:

Is there something I must set to show a message after signup?  It is not clear to me yet whether it is a problem with the WP plugin or Lock itself.  In my perfect world, I can customize the text of that message by a parameter to the lock widget.  But I was unable to find anything about this issue in the documentation.

mm That is weird.
Is there any js error in the console?
If you go to the logs section in the dashboard, does it shows any error? does it shows a successfull signup + login? (it shoulid be two different logs).
can you attach a har file of the whole interaction? (start capturing before you go to the signup page ultil you get the empty signup box).
Follow this to create the har file http://auth0.com/docs/har
Thx

No I do have a successful signup action in the log.  There is no successful login, but that is expected: I have lock configured with { loginAfterSignup: false } in the Advanced plugin Lock config setting.  If I disable that, after signup and autologin, I see:

I can make this work for me, but see the attached har exemplifying the problem for me:
local.wordpress.dev-full.har.txt

ohh makes sense now.
This is because of the { loginAfterSignup: false }.
You should be able to hook to the signup success event (check https://auth0.com/docs/libraries/lock/events).
You can add the needed js to the Customize the Login Widget with custom JS field under the appearance tab.

Gotcha, I'll try that, thanks.

In case anyone is interested, I settled on this custom CSS in the 'Customize the Login Widget CSS' setting:
#auth0-login-form {
  position: relative;
}

#signup-msg {
  position: absolute;
  top: 50%;
  transform: translateY(-50%);
  padding: 0px 24px;
}

and this custom JS in the 'Customize the Login Widget with custom JS' setting:
// called every time triggered
lock.on('signup success', function() {
   var msg = jQuery('
You have signed up successfully.  ' +
      'Once you have verified your email address ' +
      'and an admin has activated your account, ' +
      'you will be able to log in.
');

  jQuery('#auth0-login-form')
    .append(msg);
});

good :)


Getting response_format 'json_schema' not supported error when using assistant with GPT-4o

Service
OpenAI
Describe the bug
I am attempting to generate a structured output response using response_format = json_schema with an Assistant run using GPT-4o. When I attempt to execute the run, I get the following error:
Parameter: response_format

Invalid parameter: 'response_format' of type 'json_schema' is not supported with model version `gpt-4o`.

It's my understanding via this documentation that GPT-4o (which currently points to gpt-4o-2024-08-06) that this should be supported.
Additionally when attempting a simple chat completion specifying json_schema as the response_format via Postman, it works correctly.
This makes me think this could be a bug in the .NET library itself.
Steps to reproduce
Call CreateThreadAndRunAsync() using GPT-4o, with response format configured to return a specific schema.
Error is returned
Code snippets
// Most relevant snippets of code exemplifying the problem

var runCreationOptions = new RunCreationOptions()
{
    ResponseFormat = AssistantResponseFormat.CreateJsonSchemaFormat(Name, MySchema, Description, true),
    ModelOverride = "GPT-4o"
};

...

await _openAIAssistantsClient.CreateThreadAndRunAsync(_assistantId, threadCreationOptions, runCreationOptions);

// error

OS
Windows Server 2016 Standard
.NET version
.NET Core 2.2
Library version
2.0.0

FWIW I'm getting the same error using the JS SDK.

Same error in JS SDK

The error arises from a limitation in model compatibility with response_format: json_schema. Although some recent models support this setting (gpt-4o-mini, gpt-4o-mini-2024-07-18, and gpt-4o-2024-08-06), this does not guarantee that every GPT-4o variant is covered.
Suggestions
Try explicitly specifying a compatible model, such as gpt-4o-2024-08-06, instead of GPT-4o to ensure compatibility.

Yes, faced the same issue. @Todorcevic is correct.
Somehow the default string gpt-4o is not pointing to gpt-4o-2024-08-06 which it should. Explicitly using gpt-4o-2024-08-06 worked for me.


i18n(pt-BR): create recipes/dynamically-importing-images.mdx file

Description (required)
create i18n/pt-br/recipes/dynamically-importing-images.mdx file

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

pt-br
recipes/dynamically-importing-images.mdx
Localization added, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Co-ordinate possible usability testing and evaluation for WHAM! with Usability Working Group

Next meeting 6/8.  With tasks and participants identified, should be able to do testing and retrieve results by end of June.


Audit design system competition to define completeness

When are we done? The Carbon for IBM.com library has been growing and growing in the past 2 years, and more components get proposed every day. At some point, we have to stop adding, and start maintaining and focus on reuse. This is essential for the mission of enforcing consistency throughout IBM.com.

[ ] Search the WWW and identify a list of competition (focus on layout, large expressive section)
[ ] Comparison between DDS & competition
[ ] Define completeness
[ ]  Identify gaps if any

Some systems to look at:
UK.GOV
NYT
BBC
IBM Security https://ibm-security.carbondesignsystem.com/?path=/docs/layout-modules-actionbarmodule--default


feature: add snapshotter info into container json

Signed-off-by: Michael Wan<EMAIL_ADDRESS>Ⅰ. Describe what this PR did
add snapshotter info into container json
since graphdriver has been replace by snapshotter, so i also rename the GraphDriver to Snapshotter in pouch
Ⅱ. Does this pull request fix one issue?
now we has snapshotter info in container json
        "Snapshotter": {
            "Data": {
                "MergedDir": "/var/lib/pouch/containerd/state/io.containerd.runtime.v1.linux/default/6933c23039432c5a1b1f88c6d94c39fe8fd88943121ac7af419b2c42a2e440fe/rootfs",
                "UpperDir": "/var/lib/pouch/containerd/root/io.containerd.snapshotter.v1.overlayfs/snapshots/1809/fs"
            },
            "Name": "overlayfs"
        },

root@osboxes:containerd -> pouch inspect test
[
    {
        "Args": null,
        "Config": {
            "Cmd": [
                "sh"
            ],
            "Entrypoint": null,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Image": "registry.hub.docker.com/library/busybox:latest",
            "OnBuild": null,
            "Shell": null
        },
        "Created": "2018-04-15T17:01:17.359541477Z",
        "HostConfig": {
            "NetworkMode": "bridge",
            "OomScoreAdj": -500,
            "RestartPolicy": {
                "Name": "no"
            },
            "Runtime": "runc",
            "BlkioDeviceReadBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceWriteIOps": null,
            "BlkioWeightDevice": null,
            "CgroupParent": "default",
            "DeviceCgroupRules": null,
            "Devices": [],
            "MemoryExtra": 0,
            "MemorySwappiness": -1,
            "MemoryWmarkRatio": 0,
            "OomKillDisable": false,
            "Ulimits": null
        },
        "Id": "6933c23039432c5a1b1f88c6d94c39fe8fd88943121ac7af419b2c42a2e440fe",
        "Image": "registry.hub.docker.com/library/busybox:latest",
        "Mounts": [],
        "Name": "test",
        "NetworkSettings": {
            "Networks": {
                "bridge": {
                    "Aliases": null,
                    "EndpointID": "58889c2650a2051fc2ad76d44d1e0fe54044bf043a38f4b74104c4f5c14cde1f",
                    "Gateway": "<IP_ADDRESS>",
                    "IPAddress": "<IP_ADDRESS>",
                    "IPPrefixLen": 24,
                    "Links": null,
                    "MacAddress": "02:42:ac:11:00:02",
                    "NetworkID": "3f31a4ebae28cb6ec7dbe6950ae736929ee9dac611a49a7d369b8b8bcdfb5e6c"
                }
            },
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null
        },
        "Snapshotter": {
            "Data": {
                "MergedDir": "/var/lib/pouch/containerd/state/io.containerd.runtime.v1.linux/default/6933c23039432c5a1b1f88c6d94c39fe8fd88943121ac7af419b2c42a2e440fe/rootfs",
                "UpperDir": "/var/lib/pouch/containerd/root/io.containerd.snapshotter.v1.overlayfs/snapshots/1809/fs"
            },
            "Name": "overlayfs"
        },
        "State": {
            "Pid": 10364,
            "StartedAt": "2018-04-15T17:01:17.71750248Z",
            "Status": "running"
        }
    }
]

Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

In fact, i am not sure whether this PR match your requirement, @yyb196  can you pls review this PR and give me some advise?

Codecov Report

Merging #1130 into master will increase coverage by 0.34%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1130      +/-   ##
==========================================
+ Coverage   15.28%   15.62%   +0.34%
==========================================
  Files         172      171       -1
  Lines        9591     9683      +92
==========================================
+ Hits         1466     1513      +47
- Misses       8019     8062      +43
- Partials      106      108       +2

Impacted Files
Coverage Δ

daemon/mgr/container_types.go
15.38% <ø> (ø)
:arrow_up:

ctrd/snapshot.go
0% <0%> (ø)
:arrow_up:

apis/server/container_bridge.go
0% <0%> (ø)
:arrow_up:

daemon/mgr/container.go
4.89% <0%> (-0.09%)
:arrow_down:

client/client.go
33.33% <0%> (-7.85%)
:arrow_down:

cli/command.go

cli/blkio.go
69.66% <0%> (+2.99%)
:arrow_up:

pkg/kernel/kernel.go
100% <0%> (+16.66%)
:arrow_up:

LGTM


Releases

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/52850
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 7bbcd9f48f9ebce0507e164aee4107482cb27cdf
git push origin v0.1.0

@Wikunia @TheCedarPrince I should have registered the package. Note that right now test fails because I tagged Javis as 0.8.0 which will be the release that will work with this package. Hope this is how it is supposed to go.

Oh and also thank you both guys for all the help @Wikunia and @TheCedarPrince!!!

@Wikunia @TheCedarPrince
So the auto merge thing
wants us to to add the .jl at the end of the repo name but I believe I can't do it.
Also there are some issues with the fact that the compat for Javis is currently too high so the automatic merge in the registry can't happen. I can either remove the compat for now or you can push Javis to 0.8 and then I will retrigger the registration.
Let me know what you prefer!

Oh yeah we should have named it JavisNB.jl
Hmm interesting case with the version. I don't want to Release v0.8 of Javis when JavisNB isn't tagged as we would still need to wait for 3 days.
The test cases will fail though if we run JavisNB with the current version of Javis, right? Which probably also breaks auto merging. Also tagging JavisNB with compat Javis pre 0.8 we would have a version that someone might install and expect it to work with Javis pre 0.8 😂

Oh yeah we should have named it JavisNB.jl Hmm interesting case with the version. I don't want to Release v0.8 of Javis when JavisNB isn't tagged as we would still need to wait for 3 days. The test cases will fail though if we run JavisNB with the current version of Javis, right? Which probably also breaks auto merging. Also tagging JavisNB with compat Javis pre 0.8 we would have a version that someone might install and expect it to work with Javis pre 0.8 😂

On the issue in the registry it says we can comment and explain and then it will be merged manually. If this is the way I will write the comment where I explain the situation

Yeah that would be good. Make sure to update the links first though and then trigger the register command again.

Yeah that would be good. Make sure to update the links first though and then trigger the register command again.

I think they were all already set with JavisNB.jl already.

@JuliaRegistrator register()

Registration pull request updated: JuliaRegistries/General/52850
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 7bbcd9f48f9ebce0507e164aee4107482cb27cdf
git push origin v0.1.0

@JuliaRegistrator register()

Error while trying to register: Register Failed
@Wikunia, it looks like you are not a publicly listed member/owner in the parent organization (JuliaAnimators).
If you are a member/owner, you will need to change your membership to public. See GitHub Help

@JuliaRegistrator register()

Registration pull request updated: JuliaRegistries/General/52850
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 9aa6c6c90efac517c172e8207a225cc8fcc3265b
git push origin v0.1.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/94774
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.1 -m "<description of version>" f7926ce136a057c922d0fa7aa8119d096ea722d2
git push origin v0.1.1


Fix long read manifest upload

Changes proposed in this pull request:

Removes the ability to customize a column 'name' as this results in the later column definitions over-writing earlier ones.
Add updates: attribute to allow over-riding behaviour instead.

For future reference:
This bug actually had wider repercussions than first assumed, as it affects All library manifests. This is as all columns map back to the long_read_library_type column on upload. Not a problem when it works, as the behaviour is identical, but is a problem otherwise.
Might be worth a revisit to add some validation to make sure that all columns with the same header have the same 'update' behaviour.


WeightInfo for Identity Pallet

This PR introduces the WeightInfo trait for the Identity Pallet, taking advantage of the automated benchmarking system.
Changes:

Split set_subs benchmark into set_subs_new and set_subs_old.

This was needed because old subs and new subs both write to storage, and it was not possible to decouple the storage read/writes from one another. So I created two benchmarks, one which takes into account only adding new subs, and the other that takes into account only removing old subs.
This has known issues that the base weight and some base reads/writes are repeated, but I can't think of a cleaner solution given the current tooling. In general, the set_subs function looks to me to be very unoptimized and probably needs to be refactored all-together. For now, this weight is high, but safe.

Fix benchmarks for kill_identity making sure to not whitelist the target account.
Changed benchmark variable from p to s for add/rename/remove/quit_sub. Moved to bottom to match extrinsic order.
Moved Identity tests to their own file.
Integrated new weight formulas into pallet.
Outputted benchmark files now use underscore to delimit large numbers.

also don't you want to add generated weight_info in node-runtime as well ?

@thiolliere yes I will add everything to polkadot, probably as one larger pr with a few of these seperate weightinfos we have been adding.

bot merge


ninja: build stopped: subcommand failed.

COMMAND
python3 main.py
ENVS
ubuntu 18.04
NVIDIA-SMI 470.86       Driver Version: 470.86       CUDA Version: 11.4
GeForce RTX 3090
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2020 NVIDIA Corporation
Built on Wed_Jul_22_19:09:09_PDT_2020
Cuda compilation tools, release 11.0, V11.0.221
Build cuda_11.0_bu.TC445_37.28845127_0
ERROR
Traceback (most recent call last):
File "/opt/conda/envs/barber/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1539, in _run_ninja_build
env=env)
File "/opt/conda/envs/barber/lib/python3.7/subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "main.py", line 13, in
from models.Embedding import Embedding
File "/home/user/jupyter-work/barber/models/Embedding.py", line 3, in
from models.Net import Net
File "/home/user/jupyter-work/barber/models/Net.py", line 3, in
from models.stylegan2.model import Generator
File "/home/user/jupyter-work/barber/models/stylegan2/model.py", line 11, in
from models.stylegan2.op import FusedLeakyReLU, fused_leaky_relu, upfirdn2d
File "/home/user/jupyter-work/barber/models/stylegan2/op/init.py", line 1, in
from .fused_act import FusedLeakyReLU, fused_leaky_relu
File "/home/user/jupyter-work/barber/models/stylegan2/op/fused_act.py", line 17, in
os.path.join(module_path, "fused_bias_act_kernel.cu"),
File "/opt/conda/envs/barber/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 997, in load
keep_intermediates=keep_intermediates)
File "/opt/conda/envs/barber/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1202, in jit_compile
with_cuda=with_cuda)
File "/opt/conda/envs/barber/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1300, in write_ninja_file_and_build_library
error_prefix="Error building extension '{}'".format(name))
File "/opt/conda/envs/barber/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1555, in run_ninja_build
raise RuntimeError(message) from e
RuntimeError: Error building extension 'fused': [1/3] /usr/local/cuda-11.0/bin/nvcc -DTORCH_EXTENSION_NAME=fused -DTORCH_API_INCLUDE_EXTENSION_H -DPYBIND11_COMPILER_TYPE="gcc" -DPYBIND11_STDLIB="libstdcpp" -DPYBIND11_BUILD_ABI="cxxabi1011" -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/TH -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/THC -isystem /usr/local/cuda-11.0/include -isystem /opt/conda/envs/barber/include/python3.7m -D_GLIBCXX_USE_CXX11_ABI=0 -D__CUDA_NO_HALF_OPERATORS -D__CUDA_NO_HALF_CONVERSIONS -D__CUDA_NO_HALF2_OPERATORS --expt-relaxed-constexpr -gencode=arch=compute_86,code=sm_86 --compiler-options '-fPIC' -std=c++14 -c /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act_kernel.cu -o fused_bias_act_kernel.cuda.o
FAILED: fused_bias_act_kernel.cuda.o
/usr/local/cuda-11.0/bin/nvcc -DTORCH_EXTENSION_NAME=fused -DTORCH_API_INCLUDE_EXTENSION_H -DPYBIND11_COMPILER_TYPE="gcc" -DPYBIND11_STDLIB="libstdcpp" -DPYBIND11_BUILD_ABI="cxxabi1011" -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/TH -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/THC -isystem /usr/local/cuda-11.0/include -isystem /opt/conda/envs/barber/include/python3.7m -D_GLIBCXX_USE_CXX11_ABI=0 -D__CUDA_NO_HALF_OPERATORS -D__CUDA_NO_HALF_CONVERSIONS_ -D__CUDA_NO_HALF2_OPERATORS__ --expt-relaxed-constexpr -gencode=arch=compute_86,code=sm_86 --compiler-options '-fPIC' -std=c++14 -c /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act_kernel.cu -o fused_bias_act_kernel.cuda.o
nvcc fatal   : Unsupported gpu architecture 'compute_86'
[2/3] c++ -MMD -MF fused_bias_act.o.d -DTORCH_EXTENSION_NAME=fused -DTORCH_API_INCLUDE_EXTENSION_H -DPYBIND11_COMPILER_TYPE="_gcc" -DPYBIND11_STDLIB="_libstdcpp" -DPYBIND11_BUILD_ABI="_cxxabi1011" -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/TH -isystem /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/THC -isystem /usr/local/cuda-11.0/include -isystem /opt/conda/envs/barber/include/python3.7m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++14 -c /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp -o fused_bias_act.o
In file included from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/c10/core/DeviceType.h:8:0,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/c10/core/Device.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/c10/core/Allocator.h:6,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/ATen.h:7,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/types.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader_options.h:4,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/base.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/stateful.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/all.h:8,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/extension.h:4,
from /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:1:
/home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp: In function ‘at::Tensor fused_bias_act(const at::Tensor&, const at::Tensor&, const at::Tensor&, int, int, float, float)’:
/home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:7:42: warning: ‘at::DeprecatedTypeProperties& at::Tensor::type() const’ is deprecated: Tensor.type() is deprecated. Instead use Tensor.options(), which in many cases (e.g. in a constructor) is a drop-in replacement. If you were using data from type(), that is now available from Tensor itself, so instead of tensor.type().scalar_type(), use tensor.scalar_type() instead and instead of tensor.type().backend() use tensor.device(). [-Wdeprecated-declarations]
#define CHECK_CUDA(x) TORCH_CHECK(x.type().is_cuda(), #x " must be a CUDA tensor")
^
/home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:13:5: note: in expansion of macro ‘CHECK_CUDA’
CHECK_CUDA(input);
^~~~~~~~~~
In file included from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/Tensor.h:3:0,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/Context.h:4,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/ATen.h:9,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/types.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader_options.h:4,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/base.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/stateful.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/all.h:8,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/extension.h:4,
from /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:1:
/opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/core/TensorBody.h:277:30: note: declared here
DeprecatedTypeProperties & type() const {
^~~~
In file included from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/c10/core/DeviceType.h:8:0,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/c10/core/Device.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/c10/core/Allocator.h:6,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/ATen.h:7,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/types.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader_options.h:4,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/base.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/stateful.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/all.h:8,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/extension.h:4,
from /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:1:
/home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:7:42: warning: ‘at::DeprecatedTypeProperties& at::Tensor::type() const’ is deprecated: Tensor.type() is deprecated. Instead use Tensor.options(), which in many cases (e.g. in a constructor) is a drop-in replacement. If you were using data from type(), that is now available from Tensor itself, so instead of tensor.type().scalar_type(), use tensor.scalar_type() instead and instead of tensor.type().backend() use tensor.device(). [-Wdeprecated-declarations]
#define CHECK_CUDA(x) TORCH_CHECK(x.type().is_cuda(), #x " must be a CUDA tensor")
^
/home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:14:5: note: in expansion of macro ‘CHECK_CUDA’
CHECK_CUDA(bias);
^~~~~~~~~~
In file included from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/Tensor.h:3:0,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/Context.h:4,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/ATen.h:9,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/types.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader_options.h:4,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/base.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader/stateful.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data/dataloader.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/data.h:3,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/csrc/api/include/torch/all.h:8,
from /opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/torch/extension.h:4,
from /home/user/jupyter-work/barber/models/stylegan2/op/fused_bias_act.cpp:1:
/opt/conda/envs/barber/lib/python3.7/site-packages/torch/include/ATen/core/TensorBody.h:277:30: note: declared here
DeprecatedTypeProperties & type() const {
^~~~
ninja: build stopped: subcommand failed.

I had faced with the same issue,
for me helped next:
export TORCH_CUDA_ARCH_LIST="7.5"

It's related to your CUDA version. Please install the newest CUDA and Pytorch.

Sometimes it is because " ninja --version " return something more than just a version number. in this case, download Ninja executable file and add it to the path. That happened to me on windows.


Need basic documentation and better/more examples

As of September 11th	327,106 sites are running drupal 6 and only 154,146	sites run drupal 7
so why not release a D6 version or one that works for both?
There is no readme for the Drupal module.
the example is not complete, it only shows you how to load an editor not how to connect it to the back end.
The readme for zend does not explain how to install it.
I have the editor running locally but dont know how to connect it to my PostGis DB.
I am ready to integrate the OLE into my project but cannot find method or API documentation.
Thanks for Writing this, I think it will be excellent once I can make it work!
Cheers
Franco

Took longer than expected, but finally we have published the Zend demo application at https://github.com/geops/ole/tree/master/demo.


Support cancel

Cancel if request takes > 30 second
Cancel button for user

OpenAI won't actually cancel the request, so we are going to nix the button (at least for now).

Won't do (for now)


484 box sizing border box (3)

Fix #484
Added universal star selector for box-sizing: border-box (normalization, reset, streamline).
Test URLs

Before: https://main--hlx-test--urfuwo.hlx.page/design/design-system
After: https://484-box-sizing-border-box-rebase--hlx-test--urfuwo.hlx.page/design/design-system (looks the same)

@eduardseifert I see problems on the content hub homepage
https://484-box-sizing-border-box-rebase--hlx-test--urfuwo.hlx.page/topics/

In mobile view, the active marker on main nav is not aligned.

@saurabh-khare This is exactly the typical problem with content-box. What shall we (I) do? Again drive-by fixing?

Based on our last discussion, we'll fix the issues and proceed with merging so that we can take advantage of the new border-box setup.

@saurabh-khare + @alexcarol As discussed, fixed the issues. Please take a look: https://484-box-sizing-border-box-rebase--hlx-test--urfuwo.hlx.page/topics/

👊 💪


build: remove Dockerfile and add codespace config

This PR removes our now-defunct Dockerfile. Instead, we recommend that you use the TRTools image maintained by the Bioconda team on the biocontainers registry. The docs have been updated to reflect this.
To offset the removal of the Dockerfile, this PR adds an alternative way to work with TRTools in the cloud: GitHub codepsaces! This can be helpful when you want to quickly play around with our code but don't want to go through all of the setup steps. Just click on the "Open in Github Codespaces" badge on the README and voila - you'll be presented with an environment automagically set up with TRTools and our development dependencies. This environment will run with (usually free) credits on Github's codespace VMs.
Finally, this PR also specifies a strategy for our support for various python versions. From now on, we will only formally support active versions of python that are not end-of-life (3.8+). However, at least for now, we think that TRTools will still run properly for versions 3.6 and 3.7 - although support for those versions is not guaranteed and may break at any time.

@aarushi03, can I request your review on this PR, since you've worked with GitHub codespaces before? Can you try out the new badge (checked out to the build/Dockerfile branch) and let me know if it works for you?

@aarushi03, can I request your review on this PR, since you've worked with GitHub codespaces before? Can you try out the new badge (checked out to the build/Dockerfile branch) and let me know if it works for you?

Certainly. Reviewing it now.


Fix formatting

Fix formatting and remove unrequired heading.

@gkhanna79 : Thanks for your contribution! The author, @TylerMSFT, has been notified to review your proposed change.

Looks good - thank you.


Check if project has the same repository id with issue when assign project to issue

Codecov Report

Merging #20133 (aef67da) into main (711cbcc) will decrease coverage by 0.00%.
The diff coverage is 53.93%.

@@            Coverage Diff             @@
##             main   #20133      +/-   ##
==========================================
- Coverage   46.91%   46.91%   -0.01%
==========================================
  Files         973      973
  Lines      134721   134838     +117
==========================================
+ Hits        63204    63256      +52
- Misses      63768    63825      +57
- Partials     7749     7757       +8

Impacted Files
Coverage Δ

models/issues/issue_project.go
30.00% <0.00%> (-2.24%)
:arrow_down:

modules/markup/markdown/toc.go
0.00% <0.00%> (ø)

modules/setting/i18n.go
100.00% <ø> (ø)

modules/setting/setting.go
47.59% <ø> (+0.38%)
:arrow_up:

modules/templates/helper.go
45.86% <ø> (ø)

routers/install/install.go
1.77% <0.00%> (ø)

routers/install/routes.go
44.00% <0.00%> (ø)

routers/private/hook_pre_receive.go
41.88% <0.00%> (ø)

routers/web/admin/admin.go
10.02% <0.00%> (ø)

routers/web/auth/auth.go
26.26% <0.00%> (-0.13%)
:arrow_down:

... and 38 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 26ec628...aef67da. Read the comment docs.

make L-G-T-M work


Multiple tooltips created on zoom

HELLo,
Seems like PruneCluster is adding a new tooltip on top of the old one everytime you zoom in or out. Hence, zooming back and forth 10 times will cause the tooltip to be created 10 times on top of each other.

This library is broken in so many ways, it has more bugs then functions.

Hey! Be a little bit more constructive and friendlier, please. People are putting their free time working on this. It's a group effort and you as a user are as much responsible for making/helping to make this library work as anyone already working on it. Just killing everyone's motivation and spirit totally doesn't serve anyone.
Which version of Leaflet are you using? Newer versions might have some issues with PruneCluster. If you look into previous issues, you'll notice that newer versions of Leaflet have changed oh things work and thus this library (which was built during Leaflet 0.7) might have some issues especially with popups/tooltips. There are also some tips and ideas how to get them work.
Pull requests are always welcome, you can make it work for yourself and thus be more productive and useful. :-)
If you can provide exact steps or code to replicate those bugs you're encountering, it would help so much!

And while at it, you should check also https://github.com/mapbox/supercluster — an excellent library which might be more up to date.

@simison I came from Supercluster.
Regarding the rest of your comments, then i just hear excuses as to why this isn't working. Asking me to fix what never worked in the first place is not going to happen, would be easier to simply start over.

@fjeddy I wish you luck in the world of using open source libararies with that attitude! <3

(@yellowiscool; I recon this can be closed)

Ok, this is obviously not a constructive discussion.

@fjeddy I highly recommend you to read this: https://www.ubuntu.com/about/about-ubuntu/conduct and consider next time your style of communicating.

@simison I highly recommend you to read this: https://opensource.com/business/13/5/open-source-your-code and consider next time you plan to open source something.

@fjeddy Your behaviour is not ok. Please move on.

@yellowiscool Then stop replying and move on.

@yellowiscool https://help.github.com/articles/locking-conversations/

@simison Thanks for your time 😃
I blocked and reported this weird user. We only got very positive feedback so far, so it had to happen. I will upload a code-of-conduct because being nice is not obvious for everyone.


chore: sdk camera control test coverage

Adds test coverage for the feature introduced at https://github.com/decentraland/unity-explorer/pull/1744
TARGET BASE BRANCH TO BE CHANGED TO main AFTER https://github.com/decentraland/unity-explorer/pull/1744 IS MERGED.

closing in favor of https://github.com/decentraland/unity-explorer/pull/2001


Github slack plugin outdated

Hey our dear community, we just found our github plugin for our slack is outdated so the new issues were not alerting in our slack channel, we did not check the Github issues in time recently.
We are checking the recent reported issues and fix the plugin at the same time. Thank you for your support!
Regards
Tianduo

Thank You!
Also, @zhaitianduo please check #348 because a 404 Not Found error appears with the tracks.

Hey Bryce
Sorry my github account was locked, can not reply to you directly in slack,
we will take a look.
On Tue, Feb 15, 2022 at 9:59 PM Bryce Monaghan @.***>
wrote:

Thank You!
Also, @zhaitianduo https://github.com/zhaitianduo please check #348
https://github.com/kartaview/openstreetcam.org/issues/348 because a 404
Not Found error appears with the tracks.
—
Reply to this email directly, view it on GitHub
https://github.com/kartaview/openstreetcam.org/issues/342#issuecomment-1040307080,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIEO64QT4ALS7HPISYZVODU3JL27ANCNFSM5ERAD6WQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

--
[image: Grab (Beijing)] https://htmlsig.com/t/000001BKA99J
[image: Twitter]  https://htmlsig.com/t/000001BKDVDC [image: Facebook]
https://htmlsig.com/t/000001BF8J9Q [image: LinkedIn]
https://htmlsig.com/t/000001BKYJ3R [image: Instagram]
https://htmlsig.com/t/000001BH4CH1 [image: Youtube]
https://htmlsig.com/t/0000001BMMNPF
Tianduo Zhai / Engineer Manager, Geo
@.*** / +86<PHONE_NUMBER>4
Grab (Beijing)
7 F, Block A, China Overseas International Center, No.5 Anding Road,
Chaoyang District, Beijing China 北京市朝阳区安定路5号院中海国际中心A座7层
https://www.grab.com
[image: Download on the App Store]
https://htmlsig.com/t/000001BEBS2K [image:
Get it on Google Play]  https://htmlsig.com/t/000001BFTMV9
This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Company Name is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
--
By communicating with Grab Inc and/or its subsidiaries, associate
companies and jointly controlled entities (“Grab Group”), you are deemed to
have consented to the processing of your personal data as set out in the
Privacy Notice which can be viewed at https://grab.com/privacy/
https://grab.com/privacy/
This email contains confidential information
and is only for the intended recipient(s). If you are not the intended
recipient(s), please do not disseminate, distribute or copy this email
Please notify Grab Group immediately if you have received this by mistake
and delete this email from your system. Email transmission cannot be
guaranteed to be secure or error-free as any information therein could be
intercepted, corrupted, lost, destroyed, delayed or incomplete, or contain
viruses. Grab Group do not accept liability for any errors or omissions in
the contents of this email arises as a result of email transmission. All
intellectual property rights in this email and attachments therein shall
remain vested in Grab Group, unless otherwise provided by law.


fix silly if error. Fixes #10

@tomasen @cryptix @whyrusleeping please CR?

LGTM

thanks @cryptix

@whyrusleeping maybe we should pull this into go-ipfs at some point


Update SDHI SMS to v.3.2.1 (KSP 1.2.1)

#rebuild

With the missing dependency updated, all looks fine. Merging with thanks!


AttributeError during ConvertLayout to NHWC

When using tvm.relay.transform.ConvertLayout (in the context of #6302), I'm getting some errors that are not really clear on how they are related to the convert process.
It seems ConvertLayout it is looking for shape (this check was introduced in #5284), when trying to find depthwise convolutions, but it doesn't seem to be the case that shape is there for some imported models, and might need some fixing.
https://github.com/apache/incubator-tvm/blob/4b48d89c79a72f7799606e845bdb1ed938baa115/python/tvm/relay/op/nn/_nn.py#L158-L164
This is the error I see, when trying to run ConvertLayout on an ONNX model:
AttributeError: <class 'tvm.relay.expr.TupleGetItem'> has no attribute shape

To reproduce the issue, you can run the script below:

Download resnet50:

wget https://github.com/onnx/models/raw/master/vision/classification/resnet/model/resnet50-v2-7.onnx

Run the ConvertLayout following the script below:

import onnx
import tvm
from tvm import relay

# boilerplate to load the ONNX model
model = onnx.load("resnet50-v2-7.onnx")
name = model.graph.input[0].name
proto_shape = model.graph.input[0].type.tensor_type.shape.dim
shape = [d.dim_value for d in proto_shape]
shape_dict = {name: shape}
mod, params = relay.frontend.from_onnx(model, shape_dict)

# converting layout
desired_layouts = {'nn.conv2d': ['NHWC', 'default']}
seq = tvm.transform.Sequential([relay.transform.RemoveUnusedFunctions(),
                                relay.transform.ConvertLayout(desired_layouts)])

with tvm.transform.PassContext(opt_level=3):
    mod = seq(mod)

with relay.build_config(opt_level=3):
     graph, lib, params = relay.build(mod, "llvm", params=params)

PS: It also happens if I get a NHWC TFlite model and try to force it into an NHWC convertion, but that is a negative test, that is why I didn't add it here.
cc @comaniac @jwfromm

I think this is happening because the shape of data is accessed by data.shape, at some point something in TVM changed meaning shape needs to be accessed by data.checked_type.shape. It looks like the convert layout tests didn't pick this up.

If we agree this is a legitimate issue, I found two places that need fixing:
https://github.com/apache/incubator-tvm/blob/4b48d89c79a72f7799606e845bdb1ed938baa115/python/tvm/relay/op/nn/_nn.py#L160
https://github.com/apache/incubator-tvm/blob/4b48d89c79a72f7799606e845bdb1ed938baa115/python/tvm/relay/qnn/op/layout_conversions.py#L65

cc @anijain2305

Thanks @leandron for raising the issue. Your fixes look good to me.

Just to mention, I checked PR #6419 and it completely fixes this issue here, so we can close it once that PR is merged.

Thanks @leandron. This can be closed now.


moving shot v1

shooting on the move!

[x] test on the actual robot
[ ] test on various robot speeds
[ ] account for acceleration? due to SlewRateLimiters we are limiting our maximum accel

testing will be difficult without a proper field -- vision requires the proper distance
otherwise a static shot does remain a static shot

ded2560 uses chassis kinematics which disregards potential noise coming from limelight feeding into odometry system
this uses solely wheel encoders to determine chassis velocity

test on bot -- actions not requiring the turret work
current theory: we do not compensate for the bots relative movement aka it assumes that at the current point the bot is already at the rotation for the turret we want it to be, although this is not the case as there is nothing that fixes the turret even with bot motion


feature/cplp 831 post app consent

https://jira.catena-x.net/browse/CPLP-831

@qxz2mqe As #196 also contains a new Migration I'll review this PR as soon #196 is merged in main and into this branch and then the Migration in this PR is recreated based on latest DBContext from #196

PR #196 is merged, please pull main, resolve the conflicts and recreate the migration.

@ntruchsess  I demonstrated the feature to Julia. It is working as expected. Additional Item for linking the respective agreements to the offerTypeId (suggested table name would be agreement_assigned_offer_ids / AgreementAssignedOfferIds can be taken into upcoming sprint. Please review the PR

migration applied to local devenv in https://github.com/tractusx-team-portal-onboarding/devenv/pull/132

@qxz2mqe :
you wrote:

'I demonstrated the feature to Julia. It is working as expected'.

I have no idea what you did demonstrate, but apparently it was not the creation of a consent by calling /api/apps/AppReleaseProcess/consent/{appId}/OfferAgreementConsents and subsequently getting the newly created consent via /api/apps/AppReleaseProcess/consent/{appId}
The get-endpoint does correctly access consent_assigned_offer-table while the POST-endpoint does not create an entry in there
https://github.com/catenax-ng/product-portal-backend/blob/e9ea8fe56ced0cf4696e2729dc613bc35a954750/src/marketplace/CatenaX.NetworkServices.Apps.Service/BusinessLogic/AppReleaseBusinessLogic.cs#L270
your code is missing this line:
https://github.com/catenax-ng/product-portal-backend/blob/ca4cded659db409d13cc16a9eeb0f21b9aa41af4/src/marketplace/CatenaX.NetworkServices.Offers.Library/Service/OfferService.cs#L161


[Segment Replication] Investigate lower p50/p90 index latencies with benchmark runs

The benchmark comparison for so dataset also shows p50, p90 indexing latency hit by ~20%, ~40% respectively for segment replication.
Cluster setup

10 data node
3 cluster manager node
m5.xlarge instance type.

Steps:

Create docrep index with below settings

 {
    "settings": {
        "index": {
            "number_of_shards": 40,
            "number_of_replicas": 1,
            "replication.type": "DOCUMENT"
        }
    }
}

Ingest data using

opensearch-benchmark execute_test --pipeline benchmark-only --workload so --target-hosts "$host:80" --distribution-version=2.7.0 --include-tasks index-append --results-file=~/.benchmark/so_first_segrep --show-in-results=all --kill-running-processes;

Delete index and repeat for segrep.

One sample comparison below, baseline: docrep, contender: segrep
ubuntu@ip-172-31-49-145:~/OpenSearch-Benchmark$ opensearch-benchmark compare --baseline=8c33cbc6-6f0b-4e77-840e-4b16a0aabcc8  --contender=f615b039-6598-44f5-aab6-467d2671a6ba

   ____                  _____                      __       ____                  __                         __
  / __ \____  ___  ____ / ___/___  ____ ___________/ /_     / __ )___  ____  _____/ /_  ____ ___  ____ ______/ /__
 / / / / __ \/ _ \/ __ \\__ \/ _ \/ __ `/ ___/ ___/ __ \   / __  / _ \/ __ \/ ___/ __ \/ __ `__ \/ __ `/ ___/ //_/
/ /_/ / /_/ /  __/ / / /__/ /  __/ /_/ / /  / /__/ / / /  / /_/ /  __/ / / / /__/ / / / / / / / / /_/ / /  / ,<
\____/ .___/\___/_/ /_/____/\___/\__,_/_/   \___/_/ /_/  /_____/\___/_/ /_/\___/_/ /_/_/ /_/ /_/\__,_/_/  /_/|_|
    /_/

Comparing baseline
  TestExecution ID: 8c33cbc6-6f0b-4e77-840e-4b16a0aabcc8
  TestExecution timestamp: 2023-04-25 23:57:26
  TestProcedure: append-no-conflicts
  ProvisionConfigInstance: external

with contender
  TestExecution ID: f615b039-6598-44f5-aab6-467d2671a6ba
  TestExecution timestamp: 2023-04-26 00:13:05
  TestProcedure: append-no-conflicts
  ProvisionConfigInstance: external

------------------------------------------------------
    _______             __   _____
   / ____(_)___  ____ _/ /  / ___/_________  ________
  / /_  / / __ \/ __ `/ /   \__ \/ ___/ __ \/ ___/ _ \
 / __/ / / / / / /_/ / /   ___/ / /__/ /_/ / /  /  __/
/_/   /_/_/ /_/\__,_/_/   /____/\___/\____/_/   \___/
------------------------------------------------------

|                                                        Metric |         Task |   Baseline |   Contender |     Diff |   Unit |
|--------------------------------------------------------------:|-------------:|-----------:|------------:|---------:|-------:|
|                    Cumulative indexing time of primary shards |              |    115.845 |     137.057 |  21.2119 |    min |
|             Min cumulative indexing time across primary shard |              |     2.4691 |     2.74135 |  0.27225 |    min |
|          Median cumulative indexing time across primary shard |              |    2.85135 |     3.51008 |  0.65873 |    min |
|             Max cumulative indexing time across primary shard |              |    3.56195 |     4.11007 |  0.54812 |    min |
|           Cumulative indexing throttle time of primary shards |              |          0 |           0 |        0 |    min |
|    Min cumulative indexing throttle time across primary shard |              |          0 |           0 |        0 |    min |
| Median cumulative indexing throttle time across primary shard |              |          0 |           0 |        0 |    min |
|    Max cumulative indexing throttle time across primary shard |              |          0 |           0 |        0 |    min |
|                       Cumulative merge time of primary shards |              |          0 |     103.464 |  103.464 |    min |
|                      Cumulative merge count of primary shards |              |          0 |        1421 |     1421 |        |
|                Min cumulative merge time across primary shard |              |          0 |     1.64495 |  1.64495 |    min |
|             Median cumulative merge time across primary shard |              |          0 |     2.45208 |  2.45208 |    min |
|                Max cumulative merge time across primary shard |              |          0 |      3.7272 |   3.7272 |    min |
|              Cumulative merge throttle time of primary shards |              |          0 |     37.8906 |  37.8906 |    min |
|       Min cumulative merge throttle time across primary shard |              |          0 |    0.315733 |  0.31573 |    min |
|    Median cumulative merge throttle time across primary shard |              |          0 |    0.837842 |  0.83784 |    min |
|       Max cumulative merge throttle time across primary shard |              |          0 |     1.71068 |  1.71068 |    min |
|                     Cumulative refresh time of primary shards |              |    27.2749 |      51.285 |  24.0101 |    min |
|                    Cumulative refresh count of primary shards |              |        459 |        7021 |     6562 |        |
|              Min cumulative refresh time across primary shard |              |   0.529367 |    0.871567 |   0.3422 |    min |
|           Median cumulative refresh time across primary shard |              |   0.693942 |     1.35739 |  0.66345 |    min |
|              Max cumulative refresh time across primary shard |              |   0.839817 |     1.61723 |  0.77742 |    min |
|                       Cumulative flush time of primary shards |              |     3.0851 |    0.900667 | -2.18443 |    min |
|                      Cumulative flush count of primary shards |              |         40 |          92 |       52 |        |
|                Min cumulative flush time across primary shard |              |     0.0184 |      0.0064 |   -0.012 |    min |
|             Median cumulative flush time across primary shard |              |  0.0753083 |     0.01775 | -0.05756 |    min |
|                Max cumulative flush time across primary shard |              |    0.14295 |     0.06245 |  -0.0805 |    min |
|                                       Total Young Gen GC time |              |     30.535 |        7.63 |  -22.905 |      s |
|                                      Total Young Gen GC count |              |       1011 |         531 |     -480 |        |
|                                         Total Old Gen GC time |              |          0 |           0 |        0 |      s |
|                                        Total Old Gen GC count |              |          0 |           0 |        0 |        |
|                                                    Store size |              |    69.5802 |     98.3018 |  28.7217 |     GB |
|                                                 Translog size |              |    30.4832 |     28.3262 | -2.15695 |     GB |
|                                        Heap used for segments |              |          0 |           0 |        0 |     MB |
|                                      Heap used for doc values |              |          0 |           0 |        0 |     MB |
|                                           Heap used for terms |              |          0 |           0 |        0 |     MB |
|                                           Heap used for norms |              |          0 |           0 |        0 |     MB |
|                                          Heap used for points |              |          0 |           0 |        0 |     MB |
|                                   Heap used for stored fields |              |          0 |           0 |        0 |     MB |
|                                                 Segment count |              |        647 |         915 |      268 |        |
|                                                Min Throughput | index-append |    65101.5 |     75422.1 |  10320.6 | docs/s |
|                                               Mean Throughput | index-append |    66831.3 |     78430.6 |  11599.4 | docs/s |
|                                             Median Throughput | index-append |    66893.6 |     78448.2 |  11554.6 | docs/s |
|                                                Max Throughput | index-append |    67664.2 |     80842.5 |  13178.3 | docs/s |
|                                       50th percentile latency | index-append |    400.337 |     465.148 |   64.811 |     ms |
|                                       90th percentile latency | index-append |    555.599 |     762.042 |  206.443 |     ms |
|                                       99th percentile latency | index-append |    7831.66 |     1478.02 | -6353.63 |     ms |
|                                     99.9th percentile latency | index-append |     9041.4 |     2005.12 | -7036.28 |     ms |
|                                      100th percentile latency | index-append |    9376.91 |     2674.49 | -6702.41 |     ms |
|                                  50th percentile service time | index-append |    400.337 |     465.148 |   64.811 |     ms |
|                                  90th percentile service time | index-append |    555.599 |     762.042 |  206.443 |     ms |
|                                  99th percentile service time | index-append |    7831.66 |     1478.02 | -6353.63 |     ms |
|                                99.9th percentile service time | index-append |     9041.4 |     2005.12 | -7036.28 |     ms |
|                                 100th percentile service time | index-append |    9376.91 |     2674.49 | -6702.41 |     ms |
|                                                    error rate | index-append |          0 |           0 |        0 |      % |

-------------------------------
[INFO] SUCCESS (took 0 seconds)
-------------------------------

Originally posted by @dreamer-89 in https://github.com/opensearch-project/OpenSearch/issues/7296#issuecomment-1522612959

Ran some benchmarks and found the cause of this.  It is the restriction of shard idle with SR that causes this degradation in p50. With SR we disabled shard idle because replica refresh is not independent of the primary, meaning a search req would need to specifically hit a primary shard for SR to trigger and replicas to catch up.  So we would be serving old data on replicas even if it has search load.  We could optimize this to force a primary refresh when any search req is received by the replication group, though I'm not sure what that would look like.  A side effect there is when refresh does eventually kick in either through a req, buffer or translog limit, it will potentially copy larger set of segments.
Baseline = Docrep
Contender = segrep with current main branch.
    _______             __   _____
   / ____(_)___  ____ _/ /  / ___/_________  ________
  / /_  / / __ \/ __ `/ /   \__ \/ ___/ __ \/ ___/ _ \
 / __/ / / / / / /_/ / /   ___/ / /__/ /_/ / /  /  __/
/_/   /_/_/ /_/\__,_/_/   /____/\___/\____/_/   \___/
------------------------------------------------------
|              Cumulative merge throttle time of primary shards |                          |      2.4677 |     22.0339 |  19.5662 |    min |
|       Min cumulative merge throttle time across primary shard |                          |           0 |    0.382033 |  0.38203 |    min |
|    Median cumulative merge throttle time across primary shard |                          |           0 |    0.511267 |  0.51127 |    min |
|       Max cumulative merge throttle time across primary shard |                          |    0.348083 |    0.857683 |   0.5096 |    min |
|                     Cumulative refresh time of primary shards |                          |     14.6831 |     29.4362 |  14.7531 |    min |
|                    Cumulative refresh count of primary shards |                          |         658 |       10053 |     9395 |        |
|              Min cumulative refresh time across primary shard |                          |    0.325767 |      0.6665 |  0.34073 |    min |
|           Median cumulative refresh time across primary shard |                          |    0.359683 |    0.739017 |  0.37933 |    min |
|              Max cumulative refresh time across primary shard |                          |     0.43405 |      0.8013 |  0.36725 |    min |
|                       Cumulative flush time of primary shards |                          |     2.31815 |      1.1514 | -1.16675 |    min |
|                      Cumulative flush count of primary shards |                          |          40 |          80 |       40 |        |
|                Min cumulative flush time across primary shard |                          |   0.0136333 |  0.00306667 | -0.01057 |    min |
|             Median cumulative flush time across primary shard |                          |   0.0552417 |      0.0241 | -0.03114 |    min |
|                Max cumulative flush time across primary shard |                          |    0.104317 |   0.0630167 |  -0.0413 |    min |
|                                       Total Young Gen GC time |                          |       23.88 |       4.395 |  -19.485 |      s |
|                                      Total Young Gen GC count |                          |         447 |         203 |     -244 |        |
|                                         Total Old Gen GC time |                          |           0 |           0 |        0 |      s |
|                                        Total Old Gen GC count |                          |           0 |           0 |        0 |        |
|                                                    Store size |                          |     70.9096 |     75.2277 |  4.31812 |     GB |
|                                                 Translog size |                          | 4.09782e-06 |     17.7238 |  17.7238 |     GB |
|                                        Heap used for segments |                          |           0 |           0 |        0 |     MB |
|                                      Heap used for doc values |                          |           0 |           0 |        0 |     MB |
|                                           Heap used for terms |                          |           0 |           0 |        0 |     MB |
|                                           Heap used for norms |                          |           0 |           0 |        0 |     MB |
|                                          Heap used for points |                          |           0 |           0 |        0 |     MB |
|                                   Heap used for stored fields |                          |           0 |           0 |        0 |     MB |
|                                                 Segment count |                          |         905 |         800 |     -105 |        |
|                                                Min Throughput |             index-append |       38156 |     40419.6 |  2263.61 | docs/s |
|                                               Mean Throughput |             index-append |     40531.2 |     42513.9 |   1982.7 | docs/s |
|                                             Median Throughput |             index-append |     40654.4 |     41628.4 |  974.006 | docs/s |
|                                                Max Throughput |             index-append |     42781.7 |     50519.4 |  7737.69 | docs/s |
|                                       50th percentile latency |             index-append |     700.192 |     779.575 |  79.3828 |     ms |
|                                       90th percentile latency |             index-append |     1974.44 |     1729.77 | -244.672 |     ms |
|                                       99th percentile latency |             index-append |     4004.71 |     2016.16 | -1988.55 |     ms |
|                                     99.9th percentile latency |             index-append |     5006.04 |     2741.02 | -2265.02 |     ms |
|                                      100th percentile latency |             index-append |     5842.76 |     3088.05 | -2754.71 |     ms |
|                                  50th percentile service time |             index-append |     700.192 |     779.575 |  79.3828 |     ms |
|                                  90th percentile service time |             index-append |     1974.44 |     1729.77 | -244.672 |     ms |
|                                  99th percentile service time |             index-append |     4004.71 |     2016.16 | -1988.55 |     ms |
|                                99.9th percentile service time |             index-append |     5006.04 |     2741.02 | -2265.02 |     ms |
|                                 100th percentile service time |             index-append |     5842.76 |     3088.05 | -2754.71 |     ms |
|                                                    error rate |             index-append |           0 |           0 |        0 |      % |
|                                                Min Throughput | wait-until-merges-finish |   0.0305944 |    0.381946 |  0.35135 |  ops/s |
|                                               Mean Throughput | wait-until-merges-finish |   0.0305944 |    0.381946 |  0.35135 |  ops/s |
|                                             Median Throughput | wait-until-merges-finish |   0.0305944 |    0.381946 |  0.35135 |  ops/s |
|                                                Max Throughput | wait-until-merges-finish |   0.0305944 |    0.381946 |  0.35135 |  ops/s |
|                                      100th percentile latency | wait-until-merges-finish |     32685.3 |     2617.74 | -30067.6 |     ms |
|                                 100th percentile service time | wait-until-merges-finish |     32685.3 |     2617.74 | -30067.6 |     ms |
|                                                    error rate | wait-until-merges-finish |           0 |           0 |        0 |      % |

-------------------------------
[INFO] SUCCESS (took 0 seconds)
-------------------------------

Baseline = Docrep
Contender = Patch to allow shard idle for SR indices.
Comparing baseline
  TestExecution ID: ae0e92a8-6890-4b23-897e-bb7f00bae3b3
  TestExecution timestamp: 2023-05-19 19:12:20
  TestProcedure: append-no-conflicts
|              Cumulative merge throttle time of primary shards |                          |      2.4677 |      0.4342 |  -2.0335 |    min |
|       Min cumulative merge throttle time across primary shard |                          |           0 |           0 |        0 |    min |
|    Median cumulative merge throttle time across primary shard |                          |           0 |           0 |        0 |    min |
|       Max cumulative merge throttle time across primary shard |                          |    0.348083 |      0.4342 |  0.08612 |    min |
|                     Cumulative refresh time of primary shards |                          |     14.6831 |     11.3224 |  -3.3607 |    min |
|                    Cumulative refresh count of primary shards |                          |         658 |         627 |      -31 |        |
|              Min cumulative refresh time across primary shard |                          |    0.325767 |    0.197517 | -0.12825 |    min |
|           Median cumulative refresh time across primary shard |                          |    0.359683 |    0.275858 | -0.08382 |    min |
|              Max cumulative refresh time across primary shard |                          |     0.43405 |     0.38305 |   -0.051 |    min |
|                       Cumulative flush time of primary shards |                          |     2.31815 |     3.90867 |  1.59052 |    min |
|                      Cumulative flush count of primary shards |                          |          40 |          80 |       40 |        |
|                Min cumulative flush time across primary shard |                          |   0.0136333 |   0.0352667 |  0.02163 |    min |
|             Median cumulative flush time across primary shard |                          |   0.0552417 |    0.090825 |  0.03558 |    min |
|                Max cumulative flush time across primary shard |                          |    0.104317 |    0.196183 |  0.09187 |    min |
|                                       Total Young Gen GC time |                          |       23.88 |      11.639 |  -12.241 |      s |
|                                      Total Young Gen GC count |                          |         447 |         247 |     -200 |        |
|                                         Total Old Gen GC time |                          |           0 |           0 |        0 |      s |
|                                        Total Old Gen GC count |                          |           0 |           0 |        0 |        |
|                                                    Store size |                          |     70.9096 |     64.9391 | -5.97045 |     GB |
|                                                 Translog size |                          | 4.09782e-06 | 4.09782e-06 |        0 |     GB |
|                                        Heap used for segments |                          |           0 |           0 |        0 |     MB |
|                                      Heap used for doc values |                          |           0 |           0 |        0 |     MB |
|                                           Heap used for terms |                          |           0 |           0 |        0 |     MB |
|                                           Heap used for norms |                          |           0 |           0 |        0 |     MB |
|                                          Heap used for points |                          |           0 |           0 |        0 |     MB |
|                                   Heap used for stored fields |                          |           0 |           0 |        0 |     MB |
|                                                 Segment count |                          |         905 |         860 |      -45 |        |
|                                                Min Throughput |             index-append |       38156 |     50159.5 |  12003.5 | docs/s |
|                                               Mean Throughput |             index-append |     40531.2 |     53857.5 |  13326.3 | docs/s |
|                                             Median Throughput |             index-append |     40654.4 |     52548.7 |  11894.3 | docs/s |
|                                                Max Throughput |             index-append |     42781.7 |     64913.9 |  22132.2 | docs/s |
|                                       50th percentile latency |             index-append |     700.192 |     464.637 | -235.555 |     ms |
|                                       90th percentile latency |             index-append |     1974.44 |      1584.2 | -390.243 |     ms |
|                                       99th percentile latency |             index-append |     4004.71 |     5614.85 |  1610.13 |     ms |
|                                     99.9th percentile latency |             index-append |     5006.04 |     7648.06 |  2642.02 |     ms |
|                                      100th percentile latency |             index-append |     5842.76 |     9632.15 |  3789.39 |     ms |
|                                  50th percentile service time |             index-append |     700.192 |     464.637 | -235.555 |     ms |
|                                  90th percentile service time |             index-append |     1974.44 |      1584.2 | -390.243 |     ms |
|                                  99th percentile service time |             index-append |     4004.71 |     5614.85 |  1610.13 |     ms |
|                                99.9th percentile service time |             index-append |     5006.04 |     7648.06 |  2642.02 |     ms |
|                                 100th percentile service time |             index-append |     5842.76 |     9632.15 |  3789.39 |     ms |
|                                                    error rate |             index-append |           0 |           0 |        0 |      % |
|                                                Min Throughput | wait-until-merges-finish |   0.0305944 |   0.0496007 |  0.01901 |  ops/s |
|                                               Mean Throughput | wait-until-merges-finish |   0.0305944 |   0.0496007 |  0.01901 |  ops/s |
|                                             Median Throughput | wait-until-merges-finish |   0.0305944 |   0.0496007 |  0.01901 |  ops/s |
|                                                Max Throughput | wait-until-merges-finish |   0.0305944 |   0.0496007 |  0.01901 |  ops/s |
|                                      100th percentile latency | wait-until-merges-finish |     32685.3 |     20160.5 | -12524.8 |     ms |
|                                 100th percentile service time | wait-until-merges-finish |     32685.3 |     20160.5 | -12524.8 |     ms |
|                                                    error rate | wait-until-merges-finish |           0 |           0 |        0 |      % |

-------------------------------
[INFO] SUCCESS (took 0 seconds)
-------------------------------

Disabling this our throughput is significantly better but p99/100 latencies are worse. I suspect this is the slow down after a larger refresh & segment copy slowing some incoming writes.
An immediate optimization we can make here is when there are zero replicas but segrep is enabled as the replication strategy, we bypass this change and let shard idle operate normally.

Raised PR here to allow shard idle when the replication group has no replicas, even is SR is enabled.

Closing this issue as investigation has been done, will track the zero replica case here.


rviz2 in turtlebot3_bringup really required?

I am compiling TB3 packages for RPi. When I generate the dependencies as follows, then rviz2 is also included as a dependency.
$ ROS_DISTRO=galactic ROS_PACKAGE_PATH=/opt/ros2/galactic/ rosinstall_generator turtlebot3 --deps --exclude RPP turtlebot3_navigation2 turtlebot3_cartographer
...
- git:
    local-name: rviz/rviz2
...

It seems turtlebot3_bringup requires it:
https://github.com/ROBOTIS-GIT/turtlebot3/blob/bb4524c09650ccc3f1c619c1b9527efcb6762503/turtlebot3_bringup/package.xml#L16-L21
Is rviz2 really required to bring up TB3?

Hi @goekce
During the bringup of the TurtleBot3 robot itself, RViz2 package is not necessary so you may delete the RViz2 related code and dependencies.
However, the RViz2 is required for most cases when running with the remote PC unless your TurtleBot3 doesn't need a remote PC to operate like TurtleBot3 Autorace Challenge.
Thank you.

Dear Will thank you for your thorough reply.
I suppose that turtlebot_bringup also contains a launch script which can launch rviz, that is why you included rviz2. Don't you think that most users will run turtlebot_bringrup on headless computers without graphical interface and run rviz2 on their remotes?
Still I can also understand the inclusion, this way the package stays more generic.

@goekce
Thank you for the suggestions.
I agree with your thoughts.
As the performance of the recent SBC is getting improved over time, the headless configuration as a standalone robot will be the goal that we should pursue.
I'll try to come up with reasonable modification that can reduce the size of the necessary packages for the robot.
Thanks!


Finish TypeScript rewrite and structure cleanup.

Description
It has been a while for this project –– it is nearly the time to wrap it up. Here are what I have done so far:

I have been re-writing the website and packages using TypeScript. (#27)
I have been separating original component into several libraries for different use cases (headless version and complete version), which makes Ams Date Picker more composable and reusable. It has not finished yet, but composable API design is pushing well.
Re-build the website to make it more clean, focus-efficient, and UX-friendly with dozens of new features like dark mode, variable fonts, and more.
Cutting several bad API designs in original headless version Ams Date Picker. In the first major release, Ams Date Picker will be fully unstyled and composable, which is the best solution for all developers. (And there will be a styled version delivering in a separate package).
Re-organize the code structure by using PNPM.

Related Issues

#27

Contribution Checklist

[x] I read and understood the code of conduct.
[x] My changes generate no new warnings.
[x] My code builds and runs properly on my machine.
[x] I have documented my code.

Some vercel settings need to be adjusted in order to fit the new code structure and PNPM settings.

I would say there may be some additional bugs made by the typing. Will fix them later if there is any. For now, it is good to go (without testing).


fix: make group owner lowercase for comparison

Signed-off-by: ankitm123<EMAIL_ADDRESS>

/cc @jstrachan

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign jstrachan
You can assign the PR to them by writing /assign @jstrachan in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jstrachan
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jstrachan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/approve


[feature] BEM class instead of data-target

I feel data-target very redundant in case of BEM usage.
Could we have targets declaration points to BEM class?

export default class extends Controller {
  static targets = ['drop-area'];

  connect() {

  }
}

Imagine coming back to that HTML a year later. Would you know just by looking that the inner
 has associated JavaScript behavior and that its class name shouldn't be changed or removed? Stimulus is all about making that association explicit, and encourages you to maintain a healthy Separation of Concerns.