chore: release main

:robot: I have created a release beep boop
auto-instrumentations-node: 0.35.0
0.35.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-amqplib bumped from ^0.31.0 to ^0.32.0
@opentelemetry/instrumentation-aws-lambda bumped from ^0.33.1 to ^0.34.0
@opentelemetry/instrumentation-aws-sdk bumped from ^0.9.3 to ^0.10.0
@opentelemetry/instrumentation-bunyan bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-cassandra-driver bumped from ^0.31.0 to ^0.32.0
@opentelemetry/instrumentation-connect bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-dataloader bumped from ^0.2.1 to ^0.3.0
@opentelemetry/instrumentation-dns bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-express bumped from ^0.31.3 to ^0.32.0
@opentelemetry/instrumentation-fs bumped from ^0.5.1 to ^0.6.0
@opentelemetry/instrumentation-fastify bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-generic-pool bumped from ^0.30.0 to ^0.31.0
@opentelemetry/instrumentation-graphql bumped from ^0.32.0 to ^0.33.0
@opentelemetry/instrumentation-hapi bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-ioredis bumped from ^0.32.2 to ^0.33.0
@opentelemetry/instrumentation-knex bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-koa bumped from ^0.33.0 to ^0.34.0
@opentelemetry/instrumentation-lru-memoizer bumped from ^0.31.0 to ^0.32.0
@opentelemetry/instrumentation-memcached bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-mongodb bumped from ^0.32.2 to ^0.33.0
@opentelemetry/instrumentation-mongoose bumped from ^0.31.1 to ^0.32.0
@opentelemetry/instrumentation-mysql bumped from ^0.31.2 to ^0.32.0
@opentelemetry/instrumentation-mysql2 bumped from ^0.32.1 to ^0.33.0
@opentelemetry/instrumentation-nestjs-core bumped from ^0.31.1 to ^0.32.0
@opentelemetry/instrumentation-net bumped from ^0.30.2 to ^0.31.0
@opentelemetry/instrumentation-pg bumped from ^0.32.0 to ^0.33.0
@opentelemetry/instrumentation-pino bumped from ^0.32.1 to ^0.33.0
@opentelemetry/instrumentation-redis bumped from ^0.33.1 to ^0.34.0
@opentelemetry/instrumentation-redis-4 bumped from ^0.33.1 to ^0.34.0
@opentelemetry/instrumentation-restify bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-router bumped from ^0.31.0 to ^0.32.0
@opentelemetry/instrumentation-tedious bumped from ^0.4.1 to ^0.5.0
@opentelemetry/instrumentation-winston bumped from ^0.30.1 to ^0.31.0

auto-instrumentations-web: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-document-load bumped from ^0.30.1 to ^0.31.0
@opentelemetry/instrumentation-user-interaction bumped from ^0.31.1 to ^0.32.0

contrib-test-utils: 0.33.0
0.33.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

host-metrics: 0.31.0
0.31.0 (2022-11-16)
Features

