Seperate application configuration and environment settings.

Currently we are mixing application configuration with environment settings.  We need to separate these.
I have been playing with some ideas, and have ended up creating a .config folder, like so:
.config
   |- project.js
   |- client.js
   |- server.js
   |- development.js

Then the environment variables need only be concerned about the actual stuff that is likely to change between environments.  For example the new .env file looks like:

Much cleaner.
And as per @bkniffler's suggestion we can even make the .env file completely optional, having our config files have reasonable defaults.  Then it's up to you to provide environment overrides for the typical stuff that would need to be overridden.

Other cool things coming out of this:

.env file is optional
no longer need an .env_whitelist
simplified webpack config - don't need to pass env vars through the DefinePlugin.
overall simpler and easier to understand.

I've merged all the configs into a single project.js configuration file.  I've also introduce a check that will ensure that the configuration file doesn't get bundled into the client, which would pose serious security concerns.

On next branch.
Application configuration is at /tools/config.js now.
Environment configuration greatly simplified.

Thoughts @bkniffler @strues @enten @carsonperrotti ?

Sounds great. Going to pull it down and check it out now. I'll let you know.

Here Ive expanded upon what you've done with the configuration.  The idea being you can easily store configuration defaults for multiple environments. Let me know what you think.

const config = {
  all: {
    env: process.env.NODE_ENV || 'development',
    // SSR enabled?
    ssrEnabled: true,

    // Configuration settings for the service worker.
    serviceWorker: {
      // Enable the service worker?
      // ... excluded for brevity
    },

    // Client bundle specific configuration.
    client: {
      // What should we name the json output file that webpack generates containing
      // details of all output files for a bundle?
      assetsFilename: clientBundleAssetsJSONFilename,
      // What is the public http path at which we must serve our client from?
      webRoot: clientBundleWebRoot,
    },

    // Server bundle specific configuration.
    server: {
      // The protocol for the server.
      protocol: envVars.SERVER_PROTOCOL || 'http',
      // ... excluded for brevity
    },

    // Development specific configuration.
    development: {
      // ... excluded for brevity
      vendorDLL: {
       // ... excluded for brevity
      },
    },
    paths: {
      buildOutput: buildOutputPath,
      clientBundle: clientBundlePath,
      // ... excluded for brevity
    },
  },
  production: {},
  staging: {},
};

module.exports = Object.assign({}, config.all, config[config.all.env]);

Awesome thanks @strues - I will review this in the morning.

It's a complex topic (and I cry for the time that I will put to express awkwardly my thought).
First of all, we need to distinguish two environment levels (each corresponding to a distinct configuration level):

a concrete environment used to act on webpack compilers configuration: it's the current user's environment state
a fake environment used to act on runtime: it's the user's environment state when the build or hot build is made.

In production environment, we shouldn't have to install dev dependencies. But we must be able to override the bundle configuration on runtime. Using webpack.DefinePlugin to define global constants will break the user's environment influence.
So, on the server side: we can override an process.env variable under development environment only. Developers will be able to keep their own favorite configuration store to set up the runtime settings.
On the client side: its runtime configuration must be given by the server (with an inline javascript script tag for example).
I want to highlight that it's important to exclude configuration variables specific to the bundles execution. It's the server responsibility to deal with runtime configuration and allow environment overrides.
Configuration settings like ssrEnabled and http.protocol mustn't figure in the configuration. Because the configuration that we try to determine is a kind of meta-configuration. That configuration must be used to building bundles only: not for change runtime behavior (except for development purposes but in that case, we use DefinePlugin to hack the runtime).
The most settings in that meta-configuration are "static" in the sense which they not often changed. The meta-configuration provide data used by webpack compilers (like output.path) and server bundles (like the path to the client assets). Change the value of one of them setting will deeply affect the project structure and/or bundles output. So I think it's not necessary to allow environment overrides in this meta-configuration level.
That being said, below is my suggestion.
module.exports = {
  // server bundle
  server: {
    // target resolved as `node` target
    // by the webpackc onfig factory
    target: 'server',

    // path to the webpack config factory
    configFactory: './tools/webpack/configFactory',

    // path to the server source
    srcPath: './src/server',

    // path to the entry point (relative to `srcPath`)
    entryIndex: 'index.js',

    // path to the bundle output (webpack config `output.path`)
    outputPath: './build/server',

    // env vars defines by webpackDefinePlugin
    // used for development purposes only
    // we assume that the server handle runtime configuration
    // and environment overrides
    envVars: {
      SERVER_HOST: 'localhost',
      SERVER_PORT: 1337
    },

    // webpack-node-externals options
    nodeExternals: {
      // default to "./node_modules"
      modulesDir: './node_modules'
    }
  },

  // client bundle
  client: {
    // as like in server bundle
    target: 'web',
    configFactory: './tools/webpack/configFactory',
    srcPath: './src/client',
    entryIndex: 'index.js',
    outputPath: './build/client',

    // used as base URI and webpack config `output.publicPath`
    publicPath: '/client/',

    // path to static assets (favicon, robot.txt, etc)
    staticPath: './public',

    // webpack-dev-server options
    devServer: {
      port: 7331
    },

    // assets-webpack-plugin options
    assets: {
      // default to "assets.json"
      filename: 'assets.json',
      // default to `client.outputPath`
      path: './build/client'
    },

    // webpack-bundle-analyzer options
    analyzer: {
      analyzerPort: 8888
    },

    // dll configuration
    dll: {
      // default to false
      enabled: true,
      // default to "vendor"
      name: 'vendor',
      // default to ${dll.name}.js
      filename: 'vendor.js',
      // default to ${client.outputPath}/dlls
      outputPath: './build/client/dlls',
      // default to ${dll.outputPath}/${dll.name}.hash.json
      hashPath: './build/client/dlls/vendor.hash.json',
      // default to ${dll.outputPath}/${dll.name}.manifest.json
      manifestPath: './build/client/dlls/vendor.manifest.json'
      // additional paths to scan for catch imports
      sharedPath: ['./src/shared'],
      // packages excludes from dll
      excludes: ['**/*.css']
    }
  },
}

Each bundle property (client and server) will be passed in arg to the configFactory on build or hot build process. We assume that the webpack configuration factory will compute a valid webpack config depending on the bundle given in arg.

So, because i'm going to be using this in production with multiple live environments, my solution for this looks something like this:
// tools/config/envVars.js
module.exports = function getEnvVarsForMode(mode) {...return env-<mode>...}

This way I can have multiple .env files (i.e. production,staging,hot-branch, whatever) and then deploy them.

Great feedback guys. I am going to incorporate something like this.

I guess one decision that needs to be made is whether we expose multi environment configurations (development/staging/production) like @cellis and @strues have suggested, or should we expect each host environment to be providing the necessary environment configuration (bootstrapped by a CI process or whatever).
My preference is for the later personally as I like the environment configuration to live with each host, but I am completely open to suggestions otherwise.

@enten
Thanks for taking so much time to discuss this issue.  I really appreciate it!

On the client side: its runtime configuration must be given by the server (with an inline javascript script tag for example). This is the server's job to not expose security settings to the client.

Should we not just have the DefinePlugin parse and provide the restricted/required environment variables for the client?  We could make them explicit then, and webpack ensures that are inlined for us.

So then in terms of the server.  We could move the call to dotenv within /src/server/index.js, which would allow bootstrapping of additional environment variables from a .env file that may exist within the executing environment.  Otherwise we expect the environment variables to have been provided to the executing process.
In my opinion we would then need do a parse of the environment variables, ensuring that the required values have been provided, and do error logging if they don't.
This then keeps the config file clean, and have it simply contain the required values for the build process.  One thing though, throughout the source we need to make references to various paths (for example the vendor DLL).  Do you think we should be providing these values via the DefinePlugin, which will inline them, or should the config file be referenced directly by the respective server source?

Great discussion.
If you decide to go the route that @strues sketched, be aware that sometimes Object.assign is not enough to merge default options with environmental options in case of webpack.
I've used webpack-merge to deal with that previously.

The server needs configuration settings for...

the compilation process (like the dll path, assets metadata file path, static resources path, ...). I suggest to call these setting "meta-configuration". These settings can't be changed after a build (or hot build).

the runtime/executing process. It's the standard configuration layer specific to each project (chosen by the developer). These settings can be changed after a build. They can be grabbed from the environment, from a file inside the project or a file from the current user home's directory, a socket, a remote config store service, etc.

If we use DefinePlugin to manage runtime configuration settings: this will break the environment influence on the execution and we will need dev dependencies under the production environment to rebuild server and client bundles.
For these reasons, we mustn't include runtime settings in that configuration which we try specify.
The client needs configuration settings for the runtime/execution process only. The client bundle often targeting the web/browser environment. The browser don't know what is the process object (but the window object to infer lot of environment settings like window.location). Webpack allow to polyfill/mock the process object but I think that use it to store client configuration settings isn't the purpose. The main purpose of process object polyfill/mock is to make a piece of code universal and avoid reference errors. It's like mocking window object on server side to avoid reference errors (yes it's sadly exists) and use it to store runtime configuration settings.

Should we not just have the DefinePlugin parse and provide the restricted/required environment variables for the client? We could make them explicit then, and webpack ensures that are inlined for us.

Well, what kind of configuration settings the client needs? It's often stuff like the Google Analytics public key or Recaptcha public key, the URL to the backend and so on. Even without SSR, it's the server responsibility to serve that configuration settings to the client. That runtime settings mustn't be hardcoded by the DefinePlugin. Because we need to allow environment influence without rebuilding step.
The only exceptions that we can hardcode (with DefinePlugin) both on client and server bundles are some meta-configuration settings: the server can receive all of them, but the client need a tiny part (put in the process.env mock/polyfill generally, like ENV_NAME or IS_NODE) for security reasons.

In resume:

It's necessary to distinguish compilation (meta) configuration and runtime/executing configuration
We mustn't mixed them into the same file
We must let the developer choice how to handle the runtime configuration level but we suggest a solution baked in the boilerplate into the server sources (as current dot files, I have a preference for rc files)
We must use DefinePlugin to hardcode compilation (meta) configuration (a little part of them for the client bundle)
We can use DefinePlugin to hack the runtime for development purposes (like inject an environement variable to define the server port) according to the server runtime configuration implementation

