Vite dev isn't working

Describe the bug
I am trying to develop with vanilla vite on my intel macbook in Firefox. But page refuses to load only in ff.

It works in safari and on my windows 11 machine.
Both have the same npm, vite and ff versions.
Vite build works fine on mac. I tried to troubleshoot it by ff article.
Reproduction
https://stackblitz.com/edit/vitejs-vite-y3megm?file=index.html
Steps to reproduce
npm create vite@latest
cd edgeq
npm i
npm run dev
Open localhost:5173 in firefox on macos
System Info
System:
    OS: macOS 12.6.3
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Memory: 21.11 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.12.1 - /usr/local/bin/node
    npm: 8.19.2 - /usr/local/bin/npm
  Browsers:
    Firefox: 111.0.1
    Safari: 16.3
  npmPackages:
    vite: ^4.2.0 => 4.2.1

Used Package Manager
npm
Logs

Click to expand!
leon@Levs-MacBook-Pro edgeq % vite --debug
  vite:config no config file found. +0ms
  vite:esbuild init tsconfck (root: /Users/leon/PhpstormProjects/work/little-fun/edgeq) +0ms
  vite:esbuild init tsconfck (root: /Users/leon/PhpstormProjects/work/little-fun/edgeq) +2ms
  vite:esbuild init tsconfck end +4ms
  vite:esbuild init tsconfck end +0ms
  vite:config using resolved config: {
  vite:config   root: '/Users/leon/PhpstormProjects/work/little-fun/edgeq',
  vite:config   base: '/',
  vite:config   mode: 'development',
  vite:config   configFile: undefined,
  vite:config   logLevel: undefined,
  vite:config   clearScreen: undefined,
  vite:config   optimizeDeps: {
  vite:config     disabled: 'build',
  vite:config     force: undefined,
  vite:config     esbuildOptions: { preserveSymlinks: false }
  vite:config   },
  vite:config   server: {
  vite:config     preTransformRequests: true,
  vite:config     sourcemapIgnoreList: [Function (anonymous)],
  vite:config     middlewareMode: false,
  vite:config     fs: { strict: true, allow: [Array], deny: [Array] }
  vite:config   },
  vite:config   configFileDependencies: [],
  vite:config   inlineConfig: {
  vite:config     root: undefined,
  vite:config     base: undefined,
  vite:config     mode: undefined,
  vite:config     configFile: undefined,
  vite:config     logLevel: undefined,
  vite:config     clearScreen: undefined,
  vite:config     optimizeDeps: { force: undefined },
  vite:config     server: {}
  vite:config   },
  vite:config   rawBase: '/',
  vite:config   resolve: {
  vite:config     mainFields: [ 'module', 'jsnext:main', 'jsnext' ],
  vite:config     browserField: true,
  vite:config     conditions: [],
  vite:config     extensions: [
  vite:config       '.mjs',  '.js',
  vite:config       '.mts',  '.ts',
  vite:config       '.jsx',  '.tsx',
  vite:config       '.json'
  vite:config     ],
  vite:config     dedupe: [],
  vite:config     preserveSymlinks: false,
  vite:config     alias: [ [Object], [Object] ]
  vite:config   },
  vite:config   publicDir: '/Users/leon/PhpstormProjects/work/little-fun/edgeq/public',
  vite:config   cacheDir: '/Users/leon/PhpstormProjects/work/little-fun/edgeq/node_modules/.vite',
  vite:config   command: 'serve',
  vite:config   ssr: {
  vite:config     format: 'esm',
  vite:config     target: 'node',
  vite:config     optimizeDeps: { disabled: true, esbuildOptions: [Object] }
  vite:config   },
  vite:config   isWorker: false,
  vite:config   mainConfig: null,
  vite:config   isProduction: false,
  vite:config   plugins: [
  vite:config     'vite:pre-alias',
  vite:config     'alias',
  vite:config     'vite:modulepreload-polyfill',
  vite:config     'vite:optimized-deps',
  vite:config     'vite:resolve',
  vite:config     'vite:html-inline-proxy',
  vite:config     'vite:css',
  vite:config     'vite:esbuild',
  vite:config     'vite:json',
  vite:config     'vite:wasm-helper',
  vite:config     'vite:worker',
  vite:config     'vite:asset',
  vite:config     'vite:wasm-fallback',
  vite:config     'vite:define',
  vite:config     'vite:css-post',
  vite:config     'vite:worker-import-meta-url',
  vite:config     'vite:asset-import-meta-url',
  vite:config     'vite:dynamic-import-vars',
  vite:config     'vite:import-glob',
  vite:config     'vite:client-inject',
  vite:config     'vite:import-analysis'
  vite:config   ],
  vite:config   esbuild: { jsxDev: true },
  vite:config   build: {
  vite:config     target: [ 'es2020', 'edge88', 'firefox78', 'chrome87', 'safari14' ],
  vite:config     cssTarget: [ 'es2020', 'edge88', 'firefox78', 'chrome87', 'safari14' ],
  vite:config     outDir: 'dist',
  vite:config     assetsDir: 'assets',
  vite:config     assetsInlineLimit: 4096,
  vite:config     cssCodeSplit: true,
  vite:config     sourcemap: false,
  vite:config     rollupOptions: {},
  vite:config     minify: 'esbuild',
  vite:config     terserOptions: {},
  vite:config     write: true,
  vite:config     emptyOutDir: null,
  vite:config     copyPublicDir: true,
  vite:config     manifest: false,
  vite:config     lib: false,
  vite:config     ssr: false,
  vite:config     ssrManifest: false,
  vite:config     ssrEmitAssets: false,
  vite:config     reportCompressedSize: true,
  vite:config     chunkSizeWarningLimit: 500,
  vite:config     watch: null,
  vite:config     commonjsOptions: { include: [Array], extensions: [Array] },
  vite:config     dynamicImportVarsOptions: { warnOnError: true, exclude: [Array] },
  vite:config     modulePreload: { polyfill: true },
  vite:config     cssMinify: true
  vite:config   },
  vite:config   preview: {
  vite:config     port: undefined,
  vite:config     strictPort: undefined,
  vite:config     host: undefined,
  vite:config     https: undefined,
  vite:config     open: undefined,
  vite:config     proxy: undefined,
  vite:config     cors: undefined,
  vite:config     headers: undefined
  vite:config   },
  vite:config   envDir: '/Users/leon/PhpstormProjects/work/little-fun/edgeq',
  vite:config   env: { BASE_URL: '/', MODE: 'development', DEV: true, PROD: false },
  vite:config   assetsInclude: [Function: assetsInclude],
  vite:config   logger: {
  vite:config     hasWarned: false,
  vite:config     info: [Function: info],
  vite:config     warn: [Function: warn],
  vite:config     warnOnce: [Function: warnOnce],
  vite:config     error: [Function: error],
  vite:config     clearScreen: [Function: clearScreen],
  vite:config     hasErrorLogged: [Function: hasErrorLogged]
  vite:config   },
  vite:config   packageCache: Map(0) {},
  vite:config   createResolver: [Function: createResolver],
  vite:config   worker: {
  vite:config     format: 'iife',
  vite:config     plugins: [
  vite:config       'vite:pre-alias',
  vite:config       'alias',
  vite:config       'vite:modulepreload-polyfill',
  vite:config       'vite:optimized-deps',
  vite:config       'vite:resolve',
  vite:config       'vite:html-inline-proxy',
  vite:config       'vite:css',
  vite:config       'vite:esbuild',
  vite:config       'vite:json',
  vite:config       'vite:wasm-helper',
  vite:config       'vite:worker',
  vite:config       'vite:asset',
  vite:config       'vite:wasm-fallback',
  vite:config       'vite:define',
  vite:config       'vite:css-post',
  vite:config       'vite:worker-import-meta-url',
  vite:config       'vite:asset-import-meta-url',
  vite:config       'vite:dynamic-import-vars',
  vite:config       'vite:import-glob',
  vite:config       'vite:client-inject',
  vite:config       'vite:import-analysis'
  vite:config     ],
  vite:config     rollupOptions: {},
  vite:config     getSortedPlugins: [Function: getSortedPlugins],
  vite:config     getSortedPluginHooks: [Function: getSortedPluginHooks]
  vite:config   },
  vite:config   appType: 'spa',
  vite:config   experimental: { importGlobRestoreExtension: false, hmrPartialAccept: false },
  vite:config   getSortedPlugins: [Function: getSortedPlugins],
  vite:config   getSortedPluginHooks: [Function: getSortedPluginHooks]
  vite:config } +15ms
  vite:deps scanning for dependencies... +0ms

  VITE v4.2.1  ready in 351 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
  vite:deps Crawling dependencies using entries:
  vite:deps   /Users/leon/PhpstormProjects/work/little-fun/edgeq/index.html +0ms
  vite:resolve 0.76ms /src/main.ts -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/main.ts +0ms
  vite:resolve 4.06ms ./counter -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/counter.ts +8ms
  vite:deps Scan completed in 195.01ms: {} +130ms
  vite:deps no dependencies found by scanner +198ms
  vite:html-fallback Rewriting GET / to /index.html +0ms
  vite:time 39.62ms /index.html +0ms
  vite:html-fallback Rewriting GET / to /index.html +58ms
  vite:time 10.26ms /index.html +29ms
  vite:resolve 4.04ms /@vite/client -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/node_modules/vite/dist/client/client.mjs +0ms
  vite:resolve 1.53ms /src/main.ts -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/main.ts +14ms
  vite:load 8.40ms [fs] /@vite/client +0ms
  vite:load 9.28ms [fs] /src/main.ts +7ms
  vite:resolve 0.34ms ./style.css -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/style.css +73ms
  vite:resolve 0.30ms /src/style.css -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/style.css +3ms
  vite:resolve 0.34ms ./typescript.svg -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/typescript.svg +2ms
  vite:resolve 1.14ms /src/typescript.svg -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/typescript.svg +2ms
  vite:resolve 0.24ms ./counter -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/counter.ts +2ms
  vite:resolve 0.15ms /src/counter.ts -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/src/counter.ts +0ms
  vite:import-analysis 12.40ms [4 imports rewritten] src/main.ts +0ms
  vite:transform 72.90ms /src/main.ts +0ms
  vite:time 88.45ms /src/main.ts +126ms
  vite:load 0.85ms [plugin] /src/typescript.svg +92ms
  vite:load 11.13ms [plugin] /vite.svg +11ms
  vite:import-analysis 0.03ms [no imports] src/typescript.svg +30ms
  vite:transform 3.44ms /src/typescript.svg +31ms
  vite:import-analysis 0.03ms [no imports] /vite.svg +3ms
  vite:transform 3.41ms /vite.svg +1ms
  vite:resolve 1.99ms @vite/env -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/node_modules/vite/dist/client/env.mjs +46ms
  vite:resolve 0.52ms /node_modules/vite/dist/client/env.mjs -> /Users/leon/PhpstormProjects/work/little-fun/edgeq/node_modules/vite/dist/client/env.mjs +0ms
  vite:import-analysis 11.50ms [1 imports rewritten] node_modules/vite/dist/client/client.mjs +12ms
  vite:transform 99.70ms /@vite/client +13ms
  vite:time 149.58ms /@vite/client +44ms
  vite:cache [304] /vite.svg +0ms
  vite:time 0.40ms /vite.svg?import +19ms
  vite:cache [304] /src/typescript.svg +1ms
  vite:time 1.13ms /src/typescript.svg?import +2ms
  vite:load 51.15ms [fs] /src/counter.ts +39ms
  vite:load 53.03ms [fs] /src/style.css +2ms
  vite:load 33.36ms [fs] /node_modules/vite/dist/client/env.mjs +11ms
  vite:import-analysis 0.13ms [no imports] src/counter.ts +41ms
  vite:transform 17.29ms /src/counter.ts +40ms
  vite:time 27.60ms /src/counter.ts +24ms
  vite:import-analysis 0.42ms [no imports] node_modules/vite/dist/client/env.mjs +23ms
  vite:transform 11.49ms /node_modules/vite/dist/client/env.mjs +23ms
  vite:time 47.25ms /node_modules/vite/dist/client/env.mjs +19ms
  vite:hmr [self-accepts] src/style.css +0ms
  vite:import-analysis 0.44ms [0 imports rewritten] src/style.css +25ms
  vite:transform 60.60ms /src/style.css +25ms
  vite:time 84.42ms /src/style.css +25ms
  vite:time 14.78ms /vite.svg +31ms
  vite:time 13.80ms /src/typescript.svg +3ms
  vite:deps ✨ static imports crawl ended +617ms
  vite:deps ✨ no dependencies found by the scanner or crawling static imports +1ms
  vite:hmr [file change] .idea/workspace.xml +5s
  vite:hmr [no modules matched] .idea/workspace.xml +0ms

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Can not reproduce with Firefox on my mac. I doubt that this is caused by Vite, otherwise, the inability to run basic projects would lead to more problems. I see that you have installed many extensions on Firefox, try disabling them or using incognito mode to determine the cause.