use GA version of metrics (#1281) (7f02de2)

instrumentation-amqplib: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-aws-lambda: 0.34.0
0.34.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-aws-sdk: 0.10.0
0.10.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/propagation-utils bumped from ^0.29.0 to ^0.29.1

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-bunyan: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-cassandra-driver: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-connect: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-dataloader: 0.3.0
0.3.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-dns: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-document-load: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-express: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-fastify: 0.31.0
0.31.0 (2022-11-16)
Features

fastify: add requestHook support (#1255) (c9923e3)
update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Bug Fixes

instrumentation-fastify: stop using fastify types in public api (#1267) (40515c3)

instrumentation-fs: 0.6.0
0.6.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-generic-pool: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-graphql: 0.33.0
0.33.0 (2022-11-16)
Features

graphql: add ignoreTrivialResolveSpans config option (#1256) (aff84bb)
update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Bug Fixes

instrumentation-graphql: stop using types from graphql library in public api (#1268) (f8cabf3)

instrumentation-hapi: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-ioredis: 0.33.0
0.33.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-knex: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-koa: 0.34.0
0.34.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-long-task: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-lru-memoizer: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-memcached: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-mongodb: 0.33.0
0.33.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-mongoose: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-mysql: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-mysql2: 0.33.0
0.33.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-nestjs-core: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-net: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-pg: 0.33.0
0.33.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-pino: 0.33.0
0.33.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-redis: 0.34.0
0.34.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-redis-4: 0.34.0
0.34.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-restify: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-router: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-tedious: 0.5.0
0.5.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

instrumentation-user-interaction: 0.32.0
0.32.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

instrumentation-winston: 0.31.0
0.31.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

@opentelemetry/propagation-utils: 0.29.1
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.31.0 to ^0.33.0

@opentelemetry/resource-detector-alibaba-cloud: 0.27.3
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

@opentelemetry/resource-detector-aws: 1.2.1
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

@opentelemetry/resource-detector-container: 0.2.1
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

@opentelemetry/resource-detector-gcp: 0.27.4
Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

resource-detector-instana: 0.4.0
0.4.0 (2022-11-16)
Features

update experimental deps to ^0.34.0, core deps to ^1.8.0, api to ^1.3.0 (#1278) (e9fe8e1)

Dependencies

The following workspace dependencies were updated

devDependencies

@opentelemetry/contrib-test-utils bumped from ^0.32.0 to ^0.33.0

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-alibaba-cloud-v0.27.3 :sunflower:

robot Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-alibaba-cloud-v0.27.3 sunflower

@dyladan It seems the release wasn't fully completed, only one package was released

https://github.com/open-telemetry/opentelemetry-js-contrib/actions/runs/3482104051/jobs/5824030580

@dyladan will there be a fixed release? Maybe just restarting the failed publish job would work?

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-aws-v1.2.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-container-v0.2.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-gcp-v0.27.4 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-node-v0.35.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-web-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/host-metrics-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/propagation-utils-v0.29.1 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/contrib-test-utils-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-amqplib-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dataloader-v0.3.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fs-v0.6.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-lru-memoizer-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongoose-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-tedious-v0.5.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-sdk-v0.10.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-bunyan-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-connect-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-dns-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-express-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fastify-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-generic-pool-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-graphql-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-hapi-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-ioredis-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-knex-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-memcached-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mongodb-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-mysql2-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-nestjs-core-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pg-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-pino-v0.33.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-redis-4-v0.34.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-restify-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-router-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-winston-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-document-load-v0.31.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-long-task-v0.32.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-user-interaction-v0.32.0 :sunflower:


Some BoM stations report null short_text

I found that my local forecast would have 'null' for the short_text. This resulted in hass showing 'Unknown' in the weather forecast card.
#54 This is a short hack to generate the condition/state from the first part of the extended_text.
Example forecast: https://api.weather.bom.gov.au/v1/locations/qd6dv8/forecasts/daily

Hey Adrian, Thanks so much for your pull request, but I have decided to go with the "standard" states for the 'weather.placename' entity, as per issues #55. so short text missing won't be a problem going forward because it won't be used for the state.

Fixed in release 0.10.1


Build System for Custom Application Configuration

Shared package structure / repository for loading in pre-build configuration / overrides that would make keeping brand specific requirements out of the core mobile repositories

From discussion, suggestion to use python based configuration repo / tool to help populate assets / configuration / etc.

Subtask in Android repository : https://github.com/openedx/openedx-app-android/issues/88


upd(microsoft-edge-dev-deb): 118.0.2060.1 --> 130.0.2835.2-1

Just another update of Microsoft Edge Dev from 118.0.2060.1 --> 130.0.2835.2-1. Please merge immediately when everything's okay.

Don't update .SRCINFO manually, that can mess things up.
If you install pre-commit  and run pre-commit install, the .SRCINFO will always be autogenerated for you

Don't update .SRCINFO manually, that can mess things up. If you install pre-commit and run pre-commit install, the .SRCINFO will always be autogenerated for you

Ah, I see. that's why precommit doesn't work. Anyway, I commit it manually and not using git on Terminal, and I was think that .SRCINFO was generaten manually. So, I just need to write only pacscript, right ?


Need test to check process_model output compiles

Since we are generating Fortran code we should have an easy way to check the validity (from a compile point of view) of the generated code.

#6 resolves this


[RFC] Creating Components

Most UI components require a common set of behavior such as styling and accessibility.  There should be a single point of responsibility for implementing these behaviors.
Goals

:+1: Provide a single path for creating components.
:+1: Allow future extension for base features, such as state machines.
:+1: Expose a public API for consumers to create components.
:+1: Support cascading the CSS-in-JS renderer and theme in the React tree.
:+1: Support overriding component styles, variables, and theme.
:+1: Allow passing component state to the style function
:+1: Keep the component on top in the render tree for optimal testing and debugging.
:+1: Consumer's should be able to react to props/context changes using shouldComponentUpdate.
:+1: Allow us to add static members and methods to components

Restrictions

:-1: Avoid private and deprecated APIs.
:-1: Avoid polluting props with computed values that aren't part of the public API
:-1: Limit the number of wrapping elements in the render tree
:-1: Keep the component first in render tree if wrapping components are required

Proposals
We explored the following approaches.  The below code snippets simplified for ease of review.
createComponent(Component, config)
A HOC that wraps the provided component and passes features through props.
import imageRules from './imageRules'
import imageVariables from './imageVariables'

const Image = (props) => {
  const { classes } = props

  return
}

export default createComponent(Image, {
  rules: imageRules,
  variables: imageVariables,
})

<Render />
A component that takes config as props and computes all the values necessary to create your component.
class Image extends Component {
  render() {
    return (
      <Render
        handledProps={[ ... ]}
        state={StateMachine}
        props={this.props}
        rules={...}
        variables={...}
        render={({ ElementType, rest, classes }) => (
          <ElementType {...rest} className={classes.root} />
        )}
      />
    )
  }
}

Directly render consumers
Directly import context consumers and use them in the render method to access the CSS-in-JS renderer and theme.
import Provider from '../Provider'
import imageRules from './imageRules'
import imageVariables from './imageVariables'

class Image extends Component {
  render() {
    return (
      <Provider.Consumer
        render={(theme) => {
          const classes = getClasses(this.props, imageRules, imageVariables, theme)

          return
        }}
      />
    )
  }
}

HOC Context
A function to be returned in the render method. Calls back with the theme.  Implemented by using a theme consumer in a function.
import Provider from '../Provider'
import imageRules from './imageRules'
import imageVariables from './imageVariables'

const Image = (props) => {
  return hocContext((theme) => {
    const classes = getClasses(props, imageRules, imageVariables, theme)

    return
  })
}

Others
We tested and ruled out these approaches as they rely on the legacy context API and private fela APIs.

BaseComponent - Extend a base class which provides context and a method for creating style classes.
Functional context - "Hides" usage of the legacy context API.  Adds statics to the component and provides a function for accessing context.

Conclusions

Multiple wrapping elements in the React tree are unavoidable due to the need for cascading themes and CSS-in-JS renderers.
...

There has been a lot of conversation around this.  The majority of participants in the conversation are leaning away from the createComponent() HOC.  The preference is toward a pattern where the render method of a component is responsible for wiring the base functionality of the component.  Why?  When the functionality is added from within the component vs from outside the component:

Better debugging - The render tree shows the component on top and the wrapping components inside, vs the component being wrapped in several HOCs.
Easier test access - See 1.  Since the component under test is rendered on top, it is easier to access it and make assertions.  There is no need to hoist properties as in the case of HOCs.
Avoids polluting props - An HOC requires passing computed values through the component's props.  It is not a design goal nor ideal to pass extra information through props, it is only a consequence of computing the values above the component.  Computing values in the render method means the props of the component are not polluted with arbitrary values.  The props API is limited to values that are useful to the user.

For these reasons, I'll add the <Render /> pattern to this PR for consideration.  We may also further explore the pattern of returning a function in the render method.  This accomplishes the same thing as the <Render /> component, but does not add yet another wrapping component to the tree.

If we'll consider the first approach - one thing that would like to clarify for myself to get the full picture.
// better :)
const Image = (props) => {
  return (
    <Render
      rules={imageRules}
      props={props}
      render={({ classes }) => }
    />
  )
}

Would we need to mock the module of Render component in that case? Would it be about something like the following?
// ------ Image.spec ------------
import render from './render'
mock(render.default, RenderMock)

import Image from './image'

.. actual tests ..

Thanks!

just few words around the following goal:
👍 Allow us to add static members and methods to components
It looks like even with render function approach - or, generally speaking, with any approach taken - we would be able to cover this aspect by introducing additional function that should be used to provide static members to component.
Specifically, this is how the render function approach might look like (simplified)
import { renderWithStyles, withStaticMembers } from './core'

class MyComponent {
     render = () => renderWithStyles((theme, classNames) => (
 ... <>);
}

export default withStaticMembers(MyComponent);

Please, note that, essentially, any other approach that is suggested so far (but, I might bet, literally, any) could use the same pattern. With that being said, it seems that requirement of 'having general functionality to introduce static methods' is something that shouldn't be a decisive factor, due to this moment could be addressed pretty easily as a separate piece of common logic.
Also, if would take into account that there are conformance tests that will check whether specific properties are present or not for the exported component, the approach when we will divide common rendering aspects (with render function) and common logic to introduce static properties (via dedicated function) seems to be a promising thing even from the extensibility and maintainability point of view, due to there would be very low risk of coupling these aspects in the implementation code.

'having general functionality to introduce static methods' is something that shouldn't be a decisive factor

Agreed, removed.

@mnajdova has merged an update here that implements the renderComponent() function.  Tests were also updated.  The render tree is great with this approach and our conformance tests were greatly simplified.
We will merge this soon and use this pattern as our approach.  We are open to changes, but they need to prove material superior to this one.

After much consideration, conversations, and iterating we've ended up on what I feel confident as the best middle ground solution.  We've retained all the benefits of returning a function from the render method while reducing the large config and retaining a more sane render method.
This was done using a base UIComponent to implement our base features and leveraging statics for the component concerns: displayName, className, styles (rules/variables), and handledProps.  Defining these as statics means they are created once and available for all instances.  It also means the UIComponent can use them to compute the ElementType, rest props, and css-in-js classes and pass those to the render method.
Refactored example implementation:
class Button extends UIComponent<any, any> {
  static displayName = 'Button'

  static className = 'ui-button'

  static rules = buttonRules

  static variables = buttonVariables

  static propTypes = {
    /** An element type to render as (string or function). */
    as: customPropTypes.as,

    /** Additional classes. */
    className: PropTypes.string,

    /** A button can appear circular. */
    circular: PropTypes.bool,
  }

  static handledProps = ['as', 'circular', 'className']

  static defaultProps = {
    as: 'button',
  }

  render({ ElementType, classes, rest }) {
    return <ElementType {...rest} className={classes.root} />
  }
}

This requires no changes to our tests and retains all previous features.  We will update all components to use this new pattern.  We will also still provide traditional HOCs for consumers that do this same thing.   This way, the user can choose between an HOC or extending the UIComponent.

I've been lurking and generally following the conversation here until I have some extra time to throw at contributing. I really like this final solution. It cleans a lot of things up. Another benefit I think we get here is a pattern that is easier to follow for new contributors.

Hmm. How does this split out state from the view? Are they still intertwined? Where would state be managed?
I preferred the createComponent primarily because it provides an opportunity to enforce state/view separation and could enforce good coding practices (e.g. views should be dumb stateless components that take in props only):
export const Toggle= createComponent({
  state: toggleState,
  styles: toggleStyles,
  view: toggleView,
  statics: { defaultProps: ... }
});

The way I see props flowing is as such:
user props => state transforms => styling => final view props used for view
The "view" could be enforced as a functional thing, implying that both 1. it is the simplest logic possible for the render code, and 2. we could literally call the function to avoid adding any view overhead to reduce the react wrapper code.
This means for partners, if you want to re-scaffold a component to change around the composed subcomponent orientation, (e.g.) a chevron icon moves to the far side or near side) it's easy. Just create a component that provides all the same values except a new view.
You could technically even expose an augmentation API surface to take an existing component and easily replace parts of it.
I like this because it makes it easy to "glue" together separate pieces, rather than to create monolithic components that manage state, props, and rendering all in one place.
Just a bit nervous

Guys, I have made some changes in the implementation of the UIComponent, that you can check in my pull request with the custom resolver for the react-docgen: https://github.com/stardust-ui/stardust/pull/42 The change is in the following: I moved the implementation of the renderComponent service to the render method of the UIComponent in order to avoid passing the overridden renderComponent method as a callback. This is done in order for us to be able to use this in the context of the renderComponent method, which we cannot use if we are using it as a callback to the renderComponent function. I pushed the changes there, because the docs side is working and we can actually try the examples for the components.

I moved the implementation of the renderComponent service to the render method of the UIComponent in order to avoid passing the overridden renderComponent method as a callback. This is done in order for us to be able to use this in the context of the renderComponent method, which we cannot use if we are using it as a callback to the renderComponent function.

We should be able to handle calling any function with a different context using function methods like .bind(), .call() or .apply().  These methods allow setting the this value inside the function.

  All components now extend the UIComponent class.  This will be merged now, though, we aren't opposed to improvements moving forward.


use separate event loop for opened tabs

fix #124231: Use windowOpenNoOpenerWithSuccess only in Safari otherwise windowOpenNoOpener

@isidorn did you mean something like that?

Sorry for the slow response, I was on vacation the previous week. Assigning to June so I review this some time this week.
Thanks for the PR.

Looks great, thank you very much for this PR 👏
And sorry for the slow response.
Merging in.


Mark this as passing in the meantime

There should be some better tests, probably calling mergeAttachments directly, but those are forthcoming.

thanks! it's a start!


'REACT_APP_INJECTABLE' is not recognized as an internal or external command

I cloned the demo react-bootsrap-main repo and installed the packages. After that when I run the command "npm run build", it runs successfully. however when I run "npm run build:lib", it gives the following error

<EMAIL_ADDRESS>build:lib
REACT_APP_INJECTABLE=true npm run build

'REACT_APP_INJECTABLE' is not recognized as an internal or external command,
operable program or batch file.

https://stackoverflow.com/questions/11928013/node-env-is-not-recognized-as-an-internal-or-external-command-operable-comman


Add default subscriber profile to FastDDS example

Running the tutorial as-is, I ran into the following error:
2023-02-08 18:56:54.513 [RTPS_READER_HISTORY Error] Change payload size of '76' bytes is larger than the history payload size of '35' bytes and cannot be resized. -> Function can_change_be_added_nts
I resolved this using a solution based on:
https://github.com/ros2/rmw_fastrtps/pull/663

Ah, looks like there is a PR here already: https://github.com/ros2/ros2_documentation/pull/3290

closing in favor of https://github.com/ros2/ros2_documentation/pull/3290.
@edgex004 it would be nice if you can do review on https://github.com/ros2/ros2_documentation/pull/3290


Range Disabled?

Not sure if this is a request or more so a question.
Is it possible to if you have say 3 sliders on a page with range of 0 - 100 but none of the sliders could overlap in range?
Slider 1 could be 0-50
Slider 2 could be 75 - 100
So slider 3 can only use 51-74?
In theory I would like a scroller to be for hours in a day, but you can have different sets of hours for a 24 hour peiod, but hours could not be used more than once or overlap.
So Range could be 12:00am - 6:00am [6:15am - 4pm used so excluded from range] then continue with 4:15 - 12:00am

The slider can use min/max in dotOptions to limit the sliding range.

But the range has to be concurrent. I did / cant see a way to allow 0 thru 10, then say block anything form 11-19, then allow 20-50
0--------allowed-------------10 - 11---------cant select in here----------19 - 20------allowed---------50

Sorry, this setting is not supported.
But it should be possible to write by myself, I wrote an example:
https://jsfiddle.net/NightCatSama/2xy72dod/10491/


drivers: counter: add snps dw timer

adding driver for snps dw timer
adding shell support
adding driver support for agilex platform
adding agilex board support for alarm application

Hi @nashif @nordic-krch @SgrrZhf @npitre @carlocaione @povergoing
could you please review?


Remove InteractionModelDelegate usage in Python

It's not used anymore, so let's remove it.

Fast tracking, this change has had enough time for review. (> 3 days)


New typescript error only appears while emitting declarations

Bug Report
I have two config files... one that checks types but does not emit anything and the other pretty much the same, except it emit types for when we publish our library. When I run the first configuration everything passes. When I merged my code and the publish happens it failed with the following error:
<path to code>/gridOneOfField.tsx:22:17 - error TS2742: The inferred type of 'getSelectedOption' cannot be named without a reference to '@rjsf/core/node_modules/@types/json-schema'. This is likely not portable. A type annotation is necessary.

22 export function getSelectedOption(options: SchemaType[], selectorField: string, value: any, convertOther: boolean) {
                   ~~~~~~~~~~~~~~~~~

🔎 Search Terms
TS2742 on emit only
🕗 Version & Regression Information

I was unable to test this on prior versions because I just started using Typescript

⏯ Playground Link
None
💻 Code
config that works:
  "compilerOptions": {
    "target": "es6",
    "module": "esnext",
    "moduleResolution": "node",
    "strict": true,
    "noUnusedParameters": false,
    "forceConsistentCasingInFileNames": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "jsx": "react",
    "lib": ["dom", "dom.iterable", "esnext"],
    "noEmit": true
  },

config that fails:
  "compilerOptions": {
    "target": "es6",
    "module": "esnext",
    "moduleResolution": "node",
    "strict": true,
    "noUnusedParameters": false,
    "forceConsistentCasingInFileNames": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "jsx": "react",
    "lib": ["dom", "dom.iterable", "esnext"],
    "declaration": true,
    "emitDeclarationOnly": true,
    "declarationMap" : true,
    "outDir": "./lib"
  },

🙁 Actual behavior
Why would emitting types cause new errors to show up?
🙂 Expected behavior
I would expect the error to have been detected regardless of whether I was emitting types or not

I would expect the error to have been detected regardless of whether I was emitting types or not

This is not a correct expectation. There are certain constructs, like the one you have here, which can't have declarations emitted, but which typecheck fine.

I would expect the error to have been detected regardless of whether I was emitting types or not

This is not a correct expectation. There are certain constructs, like the one you have here, which can't have declarations emitted, but which typecheck fine.

Does specifying the emit parameters along with noEmit: true allow me to check for this situation without actually emitting?


⚠ Bofrost.be has degraded performance

In 69f86c0, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1136 ms

Resolved: Bofrost.be performance has improved in 913684f after 306 days, 5 hours, 16 minutes.


Eye frown parameter

There is eye frown parameter in SRanipal SDK.
It seems to be used for an angry expression or for lowering and raising eyebrows.
If this parameter is added, it will help to express more emotion.

I will add this in the next update, though it won't be documented until HTC actually activates it.


ENH: remove suspicious sequence of type castings

See V220. Suspicious sequence of types castings: memsize -> 32-bit integer -> memsize.

I think the link explains it; idx and s2 are both of type npy_intp, so idx / s2 should be as well; then this gets cast to int and then assigned back to idx so back to npy_intp. So an unnecessary 64 -> 32 -> 64.

Seems fine to me, so in it goes. Thanks @cgohlke, @pvanmulbregt


Quick Fix: On chrome, the icon from buttons prevents the drop effect.

Demo: https://youtu.be/ruhN42qytbs

Nice catch!

I told him :)) My recording :D

:+1: @neacsugeorge


Build Improvements

Summary

removes the Makefile and replaces all the targets with npm scripts.
Changes the AppGroupId to be in the Info.plist file (iOS)
Modifies circleCI to use Xcode 12
Updates the version of Cocoapods to match the one in the CI
Updates Fastlane scripts
Split APK's base on arch for release builds using the ABI filters

Note:
For Android release builds the build number depends on the architecture, for example build 330 would be
armeabi-v7a: 1000330
x86: 2000330
arm64-v8a: 3000330
x86_64: 4000330
universal: 330
Ticket Link
https://github.com/mattermost/mattermost-developer-documentation/pull/709

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/11036
https://circleci.com/gh/mattermost/mattermost-mobile/11035

Building app in separate branch.

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/11047
https://circleci.com/gh/mattermost/mattermost-mobile/11046

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/11047
https://circleci.com/gh/mattermost/mattermost-mobile/11046

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/11055
https://circleci.com/gh/mattermost/mattermost-mobile/11054

Cherry pick is scheduled.

removes the Makefile and replaces all the targets with npm scripts.

Not sure if this is a known issue, I couldn't find a PR: we'll need to update our docs https://developers.mattermost.com/contribute/mobile/developer-setup/

@ashishbhate docs should be up to date.

I dont see the changes on the live version of the developer docs. I remember seeing some issue on the community server about the docs not deploying properly. I guess it could be that.

Yes I don't see it either


If you're creating a site with a slug that already exists, offer up option to delete existing site

Prevents needing to run a separate command to delete an existing site if you're just trying to override it.

Added in 03221a173fe8d93746ae16e6a0b33b56e3d25ce3


Fix a typo in PR template

Fixes a typo in the PR template

Thanks for catching this one, @aeither!


inline binary comparison ops to prevent function call overhead

Description
In a CPU bound load test where there are at least 3 binary operations in play, nearly 10% of the time on the server is spent evaluating BinaryOperatorTransformFunction.getBinaryFuncResult, because the call is virtual.

This moves the very simple overrides into the base class, and leaves the individual classes in place for the sake of the registration mechanism alone.
Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)

[ ] Yes (Please label as backward-incompat, and complete the section below on Release Notes)

Does this PR fix a zero-downtime upgrade introduced earlier?

[ ] Yes (Please label this as backward-incompat, and complete the section below on Release Notes)

Does this PR otherwise need attention when creating release notes? Things to consider:

New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed

[ ] Yes (Please label this PR as release-notes and complete the section on Release Notes)

Release Notes

Documentation

Codecov Report

Merging #7709 (c5a35d5) into master (e80198d) will decrease coverage by 42.21%.
The diff coverage is 62.19%.

:exclamation: Current head c5a35d5 differs from pull request most recent head b8fc135. Consider uploading reports for the commit b8fc135 to get more accurate results

@@              Coverage Diff              @@
##             master    #7709       +/-   ##
=============================================
- Coverage     71.50%   29.28%   -42.22%
=============================================
  Files          1581     1572        -9
  Lines         80400    80092      -308
  Branches      11943    11920       -23
=============================================
- Hits          57486    23451    -34035
- Misses        19026    54577    +35551
+ Partials       3888     2064     -1824

Flag
Coverage Δ

integration1
29.28% <62.19%> (+0.21%)
:arrow_up:

integration2
?

unittests1
?

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

.../pinot/common/utils/ClientSSLContextGenerator.java
0.00% <0.00%> (-31.04%)
:arrow_down:

...reaming/StreamingSelectionOnlyCombineOperator.java
0.00% <0.00%> (-71.12%)
:arrow_down:

...rg/apache/pinot/common/utils/helix/TableCache.java
80.58% <62.50%> (-2.13%)
:arrow_down:

...e/pinot/common/utils/FileUploadDownloadClient.java
53.16% <66.66%> (-13.79%)
:arrow_down:

.../core/operator/combine/GroupByCombineOperator.java
75.00% <68.00%> (-4.37%)
:arrow_down:

...form/function/BinaryOperatorTransformFunction.java
27.93% <77.77%> (-4.31%)
:arrow_down:

...or/transform/function/EqualsTransformFunction.java
100.00% <100.00%> (ø)

.../function/GreaterThanOrEqualTransformFunction.java
100.00% <100.00%> (ø)

...ansform/function/GreaterThanTransformFunction.java
100.00% <100.00%> (ø)

...orm/function/LessThanOrEqualTransformFunction.java
100.00% <100.00%> (ø)

... and 1123 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 e80198d...b8fc135. Read the comment docs.


Whitelist Request - 	substrate.office.com

Microsoft To Do sync is broken if the domain is blocked.  Initializing a sync command request results in only this domain being queried. No other domain is utilized after substrate.office.com is whitelisted (such as a tracker being blocked causing a subsequent failure).
I do not have sufficient knowledge if the domain is also utilized for data tracking from other MS based applications.

Only one list blocks it (WindowsSpyBlocker extra), so I think it is a most likely a false positive. I've added it to the whitelist which means the script used to generate the blocklists will remove substrate.office.com from the list in the next version, which should be in under a day


Added function caching and return value logging.

I incorporated the fixes for return value retrieval.  That fixes most of the problems, yet some crashes on Windows still occur.  Its gotten to the point where I'm not very effective at debugging this--not without spending a lot more time (which I don't have right now, unfortunately).  I suspect its more issues with DynamoRIO on Windows.  It seems to work fine on Linux.
Can you give this a try and see what the problem might be?

It seems for me like drltrace's bug rather than DynamoRIO's. This is the output from winDBG:
(1294.ec): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
drltracelib!_output_l+0x390:
00000000`900196b0 66443911        cmp     word ptr [rcx],r10w ds:00000000`00000002=????
0:000> r
rax=000000007ffffffe rbx=0000000000000002 rcx=0000000000000002
rdx=0000000000000007 rsi=0000000000000005 rdi=000000009003e282
rip=00000000900196b0 rsp=00000000800ddfb0 rbp=00000000800de0b0
 r8=00000000ffffffff  r9=0000000090000000 r10=0000000000000000
r11=0000000000000200 r12=00000000ffffffff r13=00000000800de378
r14=0000000000000800 r15=00000000800de253
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
drltracelib!_output_l+0x390:
00000000`900196b0 66443911        cmp     word ptr [rcx],r10w ds:00000000`00000002=????

Callstack (might be wrong):
0:000> k
Child-SP          RetAddr           Call Site
00000000`800ddfb0 00000000`90011afa drltracelib!_output_l+0x390 [f:\dd\vctools\crt\crtw32\stdio\output.c @ 1640]
00000000`800de2d0 00000000`90005cf7 drltracelib!_snprintf+0x86 [f:\dd\vctools\crt\crtw32\stdio\sprintf.c @ 130]
00000000`800de350 00000000`900057e6 drltracelib!get_module_and_function_name+0x247
00000000`800de490 00000000`90006461 drltracelib!std::basic_ostream<char,std::char_traits<char> >::flush+0x196
00000000`800de670 00000000`9002f634 drltracelib!std::basic_ios<char,std::char_traits<char> >::init+0x631
00000000`800deca0 00000000`8094cbc2 drltracelib!drwrap_in_callee+0x1c4 [e:\vb\drltrace\drltrace\drltrace_src\dynamorio\ext\drwrap\drwrap.c @ 1865]
00000000`800dee80 00000000`00000000 0x8094cbc2

So, we have a null-pointer dereference here but I have no idea where exactly it happens in drltracelib...

I think the problem happens in get_module_and_function_name


Implementation of "for lock" syntax

Seems like there is a hole in the syntax. There is "for lock" statement that is not handled. I couldn't find any issue about it, so I create one. "For modify" and "for read" are handled.

METHODS lock FOR LOCK IMPORTING keys FOR LOCK /foo/bar.

https://syntax.abaplint.org/?filter=methoddef#/abap/statement/MethodDef

@Zeatynis try again, 2.95.32 published

@larshp thanks for such fast response! It is working 😃


feat: initial legacy of loathing support

Add path, dump initial items.
Enable Cincho skills even when we only have the replica.
I've disabled the consistency check for familiar hatchlings for replica familiars, because they "grow" to one of the existing familiars, and I think we want the "hatchling" of those familiars to still be the original one.

Could we customise the consistency check to account for these specific replica items?

Updated. Also added what I hope is a perf improvement: we can only get the replica if we're in the Legacy of Loathing path, so don't even check for it outside.
I'm not sure if we can get the regular one inside -- can you break ronin and then pull equipment? -- so I've left checking even if we're in path.

Also updated to fix the familiar situation. Legacy of Loathing's interaction with standard is a bit tricky for us to handle -- it seems that various (replica) IotM-derived items are usable, but they still show up in standard.php as being unusable.

I ran this in LoL yesterday and it worked fine. I think it's good to get it in the hands of autoscenders so we can identify everything else this path still needs ;)


pre-trained model

Hi,
The paper mentioned that vit-moe is pre-trained on ImageNet first. Do we have a training script to do that?
Thanks!

@tankche1 Hi, have you found a way to pre-train the models?


Remove "Rio" link

Remove "Rio" link since it is hidden from Dashboard view - https://github.com/rancher/rancher/issues/29264

Rio link is not seen anymore when testing with latest master - 5044f2


NTUEEPLUS-139. Set required in career form and auto complete some fields in add recommendation form

What is this PR for?

Set required for title、name、desireWorkType in recommendation form and title in recruitment form
Use redux store user's phone, email, studentId, name, so that recommendation add form can auto complete some fields
What type of PR is it?
[Bug Fix | Improvement | Feature | Documentation | Hot Fix | Refactoring]
improvement
Todos

[ ] - no

What is the Jira issue?

https://ntueeplus.atlassian.net/browse/NTUEEPLUS-139
Screenshots (if appropriate)
use * to note required and auto complete

alert if you don't fill the required fields

@featherchen finish!


Whether the app supports Chinese？

I want to use it to design a set of smart home devices, but it is obviously used in China, if the app does not support Chinese, it will be more troublesome to use. Especially if the user is not a developer, this can be fatal.

+1


Starting a shake in coroutines won't have any effect

Seems like it is caused by GetT() functions in CameraShake.cs.
m_startTime gets initiated in Start(). However in a coroutine it seems that GetT() will be called before initiation. So the shake would be considered complete, and deleted in the next frame.
Setting m_startTime in ctor solves the problem.

Ah, good catch! I changed initialization from Start() to Awake() which seemed to fix the issue in my test driver. Thanks.


Using Wire1 with teensy 4.0

Hi.
First of all I would like to say that I really like this library and I have several projects based on it.
The continues sampling mode is awesome!
Nowadays due to shortage of teensy's I had to adapt some projects to work with teensy 4.0. Unfortunately, the pins (pin 16 and 17) that were previously used I2C wire 0 channel now hooked to wire1 in 4.0.
Is it possible to make this library work based on wire1?
Any help would be appreciated.
Thank you!

Just had to ask it :)
Fixed it by using
ADS1115_WE adc = ADS1115_WE(&Wire1, I2C_ADDR);

Hi @ElfyShort , good to hear you solved it yourself! Thank you for your nice comments on the library.

Thank you @wollewald for making such a nice library with great examples :)


Problem with integration of MassTransit.SimpleInjector in ASP.NET Core 3.0

Is this a bug report?
Probably.
'The registered delegate for type ConsumeContext returned null.' exception will occur during asp.net core 3.0 application starting.
This application uses the latest MassTransit.RabbitMq and MassTransit.SimpleInjector NuGet packages.
Can you also reproduce the problem with the latest version?
This problem reproduced on latest version of:

MassTransit.SimpleInjector 5.5.6
MassTransit.RabbitMQ 5.5.6
SimpleInjector.Integration.AspNetCore 4.7.1
SimpleInjector.Integration.AspNetCore.Mvc.Core 4.7.1
ASP.NET Core 3.0

Environment

Operating system: Windows 10(1903), Docker <IP_ADDRESS>(39773), Alpine 3.9
Visual Studio version: 2019
Dotnet version: .Net Core 3.0

Steps to Reproduce
I have created one simple asp.net core application. It acts as a consumer and it acts as producer (for simplify).

Install Docker Desktop (download) (with linux containers)
Checkout project with a reproducible example on your local pc. git clone https://github.com/iVova/AspNetCore3_MassTransit_SimpleInjector.git
Just run the project in Visual Studio

Expected Behavior

The web application should run without any exception and an open browser with the default URL.
SendNotificationOnUserCreatedConsumer consumer should instantiate with IClock application service and receive a message

Actual Behavior
During the starting, web application exception occurred on container verification. (as recommended SimpleInjector)
Exception message:
The configuration is invalid. Creating the instance for type ISendEndpointProvider failed.
The registered delegate for type ISendEndpointProvider threw an exception. The registered delegate for type ConsumeContext threw an exception.
The registered delegate for type ConsumeContext returned null.
See attached screenshot.

Reproducible Demo project
On GitHub: https://github.com/iVova/AspNetCore3_MassTransit_SimpleInjector
Reproducible Demo code
StartUp.cs
using MassTransit;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using MyAspCoreApp.Consumers;
using MyAspCoreApp.Services;
using SimpleInjector;
using SimpleInjector.Lifestyles;
using System;

namespace MyAspCoreApp
{
    public class Startup
    {
        private readonly Container _container = new Container();

        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            _container.Options.DefaultScopedLifestyle = new AsyncScopedLifestyle();

            services.AddControllers();

            services.AddSimpleInjector(_container, options =>
            {
                // AddAspNetCore() wraps web requests in a Simple Injector scope.
                options.AddAspNetCore()
                    .AddControllerActivation();
            });

            // !!!
            AddMassTransitThroughSimpleInjector(services, _container);
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            // !!!!
            ConfigureSimpleInjector(app, _container);

            app.UseHttpsRedirection();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
        }

        public static IApplicationBuilder ConfigureSimpleInjector(IApplicationBuilder app, Container container)
        {
            // UseSimpleInjector() enables framework services to be injected into
            // application components, resolved by Simple Injector.
            app.UseSimpleInjector(container, options =>
            {
                // Add custom Simple Injector-created middleware to the ASP.NET pipeline.
                // options.UseMiddleware<CustomMiddleware1>(app);

                // Optionally, allow application components to depend on the
                // non-generic Microsoft.Extensions.Logging.ILogger abstraction.
                options.UseLogging();
            });

            InitializeContainer(container);

            // Always verify the container
            container.Verify();

            var busControl = container.GetInstance<IBusControl>();
            busControl.Start();

            return app;
        }

        private static void InitializeContainer(Container container)
        {
            // Add application services. For instance:
            container.Register<IClock, SystemClock>(Lifestyle.Scoped);
        }

        public static void AddMassTransitThroughSimpleInjector(IServiceCollection services, Container container)
        {
            container.AddMassTransit(configurator =>
            {
                configurator.AddConsumersFromNamespaceContaining<SendNotificationOnUserCreatedConsumer>();

                configurator.AddBus(() =>
                {
                    var bus = Bus.Factory.CreateUsingRabbitMq(cfg =>
                    {
                        var host = cfg.Host(new Uri("rabbitmq://myaspcoreapp.rabbitMq"), hostConfigurator =>
                        {
                            hostConfigurator.Username("guest");
                            hostConfigurator.Password("guest");
                        });

                        cfg.ConfigureEndpoints(container);
                    });

                    return bus;
                });
            });
        }
    }
}