@ctrlplusb
Have you considered dotenv for the runtime/executing configuration level instead of the current custom .env file implementation?

Yep.

So then in terms of the server. We could move the call to dotenv within /src/server/index.js, which would allow bootstrapping of additional environment variables from a .env file that may exist within the executing environment. Otherwise we expect the environment variables to have been provided to the executing process.

😃

I think it is the way to go.

@enten @strues @bkniffler @carsonperrotti
Released a new version of this on next.
Environment configuration is always resolved at runtime.
And have introduced a static configuration, babel config resolver and webpack config middleware.
All lives in ./config folder.
Let me know your thoughts.

@ctrlplusb
As you said earlier on gitter: i'm happier with the current next config's format (^21f6445). Am I so predictable? Or too repetitive? :laughing:
Firstly, I think there is a little mistake in config/environement.js:
if (fs.existsSync(path.resolve(appRoot.get(), staticConfig.envFilePath))) {
  // --- dotenv.config();
  dotenv.config({
    path: path.resolve(appRoot.get(), staticConfig.envFilePath)
  })
}

And if I'm not mistaken, the config/environement.js object will be the same under development and production mode, isn't it?
In addition, we can't override these values with a file located outside the project's folder.
Below my suggestion. Please note that I not encourage to allow the user to store the default .env file in a different path than the project root path. So in my suggestion, I used envFileName instead of envFilePath.
// config/environment.js
import dotenv from 'dotenv';
import fs from 'fs';
import path from 'path';
import appRoot from 'app-root-dir';
import staticConfig from './static';

// <+++>
import userHome from 'user-home';
import pkg from '../package.json';
// or
// const pkg = require(path.resolve(appRoot.get(), 'package.json'));
// </+++>

// <--->
// if (fs.existsSync(path.resolve(appRoot.get(), staticConfig.envFilePath))) {
//   dotenv.config();
// }
// </--->

// <+++>
const envName = process.env.NODE_ENV || 'development'
const envFile = staticConfig.envFileName // equals ".env"

;[
  path.resolve(appRoot.get(), envFile),
  path.resolve(appRoot.get(), `${envFile}.${envName}`),
  path.resolve(userHome, pkg.name, envFile),
  path.resolve(userHome, pkg.name, `${envFile}.${envName}`),
  path.resolve(userHome, '.config', pkg.name, envFile),
  path.resolve(userHome, '.config', pkg.name, `${envFile}.${envName}`)
]
  .filter((filePath) => fs.existsSync(filePath))
  .forEach((filePath) => dotenv.config({ path: filePath })
// </+++>

function getStringEnvVar(name : string, defaultVal : string) {
  return process.env[name] || defaultVal;
}

// ...

So, we can override values...

by the environment mode with creating .env.development and/or .env.production
and by files located outside the project folder with creating ~/${pkg.name}/.env or ~/.config/${pkg.name}/.env.

Great comments and advice as always @enten thank you!
I am doing another big update/parse of the configs and tools.  Making things more generic to allow for easier extension as suggested by @carsonperrotti.  I think its a worthwhile venture to allow for easier extensions of an api node bundle without expecting the adopter to hack the webpack config to bits.  I've managed to get the configs updated and have almost completed making the development tools a bit more generic to handle this.
I'll ping you all when I do the push.

@enten
Just went through your environment file resolution strategy.  Really nice!
I think I will integrate that. :)

@enten @carsonperrotti
I've updated the configs, including the environment file resolution process.
@enten - do you think all environment files should be ignored from github by default?

Thinking of renaming config/static.js -> config/project.js

@ctrlplusb

do you think all environment files should be ignored from github by default?