try disabling them or using incognito mode to determine the cause.

I have tried to use incognito mode, no luck

So I tried to troubleshoot this again. And it works when I use vite --host instead of vite. But in both cases I use localhost:5173. So it's strange.

I am also experiencing this issue. I suspect it has something to do with the node version. If I use 16.x, I am able to run everything properly. However, when I am on 18.x, I am getting this error on Firefox.

Maybe it's related to this Node.js's behavior change.
https://vitejs.dev/config/server-options.html#:~:text=The first case,when it differs.
My guess is: Vite and chrome resolves localhost to ::1 and Firefox resolves localhost to <IP_ADDRESS>.

So the issue now can be closed, I guess


fixing Deepsource issues

This issue continues to #14
issues selected to patch:

Found explicit type declarations JS-0331 (2 lines)
Detected empty functions JS-0321 (3 lines)

@weshaan JS-0321 is in progress, please select another one.

@weshaan JS-0321 is in progress, please select another one.

okay

I closed this issue, but if you still want to do it, I can open the issue again, it is not necessary to create another one, you would only have to modify the issue and change JS-0321 for another one.

okay, can i do JS-0105(3 lines) and JS-0331(2 lines)?

of source


Don't parse markdown in /command

Right now I have to type /join #\_oftc\_#room:matrix.org , for example, in order for it to work.

the parsed string is only used for the /me command
I tested /join #oftc#room:matrix.org : it seems working on my side.

Fixed for me since switching to the develop build.


Charge based on days of the month left

Hello,
I am currently implementing Mollie in my application but I was wondering if there is a way to only charge per remaining days of the month. For example, the subscription price is 10 euros per month. On the 15th of the month you increase the quantity of your subscription. You only should pay 15 euros that month (1 full price and 1 for only the remaining ~15 days).
I found that you can increase the quantity of the subscription but not a way to implement this. Any tips or advice for me?

Hi,
This package applies prorating automatically so no need to implement this on your own 👊 😃.


feat(plugin): support plugin rules

Closes #14
@kentcdodds @ta2edchimp  please share your thoughts.

Current coverage is 100.00%

Merging #18 into master will not affect coverage as of b066f85

@@            master     #18   diff @@
======================================
  Files            2       2
  Stmts           36      48    +12
  Branches         0       0
  Methods          0       0
======================================
+ Hit             36      48    +12
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of b066f85

Powered by Codecov. Updated on successful CI builds.

Looks good to me!
But could we get rid of calling getConfigFile and getConfig twice within bin.js? I know that would not do too much overhead in reality, but essentially, the whole process of compiling the config would have to be done twice.

Absolutely, I was not sure about the pattern, should I cache them in a local variable?

Yeah, I would simply cache it as something like currentConfigFile/ currentConfig above the declarations of currentRules, pluginRules, etc. if there's nothing to be said against it.

Can we mock the plugin used in the test using an appropriate proxyquire stub? That would void the requirement to include the whole plugin as a real (dev) dependency (that is something we also should consider for test/bin.js, instead of mocking the result of findNewRules/./index.js).

Could you point me to an example/usage of stubing an absent module?
I tried
proxyquire('eslint-plugin-react', {
    rules: {
        'react/display-name': 2,
        'react/jsx-no-duplicate-props': 2,
      }
});

But it does not work
Error: Cannot find module 'eslint-plugin-react'
    at Function.Module._resolveFilename (module.js:339:15)
    at Proxyquire._disableModuleCache (/Users/sabandyo/GitHub/eslint-find-new-rules/node_modules/proxyquire/lib/proxyquire.js:215:19)

I'd have to look it up more thoroughly myself, but I fear this would only work when we'd extract the whole getConfig/Rules logic into a separate file, requiring it afterwards using proxyquire and using the stub similarly to how we use it in ./test/bin.js to mock ./index.js return value of new rules.
Let's postpone this one issue.

const stub = {
  './index': () => rules,
  'eslint-plugin-react': {
    rules: {
      'react/display-name': 2,
      'react/jsx-no-duplicate-props': 2
    }
  }
}

proxyquire('../bin', stub)

failed with "Failed to load plugin react: Cannot find module 'eslint-plugin-react'"
      Proxyquire._require (/Users/sabandyo/GitHub/eslint-find-new-rules/node_modules/proxyquire/lib/proxyquire.js:164:19)

It's quite late now 3:46 AM, I would try to solve it tomorrow in fresh mind. :smile:

No problem, I'll be out for lunch for a couple of hours ...
When it's finished, it'll be great! :+1:

The stub for eslint-plugin-rule should look as follows:
'eslint-plugin-react': {
    rules: {
      'react/display-name': 2,
      'react/jsx-no-duplicate-props': 2
    },
    '@noCallThru': true,
    '@global': true
  }

@noCallThru has to be set to true or else proxyquire will look for the actual module on the filesystem (to possibly fill in missing methods in the stub) — so this is mandatory for required modules, that do not exist at all on the filesystem.
@global has to be set to true, because the module shall not only be proxied within our bin.js but also when being required from within ESLint.
There are also issues within your code, please see here.

Well... I got hyperactive and made a Pull Request to your fork's branch requested to be pulled here.
Branch coverage drops to 91.67% though.

I still see a general issue with the tests in test/bin.js though! But that discussion may be out of scope here.

We should move as much logic as possible out of bin and put all the untestable stuff (very little) in bin.

I'm with you on this, that way we would have detected the issue I tried to describe in #19 earlier and we could more thoroughly test each part of the functionality.

I would suggest we close this PR, refactor bin.js first.

Why not just merging the PR I made to your fork (the wanted functionality is given) and we then extract these functions into a separate file (for example ./rules.js)?

We should move as much logic as possible out of bin and put all the untestable stuff (very little) in bin.

@kentcdodds could you take a look?

Cool. I was thinking that we could even more easily just test bin-utils and not worry about testing bin which would simplify things I think. Or even test bin but minimally because it has only two code paths. This would make adding to the bin-utils easier as testing that should be simpler I think.

I was thinking that we could even more easily just test bin-utils