Producer
using MassTransit;
using Microsoft.AspNetCore.Mvc;
using MyAspCoreApp.Messages;
using System;
using System.Threading.Tasks;

namespace MyAspCoreApp.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private readonly IBus _bus;

        public WeatherForecastController(IBus bus)
        {
            _bus = bus;
        }

        [HttpGet]
        public async Task Get()
        {
            var message = new UserCreatedMessage
            {
                UserId = Guid.NewGuid()
            };

            await _bus.Publish(message);
        }
    }
}

Consumer
using MassTransit;
using MyAspCoreApp.Messages;
using MyAspCoreApp.Services;
using System.Threading.Tasks;

namespace MyAspCoreApp.Consumers
{
    public class SendNotificationOnUserCreatedConsumer : IConsumer<UserCreatedMessage>
    {
        private readonly IClock _clock;

        public SendNotificationOnUserCreatedConsumer(IClock clock)
        {
            _clock = clock;
        }

        public Task Consume(ConsumeContext<UserCreatedMessage> context)
        {
            var time = _clock.UtcNow;
            return Task.CompletedTask;
        }
    }
}

Does it work if you don't call Verify on the container?

So why isn't IClock registered as scoped? If you register it as Scoped, does your Verify method work?

No. Verify method does not work even with Scoped IClock. (I tried. Same error.)