It's a behavior banished from the opensource community. By contrast: this is quite common in enterprise repositories.
Sorry my good sir: i'm not an expert to give you an interesting answer.
So, I checked on other projects like the official boilerplate of adonis framework: there is an .env.example only.
In my opinion, environment config used for test purposes (like .env.test) can be versioning (it's often a requirement to make CI working).

Thinking of renaming config/static.js -> config/project.js

It's sound better.

Sounds good.  I'll update the documentation to inform the users of their options and state that it is up to them and their requirements on what route they would like to go down.  At least there is the option on persisting environment specific config should that be a need.

So, what is the current concesual way of accessing env vars like API_URL on client code? as they are not exposed on process.env with DefinePlugin anymore

My recommendation is to pass these values via the server response. i.e. the html payload initialises a config object on the window.
e.g.

  ...

     ...

In my opinion, it's the server which must share the configuration with the client.
For example, you can serialize and write a configuration object from the server in window.clientConfig.

But that will only work for client, so I'd need to write a helper func to fallback to process.env on SSR server?

No, don't do that. Your server must have a configuration layer (a file which export a plain javascript object build from process.env for example).
Below an example.
// src/server/config.js
export default {
  client: {
    api: process.env.CLIENT_API || 'http://localhost:3333/api'
  },
  // server private stuff
  jwt: {
    secret: 'supersecret!'
  }
}

// src/server/middleware/reactApplication/index.js
// ...
import {client as clientConfig} from '../../config'

function reactApplicationMiddleware(request: $Request, response: $Response) {
  // ...

  const html = generateHTML({
    app,
    nonce,
    helmet: Helmet.rewind(),
    codeSplitState: codeSplitContext.getState(),
    clientConfig
  })

  // ...
}

export default (reactApplicationMiddleware : Middleware);

// src/server/middleware/reactApplication/generateHTML.js

// ...

export default function generateHTML(args: Args) {
  const { app, initialState, nonce, helmet, codeSplitState, clientConfig } = args;
  // ...
  return `<!DOCTYPE html>

${app || ''}

      ${
        initialState
          ? inlineScript(`window.APP_STATE=${serialize(initialState)};`)
          : ''
      }
      ${
        clientConfig
          ? inlineScript(`window.CLIENT_CONFIG=${serialize(clientConfig)};`)
          : ''
      }
`;
}

So, you have the client configuration in window.CLIENT_CONFIG on client side. Be careful to not expose server secrets in the shared configuration.

@williamoliveira if you have a piece of code shared between the client and server bundles you can use the IS_SERVER or IS_CLIENT DefinePlugin flags to create bundle specific code blocks too.
Make any client bundle depend on the window.CLIENT_CONFIG like @enten and myself described, and any node/server bundle can use the project config files/envVars.

So I'd have something like (process.env.IS_CLIENT ? window : process.env).CLIENT_API ?

@williamoliveira
On the server side: you use the default src/server/config export.
On the client side: you use window.CLIENT_CONFIG
In a shared code: I recommend to not deal with the config object directly (src/server/config or window.CLIENT_CONFIG) for security purposes but passe config values in function parameters.
An example (based on our previous example) with axios as http client.
// src/shared/api.js
import axios from 'axios'
let api

export default api

export function initApi(baseUrl) {
  api = axios.create({
    baseUrl
  })
}

// src/server/index.js
// ...
import {client as clientConfig} from './config'
import {initApi} from '../shared/api'

initApi(clientConfig.api)

// src/client/index.js
// ...
import {initApi} from '../shared/api'

initApi(window.CLIENT_CONFIG.api)

Got it, nice approach
Just, could you elaborate on the security point?

If you accidentally import src/server/config in a src/shared/**/*.js file: you potentially expose the entire config server content in the client bundled sources.
Nobody wants to expose server config secrets in the client sources.

@enten @williamoliveira
By default the client bundle config is set to not include the config folder for bundling, so if you accidentally do import the configs it should fail.  The failure will be at runtime I believe as you will just get "undefined" anywhere you imported a config file.

@ctrlplusb
Below a simple strategy to deal with server runtime configuration.
// src/server/config.js
module.exports = {
  client: {
    gaPublicKey: 'xyz',
    locales: ['en', 'fr']
  },
  // server secrets
  backendApiUrl: 'http://secret-host:3333/api/v1',
  backendApiKey: 'abcef',
  // ...
}

// src/server/middleware/reactApplication/index.js
// ...
import {client as clientConfig} from '../../config'

function reactApplicationMiddleware(request: $Request, response: $Response) {
  // ...

  const html = generateHTML({
    app,
    nonce,
    helmet: Helmet.rewind(),
    codeSplitState: codeSplitContext.getState(),
    clientConfig
  })

  // ...
}

export default (reactApplicationMiddleware : Middleware);

// src/server/middleware/reactApplication/generateHTML.js
// ...
export default function generateHTML(args: Args) {
  const { app, initialState, nonce, helmet, codeSplitState, clientConfig } = args;
  // ...
  return `<!DOCTYPE html>

${app || ''}

      ${
        initialState
          ? inlineScript(`window.APP_STATE=${serialize(initialState)};`)
          : ''
      }
      ${
        clientConfig
          ? inlineScript(`window.CLIENT_CONFIG=${serialize(clientConfig)};`)
          : ''
      }
`;
}

// src/shared/config
let config
if (process.env.IS_NODE) {
  config = require('../server/config').client
} else {
  config = JSON.parse(window.CLIENT_CONFIG)
}
module.exports = config

import {locales} from './shared/config'
// ...


[rv_dm,dv] Smoke vseq is broken for some seeds

Description
For some seeds, the rv_dm smoke vseq fails with the following error:
UVM_ERROR @  18026231 ps: (jtag_dmi_monitor.sv:105) uvm_test_top.env.m_jtag_dmi_monitor [uvm_test_top.env.m_jtag_dmi_monitor] Non-ok response seen with no previous DMI request.

The bug is old and dates back to at least early 2023. Stepping further back is a bit hard because of (I suspect) unrelated fixes. For an example which shows the problem that far back, run:
util/dvsim/dvsim.py hw/ip/rv_dm/dv/rv_dm_sim_cfg.hjson --tool=xcelium -i rv_dm_smoke --fixed-seed 355

I've done a bit more squinting at waves and think I know a bit more about what's going on. The root cause for the failure is that we're sending back-to-back jtag items.

The first item completes and the jtag driver correctly completes its handshake.
Inside rv_dm, the dmi_jtag module is still contemplating things. I believe that this will be translated into a DMI request and then followed by a response.
Unfortunately, our testbench doesn't understand that at all. While rv_dm is busy messing around with a DMI handshake, we tell the jtag driver to send another item.
The dut then gets into a DMIBusy state and a monitor in the TB gets very confused.

I suspect the problem is that in some way our testbench doesn't really understand about the DMI protocol that we're running, so it just pushes things willy-nilly on the lower level jtag protocol.

Looking a bit further, this back-to-back sequence is from jtag_dmi_reg_frontdoor.sv. That code starts a DMI operation and then polls for completion, restarting DMI if the sticky InProgress bit is set.
This seems reasonable! But less reasonable is that the jtag monitor dies. I think the problem is that (from the jtag monitor's point of view):

We start a JTAG operation
That operation ends
We start a new JTAG operation
The second operation responds with DmiOpInProgress ("I'm busy!")
Huh?! But we'd finished that first operation. Boom.

I suspect the fix will just be to make the JTAG monitor a bit laxer, possibly by setting an "allow me to be busy" bit in the agent.


alter PackageSchema

Hi there,
I found the package schema a bit confusing when adding multiple packages.
Currently, I'd have to do something like this:
[[packages]]
name = "htmx.org"
source =<EMAIL_ADDRESS>[[packages]]
lit = "lit"
source =<EMAIL_ADDRESS>
Yet, from Pipenv or Poetry I am more used to something like this:
[[packages]]
htmx.org = "1.9.8"
lit = "3.0.2"

Maybe this is worth a consideration. I know it's a backwards incompatible change, but since this package is in its early days, this could be the perfect time to do such alterations.
Cheers!
Joe

Maybe moving the config to pyproject.toml worth considering too. As mentioned before, I'd be happy to contribute.

I think the move to a dict-based setting makes sense — I honestly can't remember if there was a specific reason it was set up like a list. Do you want to take a stab at it? One of the related things I had been thinking about this project is that the dependency on marshmallow seems a little unnecessary... Do you want to rewrite it and drop the need for a marshmallow schema at the same time?
Feel free to open a separate issue about pyproject.toml. I'm not totally sure which way I'd lean on that right now and can come up with several different arguments for how it could work...


[refactor](unify exception) unify exception definition and error code

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.46 seconds
stream load tsv:          452 seconds loaded<PHONE_NUMBER>9 Bytes, about 157 MB/s
stream load json:         24 seconds loaded<PHONE_NUMBER> Bytes, about 93 MB/s
stream load orc:          74 seconds loaded<PHONE_NUMBER> Bytes, about 14 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230322062259_clickbench_pr_118447.html

run buildall

run p0

run buildall


drop support for Go 1.6

Fixes #519.

Codecov Report

Merging #520 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #520      +/-   ##
==========================================
+ Coverage   90.83%   90.85%   +0.02%
==========================================
  Files          81       79       -2
  Lines        5420     5430      +10
==========================================
+ Hits         4923     4933      +10
  Misses        318      318
  Partials      179      179

Impacted Files
Coverage Δ

h2quic/client.go
88.34% <100%> (ø)
:arrow_up:

frames/ack_frame.go
95.45% <0%> (+0.02%)
:arrow_up:

ackhandler/sent_packet_handler.go
96.84% <0%> (+0.03%)
:arrow_up:

session.go
87.7% <0%> (+0.28%)
:arrow_up:

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 2a9f214...dea154d. Read the comment docs.


(simple wording update) Use better naming for VDI (actually SQL VDI)

"our" (SQL Server's) VDI full name is actually MS SQL Server VDI, or SQL VDI in shorter form. "Windows VDI" as used in current text implies a completely different thing (Virtual Desktop Infrastructure https://azure.microsoft.com/en-us/services/virtual-desktop/)

@Guillaume-Fourrat : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off
thanks @Guillaume-Fourrat


gRPC plugin is not working correctly when loaded with @grpc/proto-loader

When a proto file is loaded with @grpc/proto-loader, gRPC plugin instrumentation is not working correctly. Client and Server traces has different traceIds.
Client Traces:

Server Traces:

May be something to do with the binary propagation or client methods are not patched properly.

/cc @markwolff

Haven't looked into this yet, but it's probably for a similar reason that patching the internal function makeClientConstructor didn't also patch the externally re-exported makeGenericClientConstructor. Did this scenario work in OC?

Did this scenario work in OC?

No, it is not working as expected.

Strangly, with OC when I used lowercase method name in protos: https://github.com/open-telemetry/opentelemetry-js/pull/385/files#diff-a10e9a452e0c1da7f8f0d0f5a70622e4R12, everything works well. Maybe, we are not patching all the client methods properly: https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-plugin-grpc/src/grpc.ts#L336-L341

Strangly, with OC when I used lowercase method name in protos: https://github.com/open-telemetry/opentelemetry-js/pull/385/files#diff-a10e9a452e0c1da7f8f0d0f5a70622e4R12, everything works well. Maybe, we are not patching all the client methods properly: https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-plugin-grpc/src/grpc.ts#L336-L341

Yes the lowercase stuff was a bug I found in OC as well which would be fixed by this. If the lowercase name works in OC, then I shouldn't have to use { internals: true } and there is a bug with the existing patching.

there is a bug with the existing patching.

Possible. While testing found out https://github.com/open-telemetry/opentelemetry-js/blob/master/packages/opentelemetry-plugin-grpc/src/grpc.ts#L328 is not getting called when using proto-loader.

Looked into this, it is because of lerna linking. The grpc-plugin's devdep grpc internal files are patched because it grabs the basedir within the plugin. For a production sample, I'd imagine it would work because the dev dependency won't be installed and so basedir would resolve to the correct path. To compare with OC, basedir was set in plugin-loader.
I see 2 ways of resolving this:

Ignore it since it would work in an example outside of this repo. Maybe remove this example from lerna or add some hacks to how basedir is resolved.
Update the plugin.enable(...) signature to include basedir/version information as it did in OpenCensus

Either way, I will open a PR to fix the issue with .capitalize(...) vs .Capitalize(...)
@mayurkale22 WDYT?

I am fine with the option 1. Do you think I should merge the example - gRPC example using proto-loader #385?

I think thats fine. It just wont work if using it by cloning this whole repo.

Closing via #631


Allow emoji *.🍇 exstension.

We have *.emojic extension now, but my coding keyboard does not support these strange symbols.
Could you add support of *.😎 extension, for example?

Most interesting idea. But why exactly 😎? For instance, 🍇 is mure more iconic to Emojicode, don’t you think so?

Hm... 🤔
Yes, sounds tasty 🍇

Feel free to make the necessary change (I think you only need to change a check in Packages/Package.cpp) and open a pull request.

@zored Are you still interested in adding this?

Whoops we did it at the same time 😅
Just be carefull in #114 after compilation the filename is trunk by a constant of 7 characters, so with a filename hello.🍇 the result is hel.
Normally this is check in #115 where only the extension is strip.

Now that the extension .🍇 is in process, can we think about an extension for emojicode's interfaces .emojii ?
I thought about .🎭 because an interface is like a mask, it hides the true nature of its wearer ?
PS : I am going to correct the pull request

Hm, why not. Things to consider though:

What happens if both a .emoji and one with the emoji extension are in a package directory? Does the compiler err? Or does it prefer one automatically?
When does the compiler even create an interface file with emoji extension? If the emoji extension is used on the input?

I like the masks but we should also consider into the direction of face (interface).

I think that depends on how you want the emoji extensions to be ?
Do you prefer to encourage users to use .🍇 ? (And so potentialy updating the Hello World page)
If so (the more fun I think), we can update the code to reflect that.

I think the compiler should prefer the emoji extension over text when both are available ;
-The compiler should output an emoji extended interface, and maybe think about a compilation flag --ascii, --legacy or something like that, that would output a text extension (.emojii)

Back when I designed the very first version of Emojicode I did some experimentation with file names containing emojis and faced some difficulties with certain Linux distributions, but I don’t remember exactly what these issues were. If those issues are gone, we should certainly opt to make emoji extensions default.

I wrote a Dockerfile based on your clang one that auto build and distribute emojicode with latest commit.
It is based on ubuntu:18.04 and there is now problem when compiling hello.🍇.
Link to Dockerfile.
(I am also wondering if we could add the file to the main repository ?)

So your Docker container is basically one for using Emojicode, right?
The Dockerfiles in this repo are for CodeShip, the CI service.
Basically, I don’t see a reason why we shouldn't add your file. I have a similar one I sometimes use for testing (which installs a lots of debugging tools...), so it could certainly be useful. Feel free to open a pull request (and you could copy the shared part that you have tidied up so nicely over to the existing files )...

So I tried to add hello.🍇 to the list of standard compilation tests and it is already giving me trouble in the testing containers as for some reasons Python glob (glob.glob(os.path.join(dist.source, "tests", "compilation", "*.🍇"))) does not find the file on Ubuntu while it does on macOS.
After patching that, the subprocess module started complaining UnicodeEncodeError: 'ascii' codec can't encode character '\U0001f347' in position 35: ordinal not in range(128)...
So I’m not positive the world is yet ready for emoji extensions as a default. Though, I don't feel like into digging that issue right now. Maybe there is an easy fix. I’ve pushed the branch emoji-extensions in case you’re interested.

I’ll close this issue because its main goal was achieved. Concerning .🎭 we can still continue the discussion here and open a new issue later.

I checked the error, and I ran into the same.
After investigation it was due to locale not being correctly set in Docker/Ubuntu. I added the right locale in #117 and was able to successfully ninja tests the emoji-extensions branch.
Hopefully you will have the same result, and that would say that I’m positive the world is ready for emoji extensions as a default !

I’m sure y’all will be delighted to learn that the default packages have been changed to use the .🍇 extension and the interface files will be named 🏛 by default starting from 1.0!


Automatic rush update --full

This is an automatic PR generated weekly with changes from running the command rush update --full

Closing since this was generated by a manual run of the pipeline to validate script changes


Implement zWhile

Sample Code:
bool flag = true;
zWhile([&] { return flag; }, [&] {
  // calculate something while flag is true with calling other tasks
});

This issue is included in Implement zLoop, zWhile, zDoWhile, zFor #20


Debugging: Lingering break points

From<EMAIL_ADDRESS>on 2011-04-19T12:20:42Z
I had set up some break points for debugging in the past.  I later cleared them from inside the debugger.  The green dot indicating a break point no longer appears.  However, when I start debugging again the break point is still active.  If I type 'b' in the console I will see the break point listed.  I can clear it at the console, but the next time I start debugging the break point is back again.  Is there some way to permanently clear it?  It's becoming a huge hassle to use the debugger with this particular issue.
Spyder 2.0.10, python 2.6.1,  WinXP SP3
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=634

From ccordoba12 on 2011-05-15T19:31:44Z
Labels: Cat-Debugger

From<EMAIL_ADDRESS>on 2011-05-06T13:58:13Z
I ended up going into my spyder.ini and removing them manually.  It might be nice if these were exposed in the GUI somewhere so they can be removed without going to the ini file.

From<EMAIL_ADDRESS>on 2011-06-08T15:12:45Z
I think this issue is related to Issue #612 .  I believe I create breakpoints in a file after it was opened where the filename and path have been converted to all lowercase.  This causes them not to appear in spyder since the path and/or filename don't match which also prevents them from being cleared in the editor.
I believe fixing this issue #612 will also fix Issue #634 .  It might still be nice to implement a graphical way of manually editing the breakpoints from within Spyder.

From<EMAIL_ADDRESS>on 2013-08-15T21:22:24Z
I can reproduce this, and I agree that it is related to the filename changing from lowercase to uppercase. That's really related to issue #612 , which is a more general problem of dealing with the fact that Windows doesn't care about case in filenames.
I would say that managing the lingering breakpoints is possible now with the breakpoint plugin. From there it is possible to remove a single breakpoint even if it is not showing up in the Editor. I'm going to call this issue Fixed, and we'll leave the more general issue of file case to issue #612 .
Status: Fixed
Labels: MS-v2.2.3


Duck DNS stops working when internet disconnect

Home Assistant release with the issue:
0.89.2

Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):
raspberry pi3b /hassio

Component/platform:
https://www.home-assistant.io/addons/duckdns/

Description of problem:
i am running hassio in a raspberry pi3b , and configured Duck DNS with Let’s Encrypt and all is working fine for the last 3 months , but one problem i am facing from the beginning is whenever my internet connection is disconnected for a long time (5-10Minutes or more) then my duckdns stops working , and i have to manually start the addon again . this happens each and everytime the internet is disconnected for a longer period , but doesent happen when the connection is disconnected for just 1-2 minutes .
what should be the problem or solution ?
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

/move to home-assistant/hassio-addons


[T3A4][W14-A3] Low Jian Sheng

As mentioned during tutorial, consider whether exiting is the best way to handle this exception. :)


Autovacuum from jsonlog is not properly parsed - some parts of html report lacks data

Created Pull request https://github.com/darold/pgbadger/pull/828 to address this issue.
I added tests with fixture files taken from the PostgreSQL15 instance.
Missing parts of the report are listed in the pull request.

Many thanks, PR merged


Fixing backwards compatibility tests

🚀 🚀 Pull Request
Impact

[X] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Fixing failing backwards compatibility tests

Issue was elsewhere


Importing tablesaw with webpack causes an error resolving shoestring

I'm having trouble importing tablesaw into a Webpack vendor file. When I attempt to import it:
import "tablesaw";
I get a Webpack compilation error stating Cannot resolve module 'shoestring' in <directory>. Seems to be a problem with the define in the UMD model definition around line 1940:
(function (factory) {
	if (typeof define === 'function' && define.amd) {
			// AMD. Register as an anonymous module.
			define(['shoestring'], factory); <-- error here

Included with v3.0.0-beta.2


Disconnecting and Reconnecting on a continuous loop

Just today, an issue started occurring where all my twitch channel tabs started to reconnect and disconnect on a loop. I know this has been a documented issue before but I have less than 100 twitch tabs (less than 80 in fact) and I didn't add any recently that should have caused this behavior. I also haven't had any changes in network connectivity. It also seems version-less as an older version of Chatterino on my personal laptop also had this start randomly occurring at the same time. So far I've tried restarting my router (even though there has been no network issues), opening Chatterino as an admin, restarting computer, and uninstalling and re-installing Chatterino.
Screenshots

OS and Chatterino Version
Windows 10, Chatterino 2.3.2 on PC and Windows 10, Chatterino 2.2.2-fix on laptop.

we know, it's mostly a twitch issue

we know, it's mostly a twitch issue

Oh really? Is this documented somewhere else I could look to understand the situation? Thanks!

You can start a Chatterino with a single channel (-c CLI argument) and it should work.

duplicates #2245

duplicates #2245

Actually false, please see #3107


dbeaver: 22.2.2 -> 22.3.0

Description of changes

Latest version bump;
Includes hotfixes to build against latest eclipse;
Pinned versions for the dependencies that were using "LATEST" as revision.

Full changelog: https://github.com/dbeaver/dbeaver/compare/22.2.2...22.3.0
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

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

[ ] Fits CONTRIBUTING.md.

My take on this wasn't good neither, even pinning the POM, every time I build it mavenfod just outputs a different hash.


new style device (this is the good one)

@nimlgen if you want to base CUDA and HIP on this, it's here to stay


Less hits than the count found in ES

Our system is more likely real-time monitoring one. Given the same query string and window (in milliseconds) elastalert sometimes report less hits than what I can find in the ES. I guess the elastalert might send the query slightly early (few seconds) before the data actually come down to the elasticsearch. It misses 1 or 2 hits even though the full data events are found in ES. Can I configure the elastalert to query with a slight delay? Or am I guessing in a wrong way?

Add to your rule
query_delay:
  minutes: 5


Amend advanced algorithms italian translation

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[ ] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[x] Add new translation (feature adding new translations)

Checklist:

[ ] Tested changes locally.
[ ] Closes currently open issue (replace XXXX with an issue no): Closes #XXXX

Description

Amends https://github.com/FreeCodeCamp/FreeCodeCamp/pull/9728 , Italian translation of advanced algorithms ( submitted by @devilicecream ).

LGTM :+1:
Thanks for contributing :tada:


Announce Bazel 0.13

Thanks!
Done.

"Changes requested" -> how do I mark them as done?
Seems like I can't merge because of that.


fix: Explore layout is sometimes too short for the viewport

SUMMARY

Flex layout in the explore section usually looks OK, but when things are in an error state, and all three columns are shorter than the viewport, that means the whole layout can get too short, making a weird gap under the menu. This sets a flex-basis property that's plenty tall (the entire viewport) to take up the space, and then flexbox will shrink things as needed.
Issue reported by @srinify
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:

After:

TEST PLAN

Select a dataset without too many fields (so the list is short)
Find a viz with a sufficiently short control panel (either tab in the control panel, as seen in the gifs above)
Put the chart in an error state so it loses its height.
Witness the layout shift at the top (or... hopefully not).
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up

/testenv up

Glad this is fixed, exciting! LGTM


!important

fix #26

I checked this page https://developer.mozilla.org/zh-CN/docs/Web/CSS/Specificity , and decided to use id selector.


E2E identity tests with Azure functions

Steps left for this :
Instructions
Deploy to azure functions, code works locally

The steps to create azure resources for azure functions in order to deploy fail - https://docs.microsoft.com/en-us/azure/azure-functions/create-first-function-cli-typescript?tabs=azure-cli%2Cbrowser#create-supporting-azure-resources-for-your-function

https://github.com/Azure/azure-sdk-for-js/issues/10485

@sadasant @maorleger This is ready for review - can you try the instructions once on your end and see if it is sufficient enough for you to follow through? It will be good feedback.

@KarishmaGhiya take a look at this gist: https://gist.github.com/maorleger/8a3eab60acfa5ffab0da8d6433fed95d
Which provides a zero-config arm template - you no longer have to set access policies or enable managed identity - it's all going to be set in code 🎸


gc:arc?

https://github.com/nim-lang/RFCs/issues/177
Following this discussion, for old behaviour, code should be compiled with --exceptions:setjmp --panics:on

Specifying rasises: [] on all the used procs should also get rid of the branching introduced by exceptions:goto.

I am not sure I understand the meaning. Do you mean that, if I specify raises: on a proc, the goto exceptions handler won't introduce any branching, since it sees that the proc can already raise specific things?

If you specify raises: [] then the compiler will see that it can't raise, and thus won't introduce branching.

Aaah, I see. Thanks! I'll keep it in mind :)


Not work with Rider

Hey.
Not work with Rider. Version 2020.1.3
https://i.imgur.com/TNkiyut.png

Unfortunately, Rider is very different from other IntelliJ-based IDEs. It has its own ProjectViewTree node implementation, which ignores plugin's ColorProvider. I will open the issue in the JB tracker and hope that someday Rider developers will fix it.

Still not working :(


Proxy example, please?

Hello!
What is JSON Proxy Object and how to create it and supply to Capabilities? Can you throw a little example, say I have  proxy
http://<IP_ADDRESS>:5678
Sadly I lack any knowledge in JSON, I only Selenium to test some heavy Ajax content and I need to do it via proxies.
EDIT: Reading JSON and GO and asking question on stackoverflow, seems like just need to use map[string]interface{} like
caps := selenium.Capabilities{"browserName": "firefox", "proxy": map[string]interface{}{"proxyType": "manual", "httpProxy": "<IP_ADDRESS>:80"}}

Hi,
It's been a while since I worked with Selenium. Sorry but I can't help you.
Probably ask in StackOverflow.
Good luck,
Miki

Hi, you made great work, Mikki! Proxy works, as I added in edit.
On May 8, 2015 4:01 PM, "Miki Tebeka"<EMAIL_ADDRESS>wrote:

Closed #6 https://github.com/tebeka/selenium/issues/6.
—
Reply to this email directly or view it on GitHub
https://github.com/tebeka/selenium/issues/6#event-300220370.

This is awesome! Happy testing ...


Fix url string format PoinOfInteraction

afaik, url is not a valid format in json schema, replaced with uri
which is a super set of url, better would be probably to use a pattern.
feedbacks?

LGTM thanks


Add python_version marker constraint in setup.py

Describe the bug
I've found a dependency resolution problem when installing ormar with black using poetry.
  Because no versions of black match >21.9b0,<22.0
   and black (21.9b0) depends on typing-extensions (>=<IP_ADDRESS>), black (>=21.9b0,<22.0) requires typing-extensions (>=<IP_ADDRESS>).
  And because ormar (0.10.20) depends on typing-extensions (>=3.7,<<IP_ADDRESS>)
   and no versions of ormar match >0.10.20,<0.11.0, black (>=21.9b0,<22.0) is incompatible with ormar (>=0.10.20,<0.11.0).
  So, because ormartest depends on both ormar (^0.10.20) and black (^21.9b0), version solving failed.

To Reproduce
Steps to reproduce the behavior:

poetry new test
cd test
poetry add black --dev
poetry add ormar
You found the error.

Expected behavior
A clear and concise description of what you expected to happen.
Versions (please complete the following information):

Database backend used (mysql/sqlite/postgress)
Python version
poetry ^1.1.11
ormar ^0.10.20
black ^21.9b0

Possible solution
Since you use typing_extensions only for providing Protocol and Literal, you may add constraint to avoid this issue.
The solution is to specify the typing_extension version in your setup.py as following:
install_requires=[
        ...
        "typing_extensions>=3.7,<<IP_ADDRESS>; python_version < '3.8'",
    ],

Additional context
This issue is crucial for me, since I want to integrate your super cool library in my project generator. It uses black by default,  but I can't get it work with your library because of this issue.
Thanks in advance.

I can make pull request that adds this constraint or I can add poetry as your dependency manager. Poetry would be really nice because it's easier to maintain than setup.py for both development and publication.

I haven't change the any config file.
Here is some diffs with before and after black:
-def post_save(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable:
+def post_save(
+    senders: Union[Type["Model"], List[Type["Model"]]],
+) -> Callable:
     """
     Connect given function to all senders for post_save signal.

@@ -54,7 +56,9 @@ def post_save(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable:
     return receiver(signal="post_save", senders=senders)

-def post_update(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable:
+def post_update(
+    senders: Union[Type["Model"], List[Type["Model"]]],
+) -> Callable:
     """
     Connect given function to all senders for post_update signal.

@@ -67,7 +71,9 @@ def post_update(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable
     return receiver(signal="post_update", senders=senders)

-def post_delete(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable:
+def post_delete(
+    senders: Union[Type["Model"], List[Type["Model"]]],
+) -> Callable:
     """
     Connect given function to all senders for post_delete signal.

@@ -43,8 +43,8 @@ class NoMatch(AsyncOrmException):

 class MultipleMatches(AsyncOrmException):
     """
-        Raised for database queries that should return one row (i.e. get, first etc.)
-        but has multiple matching results in response.
+    Raised for database queries that should return one row (i.e. get, first etc.)
+    but has multiple matching results in response.
     """

     pass
@@ -52,11 +52,11 @@ class MultipleMatches(AsyncOrmException):

 class QueryDefinitionError(AsyncOrmException):
     """
-        Raised for errors in query definition:
+    Raised for errors in query definition:

-        * using contains or icontains filter with instance of the Model
-        * using Queryset.update() without filter and setting each flag to True
-        * using Queryset.delete() without filter and setting each flag to True
+    * using contains or icontains filter with instance of the Model
+    * using Queryset.update() without filter and setting each flag to True
+    * using Queryset.delete() without filter and setting each flag to True
     """

     pass

I guess the game changer for function is a comma after the function parameters.
Like
def test(a: int,) -> None: # Would be refformated
   ...

def test(a: int) -> None: # Wouldn't be refformated
   ...

But why does it reformat docstring like this?

I think string-related handling was experimental and was enabled by default in the newest version of black.
but changes like those seem weird as it was black which inserted those commas in the first place :)
-def post_save(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable:
+def post_save(
+    senders: Union[Type["Model"], List[Type["Model"]]],
+) -> Callable:
     """
     Connect given function to all senders for post_save signal.

@@ -54,7 +56,9 @@ def post_save(senders: Union[Type["Model"], List[Type["Model"]]],) -> Callable:
     return receiver(signal="post_save", senders=senders)

I ran black twice with "-C" and without "-C" flag. It won't add those command back.


Fix paginating to second page without breadcrumbs. #551

Fixes: Pagination Causes ValueError from Breadcrumbs #551

What is the purpose of your pull request?

[x] Bug fix
[ ] New feature

Proposed changes
The proposed change is very simple, and simply checks that the accessed variable is defined.

Coverage remained the same at 100.0% when pulling 0e48363f2b22e571e19d6bfaf8f9e406b617f89f on jplehmann:develop into b4949304b104a8e1a7a7a0773cbfd024313c3a15 on Fantomas42:develop.

@Fantomas42 any chance this can get merged?

You can easily see that it's a < 1 line of defensive code.


fix the issue of cursor movement using arrow keys in the search bar for links

Associated with https://github.com/deep-foundation/deepcase/issues/102


Add an optional parameter called 'Location' to the Add/Update ActionGroup command

Related command

https://docs.microsoft.com/en-us/cli/azure/monitor/action-group?view=azure-cli-latest
We want to add an optional parameter named 'Location' which takes a string input. If location is not provided, then default it to 'Global' as current.
az monitor action-group create --action webhook https://alerts.contoso.com apiKey={APIKey} type=HighCPU --name MyActionGroup --resource-group MyResourceGroup
Is your feature request related to a problem? Please describe.

No, it is not a problem. We have always hardcoded it to "Global", but now we have regional action group, this is the support we like to add.
Describe the solution you'd like

Describe alternatives you've considered

Additional context

monitor

Hi @yonzhan , @kairu-ms , thanks for your help on this. Could you share with me an ETA when this change will be available? Thanks!

We will support it in this sprint. It will be in the release of 2022-09-06


Support for Brazilian

No language code exists for brazilian in ISO-639-1
Common workaround is pt-br. OpenSubtitles uses pb/pob.

Done in ffa38694dfdaeb87811998324e93e67c9ea1049d


Set target cluster name in status

modify options.go to include a new flag externalDispatch which when set to true would direct dispatcher to use external plug-in to dispatch workloads
modify queuejob_controller_ex.go to optionally set targetClusterName field in status. The value for the field comes from  Spec.SchedSpec.ClusterScheduling.Clusters which can contain zero or more comma separated clusterIds. If more than one clusterId is provided, the code will choose one at random.

@cwiklik:
Transitiion this PR to  our MCC branch. Suggest closing it?

work in progress, not ready


Debugging extensions in codespaces not working

Open a codespace for any extension, for example a vscode-extension-samples folder
Build and run the extension launch config
A tab with this url opens and 404s: https://github.com/codespaces/roblourens-vscode-kusto-grwc?folder=%2Fhome%2Fcodespace&payload=%5B%5B%22extensionDevelopmentPath%22%2C%22vscode-remote%3A%2F%2Fcodespaces%252Broblourens-microsoft-vscode-extension-samples-9vj55ghx599%2Fworkspaces%2Fvscode-extension-samples%2Fcodelens-sample%22%5D%2C%5B%22extensionEnvironment%22%2C%22%7B%7D%22%5D%2C%5B%22debugId%22%2C%22b5379fc5-11b0-418b-a85c-163602e2ebe2%22%5D%2C%5B%22inspect-brk-extensions%22%2C%2253601%22%5D%5D
That url is suspicious, what is roblourens-vscode-kusto-grwc?

I am not sure how extension dev works in codespaces, whose side this would be on, codespaces or us? cc @weinand @connor4312

This looks like codespaces. Nothing has changed on our side.


Mask generated via API is vastly diffrent and inaccurate

The masks look perfect when generated through the WebUi,
But generation the masks using the same exact photo and exact API payload, i get very inaccurate masks.
How is this even possible?
Any ideas why on earth this scripts reacts so differently when used without the WebUi?

https://github.com/djbielejeski/a-person-mask-generator/issues/19#issuecomment-2154665508


Defer Finished MAC handling until after state transition

In TLS we process received messages like this:

Read Message Header
Validate and transition state based on received message type
Read Message Body
Process Message

In DTLS we read messages like this:

Read Message Header and Body
Validate and transition state based on received message type
Process Message

The difference is because of the stream vs datagram semantics of the
underlying transport.
In both TLS and DTLS we were doing finished MAC processing as part of
reading the message body. This means that in DTLS this was occurring
before the state transition has been validated. A crash was occurring
in DTLS if a Finished message was sent in an invalid state due to
assumptions in the code that certain variables would have been setup by
the time a Finished message arrives.
To avoid this problem we shift the finished MAC processing to be after
the state transition in DTLS.
Thanks to github user @bathooman for reporting this issue.
Fixes #14906

There was a nearly identical bug way back, CVE-2013-4353.
I'd suggest revisiting how OpenSSL manages transcript hashes. OpenSSL currently automatically hashes every message into the transcript when it is received. This doesn't when processing a message that uses the transcript: CertificateVerify and Finished. It also doesn't work for HelloRetryRequest.
The DTLS/TLS implementation ends up compensating for it in various ways:
https://github.com/openssl/openssl/blob/72f649e061bef86cbf41303fede1a61c9fe2c05b/ssl/statem/statem_clnt.c#L1925
https://github.com/openssl/openssl/blob/72f649e061bef86cbf41303fede1a61c9fe2c05b/ssl/statem/statem_srvr.c#L3573
https://github.com/openssl/openssl/blob/72f649e061bef86cbf41303fede1a61c9fe2c05b/ssl/statem/statem_dtls.c#L382
https://github.com/openssl/openssl/blob/72f649e061bef86cbf41303fede1a61c9fe2c05b/ssl/statem/statem_lib.c#L1295
https://github.com/openssl/openssl/blob/72f649e061bef86cbf41303fede1a61c9fe2c05b/ssl/statem/statem_lib.c#L1325
I think the root cause for this and CVE-2013-4353 are that the logic for sampling the Finished hash happens outside the state machine entirely. But the other ones are also not ideal. The HRR version will need to be duplicated when DTLS 1.3 happens. The CertificateVerify version is most direct, though it still use more per-connection memory.
Instead, what we did is process those handshake messages before incorporating them into the transcript. At the beginning (back in 2014, when we were still using the old 1.0.2 state machine), we did this with a parameter to read the message without the handshake hash, but as our state machine evolved, we actually just switched to never automatically hashing in the read path. Each state just decides when to hash it itself. This way you can handle cases where you need to process after hashing, like computing keys in TLS 1.3. If you prefer the automatic hashing, another strategy could be to have to separate functions. (Maybe you could reuse the process_message/post_process_message split? Or maybe that's something else. I'm not familiar with the new state machine so I can't give very useful specific suggestions, just ideas for high-level structure.)

I'd suggest revisiting how OpenSSL manages transcript hashes.

It's a good suggestion and worthy of consideration. However I think that is a much more significant surgery on the state machine than I'm willing to do at this stage in the 3.0 lifecycle with beta1 looming. If we were to do that then it should be deferred to post 3.0.

Oh certainly! Yeah a fix like this makes sense as an immediate fix. I meant that as a suggestion for future work. :-)

Ping for review?

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Pushed. Thanks.


Finalize solution for superscript based tonal phonetics

There are some terms that cannot be converted either because they are entered improperly or we have weird tone change stuff to figure out.

Meeting with JW today to figure out the tone change stuff.


Try to fix connector alignments for every use

Connector are well aligned currently. But they are kind of hardcoded and can be offset when we add some things, like images. Maybe try to calculate the values with calc()?
Screenshot from here.

The missalignment of the connectors seems to come from the team images, changing the height of the matches.
So this issue is related to #36


Quaternion refactor

Refactored quaternion code to use MuJoCo quaternion functions instead of pyquaternion.

Refactored redundant functions in sawyer_xyz/sawyer_*	tasks into sawyer_xyz/base.py.
Swapped pyquaternion functionality in env_utils.py to use MuJoCo quaternion functions.
Created unit test (test_quat.py) to demonstrate parity between MuJoCo	functions and pyquaternion functions.
Removed pyquaternion dependency in setup.py from production, added to dev.
Removed numpy-stl dependency in setup.py.
metaworld/envs/assets directory was not copied during installation in Linux or Mac. Added MANIFEST.in file to include assets on installation, and added install_package_data=True to setup.py to fix this.

Amicable ping @tianheyu927 , would it be possible for you to review this PR? Thank you!!

LGTM

FYI your Travis build is failing because we don't share the MuJoCo key with fork PRs (for security reasons).
Please ping here when it's ready to merge, and I'll pull it into a branch here so Travis can run.

@ryanjulian @zhanpenghe I addressed your comments on my branch. I think it's ready to be tested on on Travis and merged. Thanks, let me know if there's anything more I can do!

Thank you very much! @mschachter


error: unable to parse version script file tensorflow/tf_version_script.lds

hello,thanks for provide this project.
when I build tensorflow_all.so , I get an error like this
"error: unable to open version script file tensorflow/tf_version_script.lds, that's no this file or directory"
"fatal error: unable to parse version script file tensorflow/tf_version_script.lds",
but I can find this file in  the directory, and it seems normal. how can I fix this problem, please?@cjweeks
my env:
ubuntu 16.04
tensorflow 1.2
cuda 8.0
cudnn 5.1

I tried to build TensorFlow 1.2.0 using Ubuntu 16.04, and I encountered no errors.  Just to make sure nothing has happened to the tf_version_scripts.lds file, I would run git status to see if any changes were accidentally made.  Second, make sure that you have the correct read permissions set for tf_version_scripts.lds; perhaps Bazel is unable to open the file for this reason. What is the exact commit of TensorFlow and version of Bazel you are using (I am using 12f033df4c8fa3feb88ce936eb1581eaa92b303e and 0.5.2 respectively).  I hope this helps.

@cjweeks thanks for response, maybe I have broken the tf project unconsciously, I will check out what has happened, thanks again!

@wujsy Did this end up working?

yes, I cloned anew tensorflow 1.2 and rebuild it ,there is no problem, thanks


Vector tooltips infowindow

It depends on #1624 and fix https://github.com/CartoDB/tangram.cartodb/issues/8

:+1:


feat(sbb-radio-button-group): introduce radio-button-group component

Preflight Checklist

[x] I have read the Contributing Guidelines for this project.
[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the pull request tracker for a Pull Request (PR) that matches the one I want to submit, without success.

Issue
This PR Closes #1044
Pull request checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

See Review Guidelines for more information what is checked during review process.
Changes
Changes in this pull request:

implement sbb-radio-button and sbb-radio-button-group components

Browsers
I tested the build on the following browsers:

[x] Firefox Desktop
[x] Chrome Desktop
[ ] Edge Desktop
[x] Safari Desktop
[x] Chrome Mobile
[x] Safari Mobile

Screen readers
I tested the build on the following browsers:

[ ] JAWS Firefox Desktop
[ ] JAWS Chrome Desktop
[ ] NVDA Firefox Desktop
[ ] NVDA Chrome Desktop
[x] VoiceOver Safari Desktop
[x] VoiceOver Chrome Desktop
[x] VoiceOver Safari Mobile
[x] Android Accessibility Suite Chrome Mobile

Pull request type

Please check the type of change your PR introduces:

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

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

Codecov Report

Merging #1431 (74b779a) into master (ab917b0) will increase coverage by 2.55%.
The diff coverage is 63.13%.

@@            Coverage Diff             @@
##           master    #1431      +/-   ##
==========================================
+ Coverage   54.85%   57.40%   +2.55%
==========================================
  Files          49       62      +13
  Lines        1659     2256     +597
  Branches      406      576     +170
==========================================
+ Hits          910     1295     +385
- Misses        671      870     +199
- Partials       78       91      +13

Impacted Files
Coverage Δ

src/components/sbb-clock/sbb-clock.tsx
0.00% <0.00%> (ø)

src/components/sbb-logo/sbb-logo.tsx
0.00% <0.00%> (ø)

src/components/sbb-section/sbb-section.tsx
85.00% <ø> (ø)

src/components/sbb-signet/sbb-signet.tsx
0.00% <ø> (ø)

...mponents/sbb-slot-component/sbb-slot-component.tsx
100.00% <ø> (ø)

src/components/sbb-stack/sbb-stack.tsx
76.66% <ø> (ø)

src/components/sbb-tab-amount/sbb-tab-amount.tsx
100.00% <ø> (ø)

src/components/sbb-tab-group/sbb-tab-group.tsx
76.19% <ø> (ø)

src/components/sbb-tab-title/sbb-tab-title.tsx
100.00% <ø> (ø)

src/components/sbb-teaser-hero/sbb-teaser-hero.tsx
70.00% <ø> (-22.86%)
:arrow_down:

... and 46 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

ux-review:

[ ] issue-1: https://www.figma.com/file/9r6xSfNmEfCFxl1yFYedrj?node-id=13922:464760#295548946
[ ] issue-2: https://www.figma.com/file/9r6xSfNmEfCFxl1yFYedrj?node-id=13922:464761#295549849
[ ] issue-3: https://www.figma.com/file/9r6xSfNmEfCFxl1yFYedrj?node-id=13922:464998#295563806
[ ] issue-4: https://www.figma.com/file/9r6xSfNmEfCFxl1yFYedrj?node-id=13922:464999#295565410
[ ] issue-5: https://www.figma.com/file/9r6xSfNmEfCFxl1yFYedrj?node-id=13878:483449#295598333
[ ] issue-6: https://www.figma.com/file/9r6xSfNmEfCFxl1yFYedrj?node-id=13878:483428#295594930


Unable to accept friend requests

Summary
As the title states, I'm unable to accept friend requests programatically.
Reproduction Steps

Add the following code to your main client class:

    async def on_relationship_add(self, relationship):
        if relationship.type == discord.RelationshipType.incoming_request:
            await relationship.accept()

Send a friend request to your bot
Receive a Bad Request (http code 400) in console.

Code
async def on_relationship_add(self, relationship):
    if relationship.type == discord.RelationshipType.incoming_request:
        await relationship.accept()

Expected Results
The friend request is automatically accepted.
Actual Results
2023-06-25 12:46:03 ERROR    discord.client Ignoring exception in on_relationship_add
Traceback (most recent call last):
  File "C:\Users\ivanz\AppData\Local\Programs\Python\Python311\Lib\site-packages\discord\client.py", line 507, in _run_event
    await coro(*args, **kwargs)
  File "c:\Users\ivanz\Desktop\telnet server\bot.py", line 13, in on_relationship_add
    await relationship.accept()
  File "C:\Users\ivanz\AppData\Local\Programs\Python\Python311\Lib\site-packages\discord\relationship.py", line 298, in accept
    await self._state.http.add_relationship(self.user.id, action=RelationshipAction.accept_request)
  File "C:\Users\ivanz\AppData\Local\Programs\Python\Python311\Lib\site-packages\discord\http.py", line 838, in request
    raise HTTPException(response, data)
discord.errors.HTTPException: 400 Bad Request (error code: 50035): Invalid Form Body
In miscallenous: Expected "Content-Type" header to be one of {'application/json'}.

System Information
- Python v3.11.4-final
- discord.py-self v2.0.0-final
- aiohttp v3.8.3
- system info: Windows 10 10.0.22621

Checklist

[X] I have searched the open issues for duplicates.
[X] I have shared the entire traceback.
[X] I am using a user token (and it isn't visible in the code).

Additional Information
No response

Should be fixed now

the error shows up rarely now, but it still does not accept friend requests. ive tried a pip upgrade but no luck.

I am having this issue with send_friend_request()

coming back to this, the exact same issue still occurs with the exact same code above


Release 2.1.1

Questions
Answers

Description?
Release 2.1.1, needed for https://github.com/PrestaShop/PrestaShop/issues/22668

Type?
improvement

BC breaks?
no

Deprecations?
no

Fixed ticket?
N/A

How to test?
Please perform a standard testing campaign for module release. Only significant change should be https://github.com/PrestaShop/ps_searchbar/pull/10. After install you need to delete the module template override in the theme themes/classic/modules/ps_searchbar and clear the cache then

The search icon is missing in 1.7.6.X and 1.7.7.X

@sarahdib According to https://github.com/PrestaShop/ps_searchbar/pull/25 BUT ps_searchbar 2.1.0 is only compatible with PS 1.7.8+ (so same for v2.1.1)
Let's find out with @atomiix  if we need to release v2.0.2 instead 😢

Oh ok :)
I check using develop and there is a little front problem
https://drive.google.com/file/d/1AXiO4wZ6MUDA9N5P-j5ZRldtaH-MIFEW/view

@matks I think I forgot to answer you but I made a PR so we can release a v2.0.2: https://github.com/PrestaShop/ps_searchbar/pull/31

🆙
So ps_searchbar 2.0.1 has been released => this is good for 1.7.7.x branch
We now have to handle @sarahdib feedback https://github.com/PrestaShop/ps_searchbar/pull/30#issuecomment-777010285


update osh-infra submodule to latest

This fixes the pod logs gathering, which is failing due to
kubectl >=1.15 not having the "--show-all" flag anymore
Updated to I4ed3624737af4d5c90b1b5de451a0a0b75a5eda1

I will cnacel the job as soon as there is running pods, so it can trigger the post action of gathering logs. Otherwise there is no other way of testing this correctly, so the CI for this will be red :=)


How to make .emu file ?

I have an Emotiv Epoc+ v1.1 released back in 2015 and have the latest emotiv MacOS framework installed ( community-sdk-3.5.1-WIN-MAC-ANDROID ).

I am successfully able to turn on the device and use it in the emotiv apps and see feedback.

However there does not appear to be any Profiles folder in my users Emotive folder:
/Users/peter/Library/Application Support/Emotiv

I assumed, likely incorrectly, that since I did not have that file, perhaps your instructions were stating I should make a file, as there was a comment in the example for "path/to/user/file".
Here is a sample code I used to see if I could get things running:
var Epoc = require('epocjs')();

Epoc.connectToLiveData('./test.emu', function(event) {
  if (event) {
    console.log('Event Fired');

    if (event.batteryLevel && event.batteryLevel > 0) {
      console.log(`Battery level: ${event.batteryLevel}%`);
    }
  }
});

Here is the output from that command

If there is something I am supposed to be doing with the Emotiv in the background, it would be helpful to learn this.  The docs make it sound like I can just plug on the device, make sure I can access it via the Emotiv software, then fire up some node script to connect to it, and that is not turning out to be the case :(
BTW, for the sake of testing purposes, I also use the  Epoc.connectToEmoComposer method while tinkering with the EmotivXavierComposer app in the background, and the output from that was only ever Connected to EmoComposer but none of the tested events seemed to fire off either.  Not sure if maybe something else is going on here where the method are not firing for some reason I don't know about.
Here was my test file for that, should this be a related issues:
var Epoc = require('epocjs')();

Epoc.connectToEmoComposer(function(event) {
  if (event) {
    pastAction = action;

    if (event.blink > 0) {
      action = 'blink';
    }

    if (event.lookingLeft > 0) {
      action = 'looking left'
    }

    if (event.lookingUp > 0) {
      action = 'looking up'
    }

    if (event.gyroX) {
      console.log("gyroX: ", event.gyroX);
    }

    if (event.gyroY) {
      console.log("gyroY: ", event.gyroY);
    }

    // at the moment will only handle 1 event at a time. Need to fix that
    if (pastAction !== action) {
      console.log('action', action)
    }
  }
});

Any help would be greatly appreciated 😃

Just a heads up that I was able to figure out why I was not getting any output from these methods.  Looks like this library only works with the USB Dongle connection, which I was not aware of.  I was using the Bluetooth LTE connection.
The original question regarding how one makes the profile .emu file, or if it is even required, is still something I am interested in learning more about.

@manifestinteractive I'm also confused about the existence of this file, any clue yet?

@ocyedwin Nope :)
Only thing I could remotely find on it was related to Emotiv Cloud Profiles.  Here are three files on the Emotiv Community SDK that seemed to talk about it, though not exactly sure of any Emotiv apps that have this feature built in.
https://github.com/Emotiv/community-sdk/search?q=.emu&unscoped_q=.emu
Heck, I even have the pro account at $99 a month and don't see any way of exporting these files.
However, it does appear that the code works regardless if the .emu file exists.  So who knows at this point.  Would be super awesome to learn how this is used in this project, but guessing that's not the biggest priority given the other stuff they are working on.

Hello world! I'm fairly new to the use of Emotiv and am having similar issues finding the profile file.
I've so far used the EmotivBCI app to train the expression/command recognition. Within the EmotivBCI I can definitely see it works for smile recognition.
I suspect the profile files are "in the cloud." Maybe it's worth reaching out to Emotiv to see if we can still access those training profiles.


Consider converting proof timestamps to secs and floor (ignore nanos)

Since other implementations may just use seconds, I'm wondering if we should instead of using the block time and client timestamp in nanos actually just convert them to seconds and floor it (ie ignore subseconds) to be consistent

In practice, this is a non-issue but worth noting and deciding on before release

Originally posted by @AdityaSripal in https://github.com/cosmos/ibc-go/pull/7464#pullrequestreview-2385153760

Just to be clear, is this issue about potentially changing the light clients to use seconds instead of nanoseconds?
@AdityaSripal

We probably will not change the ibc-go light clients directly since we want to still support IBC v1 and minimize changes.
Rather this is about how to convert the nanoseconds from the client to seconds in the v2 handler correctly


feat: Update new version modal for v3.3. Fixes #7639

Signed-off-by: Alex Collins<EMAIL_ADDRESS>Fixes #7639
Don't bother creating a PR until you've done this:

[x] Run make pre-commit -B to fix codegen, lint, and commit message problems.

Create your PR as a draft.

Your PR needs to pass the required checks before it can be approved. If the check is not required (e.g. E2E tests) it
does not need to pass.
Once required tests have passed, you can make it "Ready for review".
Say how you tested your changes. If you changed the UI, attach screenshots.

Tips:

If changes were requested, and you've made them, then dismiss the review to get it looked at again.
Add you organization to USERS.md if you like.
You can ask for help!

2 weeks old. Not going to wait for docs anymore.


Allow megaparsec 9.0.0

https://github.com/commercialhaskell/stackage/issues/5632
config-ini-2.4.0 builds with megaparsec-9.0.0, so a hackage revision should be enough.
The ini-compat test suite fails to build, but that's #22, not megaparsec-related.

Ping

Sorry about the delay! I've pushed a revision that allows megaparsec-10. You should be good to go!

Thanks! 🙏🏻

The revision change does not update the config-ini.cabal file's boundaries which prevents nix's callHackageDirect rule from seeing the updated bounds. It would be helpful to us to have new, genuine version upload.

The revision change does not update the config-ini.cabal file's boundaries which prevents nix's callHackageDirect rule from seeing the updated bounds. It would be helpful to us to have new, genuine version upload.

Version <IP_ADDRESS> that builds with ghc 9.4.2 has been uploaded to hackage, so I think this can be closed


Support the burn transaction

There is an explicit burn tx type that, although likely currently totally unused, is useful in certain situations.  This should be exposed and available as a wallet operation.

The OasisScan API is returning wrong data about the burns in the transaction list. ( See here: https://github.com/bitcat365/oasisscan-backend/issues/5 ) Until that is fixed, we can only show these transactions with the Oasis Monitor backend.


Xamarin.Firebase.MLKit.Common cannot be built

I try to use Xamarin.Firebase.iOS.MLKit, but I found the dependency issue on that nuget. Then, I just want to inst MLKit.Common first.
I can install it, but I get build error
      clang : error : linker command failed with exit code 1 (use -v to see invocation)
MTOUCH : error MT5210: Native linking failed, undefined symbol: _FIRLogBasic. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
MTOUCH : error MT5210: Native linking failed, undefined symbol: _kFIRLoggerMLKit. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
MTOUCH : error MT5201: Native linking failed. Please review the build log and the user flags provided to gcc: -ObjC -lc++ -lsqlite3 -lz -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/jesse/Documents/Project/SmartElements/SmartElements.iOS/obj/iPhoneSimulator/Debug/device-builds/iphone11.4-12.1/Entitlements.xcent
MTOUCH : error MT5202: Native linking failed. Please review the build log.
    11 Warning(s)

I try to follow up the solution clean cache in this issue https://github.com/xamarin/GoogleApisForiOSComponents/issues/158
It still not work.
Please help us to fix this issue.
Thanks

@jessejiang0214 Just letting you know that the fix has been published.

@SotoiGhost  brilliant!!!, Thanks very much.
Just a quick question, do you know what time Xamarin.Firebase.ML.Vision release or pre-release? Cause we need the same solution for Android.
I create a issue for this https://github.com/xamarin/GooglePlayServicesComponents/issues/180
Would you please give me some ETA about that?


Typo in the help message derived from comment by clap

This comment contains a typo (deply instead of deploy) that's user visible because the comment is used by clap e.g. in elf2uf2-rs --help's output:
% elf2uf2-rs --help
elf2uf2-rs
Jonathan Nilsson

USAGE:
    elf2uf2-rs [OPTIONS] <INPUT> [OUTPUT]

ARGS:
    <INPUT>     Input file
    <OUTPUT>    Output file

OPTIONS:
    -d, --deploy     Deploy to any connected pico
    -h, --help       Print help information
    -s, --serial     Connect to serial after deply
    -v, --verbose    Verbose

Fixed!


testing got wrong with ci-info

refer to : https://github.com/wechaty/wechaty-puppet-official-account/runs/1308782369?check_suite_focus=true
It seems that sendCustomMessage unit test can't skip pr, so it remains wrong with Github Actions.  And more, only the sendCustomMessage unit test can't skip pr runtime test.

The unit test will send a message to my WeChat account, so I have just sent a message to the OA account which was used by the unit test.
The GitHub Action should be passed this time, let's see.

Cherrs.  🍻


Tags doesn't seem to work and redirected to 404 page

Issue Summary
Hi,
I have recently set up my Ghost blog at zinkohlaing.com and it is self-hosted via Pikapods.
Here's an example URL that contains the tag "OMSA"
https://www.zinkohlaing.com/my-experience-with-georgia-tech-omsa-program-part-4/

I can see from Inspect Element that it should be redirected to https://www.zinkohlaing.com/tag/omsa/
But when I open this link or click on the tag, it is redirected to 404.
Based on my research, it seems that my Route file needs to be updated/changed. But the thing is I haven't made any modifications since the setup. This is what the Route file looks like.

I have already deleted / re-added the tags and it is happening to all tags so far.
Steps to Reproduce

Visit the post that contains a tag (like this: https://www.zinkohlaing.com/my-experience-with-georgia-tech-omsa-program-part-4/)
Click on the tag
404 happens

Ghost Version
5.100.1
Node.js Version
Not sure
How did you install Ghost?
Via Pikapods
Database type
Other
Browser & OS version
No response
Relevant log / error output
No response
Code of Conduct

[X] I agree to be friendly and polite to people in this repository

🙌yes!
Sent from Gmail Mobile
On Wed, 20 Nov 2024 at 12:06 am, Cathy Sarisky @.***>
wrote:

I believe you got it solved over on the Ghost forum, right?
https://forum.ghost.org/t/tags-doesnt-seem-to-work-and-redirected-to-404-page/52525/4
So this issue can be closed.
—
Reply to this email directly, view it on GitHub
https://github.com/TryGhost/Ghost/issues/21633#issuecomment-2485664795,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADJDOQ4F4VUKOH6HAKL3OKL2BMZTVAVCNFSM6AAAAABR4LOZESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBVGY3DINZZGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Glad you got it sorted 👍 .


rdp bulk 6.1 version, Decompression data missing

bulk.c.txt
mppc.c.txt
xcrush.c.txt
The code files related to the decompression algorithm are as above. I have hardly changed the main logic and added some log printing. Because I got the data of the RDP protocol,
so I will call the bulk_decompress_cc function in bulk.c to decompress the data in bulk.
cc.log
My data sample file is in cc.log. The data in the log:
The data starting with the keyword xcrush-cc-go is the data I passed to bulk_decompress_cc
The data starting with the keyword xcrush-cc-mppc after decompression is the data decompressed by 5.0mppc
The data starting with the keyword xcrush-cc-xcrush after decompression is the data decompressed by 6.1
You can see that the error code -1009 of xcrush decompression failure appears in the log
and part of the decompressed data is missing:

Original content

@chengxiaoku and what do you want from us?
you do something and it does not work so retry until it does?
or provide a minimal sample that we can compile and analyze to provide some feedback.
not an issue, so closing.


minor lang fixes

[INC] update i18n
[FIX] flag icon
[FIX] langs in code

We are updaing the language system, tks for the fixes.


else goto new line for "k&r" indent_style

i.e. was before
if ($attempt++ > 5) {
die("\t\t\terror : max attempt limit reached.\n");
} else {
$sleep_time+= $sleep_time;
MyEcho("curl again after $sleep_time sec's.");
}
and now
if ($attempt++ > 5) {
die("\t\t\terror : max attempt limit reached.\n");
}
else {
$sleep_time+= $sleep_time;
MyEcho("curl again after $sleep_time sec's.");
}

Any update to this? Its aggravating to me and also PHPBeautifier itself does not break them onto separate lines. Anyone know what file/line is doing this within the plugin?

my else statements look so weird. need a fix for this, but great plugin everything else looks great.

confirmed, also class gets newline even if set to false... this happened after I recompiled PHP on another machine

This issue is caused by the commit c407cc5f10

can we get this ?
obviously the hack to fix is...
if (strtolower($this->getSetting('style')) == 'allman') { $this->oBeaut->addNewLineIndent(); }
what it should of been since his fix broke k&r!

Send me pull request and I will merge it

After the fix is applied don't forget to set pear to false because pear defaults to allman for else statements.

Is my P.R. ever going to get merged? I updated meh box today stuck with this issue again. Pear is off and else still get shoved to new lines it needs the patch.

CodeFormatter updated to version 3.0.0
Maybe your problems solved
See Release Notes


Adding in jest and making it work. Testing jest

The files that I have added were my testing files. The package.json modifications and other new config files were needed to make jest work in general for some reason. I will be working on making actual unit test for login and etc after this

it doesn't have the actual unit test yet but tester files I made to get it all up and running.


Can you provide the meshes of your method and the baseline methods on ScanNet and 7Scenes?

Can you provide the meshes of your method and the baseline methods on ScanNet and 7Scenes? Thank you so much!

I do not have them stored anymore. But once you have the input data and predictions structured like this: https://github.com/ardaduz/deep-video-mvs/tree/master/sample-data, you can produce the meshes using https://github.com/ardaduz/deep-video-mvs/blob/master/sample-data/run-tsdf-reconstruction.py. Some instructions are here: https://github.com/ardaduz/deep-video-mvs#tsdf-reconstructions.
Everything you need to get the meshes is in this repository:

a script to create the keyframe indices (https://github.com/ardaduz/deep-video-mvs/blob/master/dvmvs/simulate_keyframe_buffer.py)
the prediction pipelines of the our method and the baseline methods, that are suitable to be run with the generated keyframe indices (https://github.com/ardaduz/deep-video-mvs/tree/master/dvmvs/baselines)
a script to generate the meshes using TSDF fusion out of the predictions (https://github.com/ardaduz/deep-video-mvs/blob/master/sample-data/run-tsdf-reconstruction.py)

Let me know if something is not clear.

Hi, thanks so much for your reply. Did you test other metics on ScanNet and 7Scenes? For example, absolute relative error, absolute difference, and squared relative loss?

Please check the paper.
We have Abs Rel, Abs Diff and delta < 1.25 metrics. Also, we evaluate Abs Inv, since that is our loss function.


Add view/nv to Bin Op Matrix

Integrating Binary Op matrix into IR Translator, a few comparators were missing from PowerFx.Core

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll


[Nexus] npm proxy repo fails on client (Content-Length with chunked encoding mixed)

I run the recommended setup of the Nexus Helm chart on GKE.
...
ingress:
  enabled: true
  path: /*
  annotations:
    kubernetes.io/ingress.class: gce
    kubernetes.io/ingress.global-static-ip-name: my-static-ip
  tls:
    enabled: true
    secretName: wildcard-cert
nexusProxy:
  env:
    nexusHttpHost: nexus.company.com
    nexusDockerHost: containers.company.com
    enforceHttps: true
...

Nexus is reachable and runs fine. I configured Nexus to proxy the npm registry and I get the following issue:
 ERROR  request to https://nexus.company.com/repository/npm-public/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz failed, reason: Parse Error: Content-Length can't be present with chunked encoding
It seems that in the HTTP Headers both Content-Length and chunked encoding is present which violates the http standard.
I'm not entirely sure if this is the fault of the gce lb or nexus but since gce is the recommended setting I wanted to at least make you guys aware of this. I don't have a working solution yet. Will update this issue when I found it.

"Fixed" it by disabling nexusProxy entirely
nexusProxy:
  enabled: false

So the problem is something related to the nexusProxy, I'll close this issue since it's not directly related to the Helm chart.


chore: Merge main into v2

Issue #, if available:
Periodic merge of main changes down into V2.
Description of changes:

Checklist

[x] Meet tenets criteria
[ ] Update tests
[ ] Update docs
[ ] PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This should not be squashed!

Codecov Report
All modified lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (v2@8586bf6). Click here to learn what that means.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@          Coverage Diff          @@
##             v2    #1477   +/-   ##
=====================================
  Coverage      ?   76.77%
  Complexity    ?      520
=====================================
  Files         ?       64
  Lines         ?     2136
  Branches      ?      223
=====================================
  Hits          ?     1640
  Misses        ?      424
  Partials      ?       72

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Chefora_Codechef_JulyLong21_Div2

C++ Code for CHEFORA Q asked in July Long (Div 2)
Link to the Q: https://www.codechef.com/JULY21B/problems/CHEFORA
Contributed under Hacktoberfest 2021.

Added the Q URL in the file.
Thank you


[doc] Add solution for module name too long caused compile failure

Please see the changes

I indeed saw this issue before. Thank you!


NIFI-11201 Add include-iotdb Maven build profile

Summary
NIFI-11201 Adds include-iotdb as an optional Maven build profile to support including the nifi-iotdb-nar with Apache IoTDB Processors in the nifi-assembly module.
Additional changes include correcting the evaluation of the Fetch Size property in QueryIoTDBRecord to handle FlowFile attributes, aligning with the Property Descriptor.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[X] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[X] Documentation formatting appears as expected in rendered files

@exceptionfactory did you intend for this to be 2.0 only?

Thanks for asking @MikeThomsen. With NiFi 1.20.0 including the new PutIoTDBRecord Processor, this would be a good candidate for backporting to the 1.x support branch.


Send to local and cloud

Hi,
how can we post to local and cloud emoncms at the same time?

hi
modify this sendToEmonCMS to take another parameter, host, and call it twice, once with the local host and one with emoncms.org
cheers


ZeroDivisionError while training

File "nmt/model_helper.py", line 444, in compute_perplexity
perplexity = utils.safe_exp(total_loss / total_predict_count)
ZeroDivisionError: integer division or modulo by zero

Hi, I solved it by modifying the code as below
if total_predict_count > 0:
    perplexity = utils.safe_exp(total_loss / total_predict_count)
  else:
    perplexity = 0

I have done the training process and the model for Inference performs really well.
But  the thing is, by doing so, we will get
eval test: perplexity 0.00

and the output_test will be empty
By the way,
there is also a ZeroDivisionError in bleu.py
and I changed likewise.

Fixed, pull request has been made


Breaks server rendering

So, I'm not really sure why, but when I try to server render this, the toggle-icon button breaks. It gives the error document is not defined.

It's actually a problem with material-ui-toggle-icon ...I sent a pr https://github.com/TeamWertarbyte/material-ui-toggle-icon/pull/4

Thanks for the fix, I'll update the toggle icon and the password field asap.

Done; I also updated the legacy version.

Niice wow, that was fast

@zwhitchcox Github integration for slack FTW!


tx history shows 0 fc cost when transfer FC into moondex

and there should not be the $ prefix

moondex is using the sendTransaction method with raw data, portal can't get the FC amount through that

tx is valid but portal can't read contract interaction detail from signed data
need to add docs to portal-docs to explain this

https://github.com/Conflux-Chain/conflux-portal-docs/pull/11