I planned on changing the testing either way (see #19) tonight or tomorrow at latest (if no one else does this before me).
If you guys are ok with it, we could just merge this in and I'd rewrite the testing?

Sounds great

Thanks guys for following up on the PR, have been busy since the last commit, with gardening and spring decoration.

I was thinking that we could even more easily just test bin-utils and not worry about testing bin

I could see @ta2edchimp has already raised #20 to tackle the tests. :+1:
Welcome Spring :bouquet:


Creating aws vpc in different regions based on region input variable doesn't work as expected

I'm trying to create an aws vpc using this module - and I need it to be created in different region depending on input variable.
Here is what I got in main.tf file:
provider "aws" {
region  = var.region
}
data "aws_availability_zones" "available" {   - to retrieve availability zone names based on specified region
}
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
name = local.workspace["vpc_name"]
cidr = local.workspace["vpc_cidr"]
azs             = local.workspace["vpc_azs"]
private_subnets = local.workspace["vpc_private_subnets"]
public_subnets  = local.workspace["vpc_public_subnets"]
...
}
Here is what I have in backend.tf file:
terraform {
 backend "s3" {
  bucket         = "bucket-name"
 profile        = "profile-name"
dynamodb_table = "tf-state-lock-dyndb"
region         = "us-west-2"
 key            = "key-prefix/terraform.tfstate"
 }
}
And here is what I have in variables.tf:
variable "region" {}
...
locals {
env = {
default = {}
...
app-dev = {
env_name                     = "dev"
vpc_name                     = "app-vpc-dev"
vpc_cidr                        = "<IP_ADDRESS>/16"
vpc_azs                        = data.aws_availability_zones.available.names
vpc_private_subnets    = ["<IP_ADDRESS>/24", "<IP_ADDRESS>/24"]
vpc_public_subnets      = ["<IP_ADDRESS>/24", "<IP_ADDRESS>/24"]
}
app-prod = {
env_name                     = "prod"
vpc_name                     = "app-vpc-prod"
vpc_cidr                        = "<IP_ADDRESS>/16"
vpc_azs                        = data.aws_availability_zones.available.names
vpc_private_subnets    = ["<IP_ADDRESS>/24", "<IP_ADDRESS>/24"]
vpc_public_subnets      = ["<IP_ADDRESS>/24", "<IP_ADDRESS>/24"]
}
...
}
environmentvars = contains(keys(local.env), terraform.workspace) ? terraform.workspace : "default"
workspace       = merge(local.env["default"], local.env[local.environmentvars])
}
`
And then I want to apply it with different variable,like:
terraform apply -var="region=us-west-2"
or
terraform apply -var="region=eu-west-2"
And it should create vpc in different region. But it doesn't work - it adds resources in one region and when adding to another one, tries to replace route tables instead of creating new one.
Plan: 24 to add, 0 to change, 4 to destroy.
module.vpc.aws_route_table_association.private[0] must be replaced
-/+ resource "aws_route_table_association" "private" {
~ id             = "rtbassoc-035aef7e37dad1ac1" -> (known after apply)
~ route_table_id = "rtb-026bfeee8c7e042a6" -> (known after apply)
~ subnet_id      = "subnet-070f46911b6ac5d20" -> (known after apply) # forces replacement
}
module.vpc.aws_route_table_association.private[1] must be replaced
-/+ resource "aws_route_table_association" "private" {
~ id             = "rtbassoc-079f04e405eca2ed3" -> (known after apply)
~ route_table_id = "rtb-0aabe71401689c1be" -> (known after apply)
~ subnet_id      = "subnet-03fe27c23fd3178f3" -> (known after apply) # forces replacement
}
module.vpc.aws_route_table_association.public[0] must be replaced
-/+ resource "aws_route_table_association" "public" {
~ id             = "rtbassoc-02af1c10bea83bdd2" -> (known after apply)
~ route_table_id = "rtb-000cfffca8956073c" -> (known after apply)
~ subnet_id      = "subnet-0951342807d06a0f3" -> (known after apply) # forces replacement
}
module.vpc.aws_route_table_association.public[1] must be replaced
-/+ resource "aws_route_table_association" "public" {
~ id             = "rtbassoc-051ff11315ef42d31" -> (known after apply)
~ route_table_id = "rtb-000cfffca8956073c" -> (known after apply)
~ subnet_id      = "subnet-0da8a20c3f25fcc44" -> (known after apply) # forces replacement
}
So, not sure, it looks like a bug but maybe I'm doing something wrong here...

Didn't realized I need different workspaces for different regions to save state, closing.


Slide attribute "frontmatter" is always "[object Object]"

Describe the bug
Each div.slidev-layout has an attribute frontmatter that's always [object Object]
Minimal reproduction
Steps to reproduce the behavior:

npm init slidev@latest
Fill out the necessary things to create and start the project
Check HTML

Environment

Slidev version: 0.49.23
Browser: any
OS: Debian 12

Thank you for mentioning this. This is because currently, we can't find a way to detect whether the layout component receives a frontmatter property. As a workaround, all frontmatters excluding the known ones and frontmatter for the frontmatter object are passed to props. If the layout component doesn't have the corresponding props, these "extra" props will become DOM attributes.

That's how Vue works - do you have any runtime problems because of that? Otherwise I'd say just ignore it, it doesn't matter after all

It doesn't cause me any runtime problems.
So far, it's smooth sailing and the best and easiest-to-use slide tool for my purposes!
Just noticed the [object Object], and without any Vue knowledge, it looked like an oversight/possible issue.
However, I somehow missed the referenced issue/PR, even though I searched before creating this one...
Thank you for explaining it to me, as I didn't get far looking at constants.ts and InjectionKey myself.


Revert "Add attribute label to the UI"

Reverts AY2122S2-CS2103-F10-1/tp#89

Codecov Report

Merging #92 (aa1d908) into master (2fca478) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master      #92      +/-   ##
============================================
- Coverage     76.87%   76.86%   -0.02%
+ Complexity      628      627       -1
============================================
  Files            97       97
  Lines          1812     1811       -1
  Branches        191      191
============================================
- Hits           1393     1392       -1
  Misses          362      362
  Partials         57       57

Impacted Files
Coverage Δ

src/main/java/seedu/address/model/lab/LabList.java
95.16% <ø> (-0.08%)
:arrow_down:

src/main/java/seedu/address/ui/StudentCard.java
0.00% <0.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


artifact download (and shasum) only search for finished uploads.

The Artifact Search API endpoint supports filtering the search to finished artifacts, so that incomplete uploads are not included.
buildkite-agent artifact download and buildkite-agent artifact shasum probably want to apply that filter, otherwise they're likely to get stuck trying to download artifacts that don't exist.

[x] more testing and/or local validation.
[ ] sanity-check the decision to not attempt downloading unfinished artifacts.

Given this command:
buildkite-agent artifact download --debug hello.txt .

Before this PR, for an artifact in new state (not finished), it was downloaded:
(in this case the download was successful because I reverted an uploaded artifact back to new state)
2022-03-18 11:35:32 INFO   Searching for artifacts: "hello.txt"
2022-03-18 11:35:32 DEBUG  GET http://agent.buildkite.localhost/v3/builds/8faced79-94fc-4e61-bc99-49162bf0b275/artifacts/search?query=hello.txt
2022-03-18 11:35:32 DEBUG  ↳ GET http://agent.buildkite.localhost/v3/builds/8faced79-94fc-4e61-bc99-49162bf0b275/artifacts/search?query=hello.txt proto=HTTP/1.1 status=200 Δ=61.300692ms
2022-03-18 11:35:32 INFO   Found 1 artifacts. Starting to download to: /redacted/local/dir
2022-03-18 11:35:32 DEBUG  Downloading http://redacted/hello.txt?redacted to /redacted/local/dir/hello.txt
2022-03-18 11:35:32 INFO   Successfully downloaded "hello.txt" 6 bytes

After this PR for that same new (unfinished) artifact:
Note the /artifacts/search?query=hello.txt&state=finished API call now passes state parameter.
And the unfinished artifact is not found.
2022-03-18 11:35:28 INFO   Searching for artifacts: "hello.txt"
2022-03-18 11:35:28 DEBUG  GET http://agent.buildkite.localhost/v3/builds/8faced79-94fc-4e61-bc99-49162bf0b275/artifacts/search?query=hello.txt&state=finished
2022-03-18 11:35:28 DEBUG  ↳ GET http://agent.buildkite.localhost/v3/builds/8faced79-94fc-4e61-bc99-49162bf0b275/artifacts/search?query=hello.txt&state=finished proto=HTTP/1.1 status=200 Δ=88.67795ms
2022-03-18 11:35:28 FATAL  Failed to download artifacts: No artifacts found for downloading

After this PR, once the artifact is finished, just to make sure it still works:
Note the state=finished is still in the API call.
And again, the download succeeds because this was a successful upload that I reverted to new state.
2022-03-18 11:38:56 INFO   Searching for artifacts: "hello.txt"
2022-03-18 11:38:56 DEBUG  GET http://agent.buildkite.localhost/v3/builds/8faced79-94fc-4e61-bc99-49162bf0b275/artifacts/search?query=hello.txt&state=finished
2022-03-18 11:38:56 DEBUG  ↳ GET http://agent.buildkite.localhost/v3/builds/8faced79-94fc-4e61-bc99-49162bf0b275/artifacts/search?query=hello.txt&state=finished proto=HTTP/1.1 status=200 Δ=66.417817ms
2022-03-18 11:38:56 INFO   Found 1 artifacts. Starting to download to: /Users/pda/bk/test-repo
2022-03-18 11:38:56 DEBUG  Downloading http://redacted/hello.txt?redacted to /Users/pda/bk/test-repo/hello.txt
2022-03-18 11:38:56 INFO   Successfully downloaded "hello.txt" 6 bytes

Also a quick buildkite-agent artifact shasum test, because this PR also changes that to only look at finished uploads:
For an unfinished artifact:
pda@paulbookpro ~/bk/test-repo $ ~/bk/agent/buildkite-agent artifact shasum hello.txt
2022-03-18 11:44:08 INFO   Searching for artifacts: "hello.txt"
2022-03-18 11:44:08 FATAL  No artifacts found for downloading

For a finished artifact:
pda@paulbookpro ~/bk/test-repo $ ~/bk/agent/buildkite-agent artifact shasum hello.txt
2022-03-18 11:43:58 INFO   Searching for artifacts: "hello.txt"
f572d396fae9206628714fb2ce00f72e94f2258f

Here's a previous report that @pzeballos pointed out which validates that this change should be good: https://github.com/buildkite/agent/issues/1511

Related:

#1728


Cannot determine for which compute capability the code was compiled

On the cluster in Bielefeld I get this warning:
# [2022-04-14 23:41:01] WARN: Cannot determine for which compute capability the code was compiled!
Has the way we've been checking become deprecated somehow?

This is caused by
#ifdef ARCHITECTURE
    if (static_cast<int>(ARCHITECTURE) != gpu_arch) {
        throw std::runtime_error(stdLogger.fatal("You compiled for ARCHITECTURE=", ARCHITECTURE,
                    " but the GPUs here are ", gpu_arch));
    }
#else
    rootLogger.warn("Cannot determine for which compute capability the code was compiled!");
#endif

in the communication base

It's because ARCHITECTURE is not set properly in CMakelist.txt. I will fix that.


Nqueen implementation in Java and explanation the code

Isuue #169 : Java code is added with explanation.


Error on interactive generation

Describe the bug
Setting "text-gen-type": "interactive" results in an IndexError: : shape mismatch: indexing tensors could not be broadcast together with shapes [4], [3]. Other generation types work.
To Reproduce
Steps to reproduce the behavior:

Install, adapt 20B to local environment, add "text-gen-type": "interactive" config
Run inference
Enter arbitrary prompt when requested
See error

Expected behavior
Should work like non-interactive mode.
Environment (please complete the following information):

GPUs: 4xV100
Configs: 20B + "pipe-parallel-size": 1 + "text-gen-type": "interactive"

Additional context
Using ppc64le, so some libraries are not exactly as pinned. Please ignore the issue if it does not occur on more common platforms.

Thank you for the bug report. Can you check that this wasn’t inadvertently caused by #539?

Indeed, in 2189a4f6724770d3087a3a19b75f25bfb73b9a06 interactive text generation works (but then hits the UnboundLocalError: local variable 'generated_text' referenced before assignment)

Uhm no, I'm misunderstanding something. In both versions interactive seems to only work with 3-words prompts.

Traceback (most recent call last):
  File "generate.py", line 88, in <module>
    main()
  File "generate.py", line 71, in main
    generate_samples_interactive(
  File "/workspace/gpt-neox/megatron/text_generation_utils.py", line 745, in generate_samples_interactive
    for (
  File "/workspace/gpt-neox/megatron/text_generation_utils.py", line 311, in stream_tokens
    logits = forward_model(model, model_inputs, neox_args.is_pipe_parallel)
  File "/workspace/gpt-neox/megatron/text_generation_utils.py", line 155, in forward_model
    loss, logits = model.eval_batch(model_inputs, return_logits=True)
  File "/opt/conda/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 394, in eval_batch
    self._exec_schedule(sched)
  File "/opt/conda/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 1308, in _exec_schedule
    self._exec_instr(**cmd.kwargs)
  File "/opt/conda/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 700, in _exec_forward_pass
    self.loss = self.loss_model(outputs, labels)
  File "/workspace/gpt-neox/megatron/model/gpt2_model.py", line 67, in cross_entropy
    losses = mpu.vocab_parallel_cross_entropy(output.float().contiguous(), labels)
  File "/workspace/gpt-neox/megatron/mpu/cross_entropy.py", line 114, in vocab_parallel_cross_entropy
    return _VocabParallelCrossEntropy.apply(vocab_parallel_logits, target)
  File "/workspace/gpt-neox/megatron/mpu/cross_entropy.py", line 60, in forward
    predicted_logits_1d = logits_2d[arange_1d, masked_target_1d]
IndexError: shape mismatch: indexing tensors could not be broadcast together with shapes [27], [3]
Traceback (most recent call last):
  File "generate.py", line 88, in <module>
    main()
  File "generate.py", line 71, in main
    generate_samples_interactive(
  File "/workspace/gpt-neox/megatron/text_generation_utils.py", line 745, in generate_samples_interactive
    for (
  File "/workspace/gpt-neox/megatron/text_generation_utils.py", line 311, in stream_tokens
    logits = forward_model(model, model_inputs, neox_args.is_pipe_parallel)
  File "/workspace/gpt-neox/megatron/text_generation_utils.py", line 155, in forward_model
    loss, logits = model.eval_batch(model_inputs, return_logits=True)
  File "/opt/conda/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 394, in eval_batch
    self._exec_schedule(sched)
  File "/opt/conda/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 1308, in _exec_schedule
    self._exec_instr(**cmd.kwargs)
  File "/opt/conda/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 700, in _exec_forward_pass
    self.loss = self.loss_model(outputs, labels)
  File "/workspace/gpt-neox/megatron/model/gpt2_model.py", line 67, in cross_entropy
    losses = mpu.vocab_parallel_cross_entropy(output.float().contiguous(), labels)
  File "/workspace/gpt-neox/megatron/mpu/cross_entropy.py", line 114, in vocab_parallel_cross_entropy
    return _VocabParallelCrossEntropy.apply(vocab_parallel_logits, target)
  File "/workspace/gpt-neox/megatron/mpu/cross_entropy.py", line 60, in forward
    predicted_logits_1d = logits_2d[arange_1d, masked_target_1d]
IndexError: shape mismatch: indexing tensors could not be broadcast together with shapes [27], [3]

Newbie alert ! - A quick test input-file & interactive run across 8 GPU's :
cross_entropy.py Line 60:
    print ("DEBUG ",arange_1d, masked_target_1d)

    predicted_logits_1d = logits_2d[arange_1d, masked_target_1d]

For   "text-gen-type": "input-file",
DEBUG  tensor([0, 1, 2, 3, 4, 5, 6, 7, 8], device='cuda:6') tensor([   58, 46434,     0], device='cuda:6')
DEBUG  tensor([0, 1, 2, 3, 4, 5, 6, 7, 8], device='cuda:7') tensor([0, 0, 0], device='cuda:7')
For   "text-gen-type": "interactive",
DEBUG  DEBUG  tensor([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16, 17,
    18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,

    36, 37, 38], device='cuda:6') tensor([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16, 17,

    18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,

    36, 37, 38], device='cuda:7') tensor([  513,   417,  1158,   368,   476,  1014,  3812,   253,  1386,   670,

     3347, 47301,    13,  2167,   253,  5301,   310,  4931,   247,  1652,

     2372, 16593,   984,   247,  3347,  3024,  3542,   407,   247,  5145,

      588,   320,  1805, 14109,   407,  1529,  5145,    15,     0],

   device='cuda:6')

tensor([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], device='cuda:7')

DEBUG  DEBUG  tensor([0], device='cuda:7') tensor([0], device='cuda:7')
tensor([0], device='cuda:6') tensor([0], device='cuda:6')
DEBUG  tensor([0], device='cuda:7') DEBUG  tensor([0], device='cuda:7')
tensor([0], device='cuda:6') tensor([0], device='cuda:6')
DEBUG  DEBUG  tensor([0], device='cuda:7') tensor([0], device='cuda:7')
tensor([0], device='cuda:6') tensor([0], device='cuda:6')
DEBUG  DEBUG  tensor([0], device='cuda:7') tensor([0], device='cuda:7')
tensor([0], device='cuda:6') tensor([0], device='cuda:6')
DEBUG  tensor([0], device='cuda:7') DEBUG  tensor([0], device='cuda:7')
tensor([0], device='cuda:6') tensor([0], device='cuda:6')
DEBUG  DEBUG  tensor([0], device='cuda:6') tensor([0], device='cuda:7') tensor([0], device='cuda:6')
I don't understand enough about how this has been written but is it something to do with the large number of Tensor elements in the interactive mode - caused perhaps by the code not properly dimensioning the tensor array with the interactive input ?

With that line added on my end...
DEBUG  tensor([0, 1], device='cuda:3') tensor([0, 0, 0], device='cuda:3')
DEBUG  tensor([0, 1], device='cuda:2') tensor([   58, 46434,     0], device='cuda:2')

These tensors don't look dimensioned properly to me for smaller inputs as well, looks like we might have the root cause outlined.

See #604 for the greater prototyping effort underway to ensure that all processes have the correct context_length and context_tokens.

This is resolved

I'm observing behavior similar to this issue. Whenever I enter an interactive input longer than three tokens I receive an error like this.
Context prompt >>> Are humans born with virtue?
Traceback (most recent call last):
  File "generate.py", line 88, in <module>
    main()
  File "generate.py", line 71, in main
    generate_samples_interactive(
  File "/home/mchorse/gpt-neox/megatron/text_generation_utils.py", line 746, in generate_samples_interactive
    for (
  File "/home/mchorse/gpt-neox/megatron/text_generation_utils.py", line 312, in stream_tokens
    logits = forward_model(model, model_inputs, neox_args.is_pipe_parallel)
  File "/home/mchorse/gpt-neox/megatron/text_generation_utils.py", line 155, in forward_model
    loss, logits = model.eval_batch(model_inputs, return_logits=True)
  File "/home/mchorse/anaconda3/envs/kyle1668/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 394, in eval_batch
    self._exec_schedule(sched)
  File "/home/mchorse/anaconda3/envs/kyle1668/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 1308, in _exec_schedule
    self._exec_instr(**cmd.kwargs)
  File "/home/mchorse/anaconda3/envs/kyle1668/lib/python3.8/site-packages/deepspeed/runtime/pipe/engine.py", line 700, in _exec_forward_pass
    self.loss = self.loss_model(outputs, labels)
  File "/home/mchorse/gpt-neox/megatron/model/gpt2_model.py", line 67, in cross_entropy
    losses = mpu.vocab_parallel_cross_entropy(output.float().contiguous(), labels)
  File "/home/mchorse/gpt-neox/megatron/mpu/cross_entropy.py", line 114, in vocab_parallel_cross_entropy
    return _VocabParallelCrossEntropy.apply(vocab_parallel_logits, target)
  File "/home/mchorse/gpt-neox/megatron/mpu/cross_entropy.py", line 60, in forward
    predicted_logits_1d = logits_2d[arange_1d, masked_target_1d]
IndexError: shape mismatch: indexing tensors could not be broadcast together with shapes [6], [3]

I don't receive any errors when the length of the input does not exceed three tokens.
Context prompt Is virtue innate
Generated Text: ?
Generated Text: ? Can
Generated Text: ? Can '
Generated Text: ? Can 'nob
Generated Text: ? Can 'noble
Generated Text: ? Can 'noble sentiment
Generated Text: ? Can 'noble sentiment,'
Generated Text: ? Can 'noble sentiment,' '
Generated Text: ? Can 'noble sentiment,' 'just
Generated Text: ? Can 'noble sentiment,' 'just pride
Generated Text: ? Can 'noble sentiment,' 'just pride'
Generated Text: ? Can 'noble sentiment,' 'just pride' be
Generated Text: ? Can 'noble sentiment,' 'just pride' be fost
Generated Text: ? Can 'noble sentiment,' 'just pride' be fostered
Generated Text: ? Can 'noble sentiment,' 'just pride' be fostered in
Generated Text: ? Can 'noble sentiment,' 'just pride' be fostered in every
...
Generated Text: ? Can 'noble sentiment,' 'just pride' be fostered in every human being by wholesome influences, moral laws, sound education, the workings of love? Miss Edgeworth says, no; that society is 'inert, boys mischievous, parents fanatical, children hopeless'; that much remains to be done, 'if admiration and emulation be to be our next goal in heaven; our saints and philosophers, our poets and warriors, are there, perhaps, only a preparation

Environment

8x NVIDIA A40
Ubuntu 20.04

I think I'm also experiencing this. Any interactive prompt larger than 3 words has issues.


python2.7 and python3 working hand in hand

So...
Quite recently I've started moving from python2.7 env to a python3.6. We've re-written the code, everything was working properly and the only thing to do is to put the project on prod and battle-test it.
So I spawned a server, deployed the upgraded app, connected everything to production db and production redis server. And everything seemed to work properly. But there was a problem. There was quite a lot of 502 errors from channels connector. A lot of reconnects. From what I saw, about 25% of websocket connections to that server was failing (I based it on my own experiences, but nginx logs pretty much confirmed it). There was unnaturally more errors on python3 server then on python2.7 server.
When I did manual testing - it turned out, that I had those errors when I refreshed the web page. So basically - I was having trouble establishing the initial connection. I didn't found any problems with websockets when that connection has been established.
So at first I checked the code - but I actually didn't change anything for websocket-serving part. Well, I did have some code for reformatting byte stream into a unicode, but nothing more.
I checked the behavior of daphne and runworker - it seemed to me, that daphne received messages for my requests, but workers didn't receive it at all. I even tried running those commands in debug manually. This shown to me, that runworker command didn't receive connect/disconnect messages sometimes.
This seemed weird to me, as I couldn't replicate that situation in my local environment. I had always 100% success rate in python3 env for connecting.
So today, I've tried spawning another local server, with python2.7 environment and connecting it to my redis db, which I use in python3.6 environment. And to my astonishment - the sheer fact that I connected to redis with python2.7 env (without any traffic), broke python3.6 connection flow.
When I disconnect (disable both daphne and webworkers on python2.7 env) - I'm not having problems connecting to my python3.6 instance.
But as soon as the connection is made from python2.7 servers - it seems to break everything for python3.6 servers.
In the same time - python2.7 servers seem to be unaffected at all.
Has anyone encountered such problems before? I'm actually not sure where the problem is - is it in asgi_redis layer, or somewhere else. Just opening an issue to ask around and let the community know that there might be problems with connecting python2.7 and python3.6 apps in one redis instance.
asgi_redis version I'm using: 1.4.2
Let me know if you need anything else.

OK - I've just checked - I can leave daphne running on python2.7 server, the problem seems to occur when workers are started.

I'm not aware of any potential for incompatibility between different Python versions - they only exchange JSON, after all. I'll leave this open in case more evidence comes to light, but it'll probably get closed once we jump asgi_redis up to version 2.0 and Python 3 only.

Yep, I'm OK with that.
Actually - I'm not very acquainted with docker, but I will try to replicate the whole thing in a smaller environment with some sample code. This way I'll make sure that the problem is not related to my app.
I'm actually not even sure if the potential problem is in asgi_redis, or in some other lib...

Oh yeah - and btw. The problem is not with sent messages.
It seems to be in the connection layer itself.
I currently have:

First vagrant box with redis and my app in python3.6
Second vagrant box with my app in python2.7

That python2.7 vagrant box is connecting to redis located in python3.6 vagrant box. I only reach python3.6 vagrant box with my browser. When I disable runworker command on python2.7 box, I don't have any problems with connecting to python3.6 box websockets. Problem starts, when I enable runworker on python2.7 box. At that moment, some of my connection attempts with python3.6 box end in 502 errors. As soon as I disable the runworker once again - everything works perfectly.

OK, so I just managed to replicate the problem working on your repo, @andrewgodwin:
https://github.com/ajakubo1/channels-examples

what I did here is - I only opened redis ports in docker, so that I can access it from my local machine.
I tried out databinding app, ran all of the commands to setup docker box (added some sliders), and I made sure everything worked properly according to your scenario (so - a couple of browsers open, slide the slider) - I didn't noticed any problems at all
(again - not a docker guy - sorry :D) - from my local machine (which is ubuntu 16.04), I've created 2 virtualenvs: gremlin - with python2.7 installed, and gremlin-3 with python3.5 installed.
I installed requirements from databinding requirements files for both gremlin and gremlin-3
Just to make sure everything is working for python3.5, I've used sourced gremlin-3, and ran:

python manage.py runserver 8001
from databinding folder.
Remember - I still have that docker image running, so I can access original app on port 8000, and also connect to redis server which is used there. Plus - I'm serving the data from sqlite file.

Accessed 8001 port with a couple of tabs, move the sliders around, made sure everything is working properly, refreshed the page on port 8000 to make sure I can connect to websocket all the time
Canceled that 8001 port instance
Sourced gremlin and ran the server in exactly the same manner as I did with gremlin-3:

python manage.py runserver 8001

Accessed 8001 port with a couple of tabs, move the sliders around, made sure everything is working properly for both 8000 and 8001 instances
Tried refreshing a couple of times... And... This happened:

Connection failed. That's actually the original problem I had - I just reconfigured WebsocketBridge in my application so it wouldn't cancel the connection on it's own, but I increased the timeout values (this then triggered 502 errors for me).
On firefox:

Just like my symptoms - about 20-25% of connections have to be re-established.

OK, so in that case it's just general layer failure, like https://github.com/django/asgi_redis/issues/62 but maybe different. I'll try and look at it soon but I don't have a lot of spare time at the moment.

Closing as we've entirely rewritten the layer to be asyncio-based and get rid of most connection failures.


Export * and export default

I get the error Multiple default exports when trying to export everything from another file including the default export e.g.
export * from './foo';
export { default as default } from './foo';

It looks like that this case should throw an error (as shown by this test case) however babel compiles the code export * from './foo'; to:
Object.keys(_foo).forEach(function (key) {
  if (key === "default") return;
  Object.defineProperty(exports, key, {
    enumerable: true,
    get: function get() {
      return _foo[key];
    }
  });
});

Reference
so the second export is necessary to ensure the default export also gets exported.
Any suggestions? I'm not sure whether it's actually babel which is at fault here or if the assumption in this plugin is wrong. Happy to contribute a PR if a solution is agreed on.

Interesting. I think the spec dictates that imported/exported namespaces include the default name; it's not distinct from other exported names, it just has special extra syntax for exporting/importing.
So I would argue to start that Babel is doing it wrong (maybe in the interest of backwards-compatibility?).

@jkimbo Are you running ESLint on the transpiled code? If you do, that could explain the error, but I don't see why you would do that.

@jfmengels: if ./foo contains a default export, it should report Multiple default exports on both lines.
@jkimbo: http://www.ecma-international.org/ecma-262/6.0/#sec-getexportednames, 7.d.i. seems to be filtering default exports from export * from ... statements. As such, looks like this plugin is in error and Babel has it right.

Thanks for digging into it @benmosher ! I can attempt a PR to fix it (though not until tomorrow) if that would help?

@jkimbo Yes please, that'd be great :)

You're welcome to take a stab at it, but I think it goes pretty deep into the exported namespace tracking so it may get dicey. You may want to fail fast.


[production] Users with inconsistent date_confirmed and date_last_login fields

Expected
All users who have logged in have a non-null value of date_confirmed
Observed
In production, 18 users have non-null values of date_last_login but null values of date_confirmed. Based on a user report to @mckidwell, these users can't reset their passwords (but I verified manually that it's still possible to log in).
To find users with inconsistent data, run:
User.find(Q('date_confirmed', 'eq', None) & Q('date_last_login', 'ne', None))

To fix, we would need to manually set the date_confirmed fields of the affected users. All affected users created their accounts in September or October of 2014, so this likely reflects a bug that's since been fixed, although I'm not sure what it might have been.

Based on discussion with @sloria, this reflects a bug in user claiming that was fixed in November 2014, and will require a simple migration to fix: affected users should have their date_last_login fields copied to date_confirmed and is_registered set to True.

@mfraezz is currently working on the migration script for this.

@sloria .... this can be closed, yes?

The fix has been merged in.


feat: Jensen's inequality for the entropy

From PFR

Each of those seems to be a straightforward combination of two lemmas; I wonder if we need them. (No strong opinion.)

I managed to remove all uses from PFR, so no 😄


Failed build due protoc version

Describe the bug
I tried to wwrite PKGBUILD for the Arch Linux distribution. But I faced with some problems.
Seems current version of the protobuf library not compatible with fancon sources.
Build log:
-- The CXX compiler identification is Clang 10.0.0
-- Check for working CXX compiler: /usr/lib/ccache/bin/clang++
-- Check for working CXX compiler: /usr/lib/ccache/bin/clang++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found Boost: /usr/lib64/cmake/Boost-1.72.0/BoostConfig.cmake (found version "1.72.0") found components: log thread system filesystem
-- Found Sensors: /usr/include/sensors
-- Found Protobuf: /usr/lib/libprotobuf.so;-lpthread (found version "3.11.4")
-- Found GRPC: /usr/lib/libgrpc.so
-- Configuring done
-- Generating done
-- Build files have been written to: /var/cache/build/src/fancon/build
Scanning dependencies of target fancon
[  5%] Building CXX object CMakeFiles/fancon.dir/src/main.cpp.o
In file included from /var/cache/build/src/fancon/src/main.cpp:1:
In file included from /var/cache/build/src/fancon/src/main.hpp:23:
In file included from /var/cache/build/src/fancon/src/Controller.hpp:13:
In file included from /var/cache/build/src/fancon/src/Devices.hpp:6:
In file included from /var/cache/build/src/fancon/src/FanDell.hpp:4:
In file included from /var/cache/build/src/fancon/src/DellSMM.hpp:6:
In file included from /var/cache/build/src/fancon/src/FanInterface.hpp:7:
In file included from /var/cache/build/src/fancon/src/SensorInterface.hpp:8:
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:25:2: error: This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
 ^
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:26:2: error: incompatible with your Protocol Buffer headers.  Please
#error incompatible with your Protocol Buffer headers.  Please
 ^
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:27:2: error: regenerate this file with a newer version of protoc.
#error regenerate this file with a newer version of protoc.
 ^
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:215:56: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedInputStream *input) final;
                                                       ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:217:64: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedOutputStream *output) const final;
                                                               ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:219:68: error: only virtual member functions can be marked 'final'
      bool deterministic, ::google::protobuf::uint8 *target) const final;
                                                                   ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:336:56: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedInputStream *input) final;
                                                       ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:338:64: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedOutputStream *output) const final;
                                                               ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:340:68: error: only virtual member functions can be marked 'final'
      bool deterministic, ::google::protobuf::uint8 *target) const final;
                                                                   ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:459:56: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedInputStream *input) final;
                                                       ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:461:64: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedOutputStream *output) const final;
                                                               ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:463:68: error: only virtual member functions can be marked 'final'
      bool deterministic, ::google::protobuf::uint8 *target) const final;
                                                                   ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:567:56: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedInputStream *input) final;
                                                       ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:569:64: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedOutputStream *output) const final;
                                                               ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:571:68: error: only virtual member functions can be marked 'final'
      bool deterministic, ::google::protobuf::uint8 *target) const final;
                                                                   ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:800:56: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedInputStream *input) final;
                                                       ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:802:64: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedOutputStream *output) const final;
                                                               ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:804:68: error: only virtual member functions can be marked 'final'
      bool deterministic, ::google::protobuf::uint8 *target) const final;
                                                                   ^~~~~
/var/cache/build/src/fancon/src/proto/DevicesSpec.pb.h:1010:56: error: only virtual member functions can be marked 'final'
      ::google::protobuf::io::CodedInputStream *input) final;
                                                       ^~~~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[2]: *** [CMakeFiles/fancon.dir/build.make:83: CMakeFiles/fancon.dir/src/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/fancon.dir/all] Error 2
make: *** [Makefile:150: all] Error 2

PKGBUILD link: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fancon-git
Steps to Reproduce
Start docker container with the build environment:
docker run -t -i --rm registry.gitlab.com/aur1/utils:latest bash

Inside container:
sudo pacman --sync --refresh --sysupgrade --noconfirm
aur sync fancon-git --noview --noconfirm

Expected behavior
Sucess build.
Environment

Version: 0.20.1.r3.gbebdfc8
OS:  Arch Linux
Kernel: 5.6.10-zen1-1-zen
CMake: 3.17.2
CLang: 10.0.0
ProtoBuf: 3.11.4

I removed the included generated protobuf source files (https://github.com/hbriese/fancon/commit/3479347100d9fba5a3cff3320f51826e70c4c103) and added it to the cmake file so that they're generated when building (https://github.com/hbriese/fancon/commit/0488ee7c0ba8329783a3cfe2db791b7cf2ae8897).
Please pull this latest commits and test this

Thank you for the reply and fix. But still broken now.
==> Starting build()...
-- The CXX compiler identification is Clang 10.0.0
-- Check for working CXX compiler: /usr/lib/ccache/bin/clang++
-- Check for working CXX compiler: /usr/lib/ccache/bin/clang++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found Boost: /usr/lib64/cmake/Boost-1.72.0/BoostConfig.cmake (found version "1.72.0") found components: log thread system filesystem
-- Found Sensors: /usr/include/sensors
-- Found Protobuf: /usr/lib/libprotobuf.so;-lpthread (found version "3.11.4")
-- Found GRPC: /usr/lib/libgrpc.so
-- Configuring done
-- Generating done
-- Build files have been written to: /var/cache/build/fancon-git/src/fancon/build
Scanning dependencies of target fancon
[  5%] Building CXX object CMakeFiles/fancon.dir/src/main.cpp.o
In file included from /var/cache/build/fancon-git/src/fancon/src/main.cpp:1:
In file included from /var/cache/build/fancon-git/src/fancon/src/main.hpp:23:
In file included from /var/cache/build/fancon-git/src/fancon/src/Controller.hpp:13:
In file included from /var/cache/build/fancon-git/src/fancon/src/Devices.hpp:6:
In file included from /var/cache/build/fancon-git/src/fancon/src/FanDell.hpp:4:
In file included from /var/cache/build/fancon-git/src/fancon/src/DellSMM.hpp:6:
In file included from /var/cache/build/fancon-git/src/fancon/src/FanInterface.hpp:7:
In file included from /var/cache/build/fancon-git/src/fancon/src/SensorInterface.hpp:8:
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3033:2: error: #elif without #if
#elif __GNUC__
 ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3034:24: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
#pragma GCC diagnostic pop
                       ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3035:2: error: #endif without #if
#endif //__clang__
 ^
In file included from /var/cache/build/fancon-git/src/fancon/src/main.cpp:1:
In file included from /var/cache/build/fancon-git/src/fancon/src/main.hpp:23:
In file included from /var/cache/build/fancon-git/src/fancon/src/Controller.hpp:13:
In file included from /var/cache/build/fancon-git/src/fancon/src/Devices.hpp:6:
In file included from /var/cache/build/fancon-git/src/fancon/src/FanDell.hpp:4:
In file included from /var/cache/build/fancon-git/src/fancon/src/DellSMM.hpp:6:
In file included from /var/cache/build/fancon-git/src/fancon/src/FanInterface.hpp:9:
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3033:2: error: #elif without #if
#elif __GNUC__
 ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3034:24: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
#pragma GCC diagnostic pop
                       ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3035:2: error: #endif without #if
#endif //__clang__
 ^
In file included from /var/cache/build/fancon-git/src/fancon/src/main.cpp:1:
In file included from /var/cache/build/fancon-git/src/fancon/src/main.hpp:23:
In file included from /var/cache/build/fancon-git/src/fancon/src/Controller.hpp:13:
In file included from /var/cache/build/fancon-git/src/fancon/src/Devices.hpp:13:
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3033:2: error: #elif without #if
#elif __GNUC__
 ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3034:24: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
#pragma GCC diagnostic pop
                       ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3035:2: error: #endif without #if
#endif //__clang__
 ^
In file included from /var/cache/build/fancon-git/src/fancon/src/main.cpp:1:
In file included from /var/cache/build/fancon-git/src/fancon/src/main.hpp:23:
In file included from /var/cache/build/fancon-git/src/fancon/src/Controller.hpp:14:
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3033:2: error: #elif without #if
#elif __GNUC__
 ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3034:24: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
#pragma GCC diagnostic pop
                       ^
/var/cache/build/fancon-git/src/fancon/src/proto/DevicesSpec.pb.h:3035:2: error: #endif without #if
#endif //__clang__
 ^
4 warnings and 8 errors generated.
make[2]: *** [CMakeFiles/fancon.dir/build.make:83: CMakeFiles/fancon.dir/src/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/fancon.dir/all] Error 2
make: *** [Makefile:150: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Seems gen_proto.sh works incorect:
``bash
head src/proto/DevicesSpec.pb.h
#ifdef clang
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-parameter"
#elif GNUC
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-but-set-variable"
#endif //clang\n\n// Generated by the protocol buffer compiler.  DO NOT EDIT!
// source: DevicesSpec.proto
#ifndef GOOGLE_PROTOBUF_INCLUDED_DevicesSpec_2eproto

Hopefully this fixes it (https://github.com/hbriese/fancon/commit/de5bb400627f8d69b4f9b95e212f0c1eb57f67a1). The dangers of shell scripts!

Works now. Thank you.

Now the package is built and working. You can add a link to the documentation if you want.

I'm not entirely familiar with Arch. Are these install instructions sufficient?
git clone https://aur.archlinux.org/fancon-git.git; cd fancon-git
makepkg -sic

git clone https://aur.archlinux.org/fancon-git.git; cd fancon-git
makepkg -sic

that's correct. Also you can add -r to remove a make deps after build.


Purchase subscribed items issue

Steps to reproduce
IOS click to purchase subscribed items, a subscribed pop-up window will pop up, click OK, and the callback method will go to purchased instead of error
Expected results
IOS click to purchase subscribed items, a subscribed pop-up window will pop up, click OK, the callback method will go to error, and inform us that the item has been subscribed
Actual results
IOS click to purchase subscribed items, a subscribed pop-up window will pop up, click OK, and the callback method will go to purchased instead of error
Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[Paste your output here]

@tangshilin888
Please provide a complete runnable reproducible code sample along with flutter doctor -v and including current vs expected behavior upon running the code sample.


Add GEWT Logo

This is still incorrect. Logo PR Instructions

navigate to https://github.com/traderjoe-xyz/joe-tokenlists
Submit pull request by adding your token logo 120X120 PNG. (Folder name needs to be named with the token address)
-Please name it logo.png

Can emulate a PR was that correct and succesfully merged: https://github.com/traderjoe-xyz/joe-tokenlists/pull/1367


Hyperparameters for CIFAR10

Hi. Thank you for uploading your code.
Would you let me know the hyperparameters for the CIFAR10?
I tried
model, eval_model = DeepCapsNet(input_shape=x_train.shape[1:], n_class=y_train.shape[1], routings=args.routings)  # for 64*64
batch_size = 32
to train on single 1080 ti GPU. But it does not seem to converge.
Thank you.

Hi, all the hyperparameters are set in the args class for CIFAR10, could you please tell what was your test accuracy at the end?

When I tried batch_size = 32, the test accuracy was around 0.1 at the Epoch 36.
I think it was because I did not adjusted the learning rate according to the batch size.
The batch_size in the args class is 256.
But when I try to train on a single 1080 ti GPU, the out-of-memory issue occurs.
So, the CIFAR-10 model cannot be trained on a single GPU, is it right?
Instead, I tried batch_size = 128 and the test accuracy is around 0.897 at the epoch 34.

You don't necessarily have to keep batch size 256. having 128 is fine. if you train till 100 epoch and after that train with hard_loss, you can converge to 91%.
We use 256, with four V100 GPUs in parallel, to speed up the training, but you can still use a single GPU to train the model.

Yes. I got 90.6 % test accuracy.
Thanks a lot!

Great. Thank you very much.


[Bug Report] - Ender ore spawn doesn't change

Describe the bug
Changing the spawn settings for Ender Ore doesn't change anything. Ore spawn is still the same as in the original config. Only disabling ore spawn works fine.
To Reproduce
miniutilities-client.txt
miniutilities-common.txt
Steps to reproduce the behavior:

Change any settings for Ender Ore spawn
Generate a new world
Check the spawn of Ender Ore with WorldStripper for example.
It doesn't matter to what level you set the max-level it keeps at max level 55

Expected behavior
Ender Ore spawning should respect the settings in the config tile.
Screenshots
None
Mod Info (please complete the following information):

Forge: 36.2.25
MC Version:  1.16.5
Mod Version: 1.2.3

Additional context
Even setting the max-level to level 2, kept the ores spawning at max-level 55. I used WorldStripper to check the settings.

I came here to report just that, subscribing to get notifications.

sadly it does seem that its impossible to access the config from the registry area. technically it is possible to change the feature when the feature is added, but thats not good practice.


Make issue warning clearer when offering to add brand:wikidata or brand:wikipedia

Whole point of brand:wikidata and brand:wikipedia is that name alone (or combined with other indicator like object type and location) is not sufficient to identify object as belonging to a specific brand.
Despite that iD is asking user to add brand:wikidata and brand:wikipedia and describes this action as "XYZ looks like a brand with nonstandard tags" and offers user to "Upgrade the tags".
There are multiple problems here

iD is adding new tags, not "upgrading" ones that are present, so description is misleading
such heuristic usually gives good results, but there are some false positives. iD must mention to user that he is responsible for verifying this and that suggested change may be wrong
what is actually changed should be displayed in form readable to user
Even after clicking "i" button this tags are still not linking to Wikipedia/Wikidata making verification harder

See for example http://preview.ideditor.com/master/#background=Bing&disable_features=boundaries&id=w488118123&map=20.29/38.74517/-75.15497

After #6443 it was improved a bit but is still far from OK version.
Note also that

All features of the same brand should be tagged the same way.

displayed after clicking "i" is wrong - for example shops of the same brand may have different opening_hours or other tags.

Whole point of brand:wikidata and brand:wikipedia is that name alone (or combined with other indicator like object type and location) is not sufficient to identify object as belonging to a specific brand.
Despite that iD is asking user to add brand:wikidata and brand:wikipedia and describes this action as "XYZ looks like a brand with nonstandard tags" and offers user to "Upgrade the tags".

The message says "looks like", which means that iD isn't sure. The user is still making their own judgement. "Ignore this issue" is an option.

iD is adding new tags, not "upgrading" ones that are present, so description is misleading

Upgrading means iD will update to the preferred tagging for the same thing. Whether this involves adding, removing, or changing tags isn't really a factor.

such heuristic usually gives good results, but there are some false positives. iD must mention to user that he is responsible for verifying this and that suggested change may be wrong

Maybe. The wording doesn't imply absolute certainty and the user is always responsible for their edits anyway.

what is actually changed should be displayed in form readable to user

It is when you click the info button. We're not going to show this all the time since it takes up a lot of space.

All features of the same brand should be tagged the same way.

displayed after clicking "i" is wrong - for example shops of the same brand may have different opening_hours or other tags.

The message doesn't mean that all the tags should be identical. It's like answering "how should I tag a new Walmart?" A new Walmart should be tagged the same as an old Walmart. If this wording causes real problems we can change it.

The user is still making their own judgement. "Ignore this issue" is an option.

"Upgrade the tags" vs "Ignore the issue" at least for me sounds like, "are you willing to fix this issue", not "please check is it correct".
Note that it is combined with (by default) hiding what will actually happen.

Upgrading means iD will update to the preferred tagging for the same thing. Whether this involves adding, removing, or changing tags isn't really a factor.

My problem here was "XYZ looks like a brand with nonstandard tags" message - there are no "nonstandard tags" here what is even more confusing. "XYZ looks like a brand where tags may be added" would be better.
For cases where iD changes/removes existing tags "XYZ looks like a brand where tags may be changed" would be better.

In general, I think that it should be "Mark as brand XYZ {Brand XYZ logo image} {link to wikipedia/wikidata page}" to allow proper verification by tagging user.

The message says "looks like", which means that iD isn't sure. The user is still making their own judgement. "Ignore this issue" is an option.

“Looks like” is the only thing about this warning that equivocates. A typical user unfamiliar with the purpose of the QIDs will see a yellow background, ⚠ icon, and the negative words “issue” and “nonstandard” and conclude that ignoring isn’t the right thing to do.
The upgrade message is intended to merely a helpful suggestion, so it should look informational, not alerting. For example, a light blue background, ℹ icon, and even a “Did you mean?” kind of message would go a long way toward ensuring an unbiased appearance.

To be more specific, here is my mockup of solution that

presents change as likely to be valid, but not guaranteed to be correct
is not misleadingly claiming that current tagging is "nonstandard"
allows typical user to verify what clicking on button will do

For comparison current behavior:

⚠ Mark this object as operated uder branddescribed at Citizens Bank (South Bend,Indiana) Wikipedia page?

I find this wording a bit confusing too. Without knowing the purpose of this warning, the fact that it’s presented as a warning would probably still lead an inexperienced mapper to upgrade the feature without checking. A more descriptive message could potentially overcome the warning-like presentation:

 Does this feature belongto the Noah's Bagels brand?

Yeah, that would be even better.

Does this feature belong to the Noah's Bagels brand?

A related issue that might be worth revisiting; on selection of the wikidata brand via a preset, the name is often overridden; then locked.
There seem to be two styles of "brand" vs "name" - for example, a car dealership which is branded with Holden (https://www.wikidata.org/wiki/Q29281) but named "Duttons Holden":

This is likely because the dealer is independent, but has signed up to a franchise or similar; vs more "corporate owned" stores; which rely on strictly the branding:

... even if internally or on websites, they refer to themselves as some variant of Brand + Location - ie - https://www.coles.com.au/store-locator/stores/sa/firle-401 and https://www.kmart.com.au/store-detail/Firle
It might be worth relaxing the locking of name on setting of brand:wikidata; or otherwise loosening the relationship between brand + name autocorrection.

@CloCkWeRX It is a related but separate issue - can you consider moving it into a new issue (if not yet reported)?

A similar situation arises when the name is not unique and there are several potential matches in the NSI.
In Germany we have the situation that there are two supermarket chains with three brands all colloquially called “Netto”.

Netto Marken-Discount, often only gets tagged as name=Netto,
Netto City is a separate brand of Netto Marken-Discount for small shops, and
Netto (Salling) where name=Netto and brand=Netto are correct.

If you edit a supermarket tagged name=Netto, e.g. https://www.openstreetmap.org/edit?editor=id&way=31727346#map=19/52.65117/13.19552, it suggests to brand it as Netto (Salling).

Instead, it would be better if it would recognize that there are several potential matches in the NSI and offer all of them with logos. This would make it clear that the user has to make a choice and that iD can’t know which brand is the right one.
When adding a new node and searching for Netto iD lists the brands with logos (if enabled):

That makes it much more likely that a correct choice is made. I imagine that a similar choice could be displayed for the case of unambiguous brands, with the additional choice of “none of these”.


Make revision mean only one thing.

We keep confusing people by using the magical word revision to mean different things.
We have:

Bottle revisions:

bottle do
  revision 1
  sha256 "41af286dc0b172ed2f1ca934fd2278de4a1192302ffa07087cea2682e7d372e3" => :blah
end

Git revisions:

url "https://github.com/magic/unicorns.git",
    :tag => "unicorn-1",
    :revision => "eefc6ed865ca20447afc293c986676933dbfb137"

Formulae revisions:

url "https://example.org/example.tar.gz"
sha256 "13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de"
revision 1

Particularly confusing to new contributors is that we have an audit mechanism that nudges people to remove an unnecessary revision, and we see repeated examples of people removing the git commit revision rather than the revision 1.
We need to move away, long-term, from using the same keyword to represent different things, particularly where those things are used in close proximity on a regular basis. It'd probably be easier to change formulae/bottle meaning of revision, IMO, but discuss at will.

:+1: I still get confused about this myself sometimes, and a terminology change - especially w a keyword change to remove context sensitivity in formula files - would probably help.
Might be a bit harder to do the batch change, but maybe keeping 'revision' for formula would work too, with ':revision' for git resources becoming ':commit', since "commit" is in wide informal use that way and associated with Git, and 'bottle_revision' for the bottles. We could prob do a bulk search-and-replace of :revision => "\w+" since nothing else uses that symbol AFAIK, and formatting is consistent. I can't easily think of another term to use for formula revisions, but maybe that's just because I'm used to it now.
Though semantically and conversationally, it might be cleaner to change the terms for formula and bottle: since we track our formulae in git, and don't bump the formula revision with every file change, a formula revision may live for several git revisions of the formula file. And all the git revisions of a formula file over its life do not correspond to "revisions" of that formula. (E.g. If I say "what revision of asciidoc are you looking at?" I might be referring to the git revision SHA of asciidoc.rb or the revision 2 inside the file. Can't tell without more context.)
Git is the only one of these three concepts that's from outside Homebrew and has pre-existing terminology, and it uses "revision". So maybe that should take precedence.

In my mind there shouldn't be any confusion, as we're asking them to remove the revision line, not some :revision => argument from a statement. But I can see how that may trip up some people.
In my opinion, the least invasive and only acceptable solution would be to change the :revision => argument for url (I think :commit is an excellent suggestion). I'm :-1: on changing revision for both the formula itself and bottle do blocks. (We're already asking our contributors to not touch the bottle do block anyway and that should make it clear that we can't be referring to the revision line in there.)

Maybe to add to my confusion why that is an issue: People are dealing with natural languages all the time, where the same thing means something different (depending on context) all the time. But I guess if we can change things in a way that reduces confusion and thus maintenance burden, it's reasonable to pick the pragmatic solution instead of trying to educate people …

I'd propose bottle revisions become bottle_version or bottle_revision, SCM revisions become commit or revision becomes subversion or something.

revison => bottle_revision
SCM revision => commit
formula revision => edition, or just formula_revision

Not subversion, if one wants to decrease confusion.  (Imagine a formula's HEAD is a subversion repo, and also has a formula revision that we call  "subversion").

I like edition.

Keeping with the bottle them, we could call bottle revisions the bottling run or lot number.
If you like edition and want to continue the book theme, we could call each bottle revision an impression.

I think we should leave this unchanged. The meanings are each quite clear from context.

The meanings are each quite clear from context.

This rather assumes everyone has a firm grasp on the context of each usage 😉.

Chicken and egg. I don't think adding additional jargon actually helps with that.

@ilovezfs This is something people run into problems with with alarming regularity, unfortunately.

What percent of that is people modifying the bottle block when they shouldn't be as opposed to some other kind of confusion?

I believe the bottle block confusion could also be dealt with by making brew bottle surround the bottle with comments that say something like “Please do not modify this following bottle do block.” or something similar. (This would also help with people occasionally removing or otherwise modifying the bottle do block when they shouldn't.)

Yeah, that's why I asked. I'm wondering how much of the problem would be solved with that change alone.

I'd say when we ask people for a revision bump they modify the bottle block 25-50% of the time. Even when we say not to modify it in the original message it's still 10-20% of the time.

The proposal is about reducing confusion and preventing removals of the revisions that appear outside the bottle block.  The prevention of incorrect bottle-block modifications is a separate issue.  So while that separate issue would likely not be fixed by the present proposal, that's no argument against the present proposal.
But on that separate issue, let me ask what I hope is not too silly a question.  Can't the CI bots be made to handle that stuff?  When a user submits a PR that contains a bottle-block modification (an outright deletion, or a less severe change) can't they be configured to auto-github-comment on that PR saying "Nope, don't change the bottle block; put it back the way it was"?  Maybe also "If you were told by a maintainer to bump the revision, they meant blah blah, not the one in the bottle-block."

revison => bottle_revision
SCM revision => commit
formula revision => edition, or just formula_revision

Going to open a PR using bottle_revision, commit and formula_revision as those names are the most obvious/explicit for the human-readable DSL.

I know I'm probably on lost ground here, but it still feels weird to completely ignore the context in which these are used and to try to make the DSL context-independent only for this particular case. If we get formula_revision and bottle_revision, then why is it still fine and unambiguous to have sha256 instead of formula_sha256 and bottle_sha256 or url instead of formula_url and patch_url (in a patch do block)? If nothing else, this different treatment looks ugly to me.
(Yes, I realize several PRs have been created to address this, but my argument makes more sense when looking at the complete picture.)

@UniqMartin I agree with you but I think this is already decided.

@UniqMartin They are being changed because it causes confusion in the same way that sha256 etc. do not. I'm open to alternate suggestions or names to resolve this problem if they are presented in the relatively near term.

They are being changed because it causes confusion in the same way that sha256 etc. do not.

I know. I'm not debating that this causes confusion for some contributors, I'm just a bit afraid that we're solving a minor problem with a very invasive change (and the potential for breakage such a change can cause), not to mention that this is a change to our formula DSL that affects almost any formula and we have been previously cautious with such changes.

I'm open to alternate suggestions or names to resolve this problem if they are presented in the relatively near term.

From https://github.com/Homebrew/brew/issues/38#issuecomment-223781002 above:

I believe the bottle block confusion could also be dealt with by making brew bottle surround the bottle with comments that say something like “Please do not modify this following bottle do block.” or something similar.

I'm not opposed to renaming :revision in SCM urls though my gut feeling is that this has caused far less confusion than the formula/bottle revision, it just happens to have the same name and thus was prematurely included in this issue. (But as I said, this is just my gut feeling, as I haven't been following formula contributions that closely to see whether this use of :revision is indeed as problematic as stated.)

then why is it still fine and unambiguous to have sha256 instead of formula_sha256 and bottle_sha256 or url instead of formula_url and patch_url (in a patch do block)? If nothing else, this different treatment looks ugly to me.

This does not seem to cause confusion for people because it's more obvious how they are scoped whereas a formula_revision is sometimes not present when a bottle_revision or commit is and it's relatively difficult to describe which one to change.
@UniqMartin To be more explicit and general about how to handle issues/PRs like this: a problem has been raised by this issue and a solution proposed. If you're opposed to the solution the onus is on you to propose an alternate solution rather than point out perceived flaws with the current solution. What do you propose we do to solve this issue?

To be more explicit and general about how to handle issues/PRs like this: a problem has been raised by this issue and a solution proposed. If you're opposed to the solution the onus is on you to propose an alternate solution rather than point out perceived flaws with the current solution. What do you propose we do to solve this issue?

I don't know how to resolve this in general, but for this particular issue, I have proposed an alternative solution (again, cf. https://github.com/Homebrew/brew/issues/38#issuecomment-223781002) that is less invasive than changing our formula DSL en masse and I did so well before any solution was picked and implemented.
What else can I do than make such suggestions? Nobody has commented on this suggestion, not even to point out flaws inherent to it and that I might not have realized yet.
I'm not here to block progress or improvements to our contribution experience, but I'm a bit wary of sweeping changes like the one currently implemented and the least I can do is point out possible problems to help avoid nasty surprises. If my argument is not convincing and you deem the benefits worth the risks, then please simply let me know. Ultimately, I'll defer to your much greater experience with Homebrew in judging the situation.

I don't know how to resolve this in general, but for this particular issue, I have proposed an alternative solution (again, cf. #38 (comment)) that is less invasive than changing our formula DSL en masse and I did so well before any solution was picked and implemented.

Ok, my apologies for not commenting specifically on that situation.
I don't like it because I think it assumes that every tap will use our method of autogenerating/updating bottle bottles rather than updating them by hand (which some decide to do). I think those taps would find this comment more abrasive than a DSL change.
That said, given you've scoped the problem as being just about the bottle block, I'm prepared to make just a change there for now. Do you have any other suggested names for bottle_revision that would be more clearly about the bottle and not the formula? Alternatively, do you have a suggestion for what to change formula_revision to (technically revisions for bottles predate revisions for formulae if that's at all relevant).

Ok, my apologies for not commenting specifically on that suggestion.

Thanks!

I don't like it because I think it assumes that every tap will use our method of autogenerating/updating bottle bottles rather than updating them by hand (which some decide to do). I think those taps would find this comment more abrasive than a DSL change.

That's good to know and makes the decision you've made when creating the above three PRs feel less arbitrary. Another similar idea that just popped into my head would be to move the bottle do block further down to reduce this kind of confusion. It could become the last element in class Foo < Formula […] end or could even be moved into a separate code block at the end of the file (by relying on the ability to reopen classes in Ruby):
class Foo < Formula
  # Formula code created by a human.
end

class Foo
  bottle do
    # Bottle code typically created by `brew test-bot`/`brew bottle`.
  end
end

One possible downside is that this repeats the class name. An upside is that this is far easier to cut out and replace with a new bottle do block compared to the current regex solution.

That said, given you've scoped the problem as being just about the bottle block, I'm prepared to make just a change there for now. Do you have any other suggested names for bottle_revision that would be more clearly about the bottle and not the formula? Alternatively, do you have a suggestion for what to change formula_revision to (technically revisions for bottles predate revisions for formulae if that's at all relevant).

In general, I find a solution that keeps the (formula) revision as-is (for the benefit of all the contributors that have already understood this) and only changes the DSL used inside the bottle do block more desirable. The latter could be more easily seen as an implementation detail and if it changes, it doesn't really affect contributors (except for causing less confusion).
I'm not sure if this might cause new confusion, but build feels like a nice replacement for a bottle revision. After all it is indeed a new (binary) build of an otherwise unchanged formula with the same pkgversion (version+revision). If we stray a bit into book printing territory, reissue could also work. What do you think about these? Let me know while I'll ponder this a bit more in the back of my head and try to come up with terminology that is better yet.

I'm not sure if this might cause new confusion, but build feels like a nice replacement for a bottle revision.

build could work for me. It'll overload the use of build.with? etc. in the DSL but I can't see a reason why you'd ever use that inside the bottle block.

It'll overload the use of build.with? etc. in the DSL but I can't see a reason why you'd ever use that inside the bottle block.

I'd considered suggesting build and rejected it out of hand for exactly that reason.
Alternatives for inside the bottle block:
batch
bottling
impression
lot
number
rebuild
run

rebuild

This probably slightly trumps build for me.

trumps

Please don't use this word. It's probably some sort of violation of the CODEOFCONDUCT. :)

I'll use it while, legally, I still can 😉

The more I mentally chew on rebuild the more I like it; I think it concisely explains the concept well.

Unless it confuses maintainers since that's also the name of a button in Jenkins :trollface:

Right, I totally missed the obvious clash with build. But rebuild is not a bad alternative. :+1:


[WIP] initial reorganization of repo

Started reorganizing the repo. Will fix example next (to accommodate the new organization) and add a setup.py.

Feel free to add an attic/ to store things that don't seem to belong anywhere else.

Ok, that sounds good.

Looking better!  We're almost there!
Some observations about the current state:

There are still some .py files at the top level directory; can we move those into appropriate subdirectories?
We should move multitopology/ into perses/.
Add some description of the various subpackages to README.md
Under examples/, let's have subdirectories rjmc/, multitopology/, dualtopology/, etc. so that the examples are segregated.  Also need a README.md.

Looking good!

I think we still need a setup.py.  You can probably model this after the minimal one in ThermoPyL
The devtools/ tree in ThermoPyL is also pretty modern and set up for the docker travis environment, so you may want to update to that too.

Ok. I'll add those after lunch then ping the thread to see if we're ready to merge

I'm hopping on a flight to London, so feel free to merge once you think things are as far along as they can get without updates from my end!

Going to merge. Will correct nosetest issue in a future PR (needs either test exclusion or openeye installation).


Using group optional attribute to create an hierarchical layer tree

Hi devs,
I recovered these two classes that help create a layer tree, from an group attribute. I also add an example of usage, to geoext2/examples/tree/.
The only change in the existing code proposed in the PR is an additional protection (if clause) in src/GeoExt/tree/Util.js, updateLayerVisibilityByNode function, to make sure that we have a layer associated with the node before checking the layer's visibility. I think this test is necessary, since we might have nodes in the tree (not leafs) without a layer.
The two classes proposed in this PR are:
GeoExt.tree.LayerTreeBuilder that extends GeoExt.tree.Panel
GeoExt.tree.LayerGroupContainer that extends GeoExt.tree.LayerContainer
Comments are welcome.

I currently don't have time to look into this, sorry. I hope to find time for this next week. Others are free to revoew of course.

Hi @jgrocha,
thanks a lot for your contribution! This seems to be a great addition for the tree package of GeoExt.
Besides some minor issues which I addressed directly as line comments (see above) I have some major points which should be done before we can merge this:

When I run your example the group node 'Utilities' does not have a checkbox but when I check an underlying layer it appears. Can you have a look at that?
Do you see the chance to add some unit tests?
Can you please add some more API doc tags on the config properties and functions in your newly created classes, so the API-documentation will be complete?
The customized layer icons for base layers (see example tree.html) are gone in your example

Hey @jgrocha do you think you can tackle the comments of @chrismayer?


Add new backend vxlan-over-hostgw

This new backend "is a" vxlan backend, only that it "has a" host-gw
backend.
It works the same as vxlan, with the following extra functionality:

the backend would calculate its local network mask on start
when receiving network events, it would forward the event to host-gw
backend if the network events belong to local network

Description
With this backend, the nodes in the same local network would reach each other  via direct route, and the nodes in different local network would reach each other via vxlan.
This setup would help improving network bandwidth usage within local network (comparing to pure vxlan), and still make networking accessible across  networks boundary.
The relationship between vxlan, host-gw and vxlan-over-hostgw is as following:

vxlan  <--> host-gw:   could not reach each other
vxlan <--> vxlan-over-hostgw:  the flannel networks connected to each other by vxlan
host-gw <--> vxlan-over-hostgw: the flannel networks connected to each other by host-gw if they are in same local network, otherwise they could not reach each other
vxlan-over-host <--> vxlan-over-host:  networks connected by host-gw if they are in same local network, otherwise connected by vxlan

##Tests

#etcdctl  get /coreos.com/network/config
{ "Network": "<IP_ADDRESS>/8", "SubnetLen": 20, "Backend": {"Type": "vxlan-over-hostgw"} }

Test Env setup:

4 nodes with node1/node2/node3 are in network <IP_ADDRESS>/24, while node4 in network <IP_ADDRESS>/24
After starting flanneld on each nodes, the route table is as following:

node 1
#ip route
default via <IP_ADDRESS> dev enp0s3
<IP_ADDRESS>/24 dev enp0s3  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/8 dev flannel.1
<IP_ADDRESS>/20 dev docker0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/20 via <IP_ADDRESS> dev enp0s3
<IP_ADDRESS>/20 via <IP_ADDRESS> dev enp0s3
<IP_ADDRESS>/24 dev enp0s8  proto kernel  scope link  src <IP_ADDRESS>

node 2
#ip route
default via <IP_ADDRESS> dev enp0s8
<IP_ADDRESS>/24 dev enp0s8  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/8 dev flannel.1
<IP_ADDRESS>/20 via <IP_ADDRESS> dev enp0s8
<IP_ADDRESS>/20 via <IP_ADDRESS> dev enp0s8
<IP_ADDRESS>/20 dev docker0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/24 dev enp0s3  proto kernel  scope link  src <IP_ADDRESS>

node 3
#ip route
default via <IP_ADDRESS> dev enp0s8
<IP_ADDRESS>/24 dev enp0s8  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/8 dev flannel.1
<IP_ADDRESS>/20 via <IP_ADDRESS> dev enp0s8
<IP_ADDRESS>/20 dev docker0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/20 via <IP_ADDRESS> dev enp0s8
<IP_ADDRESS>/24 dev enp0s3  proto kernel  scope link  src <IP_ADDRESS>

node 4
#ip route
default via <IP_ADDRESS> dev eth0
<IP_ADDRESS>/24 dev eth0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/8 dev flannel.1
<IP_ADDRESS>/20 dev docker0  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/24 dev eth1  proto kernel  scope link  src <IP_ADDRESS>

Test steps:

On each nodes, run a simple docker process:

docker run --rm -it alpine sh

On each container, run ping to check connectivity between containers across nodes.

Expect:

All container could reach each other.

Result:

As expected.

Todos

[ ] Tests
[ ] Documentation

#765 #519

Also #787

@zq-david-wang thanks for the contribution but I'm closing this in favor of #787. Hopefully that still provides the feature you need.


winch(aarch64): abs, ceil, floor, nearest, trunc, neg, sqrt

Adds a few more float instructions abs, neg, sqrt and all roundings (ceil, floor, nearest, trunc).
I skipped copysign for now, as it is less trivial and we probably want to port the same logic from cranelift :p
Temporarily submitting as draft because I want to double-check the test cases.

I think it should be good to go


Feature/added cmd support

Closing this. Let me know if this works on Windows @Hemakasen007. If you come up with something do push it and Let me know 😄