Maybe it is related to this simple injecto's issue: https://github.com/simpleinjector/SimpleInjector/issues/754

I'm closing this, I doubt it's MassTransit.

The problem must be resolved on SimpleInjector 4.8+

Same error.
Even after upgrade application to the latest version of ASP.Net Core 3.1, SimpleInjector 4.8.1 and MassTransit 6.0.0
There is a branch with the latest changes Asp.Core3.1_SimpleInjector4.8.1_MassTransit6.0
Exception:
The configuration is invalid. Creating the instance for type ISendEndpointProvider failed. The registered delegate for type ISendEndpointProvider threw an exception. The registered delegate for type ConsumeContext threw an exception. The registered delegate for type ConsumeContext returned null.

Could you please say when can we expect the latest release containing this fix by any chance?

@phatboyg  Ive implemented the latest version of mass transit of two of my microservices using azure service bus, it works neatly when i publish and consume in the same application while testing on loacal, but the consumer application also running on my local machine with the same consumer contract does not receive the message. i have tried so many things, but im still stucked. any idea  that can help?. I am not having any errros, message is published to bus successfully and consume on consumer in the same publishing app but another consumer app is just not receiving the message


Getting error due to renamed gen_subtitles call

Getting the below error after setting this up for the first time. Seems like this function may have been accidentally reamed in the latest update: https://github.com/McCloudS/subgen/commit/f2a874b65d0196bfedaeb382cbf7e652d6addc7d
2024-03-20T01:53:11.356070262Z INFO:     <IP_ADDRESS>:60572 - "POST /jellyfin HTTP/1.1" 500 Internal Server Error
2024-03-20T01:53:11.360051873Z ERROR:    Exception in ASGI application
2024-03-20T01:53:11.360069320Z Traceback (most recent call last):
2024-03-20T01:53:11.360071443Z   File "/usr/local/lib/python3.10/dist-packages/uvicorn/protocols/http/h11_impl.py", line 407, in run_asgi
2024-03-20T01:53:11.360073498Z     result = await app(  # type: ignore[func-returns-value]
2024-03-20T01:53:11.360083352Z   File "/usr/local/lib/python3.10/dist-packages/uvicorn/middleware/proxy_headers.py", line 69, in __call__
2024-03-20T01:53:11.360085258Z     return await self.app(scope, receive, send)
2024-03-20T01:53:11.360087067Z   File "/usr/local/lib/python3.10/dist-packages/fastapi/applications.py", line 1054, in __call__
2024-03-20T01:53:11.360088799Z     await super().__call__(scope, receive, send)
2024-03-20T01:53:11.360090450Z   File "/usr/local/lib/python3.10/dist-packages/starlette/applications.py", line 123, in __call__
2024-03-20T01:53:11.360092174Z     await self.middleware_stack(scope, receive, send)
2024-03-20T01:53:11.360094362Z   File "/usr/local/lib/python3.10/dist-packages/starlette/middleware/errors.py", line 186, in __call__
2024-03-20T01:53:11.360096155Z     raise exc
2024-03-20T01:53:11.360097720Z   File "/usr/local/lib/python3.10/dist-packages/starlette/middleware/errors.py", line 164, in __call__
2024-03-20T01:53:11.360099590Z     await self.app(scope, receive, _send)
2024-03-20T01:53:11.360101244Z   File "/usr/local/lib/python3.10/dist-packages/starlette/middleware/exceptions.py", line 62, in __call__
2024-03-20T01:53:11.360102909Z     await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
2024-03-20T01:53:11.360104732Z   File "/usr/local/lib/python3.10/dist-packages/starlette/_exception_handler.py", line 64, in wrapped_app
2024-03-20T01:53:11.360106470Z     raise exc
2024-03-20T01:53:11.360108017Z   File "/usr/local/lib/python3.10/dist-packages/starlette/_exception_handler.py", line 53, in wrapped_app
2024-03-20T01:53:11.360109904Z     await app(scope, receive, sender)
2024-03-20T01:53:11.360111549Z   File "/usr/local/lib/python3.10/dist-packages/starlette/routing.py", line 758, in __call__
2024-03-20T01:53:11.360113375Z     await self.middleware_stack(scope, receive, send)
2024-03-20T01:53:11.360115073Z   File "/usr/local/lib/python3.10/dist-packages/starlette/routing.py", line 778, in app
2024-03-20T01:53:11.360116757Z     await route.handle(scope, receive, send)
2024-03-20T01:53:11.360118480Z   File "/usr/local/lib/python3.10/dist-packages/starlette/routing.py", line 299, in handle
2024-03-20T01:53:11.360120208Z     await self.app(scope, receive, send)
2024-03-20T01:53:11.360121963Z   File "/usr/local/lib/python3.10/dist-packages/starlette/routing.py", line 79, in app
2024-03-20T01:53:11.360123684Z     await wrap_app_handling_exceptions(app, request)(scope, receive, send)
2024-03-20T01:53:11.360125840Z   File "/usr/local/lib/python3.10/dist-packages/starlette/_exception_handler.py", line 64, in wrapped_app
2024-03-20T01:53:11.360127686Z     raise exc
2024-03-20T01:53:11.360129381Z   File "/usr/local/lib/python3.10/dist-packages/starlette/_exception_handler.py", line 53, in wrapped_app
2024-03-20T01:53:11.360131029Z     await app(scope, receive, sender)
2024-03-20T01:53:11.360134626Z   File "/usr/local/lib/python3.10/dist-packages/starlette/routing.py", line 74, in app
2024-03-20T01:53:11.360136344Z     response = await func(request)
2024-03-20T01:53:11.360138011Z   File "/usr/local/lib/python3.10/dist-packages/fastapi/routing.py", line 278, in app
2024-03-20T01:53:11.360139862Z     raw_response = await run_endpoint_function(
2024-03-20T01:53:11.360141544Z   File "/usr/local/lib/python3.10/dist-packages/fastapi/routing.py", line 193, in run_endpoint_function
2024-03-20T01:53:11.360143390Z     return await run_in_threadpool(dependant.call, **values)
2024-03-20T01:53:11.360145082Z   File "/usr/local/lib/python3.10/dist-packages/starlette/concurrency.py", line 42, in run_in_threadpool
2024-03-20T01:53:11.360146735Z     return await anyio.to_thread.run_sync(func, *args)
2024-03-20T01:53:11.360148527Z   File "/usr/local/lib/python3.10/dist-packages/anyio/to_thread.py", line 56, in run_sync
2024-03-20T01:53:11.360150139Z     return await get_async_backend().run_sync_in_worker_thread(
2024-03-20T01:53:11.360151868Z   File "/usr/local/lib/python3.10/dist-packages/anyio/_backends/_asyncio.py", line 2144, in run_sync_in_worker_thread
2024-03-20T01:53:11.360153691Z     return await future
2024-03-20T01:53:11.360155371Z   File "/usr/local/lib/python3.10/dist-packages/anyio/_backends/_asyncio.py", line 851, in run
2024-03-20T01:53:11.360157111Z     result = context.run(func, *args)
2024-03-20T01:53:11.360158657Z   File "/subgen/subgen.py", line 266, in receive_jellyfin_webhook
2024-03-20T01:53:11.360160443Z     titles(path_mapping(fullpath), transcribe_or_translate, True)
2024-03-20T01:53:11.360162143Z NameError: name 'titles' is not defined

You're right, not sure how that slipped through.  Fixed it.  Thanks for the heads-up.


PR: Fix some UX/UI issues in the Files pane

Description of Changes

Create the changes discussed over the file explorer pane,

[x] Add filter icon as button on toolbar (needs the blue outline pressed state)

[x] Add tooltip for new button (maybe “Activate and deactivate filter”)

[x] Change hamburger menu description to “Edit filter settings” or something similar (this menu item is now the way to open the dialog)

[x] Remove “Show all files” option in the hamburger menu

[x] Add “Return to default” button in the filter settings dialog

[x] Change Python script to Python file in the New submenu

[x] Make the window title of the filename filter dialog match the options menu text

[x] Add a description in the filter dialog

[x] Change the filter dialog to a non blocking dialog

Pane layout:

Filter dialog:

Hamburger menu:

Context menu:

Preferences config page:

Issue(s) Resolved

Fixes #13465
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: Steff456

Hello @steff456! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/plugins/explorer/widgets/explorer.py:

Line 115:20: E201 whitespace after '('
Line 115:71: E202 whitespace before ')'

@ccordoba12, @juanis2112 and @CAM-Gerlach this PR is ready for review :)

/show binder

This looks great @steff456. Thanks for taking care of this!
Some minor comments:

In the default filters "*.txt" appears twice.

I think the tooltip for the filters should be "Activate filter" when the filter is deactivated and "Deactivate filter" when it is activated. (Similar to the lock/unlock tooltips of the lock icon in the help pane)

I think we said we could add a link to point people to what a "glob pattern" means, so please add this link
https://docs.python.org/3/library/glob.html to the "glob patterns" text.

I like the new message in the filter dialog but maybe we should add something that clarifies the fact that the filters show files instead of hiding them. I would suggest: "Filer files by name, extension, or more using glob patterns. Please enter the glob patterns of the files you want to show, separated by commas". What do you think @isabela-pf?

Didn't realize I never submitted this, sorry. I agree with @juanis2112 's suggestions as well, with a couple additional followup comments:

I think the tooltip for the filters should be "Activate filter" when the filter is deactivated and "Deactivate filter" when it is activated. (Similar to the lock/unlock tooltips of the lock icon in the help pane)

Agreed, this would be better. I suggest "filename filters" to be more clear, since we have plenty of space.

I think we said we could add a link to point people to what a "glob pattern" means, so please add this link: https://docs.python.org/3/library/glob.html to the "glob patterns" text.

We should definitely add a link, but I suggest https://en.wikipedia.org/wiki/Glob_(programming) instead, since its a much friendlier introduction to the subject that explains what globs are and what the characters mean (which is what users need to know to use them); the Python docs just discuss the specific functions and methods of the glob module without actually explaining how they work. (I think it might have been my fault for suggesting this one in the first place, sorry)

@CAM-Gerlach and @juanis2112 I made all the requested changes, please let me know if there's something else that can be improved :)


Review naming of "'" functions

Stick with Haskell conventions, where possible.

No obvious better names for now.


Ability to manage the membership of a management group for a subscription

Initially the module supports placing a subscription into a management group.
Over time it may become necessary to move this subscription to a different management group.
This could be performed by using the azurerm provider and creating a azurerm_management_group_subscription_association resource

Fixed by #29


Reduce width for Footer

Description
Some changes in Footer

The footer seems too much wide (in height) for desktops, it would be much more subtle with little bit of reduced height !

Also the report button could have a slightly red text, blue doesnot looks proper on a black background

Screenshots

Additional information
No response

Hey @IAmTamal, I can work on it.
About the report button, do you want to change only the text color to red? or change both text and border color to red?


Cancel playlist when exiting Gameplay

Is ScreenGameplay's destructor the right place to do this?
Part of this is already done process is already done here:
https://github.com/Nickito12/etterna/blob/ffa358b1ade6142560ff7bd5db1ef3dfeda80f32/src/ScreenGameplay.cpp#L2262
Wouldn't adding
SONGMAN->playlistcourse = "";

in the if block on line 2262 accomplish the same thing?

Moving this to https://github.com/etternagame/etterna/pull/6


"Package Plots not found in current path"

Despite I see in setup.py the line
os.system('julia -e "import Pkg; Pkg.add([\\"DataFrames\\", \\"CSV\\", \\"Plots\\"]); Pkg.precompile()"')

when I launch a Pluto notebook on Binder, "Plots" is not found and requires (several minutes) to be installed after clicking on the "cloud icon" next to the 'using Plots' line.

Don't pay too much attention to that line, it's just to populate the global cache.
See
https://pkgdocs.julialang.org/v1/
https://github.com/fonsp/Pluto.jl/wiki/🎁-Package-management#package-installations-are-shared-between-environments


ResizeObserver loop limit exceeded when expanding layer to see features

item resolved from this pr https://github.com/1904labs/ol-kit/pull/17


add scripts to make a zip file with modules and test it

Addresses https://github.com/illinois-ceesd/planning/issues/26.

Thanks for working on this. We should also document somewhere how to use this, so that folks trying to run on big, distributed machines aren't confused.

Thanks for working on this. We should also document somewhere how to use this, so that folks trying to run on big, distributed machines aren't confused.

Maybe in a (emirge/mirgecom) wiki page? Or add it in a (README) file inside emirge/mirgecom itself?

Maybe in a (emirge/mirgecom) wiki page? Or add it in a (README) file inside emirge/mirgecom itself?

Maybe the README? It's just a sentence IMO, and the README is more
likely to stay up to date.


added(agent): chat/import to import historical chats

Adds a new chat/import request that allows editors that had custom chat implementations (JetBrains) to import their chat history to the agent so that it can be used in the webview.
Test plan
Manually tested with JetBrains. Need to add some agent tests.
Changelog
Added ability to import historical chats through the agent.

I tried these changes with JetBrains. I understand that with this (and with the JB part) we will be able to import the chats to the agent's storage. However, we still have no mechanism to retrieve the historical chats from the storage. Is that right?
I ask because I tested it like this:

started two conversations with cody
reviewed the chats in the history tab
closed project
opened project
reviewed the chats in the history tab

Actual: The chat history is empty
Expected: The persisted chats are available in the history

@mkondratek I'm not sure if I completely follow the steps. To test this, I did the following:

Checkout this branch in Cody
In the sibling JetBrains repo, I checked that there was a ./.info/cody_history.xml file with a past history of chats.
Started up this branch of JetBrains with CODY_DIR=<path to cody> ./gradlew -PforceBuild=true runIde
Opened the webview chat UI and checked out the history tab and verified my JetBrains chat history was present.

I tried it locally (also with a debugger) and:

Migration code is ran
I see history being exported/imported

But:

It only happens once, and looks like state is not really persisted. After a second restart it does not work anymore
Even during the first start when import succeeded, when I click on one of the historic chats to import them it does not work (it switches beck to the chat view but old chat is not loaded).

@pkukielka Good catches! those were fixed by:

Specifying Server-Managed global state
Keying history by ID instead of date. I must have been looking at a bad sample file that used dates as keys.

I tested it locally. Works fine now 🚀

I tested it as well and indeed it works now, but I found one bug.
When restarting a past conversation date in history was not set to today but NaN:

On the tem call we decided to merge it to be able to cut nightly release which can be run through QA.
Fixes can be done in a followup PRs.

@pkukielka I tried running it with the history you sent me, but I was unable to reproduce. The only change I made to the cody_history.xml was to sub in my account ID for yours, and the resulting cody-local-chatHistory-v2 was the same as yours
except for the account name swap.
Perhaps it has something to do with having run it with the in-progress PR when it was using dates as IDs instead of the actual chat ID?

@jamesmcnamara

When restarting a past conversation date in history was not set to today but NaN:

It appears not after export, but after you open past conversation and try to continue it, and then check history tab again.


End-to-End Demo for Google Compute Engine

Fixes #50

Instructions for Compute Engine
Reference instructions from existing End-to-End Demo document

very cool!

Sorry for the delay on reviewing this. We are in the process of getting a GCE account so we can easily verify changes made to this later.

Thanks for taking the time to review!

Awesome!


Error reported on axum version 0.6.1

Hi, first of all thank you for such a useful crate, when I upgraded axum to 0.6.1 it apparently had a compatibility issue, see the log below for details:
error[E0277]: the trait bound `GovernorLayer<'_, PeerIpKeyExtractor, governor::middleware::StateInformationMiddleware>: Clone` is not satisfied
   --> src/main.rs:50:9
    |
49  |       let app = routes::build().layer(Extension(database)).layer(
    |                                                            ----- required by a bound introduced by this call
50  | /         ServiceBuilder::new()
51  | |             .layer(HandleErrorLayer::new(|err: BoxError| async move {
52  | |                 (
53  | |                     StatusCode::INTERNAL_SERVER_ERROR,
...   |
58  | |                 config: &governor_conf,
59  | |             }),
    | |______________^ the trait `Clone` is not implemented for `GovernorLayer<'_, PeerIpKeyExtractor, governor::middleware::StateInformationMiddleware>`
    |
    = note: required for `GovernorLayer<'_, PeerIpKeyExtractor, governor::middleware::StateInformationMiddleware>` to implement `Clone`
    = note: 2 redundant requirements hidden
    = note: required for `ServiceBuilder<Stack<GovernorLayer<'_, PeerIpKeyExtractor, governor::middleware::StateInformationMiddleware>, Stack<..., ...>>>` to implement `Clone`
note: required by a bound in `Router::<S, B>::layer`
   --> /Users/wangeguo/.cargo/registry/src/mirrors.ustc.edu.cn-12df342d903acd47/axum-0.6.1/src/routing/mod.rs:316:30
    |
316 |         L: Layer<Route<B>> + Clone + Send + 'static,
    |                              ^^^^^ required by this bound in `Router::<S, B>::layer`
help: consider borrowing here
    |
50  |         &ServiceBuilder::new()
    |         +

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

Glad you're enjoying it!
Yeah, with Axum 0.6 Layers must now implement Clone. I've updated the example to show how to do that,  the easiest way is to Box the governor_config and then leak it.
I've updated the basic example and released a new version with updated dependencies.

It still looks wrong, I checked your example and found that axum in cargo.toml is still 0.5.16

Apologies, I screwed up the transfer. Pretty sure it's right now


Link to the reference for Never.

When reviewing a PR (https://github.com/apple/swift/pull/62235) to improve the API reference for Never I noticed that TSPL doesn't link to the reference for that type anywhere.

@krilnon Yes, I want to start a discussion about that, and we should add an entry to the TSPL style guide when we come to a conclusion.  Elsewhere, links use the []() syntax because that's what the RST-to-markdown exporter gave us.  I'm finding that the inline link tends to produce very long lines, which is at odds with semantic line wrapping.  That was an issue in the RST version too, although it didn't come up as much because most URLs ended up the Link Destinations.json file.


Create documentation web pages

It would be nice to have the documentation available online, e.g., on github.io, for easy reference,
similar to QCheck and many other packages: https://c-cube.github.io/qcheck/
Bonus points if we can have a CI workflow re-generate the latest one after each PR merge.

Fixed by #172


create rmb examples against zos nodes

currently all of the examples use calculator.add for no obvious benefit, does zos expose a calculator.add rpc? why not use something like zos.version or something that's more intuitive ?
also please change any occurrences of dist to dest

create a new directory for zos examples and add an rpc example for zos.system.version

Verified and it returned the version after providing mnemonic and a node:
$ go run main.go
{"level":"debug","url":"wss://tfchain.dev.grid.tf/ws","time":"2023-12-13T15:28:57+02:00","message":"connecting"}
2023/12/13 15:28:57 Connecting to wss://tfchain.dev.grid.tf/ws...
{"level":"info","twin":192,"session":"test-client","time":"2023-12-13T15:28:58+02:00","message":"starting peer"}
output: {0.0.0-fc3562a v0.2.11}


StableSoftMax panics (version 0.9), how to use this function?

import (
"fmt"
"github.com/pkg/errors"
. "gorgonia.org/gorgonia"
"gorgonia.org/tensor"

)
func main() {
    g := NewGraph()
    xn := tensor.New(tensor.WithShape(5), tensor.WithBacking([]float64{0.1, 0.2, 0.3, 0.3, 0.2}))
    xt := NewVector(g, Float64, WithValue(xn), WithName("x"))
    ssm := Must(StableSoftMax(xt))

    m := NewLispMachine(g, ExecuteFwdOnly(), WithManualGradient())
    if err := m.RunAll(); err != nil {
	fmt.Println(errors.Wrap(err, "RunAll"))
	return
    }
    //panic: Operation failed: Failed to infer shape. Op: Σ[1]: Shape mismatch: along is [1]. Shape is (5)
    fmt.Println("StableSoftMax of x: %v\n", ssm.Value())

}

I ran into trouble with SSM as well (see #323).  This may also be related to #326, which I'm working on fixing, though I'm not 100% sure.

@bdleitner
cool


feat: Forward inbound HTTP headers to the Wave app. #1704

Let's use this PR as a starting point for discussion. Once we agree on the implementation, the docs will be added as well.
wdyt about the proposal in this PR @lo5 ? It's quite straightforward I would say.
Closes #1704

ubuntu 20.04.5 LTS has 1.15 which not able to build waved
manually replaced go with 1.19.5 and  everything works like a magic
waiting for this to be merged into main

Added support for the headers from the initial index.html GET request as well. The general architecture:

Initial index.html GET generates a clientID and sets it as a cookie.
The headers from the GET request are stored in a Map<clientID, headers> within Site (might change the location).
During websocket connection, clientID cookie is retrieved and used as previous c.id.
When forwarding new changes to the Wave app, headers stored in Map and headers from the WS connection are merged and sent to the Wave app.
Wave app manages the forwarded headers in a similar fashion as q.client is handled - Dict<clientID, headers>.

Needs discussion

General thoughts about this approach?
Is exposing clientID in the cookie fine security-wise?
Should the forwarded headers be sent as headers or as a JSON payload instead? Probably the latter.
Are there any headers we might want to blacklist? E.g. Authorization?

cc @lo5

The above approach seems like the only way to address the issue. Security-wise, hard to say - since auth needs to be turned off for this to even work.

Should the forwarded headers be sent as headers or as a JSON payload instead?

If I'm not mistaken, there's already a mechanism in place to add headers to the app-request. Best to continue using that mechanism.
That said, I'm not sure it's even worth addressing this issue in the first place. How many users are using the Wave server with auth turned off?

If I'm not mistaken, there's already a mechanism in place to add headers to the app-request. Best to continue using that mechanism.

Yep, the problem is the existing mechanism doesn't support adding headers dynamically during runtime, only during startup as a config option.

How many users are using the Wave server with auth turned off?

I would say most of the apps. The reason this PR exists is so that Wave could also be used in (usual enterprisy) environments where auth is not handled by OIDC directly, but via proxy (proxy-based auth). I would love to solve this so that Wave could level up from single-person / OIDC-only envs.
On the other hand, I agree that the implementation is somewhat clunky.

Reverted to the original approach - only forward the headers from initial WS connection for these reasons:

Less overhead - no need for site-wide storage on server.
index.html GET headers can be outdated during WS reconnection - e.g. unreliable internet connection. Forwarding only websocket ones makes sure the headers are always fresh.
No need to expose client-id in a public cookie.

@lo5 can you please go over API naming?

Thanks for the review @zoido @lo5!


May I ask if this project can be joined?

https://github.com/LiheYoung/Depth-Anything
Will it be useful to us

I just added it to my repo. The code is so clean and simple so it's pretty easy
https://github.com/Fannovel16/comfyui_controlnet_aux/commit/8da67c56a3f01ad190982dfc7386f6e7e8e5c0d6


what is the MAX value for ram size creating vsphere instance?

I tried to create a VM with ram=32767 and disk=32767. I received a parse error.
Error creating machine: Error in driver during machine creation: Memory (RAM) size (32767) is invalid.

https://github.com/docker/machine/blob/eae38c196a2e10e4e11cc7b8d6dfe8863fb60519/drivers/vmwarevsphere/vsphere.go#L209

Not sure where I read this... but it's about 31000.


FilePath = FilePath issue with my INI parser

FilePath = FilePath = Loyalists.rte/Actors/Militia/HandFGA.bmp
gets turned into
FilePath = FilePath   Loyalists.rte/Actors/Militia/HandFGA.bmp

I'm pretty sure FilePath is the only instance where the game doesn't complain about syntax like this

Something I'll try to figure out, cause if it goes for anything then I should make the fix more general
Discussion here: https://discord.com/channels/746526891841945640/777224855438491670/920001593921921046

Closing old issues.


Rename set_cust_pref and del_cust_pref

#104 (introduction of 3rd party plugins) highlights the need to expand the custom preference options. There will now be 3 types of preferences for the logger_prefs table:

Logger prefs: these are managed and controlled by Logger's APIs. Names can be anything as long as they don't conflict with the previous for the other types of preferences (below).
Custom prefs: developers can add what ever they want as long as it starts with CUST_
3rd Party Plugins: for 3rd party plugins (not to be confused with Logger's plugin support) should have their own name space that does not conflict with either of the two above. Each plugin will need to "register" a common and unique prefix for pref_name. For example <common>_<unique>_<prefname>. Example: 3PP_MYPLUG_EMAIL.

I would recommend to introduce namespaces in the prefs and not rely on naming conventions.
so extend the pref table with a DOMAIN column or NAMESPACE
The main logger prefs could be in the MAIN namespace, custom in CUSTOM namespace and the plugin preferences could use the plugin name.

Good idea and solves another issue with the current pref of PLUGIN_FN_ERROR and 3rd party plugins.
Regarding 3rd party plugins, do you still think they should be prefixed with a unique code? For example
NAMESPACE |  PREF_NAME  | PREF_VALUE

PLUG      | SYSLOG_ABC | Some value

Where SYSLOG_ would be the prefix for the plugin that you developed?

Well why be stingy with the namespaces? I would suggest to give each plugin its own namespace
so
NAMESPACE | PREF_NAME   | PREF_VALUE
MAIN      | VERSION     | 3.2.0
CUSTOM    | WHATEVER    | somthing
SYSLOG    | SEVER       | localhost
TWITTER   | ACCOUNT     | @barsema

off course then we need to support  daisy chaining plugins :-)

Instead of namespace I'll be calling it PREF_TYPE where LOGGER is a reserved word.

@barsema I just added the new column logger_prefs.pref_type. Do you mind given it a test (see releases/3.1.0_beta.zip)?


Adding Teams.live.com to the list

It might be a good idea to add teams.live.com to the list of Urls, this links is needed when an MS Teams Consumer user creates a meeting and Office 365 Teams users wants to join.
I totally understand that MS Teams consumer is a different product, but you have already added a list of optional URLs for other products (outlook.com) so it might be acceptable to add teams.live.com here.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 66bd8666-3566-a901-b25b-eb6baba6264a
Version Independent ID: e9f6310f-2207-8c81-d31a-3d5a80beb26b
Content: Office 365 URLs and IP address ranges - Microsoft 365 Enterprise
Content Source: microsoft-365/enterprise/urls-and-ip-address-ranges.md
Service: o365-administration
GitHub Login: @kelleyvice-msft
Microsoft Alias: kvice

@kelleyvice-msft and @LauraWi Please help us in resolving this issue

Following up with @jamilhaddadin via internal channels regarding the process for updating this article and getting teams onboarded to the endpoint process.


RBAC support for Flame

Adds RBAC support, to enable Flame's Kubernetes integration to work on clusters that have RBAC enabled (as they all should :wink:)

The serviceAccount resource is created by exposing the serviceAccount.create boolean from the bjw-s/common chart, and defaulting it to true. I confirmed this is safe and bjw-s/common automatically runs the pod under the right account.
The clusterRole and clusterRoleBinding resources are added as templates in the chart, based on the examples given in pawelmalak/flame. They are toggleable with a new boolean rbac.create, which defaults to true. This is safe on clusters that do not have RBAC enabled.

No changes are required to the user's local values.yaml to benefit from these changes.
Fixes #652

@djjudas21 Looks great! Thank you!


bower.json ignore

Get this to work so that when it is pulled into bower_components it only has the dist folder

Fixed in ba36c1d5e3a30c6de295771adb59a51ce151c25b


GFLOPs calculation

I want to say that your work is amazing and has been incredibly helpful! I’m trying to calculate GFLOPs for HAMT(VLN) but it seems to be not straight forward where it consists with multiple transformers(Should I sum the GFLOPs for each transformer to get the total GFLOPs?). It would be helpful if you could provide the details about FLOPs calculation.

Hi! First of all, thank you very much for acknowledging our work.
I have updated the code for computing model efficiency, including the number of parameters and GFLOPs. You can calculate these metrics using the following command:
cd map_nav_src
bash scripts/model_efficiency_count.sh

Please note that we computed only a single step for each forward pass. I hope this helps you in computing GFLOPs for other similar methods.

Thank you so much!


After the vibration mode is enabled, the notification is triggered several times, and only one vibration is generated

Rules

To report a bug and help us to provide the solution as fast as possible, please follow the instructions below:
1 - Describe the bug
After the vibration mode is enabled, the notification is triggered several times, and only one vibration is generated
2 - Provide us as much information as possible
Android 13
xiaomi
3 - How To Reproduce the Error
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

...or if you prefer, you can provide us a simple example app on GitHub with the issue already reproduced instead of the steps 2 and 3.
4 - Expected behavior
A clear and concise description of what you expected to happen.
5 - Screenshots
If applicable, add screenshots to help explain your problem.
6 - Additional context
Add any other context about the problem here.

I just can't even understand the problem because it was added basically none information about it. Thank you.


Add Metabase Image Pod [DO NOT MERGE]

Description of change
SPIKE - Consider if we could use metabase in the same way as Crime Apply

Used CCQ code as a basis
Added metabase image to helm deploy
Added feature flag and enabled metabase in only dev
Added service host to connect to metabase via URL

closing as we have decided to use a UAT metabase instance for targeting all pre-prod databases for analytics


Disconnect listener and observer for OpenInHolodex

We don't need to keep a listener for DOMContentLoaded on document after it's fired.
We don't need to keep noop MutationObserver running forever if the button is already injected.

this is probably superceded by lbmaian's changes, sorry Livia!


[QPPA-1305] Remove programName and entityId from docs

Removed programName and entityId property from submissions documentation


[mgmt] containerservice preivew release

https://github.com/Azure/sdk-release-request/issues/5434

API change check
APIView has identified API level changes in this PR and created following API reviews.
@azure/arm-containerservice


Support OCI image volume mounts

/kind feature
Describe the solution you'd like
Since Kubernetes 1.31 it is possible to mount an OCI image directly to access e.g. model data. Currently, KServe supports such OCI model images via the modelcar feature, which was introduced as a workaround for missing OCI image volume mount support in Kubernetes. In that sense, modelcar are a transitory technology, eventually replaced by the image volume type. However, up to now, image volume mounts are not yet ready for prime-time: It's marked as alpha for Kubernetes 1.31, and currently, there is no released container runtime (cri-o or containerd) that supports volume mounts.
This new way of model initialization could be supported by the same API as for modelcars, i.e. with a storageUri schema of "oci://". An runtime configuration (per IService) could switch between modelcars and image volume mounts, also a global configuration could set the default value if not specified in the Iservice spec.
References:

Support for Image volumes (Blog)
Testing image volumes (Blog)
KEP #4639

Links to the design documents:
TBD

Thanks! This sounds good to me. cc @yuzisun for any feedback

Excited to see this feature. For serverless mode, maybe the upstream KNative need to support it as well or it will be injected
in pod via webhook?

That's a very good point, I opened https://github.com/knative/serving/issues/15488 to tackle this.


MultiGPU training

Hello.
is there any option for multiGPU training?
Thanks

Hi @AmeenAli , as of now multi-GPU is not supported. However, it is not difficult in PyTorch to enable multi-GPU: have a look at torch.nn.DataParallel

Hi,  i have a packages installation error
Pip subprocess error:
ERROR: Could not find a version that satisfies the requirement faiss-prebuilt==1.4
issue appears after that: conda env create --file environment.yml

Hi @Lavrikov, I solved the issue: this package is not needed in the conda environment. You can pull and check if it works now.
Please open a new issue if you have further problems with packages, this is not the right topic for this issue.


[P2P] Subsequent syncs have records to send

Describe the bug
The p2p sync does not seem to finish sending data since subsequent syncs have records to send
To Reproduce
Steps to reproduce the behavior:

Open the side menu
Click on "Settings"
Click on "Transfer Data"
Click on "Receive Data" in the new page that opens
Initiate data sending on the other device. Repeat from steps 1 to 5. Click on "Send Data"
Select the correct receiving device on the sending device
When the sending finishes, click on the "Okay" button on the  receiving device
Click on the device's back button, and start the process again from step 1 to 7.

Expected behavior
There are still available records to be sent after any p2p sync
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):

Device: [e.g. Samsung Galaxy A2 emulator]
Android version: [e.g. Settings -> About phone -> Android version]
Build number: [e.g. Settings -> About phone -> Build number]
Version [e.g. 24]

Additional context
Add any other context about the problem here.

is this correct?

There are still available records to be sent after any p2p sync
should that be "There are no records to be sent after p2p sync"?

That sounds like it means that it will be re-sending (some of) the same records, is that correct?
Could we mark records that have been confirmed received to avoid the above, and avoid showing that there are still records to sync after sync has completed successfully?

Can't the receiving device continue to track the checkpoint, w/the change here that there would be a set of monotonic IDs that the receiver can use for that tracking