DRILL-143: CGroup Support for Drill-on-YARN

Original commit works for stand-alone Drill. During testing with Drill-on-YARN, it was discovered that while the environment is sourced, the DrillApplicationManager uses a different resource for spinning up the Drillbits. This commit applies the CGroups application logic for YARN specifically.

@Ben-Zvi  please review. QA verified that Drill-on-YARN works with this patch.

@kkhatua, it turns out that upstream YARN has long had effective cgroup support per container. ( have the pleasure of sitting near the guy who maintains that work.)There has long been a discussion about whether the MapR version of YARN picked up those changes, we believe that MapR does not support this upstream work.
As a result, under Apache YARN, the YARN NM itself will impose cgroup controls and Drill need not do it itself. For MapR YARN (only) Drill (and all other YARN apps) must do their own cgroup control.
Please make sure that this feature is off by default to allow YARN to do the work. Only enable it for versions of YARN (such as MapR) which do not provide cgroup control in YARN itself.

Thanks for that pointer, @paul-rogers ! I'll make the relevant changes and add to this commit.

There may be some misunderstanding of how DoY works. The only info that users can pass to DoY is that which is in the DoY config file. We should add arguments to that file which will be passed through the DoY client to the DoY AM, and from there, as an env var, to the Drillbit containers. We already do this for memory so that both Drill and YARN agree on memory. We should do the same for CPU so that Drill, YARN and cgroups agree on the number of CPUs that Drill can use.
Since this feature is MapR-only, it might be OK to require that users alter their drill-env.sh to set an environment variable the forces Drill to police itself under YARN.

@paul-rogers DoY is no more a MapR-only feature, and if it helps to have Drill self-enforce, this works. If YARN is able to enforce for Drill, the user need not specify the settings in their drill-env.sh.
I see https://issues.apache.org/jira/browse/YARN-810 as being an open issue. (Source: Issue List ). So, I probably don't need to do any explicit checks for hadoop distros and documentation should be sufficient to address this, IMO.

@kkhatua, putting on my Apache hat... Apache Drill is an Apache project that must work with other Apache projects such as Apache YARN. The Apache Drill DoY support is designed to work well with Apache YARN (and has a few special additions for MapR YARN's unique limitations.) It is important that the Apache DoY work well with the generic YARN. No harm in adding tweaks (such as this one) to work with vendor-specific limitations. But, the overriding concern is that the DoY feature be useful in Apache.

One other thing to highlight from an earlier comment. CPU is something that the user specifies in the DoY config file. That information is passed to YARN in container requests. This feature asks the user to modify the drill-env.sh file to enable cgroups to limit CPU. As a result, the user must specify the CPU limit in two places.
DoY went to extreme lengths to unify memory configuration so it is set in one place. The assumption was that, since Apache YARN handles cgroups, we've also got unified CPU specification. But, in this "side-car" approach we don't. So, would be good to capture the CPU amount from the YARN config as explained earlier and use that to set the Drill cgroups env vars -- but only if some "self-enforcing cgroup" flag is enabled in the config (which can be done by default for the limited MapR YARN.)

@paul-rogers I went through with support on this and found that the issue is not specific to MapR. However, you make a strong argument in favor of letting YARN handle the CGroup management rather than Drill over-reaching.
I've reverted the change to yarn-drillbit.sh in the latest commit.

Yes, I agree. Support folks gave me similar feedback, so I'll commit this change in the mapr distro IFF there is a request for that. YARN is already a complex beast with numerous settings. Introducing caveats like this will only add to the confusion.

@paul-rogers, @kkhatua, is this PR ready to be merged, or some additional work should be done?

Please check with @kkhatua about his intention. The change is OK as far as it goes; the discussion was about whether it went far enough.

@vvysotskyi  Yes. This commit should carry only changes to one file, instead of the original 2 files. You can go ahead and commit it.

@paul-rogers, @kkhatua, thanks for the clarification, will merge it soon.


Fix aligned data in memory query bug

Description
Fix the query result of the mem data from aligned time series may less than they should be.
Before:

Alfter:

To reproduce, use the test file below:
AlignedWriteUtil.txt

Coverage increased (+0.009%) to 45.135% when pulling 2cf17a9a678be716694ee056e36997a5ba672cc5 on fix_mem_data_query into 95884ad6b95561bdde42eea55edc50fa23fb46a0 on master.


Failed to create a key pair

$ cosign version
______   ______        . __    _______ . .
/      | /  __  \      /       ||  |  /  ||  \ |  |
|  ,----'|  |  |  |    |   (----|  | |  |  __  |   \|  | |  |     |  |  |  |     \   \    |  | |  | |_ | |  .   |
|  ----.|  --'  | .----)   |   |  | |  || | |  |\   |
_| ______/  |_/    ||  __| || _|
cosign: A tool for Container Signing, Verification and Storage in an OCI registry.
GitVersion:    v2.1.1
GitCommit:     baf97ccb4926ed09c8f204b537dc0ee77b60d043
GitTreeState:  clean
BuildDate:     2023-06-27T06:57:11Z
GoVersion:     go1.20.5
Compiler:      gc
Platform:      linux/amd64
$ cosign generate-key-pair k8s://cosign/cosign-secret
Enter password for private key:
Enter password for private key again:
Error: new for config: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"
main.go:74: error during command execution: new for config: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"
$ kubectl  get ns |grep cosign
cosign            Active   23m
other version：

aws eks v1.24
kubectl v1.23.6

I need some help. Thanks

If you're still running into issues, I would recommend asking on #cosign in Slack.


Validations and model specs

This is the pull request for validation of my user comments likes and posts and the Rspect test.
Objectives
Use validations for models.
Write unit tests for models.

Hi @eerapheal,
While you made a great effort in this project, I cannot proceed to review your code.
Invalid Code Review Request
You have submitted a project that has failed linter checks
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.


The form cannot be submitted if the form tags are located in 2 different html sections

Laravel Version: 5.4.24
PHP Version: 7.1
Database Driver & Version: MySql

Description:
In the previous versions (i.e 5.4.9) I could open the form tag in one html section (i.e modal body) and close in another (i.e.modal footer). In the 5.4.25 it is impossible.
Steps To Reproduce:

    <form action="{{route('foo')}}" method="post">
        <input type="text" name="foo" id="foo" />

        <button type="submit">Submit</button>
    </form>

The same references to the blade components - the form cannot be submitted if the form tags are located in two different components.

This isn't a Laravel issue, but a browser/html issue. It's invalid html to nest elements in that way, just as

 is invalid. You've perhaps been lucky in the html structure/browser/something on how the browser has parsed the html and generated the missing closing tag.


Howto configure frontend?

First of all, thank you so much for this ;)
I assume several values of your extended .env (feature/local-hosting) needs to be adapted. Can you give a short summary what needs to be changed to connect the frontend with my self-hosted backend?
# Google Analytics ID
GA_ID=UA-61422507-4

# Google Tag Manager ID
GTM_ID=GTM-NMKVBMV

# Firebase config
API_KEY=AIzaSyCMsFreESs58-hRxTtiqQrIcimh4i1wbsM
AUTH_DOMAIN=postwoman-api.firebaseapp.com
DATABASE_URL=https://postwoman-api.firebaseio.com
PROJECT_ID=postwoman-api
STORAGE_BUCKET=postwoman-api.appspot.com
MESSAGING_SENDER_ID=421993993223
APP_ID=1:421993993223:web:ec0baa8ee8c02ffa1fc6a2
MEASUREMENT_ID=G-BBJ3R80PJT

# Base URL
BASE_URL=https://hoppscotch.io

# Shortcode URL Base
SHORTCODE_BASE_URL=https://hopp.sh

# API
API_URL=https://api.hoppscotch.io/graphql
API_WS_URL=wss://api.hoppscotch.io/graphql

I am not sure about that Google Analytics and Tag manager crap, then which Firebase values needs to me changed and where do I find the values in my console? What is that newly added SHORTCODE_BASE_URL?
Highly appreciate your help

Hi!
GA_ID and GTM_ID can be left empty, I did that too.
SHORTCODE_BASE_URL can be the same as BASE_URL if you don't want a separate domain for the shortcodes.
In Firebase, create a project, and under project settings, Your apps, add an web app, most env config values can be found in the example config.
The only one that isn't in there are DATABASE_URL and that's basically https://{{PROJECT_ID}}.firebaseio.com.

Perfect than your for fast response. Lastly, I see the following error when building the frontend
#0 87.72 packages/hoppscotch-app postinstall$ pnpm run gql-codegen
#0 88.49 packages/hoppscotch-app postinstall: ><EMAIL_ADDRESS>gql-codegen /app/packages/hoppscotch-app
#0 88.49 packages/hoppscotch-app postinstall: > graphql-codegen --require dotenv/config --config gql-codegen.yml
#0 90.32 packages/hoppscotch-app postinstall: [14:27:18] Parse configuration [started]
#0 90.33 packages/hoppscotch-app postinstall: [14:27:18] Parse configuration [completed]
#0 90.33 packages/hoppscotch-app postinstall: [14:27:18] Generate outputs [started]
#0 90.33 packages/hoppscotch-app postinstall: [14:27:18] Generate helpers/backend/graphql.ts [started]
#0 90.33 packages/hoppscotch-app postinstall: [14:27:18] Generate helpers/backend/backend-schema.json [started]
#0 90.33 packages/hoppscotch-app postinstall: [14:27:18] Load GraphQL schemas [started]
#0 90.33 packages/hoppscotch-app postinstall: [14:27:18] Load GraphQL schemas [started]
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] Load GraphQL schemas [failed]
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] → Failed to load schema
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] Load GraphQL schemas [failed]
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] → Failed to load schema
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] Generate helpers/backend/graphql.ts [failed]
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] → Failed to load schema
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] Generate helpers/backend/backend-schema.json [failed]
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] → Failed to load schema
#0 90.44 packages/hoppscotch-app postinstall: [14:27:18] Generate outputs [failed]
#0 90.44 packages/hoppscotch-app postinstall: Something went wrong
#0 90.46 packages/hoppscotch-app postinstall:  ELIFECYCLE  Command failed with exit code 1.
#0 90.46 packages/hoppscotch-app postinstall: Failed
#0 90.47  ELIFECYCLE  Command failed with exit code 1.
------
failed to solve: executor failed running [/bin/sh -c pnpm i --unsafe-perm=true]: exit code: 1

So looks like it cannot fetch the schema from the running backend. Backend is reachable from frontend, see:
curl -kI https://rest-backend.mic.offsec.corpintra.net/graphql/
HTTP/2 307
content-type: text/html; charset=utf-8
date: Tue, 09 Aug 2022 14:31:06 GMT
location: /graphql
server: Caddy
server: openresty
x-served-by: rest-backend.mic.offsec.corpintra.net

However, I have to make use of a corp trusted (internal) certificate, and the building image has no trust in this CA, I would assume prepending NODE_TLS_REJECT_UNAUTHORIZED=0 to graphql-codegen will do the trick.
But finally the build fails with a dependancy issue:
#0 83.76 packages/hoppscotch-app postinstall$ pnpm run gql-codegen
#0 84.62 packages/hoppscotch-app postinstall: ><EMAIL_ADDRESS>gql-codegen /app/packages/hoppscotch-app
#0 84.62 packages/hoppscotch-app postinstall: > NODE_TLS_REJECT_UNAUTHORIZED=0 graphql-codegen --require dotenv/config --config gql-codegen.yml
#0 87.61 packages/hoppscotch-app postinstall: [14:39:12] Parse configuration [started]
#0 87.62 packages/hoppscotch-app postinstall: [14:39:12] Parse configuration [completed]
#0 87.62 packages/hoppscotch-app postinstall: [14:39:12] Generate outputs [started]
#0 87.62 packages/hoppscotch-app postinstall: [14:39:12] Generate helpers/backend/graphql.ts [started]
#0 87.62 packages/hoppscotch-app postinstall: [14:39:12] Generate helpers/backend/backend-schema.json [started]
#0 87.62 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL schemas [started]
#0 87.62 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL schemas [started]
#0 87.70 packages/hoppscotch-app postinstall: (node:225) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
#0 87.70 packages/hoppscotch-app postinstall: (Use `node --trace-warnings ...` to show where the warning was created)
#0 87.78 packages/hoppscotch-app postinstall: (node:225) ExperimentalWarning: buffer.Blob is an experimental feature. This feature could change at any time
#0 87.88 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL schemas [completed]
#0 87.88 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL schemas [completed]
#0 87.88 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL documents [started]
#0 87.88 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL documents [started]
#0 87.89 packages/hoppscotch-app postinstall: [14:39:12] Load GraphQL documents [completed]
#0 87.89 packages/hoppscotch-app postinstall: [14:39:12] Generate [started]
#0 87.95 packages/hoppscotch-app postinstall: [14:39:13] Generate [completed]
#0 87.95 packages/hoppscotch-app postinstall: [14:39:13] Generate helpers/backend/backend-schema.json [completed]
#0 88.65 packages/hoppscotch-app postinstall: [14:39:13] Load GraphQL documents [completed]
#0 88.65 packages/hoppscotch-app postinstall: [14:39:13] Generate [started]
#0 88.89 packages/hoppscotch-app postinstall: [14:39:13] Generate [completed]
#0 88.89 packages/hoppscotch-app postinstall: [14:39:13] Generate helpers/backend/graphql.ts [completed]
#0 88.90 packages/hoppscotch-app postinstall: [14:39:13] Generate outputs [completed]
#0 88.93 packages/hoppscotch-app postinstall: Done
#0 88.94
#0 88.94 dependencies:
#0 88.94 + husky 7.0.4
#0 88.94 + lint-staged 12.3.1
#0 88.94
#0 88.94 devDependencies:
#0 88.94 + @commitlint/cli 16.1.0
#0 88.94 + @commitlint/config-conventional 16.0.0
#0 88.94 + @types/node 17.0.10
#0 88.94
#0 88.96  ERR_PNPM_PEER_DEP_ISSUES  Unmet peer dependencies
#0 88.96
#0 88.96 packages/hoppscotch-app
#0 88.96 ├─┬ @nuxt/types 2.15.8
#0 88.96 │ └─┬ sass-loader 10.1.1
#0 88.96 │   └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 ├─┬ @nuxt/typescript-build 2.1.0
#0 88.96 │ ├─┬ fork-ts-checker-webpack-plugin 6.4.0
#0 88.96 │ │ ├── ✕ missing peer webpack@">= 4"
#0 88.96 │ │ └── ✕ missing peer vue-template-compiler@"*"
#0 88.96 │ └─┬ ts-loader 8.3.0
#0 88.96 │   └── ✕ missing peer webpack@"*"
#0 88.96 ├─┬ @nuxtjs/eslint-module 3.0.2
#0 88.96 │ └─┬ eslint-webpack-plugin 2.5.4
#0 88.96 │   ├── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 │   └── ✕ unmet peer<EMAIL_ADDRESS>found 8.7.0
#0 88.96 ├─┬ @nuxtjs/stylelint-module 4.1.0
#0 88.96 │ ├── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 │ └─┬ stylelint-webpack-plugin 2.3.1
#0 88.96 │   └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 ├─┬ @nuxtjs/svg 0.3.0
#0 88.96 │ ├─┬ file-loader 6.2.0
#0 88.96 │ │ └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 │ ├─┬ raw-loader 4.0.2
#0 88.96 │ │ └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 │ ├─┬ url-loader 4.1.1
#0 88.96 │ │ └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 │ └─┬ vue-svg-loader 0.16.0
#0 88.96 │   ├── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 │   └─┬ svg-to-vue 0.7.0
#0 88.96 │     └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ babel-loader 8.2.3
#0 88.96 │ └── ✕ missing peer webpack@>=2
#0 88.96 ├─┬ nuxt-windicss 2.2.2
#0 88.96 │ ├─┬ @nuxt/kit-edge 3.0.0-rc.6-27667279.0b22079
#0 88.96 │ │ └─┬ @nuxt/schema-edge 3.0.0-rc.6-27667279.0b22079
#0 88.96 │ │   └─┬ unimport 0.6.5
#0 88.96 │ │     └─┬ unplugin 0.8.1
#0 88.96 │ │       ├── ✕ missing peer webpack@"4 || 5"
#0 88.96 │ │       └── ✕ missing peer<EMAIL_ADDRESS>|| ^3.0.0-0"
#0 88.96 │ └─┬ vite-plugin-windicss 1.6.1
#0 88.96 │   └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ sass-loader 10.2.0
#0 88.96 │ └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 ├─┬ worker-loader 3.0.8
#0 88.96 │ └── ✕ missing peer<EMAIL_ADDRESS>|| ^5.0.0"
#0 88.96 ├─┬ @nuxtjs/composition-api 0.31.0
#0 88.96 │ ├── ✕ missing peer vue@^2
#0 88.96 │ ├── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 │ └─┬ unplugin-vue2-script-setup 0.7.3
#0 88.96 │   └─┬ unplugin 0.2.21
#0 88.96 │     ├── ✕ missing peer webpack@"4 || 5"
#0 88.96 │     └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ @vue/test-utils 1.3.0
#0 88.96 │ ├── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 │ └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ vue-jest 3.0.7
#0 88.96 │ ├── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 │ └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ vue-template-babel-compiler 1.1.2
#0 88.96 │ └── ✕ missing peer<EMAIL_ADDRESS>
#0 88.96 ├─┬ @nuxtjs/eslint-config-typescript 8.0.0
#0 88.96 │ ├─┬ eslint-import-resolver-typescript 2.5.0
#0 88.96 │ │ └── ✕ missing peer eslint-plugin-import@"*"
#0 88.96 │ └─┬ @nuxtjs/eslint-config 8.0.0
#0 88.96 │   ├─┬ eslint-config-standard 16.0.3
#0 88.96 │   │ └── ✕ unmet peer<EMAIL_ADDRESS>found 8.7.0
#0 88.96 │   └─┬ eslint-plugin-promise 5.1.1
#0 88.96 │     └── ✕ unmet peer<EMAIL_ADDRESS>found 8.7.0
#0 88.96 ├─┬ @vue/composition-api 1.4.4
#0 88.96 │ └── ✕ missing peer vue@">= 2.5 < 3"
#0 88.96 ├─┬ vue-tippy 4.13.0
#0 88.96 │ └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ stylelint-config-standard-scss 3.0.0
#0 88.96 │ └─┬ stylelint-config-recommended-scss 5.0.2
#0 88.96 │   └─┬ postcss-scss 4.0.2
#0 88.96 │     └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 ├─┬ httpsnippet 2.0.0
#0 88.96 │ └─┬ fs-writefile-promise 1.0.3
#0 88.96 │   └─┬ mkdirp-promise 1.1.0
#0 88.96 │     └── ✕ missing peer<EMAIL_ADDRESS>#0 88.96 └─┬ nuxt 2.15.8
#0 88.96   ├─┬ @nuxt/components 2.2.1
#0 88.96   │ └── ✕ missing peer consola@"*"
#0 88.96   └─┬ @nuxt/builder 2.15.8
#0 88.96     └─┬ @nuxt/webpack 2.15.8
#0 88.96       └─┬ vue-loader 15.9.8
#0 88.96         └─┬ @vue/component-compiler-utils 3.3.0
#0 88.96           └─┬ consolidate 0.15.1
#0 88.96             ├── ✕ unmet peer<EMAIL_ADDRESS>found 4.2.0
#0 88.96             └── ✕ unmet peer<EMAIL_ADDRESS>found 7.0.0-bridge.0
#0 88.96 Peer dependencies that should be installed:
#0 88.96<EMAIL_ADDRESS>#0 88.96   consola@"*"
#0 88.96   eslint-plugin-import@"*"
#0 88.96<EMAIL_ADDRESS>#0 88.96<EMAIL_ADDRESS>#0 88.96<EMAIL_ADDRESS><3.0.0 || >=3.0.0-0 <3.0.0"
#0 88.96<EMAIL_ADDRESS><3.0.0"
#0 88.96<EMAIL_ADDRESS><3.0.0"
#0 88.96<EMAIL_ADDRESS><5.0.0 || >=5.0.0 <6.0.0"
#0 88.96
#0 88.96 hint: If you want peer dependencies to be automatically installed, add "auto-install-peers=true" to an .npmrc file at the root of your project.
#0 88.96 hint: If you don't want pnpm to fail on peer dependency issues, add "strict-peer-dependencies=false" to an .npmrc file at the root of your project.
#0 88.96
------
failed to solve: executor failed running [/bin/sh -c pnpm i --unsafe-perm=true]: exit code: 1

Any ideas ? Already tried auto-install-peers=truein .npmrc.

Did you apply the changes to the latest version of hoppscotch frontend? Or did you use my branch directly?

I have just updated to branch to match the current main branch op hoppscotch, it still doesn't work though in the Docker build (does work locally), not sure what changed. You can run pnpm config set strict-peer-dependencies false to fix it.
The env variables changed a bit due to the merge, it's now BACKEND_GQL_URL and BACKEND_WS_URL.

Thank you, finally I could run the docker image by adding RUN pnpm config set strict-peer-dependencies false && pnpm i --unsafe-perm=true to the Dockerfile. How does the data persistence work? In my instance I am not able to register an account. It's obvious that the SSO providers cannot work without further enhancements, but the method by mail also fails. I just see "FirebaseError: Firebase: Error (auth/requests-from-referer-https://hoppscotch.frontend.xxx.xxx.redacted.net-are-blocked.)." as visual error.

Nice! Sorry, there is no full blown setup guide yet, but honestly Hoppscotch was quite disappointing to me so I'm not really using it. You need to configure a few things to make it work:

Under Authentication -> Sign-in method you need to click Add new provider and add Email/Password. Under Authentication -> Settings -> Authorized domains you need to add the domain you're using for the frontend.
Under Firestore Database -> Rules you need to add these rules

Thanks it works now :-) I am open for alternatives.

Could not find any good alternatives that came close to Postman sadly. If Hoppscotch could do a bit more, like sharing variables and creating settings on folders (like auth things, so that you don't have to repeat it on every request), it would already be way better, but I keep coming back to Postman.

@schniggie just wanted to let you know that they have implemented "Team Environments" now, I have also implemented it in the backend :)

@schniggie just wanted to let you know that they have implemented "Team Environments" now, I have also implemented it in the backend :)

Awesome thank you so much :)


Add open preveiw action to port notification and setting

Add open preveiw action to port notification and setting

Enables distinct "Open in Browser" and "Open in Preview" actions in various forwarded ports entry points:

Enables distinct "Open in Browser" and "Open in Preview" actions in various forwarded ports entry points:

@mjbvz to enable the above "Open in Preview" actions, I needed to expose a bit more in the external uri service. Would you be able to review those changes?

@mjbvz to enable the above "Open in Preview" actions, I needed to expose a bit more in the external uri service. Would you be able to review those changes?

@mjbvz I've pulled in the duplicate/conflicting change around opener options, and responded to your comment.

@mjbvz I've pulled in the duplicate/conflicting change around opener options, and responded to your comment.

@mjbvz would you consider this for February?


Question on how to use static get method while using .withGraphFetched()

I want to be able to use my static get method as the result of my withGraphFetched(). Is there a way to do this?
Example:
User Model
const { Model } = require('objection');

class Users extends Model {
  static get tableName() {
    return 'users';
  }
  static get virtualAttributes() {
    return ['name'];
  }
  get name() {
    return `${this.lastName}, ${this.firstName}`;
  }

  get minimal() {
    return {
      name: this.name
    }
  }

  $formatJson() {
    return {
      firstName: this.firstName,
      lastName: this.lastName,
      name: this.name
    }
  }
}

module.exports = Users;

Pets Model
const { Model } = require('objection');

class Pets extends Model {
  static get tableName() {
    return 'pets';
  }
  static get relationMappings() {
    const Users = require('./Users');
    return {
      owner: {
        relation: Model.BelongsToOneRelation,
        modelClass: Users,
        join: {
          from: `${this.tableName}.userId`,
          to: `${Users.tableName}.${Users.idColumn}`
        }
      }
    };
  }
}

module.exports = Pets;

For my response I only want the virtual attribute I made from the get minimal() method I've defined in the Users model. I couldddd do this and it works, but I wondering if there's a better way of doing it?
const data = await Pets.query().findById(someId).withGraphFetched('owner');
console.log(data.owner); // ----> {firstName, lastName, name}
data.owner = data.owner.minimal;
console.log(data.owner); // ----> {name}

Is there another way of doing this? And if this has been answered before sorry! looked all over! And if I don't make any sense then please ask so I can explain a bit more 😅 .
Thanks!

You could make use of $afterFind method and context passing as follows.
In the User model
const { Model } = require("objection");

class Users extends Model {
  static get tableName() {
    return "users";
  }
  static get virtualAttributes() {
    return ["name"];
  }

  get name() {
    return `${this.lastName}, ${this.firstName}`;
  }

  $formatJson() {
    return {
      firstName: this.firstName,
      lastName: this.lastName,
      name: this.name,
    };
  }
}

module.exports = Users;

and in the Pet model
const { Model } = require("objection");

class Pets extends Model {
  static get tableName() {
    return "pets";
  }

  $afterFind(context) {
    if (context.minimal && this.owner && this.owner.name) {
      this.owner = { name: this.owner.name };
    }
  }

  static get relationMappings() {
    const Users = require("./Users");
    return {
      owner: {
        relation: Model.BelongsToOneRelation,
        modelClass: Users,
        join: {
          from: `${this.tableName}.userId`,
          to: `${Users.tableName}.${Users.idColumn}`,
        },
      },
    };
  }
}

module.exports = Pets;

Then you can query with minimal as
await Pets.query().findById(someId).withGraphFetched('owner').context({minimal: true});

Notice that if you don't use the context minimal: true the owner will be an instance of User as usual and not a POJO.

Mhmm I suppose this could work, though a bit awkward, I guess it makes sense if I wanna use the existing API capabilities.


Layout fix for 1.17

Currently the "use standard layout" option never activates. This fixes that by ignoring the three docks.
Eventually we'll want to use docks for our layout anyway, but this gives us a short term fix.

👍
Using Docks by default would be pretty cool

Yeah, docks have the right behaviour in a few places that we're currently hacking around.


[TFlite] unable to bazel build tensorflow/contrib/lite/toco:toco

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes and No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):  Linux Ubuntu 16.04)
TensorFlow installed from (source or binary): Source
TensorFlow version (use command below): 1.7
Python version:  2.7
Bazel version (if compiling from source): 0.13.0
GCC/Compiler version (if compiling from source): gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
CUDA/cuDNN version: 9 / 7
GPU model and memory: 4GB GTX 1050
Exact command to reproduce:

i trained a mask r-cnn model with mobilenet as backbone and i try to quantize it according to this guide: https://www.tensorflow.org/performance/quantization
My code looks like this:
MODEL_NAME="mask_rcnn_mobilenet_v1_400_coco_117k"

INPUT_FILE="models/${MODEL_NAME}/frozen_inference_graph.pb"
OUTPUT_FILE="models/${MODEL_NAME}/frozen_inference_graph.tflite"
INPUT_SHAPE="1,400,400,3"
INPUT_ARRAY=['image_tensor']
OUTPUT_ARRAY=['num_detections','detection_boxes','detection_scores','detection_classes','detection_masks']
STD_VALUE=127.5
MEAN_VALUE=127.5

bazel build tensorflow/contrib/lite/toco:toco && \
  ./bazel-bin/third_party/tensorflow/contrib/lite/toco/toco \
  --input_file=${INPUT_FILE} \
  --output_file=${OUTPU_FILE} \
  --input_format=TENSORFLOW_GRAPHDEF --output_format=TFLITE \
  --inference_type=QUANTIZED_UINT8 \
  --input_shape=${INPUT_SHAPE} \
  --input_array=${INPUT_ARRAY} \
  --output_array=${OUTPUT_ARRAY} \
  --std_value=${STD_VALUE} --mean_value=${MEAN_VALUE}

and this error i get:
ERROR: Skipping 'tensorflow/contrib/lite/toco:toco': no such package 'tensorflow/contrib/lite/toco': BUILD file not found on package path
WARNING: Target pattern parsing failed.
ERROR: no such package 'tensorflow/contrib/lite/toco': BUILD file not found on package path
INFO: Elapsed time: 1.132s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

Another thing i don't understand is that when i try to run this code in my custom model folder i see this error:
ERROR: The 'build' command is only supported from within a workspace.
What is this supposed to mean?
So i tried it in the tensorflow/models

https://github.com/tensorflow/tensorflow/issues/19525

i'm using 1.8.0 and having same issue

Perhaps add 'exports_files(["toco"])' to tensorflow/contrib/lite/BUILD

why add this ? I have got a same probilem such as GuatavZ ,what should I do ?

The toco target has been moved from //tensorflow/contrib/lite/toco to //tensorflow/lite/toco

The toco target has been moved from //tensorflow/contrib/lite/toco to //tensorflow/lite/toco

useful comment. thank you


Type Error : done is not a function

Hello i would try tutorial code but return error "TypeError: done is not a function"
It's return this error also when i not write anycode
Version in use v0.4.1

@junoprima which version of node-red and nodejs are you using? I found a reference for the change done in node-red v1.0 onwards. Are you using pre v1.0 version of node-red?

Nevermind, I saw you mentioned v0.4.1. If its possible for you to update your node-red version > v1.0 it will solve your issue. As per the link send above seems node-red introduced this change after v1.0

@junoprima which version of node-red and nodejs are you using? I found a reference for the change done in node-red v1.0 onwards. Are you using pre v1.0 version of node-red? If you can update you node-red to >v1.0 I believe it will solve your issue.

Thank for reply i upgrade my nodered from 1.0 to 1.1.2 it's useful thank for help


The SDK 'Microsoft.NET.Sdk' specified could not be found.

I'm 99% this isn't an issue with Omnisharp itself but I'm having trouble getting to the bottom of it. Basically, I'm seeing an error "The SDK 'Microsoft.NET.Sdk' specified could not be found." when I run VS Code on my Mac, except if I open VS Code as the root user, then everything is totally fine. So I'm looking for help to figure out what the cause there is (I'm assuming something that needs permissions fixed or something to that extent).
Environment Data
.NET Core SDK (reflecting any global.json):
 Version:   2.1.301
 Commit:    59524873d6

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.301/

Host (useful for support):
  Version: 2.1.1
  Commit:  6985b9f684

.NET Core SDKs installed:
  2.1.200 [/usr/local/share/dotnet/sdk]
  2.1.301 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Steps to reproduce
Open VS Code as a normal user and observe the "The SDK 'Microsoft.NET.Sdk' specified could not be found." error in the OmniSharp Logs. Open VS Code as root (by running sudo code) and this error is not observed, with everything operating as it should.
Expected behaviour
Running VS Code as a normal non-root user shouldn't prohibit Omnisharp from operating correctly.
Verbose logs
I've attached the verbose logs for a sample proect I've created trying to open VS code as a normal user and as a root user.

Non-root user
root user

Doing some homework on my logs - it looks like a key difference is that when I run as root it is finding and using mono instead of the standalone option. Digging through the code I can see the part that is running differently on my system - the "IsMono" property is the one that is coming up false (at least as best I can tell, all the other path options look correct). I'm still digging but I'm open to thoughts on this one

Closing this one off - the issue is to do with the way MacOS launches apps from finder or the Dock. When i just run code from terminal as a normal user it's fine.


[JENKINS-28824] Fix NPE on the build page when a build is running.

JENKINS-28824

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests


Connection agnostic crates

Currently most crates use a concrete type for connections, often std::net::TcpStream, but to support async I/O often a different connection type is need, e.g. tokio::net::TcpStream.
For example take the postgres crate, which uses std::net::TcpStream for blocking I/O. But to support async I/O tokio-postgres was created which uses tokio::net::TcpStream.
I think it would be worthwhile to create a generic Connection trait, which crates like postgres (but also e.g. hyper) can use as an abstract connection type. This can be used for both blocking and async I/O, where std::io::ErrorKind::WouldBlock errors are handled by the user of the crate.
This has two advantages:

Blocking and async I/O can be handled in the same code. This does require more attention then just writing blocking I/O code, i.e. the code needs to deal with an operation being restarted or it needs to support some kind of checkpointing, much like most Futures.
Support for various async I/O types in the same crate. Tokio has it's own TcpStream, but so does Mio and so does the standard libary. Supporting a single generic connection type would support also three those types with the same code (assuming they implement the correct trait).

Possible design
A simple design would be the following.
use std::io::{Read, Write};

trait Connection: Read + Write { }

And add documentation that the Connection can return std::io::ErrorKind::WouldBlock which isn't really an error and the crate must gracefully handle it.
This assumes that calling read/write on a concrete type does wake itself when it returns WouldBlock, in the context of using futures. I believe this already the case for both Tokio and mio.
Future-io's AsyncRead and AsyncWrite
For async I/O the futures-io crate provides special read and write traits that hook into the task system. These trait could also be used rather then Read and Write. The downside of this is that  blocking I/O won't be supported anymore.
Thoughts?

For example take the postgres crate, which uses std::net::TcpStream for blocking I/O. But to support async I/O tokio-postgres was created which uses tokio::net::TcpStream.

The fact that these types are different is not what prevents the two crates from sharing code. Their implementations are fundamentally and significantly different.

@sfackler I'm not familiar with the codebase, however do you think that when using a generic connection type, like proposed, the code base could share more code?
For example I've writing a client libary with Redis to experiment with this idea. It uses a future like pattern where a Request object is returned when issueing a command (likely a query in case of postgres). This Request can be polled (without arguments) until completion (like a future), in case of blocking I/O this will be a single call. The Request itself is basically a state machine; first write the command and then read the response.

hyper has done this for a while: it works with any transport type that is AsyncRead + AsyncWrite.

when using a generic connection type, like proposed, the code base could share more code?

Nothing is preventing it from using a generic connection type right now! It wouldn't enable any more code reuse between the async and sync implementations, at least as currently designed.

I think it would be worthwhile to create a generic Connection trait, which crates like postgres (but also e.g. hyper) can use as an abstract connection type. This can be used for both blocking and async I/O, where std::io::ErrorKind::WouldBlock errors are handled by the user of the crate.

I'm not quite sure what you mean here, but I think it effectively makes everything async (or at least as difficult to code as async, in terms of managing internals states with partial IO). But postgres would need to handle it internally - the user of the postgres crate couldn't do it without knowing postgres's internal state. (If postgres gets a partial response from the socket and returns WouldBlock to its user, what does it do with that partial response? What's the caller supposed to do with the WouldBlock?)

@jsgf When it reads a partial response it would store that in a bytes buffer, e.g. Vec<u8>, then it would return WouldBlock (or call read again to make the underlying connection returns WouldBlock). The caller needs to call poll again if WouldBlock is returned.
In case of blocking I/O most of them don't return partial responses, they return whatever is currently is in the buffer or blocking until something is written into it. That means that if only a part of a response is read the crate needs to call read again, which then blocks again.
For example: say when have Postgres client which sends an request. Then Postgres response with only half of the response initially. The client can then read the first half of the request and start parsing it. If it can't deal with partial requests it can just call read again and block until the entire request in read into a buffer.


Context consistency check

This introduces a cheap and simple (but not flawless) mechanism to detect word tearing when threads are interrupted as contexts are written. This mechanism has false negatives but they are very unlikely, especially conditioned on the likelihood of writing a context during an interrupt.
It also passes the now much larger context objects by reference.

Merging but any ensuing comments will still be acted upon


pushing to tiktok

hi there! i'm trying to push an rtmp stream to tiktok but i run into a problem with authentication. the url is something like this:
rtmps://push-rtmp-f5-va01.tiktokcdn.com:443/game/stream-XXX?expire=XXX&sign=XXX
looking at the log i see these lines:
Stripping target options: expire=XXX&sign=XXX
Received error response: NetStream.Publish.InvalidSign; func:OnStatus:func:RtmpStatusCode2NssError:invalid_sign
why is mistserver stripping part of the url? what can i do? many thanks!

Hey there!
Mist supports receiving further options are query parameters, so anything following a question mark symbol gets parsed as options.
If you want to forward such parameters unchanged, simply follow the URL with an extra ? at the end, as we only parse parameters after the last question mark symbol in the URL.
So, instead of rtmps://push-rtmp-f5-va01.tiktokcdn.com:443/game/stream-XXX?expire=XXX&sign=XXX you'd use rtmps://push-rtmp-f5-va01.tiktokcdn.com:443/game/stream-XXX?expire=XXX&sign=XXX?
Hope that helps!

Hey there,
As explained in the manual
https://mistserver.org/guides/MistServer_Manual_3.0.pdf (2.4.1)
MistServer will strip anything of the stream URL from the last "?" as it
expects MistServer specific selection parameters there. In order to fix
your problem simply use your push url:
rtmps://
push-rtmp-f5-va01.tiktokcdn.com:443/game/stream-XXX?expire=XXX&sign=XXX
and add an additional ? to the end:
rtmps://
push-rtmp-f5-va01.tiktokcdn.com:443/game/stream-XXX?expire=XXX&sign=XXX?
We do plan to make some adjustments to the interface in the future to make
this a bit easier to spot when you're starting a push.
With kind regards,
Balder Viëtor
Head of Testing
On Tue, Jun 14, 2022 at 12:54 PM mishcazzulani @.***>
wrote:

hi there! i'm trying to push an rtmp stream to tiktok but i run into a
problem with authentication. the url is something like this:
rtmps://
push-rtmp-f5-va01.tiktokcdn.com:443/game/stream-XXX?expire=XXX&sign=XXX
looking at the log i see these lines:
Stripping target options: expire=XXX&sign=XXX
Received error response: NetStream.Publish.InvalidSign;
func:OnStatus:func:RtmpStatusCode2NssError:invalid_sign
why is mistserver stripping part of the url? what can i do? many thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/DDVTECH/mistserver/issues/46, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN2RJEMLDC4LEXGEG6UYGTVPBQGLANCNFSM5YXIEFVA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Impossible to extend the configuration as it's explained in the sample config.

...
class SLIRConfig extends SLIRConfigDefaults
...
All the attributes and the init method are defined as static in the SLIRConfigDefaults class.
So, there's no way to extend them from the SLIRConfig class.
More specifically SLIRConfigDefaults::init() will override all the "extended" attributes from SLIRConfig.
The way to extend static variables is using late static bindings (only PHP >5.3).
More info: http://php.net/manual/en/language.oop5.late-static-bindings.php
I think the configuration guide is misleading in this point.
Btw, the library is excellent, great job!

Php 5.3 is now old. This issue is not relevant anymore.


Delete confirmation dialogue is unreadable

When I try to delete a note, it shows only squares.
The official AppImage does not have this problem, so it's likely that it's some issue with the Snap image.

PS: Thank you for your Snap image :+1:

This is a big problem that a lot of snaps have. I can't say I completely understand the nuances behind it, but it's generally speaking an incompatibility between the version of fontconfig in the snap and the fontconfig on the system host. Generally I see this pop up in snaps run mostly on Arch/Manjaro and occasionally Fedora.
From what I know of the issue, this is very likely to fix it for you:
rm -rf ~/.cache/fontconfig  sudo fc-cache -r -v rm ~/snap/joplin-james-carroll/common/.cache/fontconfig/
This should regenerate the system font cache, and then trigger the snap into copying it over fresh when it's next run.
As far as fixing this for everyone generally goes, there's discussion about how the snapd designers would like to approach it happening, but as far as my specific involvement goes, I'm lead to believe it'll just happen eventually when the gnome-platform snap this is dependent on incorporates the proper fix, but I couldn't say when that might happen.

Indeed, this fixed it! Thank you! :pray:

Generally I see this pop up in snaps run mostly on Arch/Manjaro and occasionally Fedora.

In my case this happened on Ubuntu 20.04.

there's discussion about how the snapd designers would like to approach it happening

Can you please provide a link where this discussion is happening?
Thank you in advance!

The information is spread out over a lot of threads on the Snapcraft forums and possibly elsewhere, but the single biggest thread which has the comments about how a future update to the gnome platform snaps will hopefully fix this is here:
https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484
Thanks for all the feedback, it's good to know that the font config fix does actually work; I've never personally had the problem and my understanding is 99% of people seemingly don't but there's still a substantial amount of people who have this problems with snaps and squaress for letters consistently so hopefully the proposed fixes will solve this properly.
I'd expect you to not need to rerun the font cache generation again, but for any snaps you might already have installed that might have internal copies of the older cache you'll probably find removing their internal font config caches should clear them up too and hopefully any new snaps will just be fine now.

This is fixed properly for snaps built on Snapcraft 4.4+ using a Snapcraft extension. For this Joplin Snap, versions 1.3+.

This is fixed properly for snaps built on Snapcraft 4.4+ using a Snapcraft extension. For this Joplin Snap, versions 1.3+.

Since this issue still occurs for me: do I have to install some extension or so to have it fixed?

This is fixed properly for snaps built on Snapcraft 4.4+ using a Snapcraft extension. For this Joplin Snap, versions 1.3+.

Since this issue still occurs for me: do I have to install some extension or so to have it fixed?

A Snapcraft extension refers to adding a single line to the snapcraft.yaml like this,
https://github.com/MrCarroll/joplin-snap/blob/163b1ca52323661dd78959d240856ba8bad61843/snap/snapcraft.yaml#L93
What it actually does is transform the build file just before its been processed and adds sensible defaults and wrappers to the snap. Particularly with 4.4+ of Snapcraft, the Gnome extensions were refactored so that they used private font caches per snap, so the font caches are generated with the Gnome platform snaps own binaries. In theory this should have been the magic fix for you, but in practise here we are. I have certainly noticed it have benefits, but edge cases still exist like yourself.
End users don't have to do anything to benefit from this, but the snap author does (Rebuild on 4.4+, using the extension, and publish it). There's a second issue with Electron apps though, because a lot of people distribute Electron snaps with Electron Builder rather than Snapcraft, and from what I see it basically ignores modern practises (E.G, doesn't build in a fresh container, doesn't benefit from improvements in the Snapcraft tool since it avoids it and writes the manifest files manually, etc). From what I remember, Electron Builder probably doesn't use extensions at all, because it only really applies to Snapcraft, the build tool, not snap/snapd. So without taking a closer look at the Super-Productivity snap itself, I'd guess it isn't using the Snapcraft Extensions at all. (I've only just seen the linked issue now but I assume it's still relevant).
My recommendation generally is that people avoid Electron Builder for snaps. Whilst it's nice to have the one build tool for everything Electron, it really isn't that hard to get by without it, and there's big benefits in treating Electron apps the same as every other snap. If you look at this repo as an example, you generally just treat it as if it was an AppImage and just extract the contents into the right folder so they end up in the snap directly instead, it's not generally too hard, and there's Github Actions and Launchpad that can simplify automating it.
As an aside, since you have had this font error for months and you seem more willing than most to try fix it, you might want to make an account at https://forums.snapcraft.io and have a chat with some of the core snapd devs there, where you might be able to get some more direct support from people about your unique machine. Otherwise, I'm hoping there'll be an extension for the Core20 base snap soon to upgrade to, and this should be another good chance at fixing this problem for you at least in Joplin's snap specifically.

A Snapcraft extension refers to adding a single line to the snapcraft.yaml like this,
https://github.com/MrCarroll/joplin-snap/blob/163b1ca52323661dd78959d240856ba8bad61843/snap/snapcraft.yaml#L93
What it actually does is transform the build file just before its been processed and adds sensible defaults and wrappers to the snap. Particularly with 4.4+ of Snapcraft, the Gnome extensions were refactored so that they used private font caches per snap, so the font caches are generated with the Gnome platform snaps own binaries. In theory this should have been the magic fix for you, but in practise here we are. I have certainly noticed it have benefits, but edge cases still exist like yourself.
End users don't have to do anything to benefit from this, but the snap author does (Rebuild on 4.4+, using the extension, and publish it). There's a second issue with Electron apps though, because a lot of people distribute Electron snaps with Electron Builder rather than Snapcraft, and from what I see it basically ignores modern practises (E.G, doesn't build in a fresh container, doesn't benefit from improvements in the Snapcraft tool since it avoids it and writes the manifest files manually, etc). From what I remember, Electron Builder probably doesn't use extensions at all, because it only really applies to Snapcraft, the build tool, not snap/snapd. So without taking a closer look at the Super-Productivity snap itself, I'd guess it isn't using the Snapcraft Extensions at all. (I've only just seen the linked issue now but I assume it's still relevant).
My recommendation generally is that people avoid Electron Builder for snaps. Whilst it's nice to have the one build tool for everything Electron, it really isn't that hard to get by without it, and there's big benefits in treating Electron apps the same as every other snap. If you look at this repo as an example, you generally just treat it as if it was an AppImage and just extract the contents into the right folder so they end up in the snap directly instead, it's not generally too hard, and there's Github Actions and Launchpad that can simplify automating it.
As an aside, since you have had this font error for months and you seem more willing than most to try fix it, you might want to make an account at https://forums.snapcraft.io and have a chat with some of the core snapd devs there, where you might be able to get some more direct support from people about your unique machine. Otherwise, I'm hoping there'll be an extension for the Core20 base snap soon to upgrade to, and this should be another good chance at fixing this problem for you at least in Joplin's snap specifically.

Thank you for responding so fast and clearly, James.

the font caches are generated with the Gnome platform snaps own binaries

This probably explains, why regenerating the font cache doesn't work anymore.

Thank you for responding so fast and clearly, James.

the font caches are generated with the Gnome platform snaps own binaries

This probably explains, why regenerating the font cache doesn't work anymore.

Before 4.4, everytime you run a snap it checked to see if the font caches existed, needed updating, and actually updated it. After 4.4 (with extensions of course), it runs once everytime a snap runs its configure hook (I.E, everytime its updated, freshly installed, or the snap set command is used). It also started placing the output at ~/snap/example/common/fontconfig instead of the previous location.
If you were to delete it, I'm unsure what would actually happen because nothing would recreate it until the next update, it might simply continue to work but the first time a GTK dialog box opens have a small delay.
The relevant code for making the fontconfig in the modern system is here https://github.com/snapcore/snapcraft/blob/master/extensions/desktop/common/fonts, so you might be able to recreate it yourself if you fancy experimenting.

Before 4.4, everytime you run a snap it checked to see if the font caches existed, needed updating, and actually updated it. After 4.4 (with extensions of course), it runs once everytime a snap runs its configure hook (I.E, everytime its updated, freshly installed, or the snap set command is used). It also started placing the output at ~/snap/example/common/fontconfig instead of the previous location.
If you were to delete it, I'm unsure what would actually happen because nothing would recreate it until the next update, it might simply continue to work but the first time a GTK dialog box opens have a small delay.
The relevant code for making the fontconfig in the modern system is here https://github.com/snapcore/snapcraft/blob/master/extensions/desktop/common/fonts, so you might be able to recreate it yourself if you fancy experimenting.

I just tried to run snap run --shell joplin-james-carroll.joplin and fc-cache -r -v within that container but it didn't help.
Also the message after entering the container said To run a command as administrator (user "root"), use "sudo <command>". but when I tried to call fc-cache with prepended sudo I'm getting bash: /usr/bin/sudo: Permission denied.
It seems that Snap itself still has some issues. :wink:

I just tried to run snap run --shell joplin-james-carroll.joplin and fc-cache -r -v within that container but it didn't help.
Also the message after entering the container said To run a command as administrator (user "root"), use "sudo <command>". but when I tried to call fc-cache with prepended sudo I'm getting bash: /usr/bin/sudo: Permission denied.
It seems that Snap itself still has some issues. :wink:

I've just reread the code, it's been a while since I'd last looked at it.
Everytime the configure hook runs, it generates a cache of the system fonts, using the font cache from the Gnome platform snap. This is stored in /var/snap/joplin-james-carroll/common/fontconfig, not ~/snap/joplin-james-carroll/common/fontconfig, which did exist when I installed fresh on a VM and I've no idea why. The /var fontconfig has all the actual binary cache files, and a single config file.
You can trigger the configure hook to run by doing snap set joplin-james-carroll null=null, so no need to mess with the snap run --shell above.
There's also still ~/joplin-james-carroll/current/.config/fontconfig, the fonts.conf here points to the /var one above. So without this in place, then the system caches won't be accessible either.
That folder is generated every time a new revision occurs, with a seperate mechanism to the config hook. You can trigger it to be rebuilt with rm ~/snap/joplin-james-carroll/current/.last-revision.
So with the above two commands, we can at least get everything back to being a consistent state.
Could you give the output of cat ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.conf after running the two above please.

I've just reread the code, it's been a while since I'd last looked at it.
Everytime the configure hook runs, it generates a cache of the system fonts, using the font cache from the Gnome platform snap. This is stored in /var/snap/joplin-james-carroll/common/fontconfig, not ~/snap/joplin-james-carroll/common/fontconfig, which did exist when I installed fresh on a VM and I've no idea why. The /var fontconfig has all the actual binary cache files, and a single config file.
You can trigger the configure hook to run by doing snap set joplin-james-carroll null=null, so no need to mess with the snap run --shell above.
There's also still ~/joplin-james-carroll/current/.config/fontconfig, the fonts.conf here points to the /var one above. So without this in place, then the system caches won't be accessible either.
That folder is generated every time a new revision occurs, with a seperate mechanism to the config hook. You can trigger it to be rebuilt with rm ~/snap/joplin-james-carroll/current/.last-revision.
So with the above two commands, we can at least get everything back to being a consistent state.
Could you give the output of cat ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.conf after running the two above please.

This is the output of cat ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.conf:
<fontconfig>
  <dir>/home/username/.fonts</dir>
  <include ignore_missing="yes">conf.d</include>
  <include ignore_missing="yes">/snap/joplin-james-carroll/46/gnome-platform/etc/fonts/fonts.conf</include>
  <cachedir prefix="xdg">fontconfig</cachedir>
  <cachedir>/var/snap/joplin-james-carroll/common/fontconfig</cachedir>
</fontconfig>

PS: It was ~/snap/joplin-james-carroll/current/.last_revision for me – with an underscore at last_revision

This is the output of cat ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.conf:
<fontconfig>
  <dir>/home/username/.fonts</dir>
  <include ignore_missing="yes">conf.d</include>
  <include ignore_missing="yes">/snap/joplin-james-carroll/46/gnome-platform/etc/fonts/fonts.conf</include>
  <cachedir prefix="xdg">fontconfig</cachedir>
  <cachedir>/var/snap/joplin-james-carroll/common/fontconfig</cachedir>
</fontconfig>

PS: It was ~/snap/joplin-james-carroll/current/.last_revision for me – with an underscore at last_revision

My bad, I edited the above last_revision to be correct.
I've noticed today there's progress on the Gnome extensions for the Core20 base snap, this might take a few weeks to become properly available but it's good news because the Core20 base may have a chance of improving this with the more recent font libraries it'll allow for.
In the meantime, your fontconfig above shows you have user specific fonts in ~/.fonts , just for testing purposes it might be worth renaming ~/.fonts so it's not found, regenerate the font caches on the system, delete the snaps .last_revision and see if it improves. If it doesn't, feel free to put your fonts back in right place, and try simply removing <dir>/home/username/.fonts</dir> and <cachedir prefix="xdg">fontconfig</cachedir> from the fontconfig in the snap manually.
Essentially, I'm thinking there's a chance that some of the local fonts in ~/.fonts are causing issues, and it might be one bad font causes the whole thing to come tumbling down, so avoiding importing them into the snap might be helpful.

My bad, I edited the above last_revision to be correct.
I've noticed today there's progress on the Gnome extensions for the Core20 base snap, this might take a few weeks to become properly available but it's good news because the Core20 base may have a chance of improving this with the more recent font libraries it'll allow for.
In the meantime, your fontconfig above shows you have user specific fonts in ~/.fonts , just for testing purposes it might be worth renaming ~/.fonts so it's not found, regenerate the font caches on the system, delete the snaps .last_revision and see if it improves. If it doesn't, feel free to put your fonts back in right place, and try simply removing <dir>/home/username/.fonts</dir> and <cachedir prefix="xdg">fontconfig</cachedir> from the fontconfig in the snap manually.
Essentially, I'm thinking there's a chance that some of the local fonts in ~/.fonts are causing issues, and it might be one bad font causes the whole thing to come tumbling down, so avoiding importing them into the snap might be helpful.

In the meantime, your fontconfig above shows you have user specific fonts in ~/.fonts , just for testing purposes it might be worth renaming ~/.fonts so it's not found, regenerate the font caches on the system, delete the snaps .last_revision and see if it improves.

I just did (including sudo snap set joplin-james-carroll null=null just to be sure).
The conf doesn't contain the local font directory anymore:
<fontconfig>
  <include ignore_missing="yes">conf.d</include>
  <include ignore_missing="yes">/snap/joplin-james-carroll/46/gnome-platform/etc/fonts/fonts.conf</include>
  <cachedir prefix="xdg">fontconfig</cachedir>
  <cachedir>/var/snap/joplin-james-carroll/common/fontconfig</cachedir>
</fontconfig>

But the about dialogue still shows block gibberish instead of a proper font.

If it doesn't, feel free to put your fonts back in right place, and try simply removing <dir>/home/username/.fonts</dir> and <cachedir prefix="xdg">fontconfig</cachedir> from the fontconfig in the snap manually.

Removing <cachedir prefix="xdg">fontconfig</cachedir> helped! :tada:

Essentially, I'm thinking there's a chance that some of the local fonts in ~/.fonts are causing issues, and it might be one bad font causes the whole thing to come tumbling down, so avoiding importing them into the snap might be helpful.

Is there a proper way to debug 'bad fonts'?

In the meantime, your fontconfig above shows you have user specific fonts in ~/.fonts , just for testing purposes it might be worth renaming ~/.fonts so it's not found, regenerate the font caches on the system, delete the snaps .last_revision and see if it improves.

I just did (including sudo snap set joplin-james-carroll null=null just to be sure).
The conf doesn't contain the local font directory anymore:
<fontconfig>
  <include ignore_missing="yes">conf.d</include>
  <include ignore_missing="yes">/snap/joplin-james-carroll/46/gnome-platform/etc/fonts/fonts.conf</include>
  <cachedir prefix="xdg">fontconfig</cachedir>
  <cachedir>/var/snap/joplin-james-carroll/common/fontconfig</cachedir>
</fontconfig>

But the about dialogue still shows block gibberish instead of a proper font.

If it doesn't, feel free to put your fonts back in right place, and try simply removing <dir>/home/username/.fonts</dir> and <cachedir prefix="xdg">fontconfig</cachedir> from the fontconfig in the snap manually.

Removing <cachedir prefix="xdg">fontconfig</cachedir> helped! :tada:

Essentially, I'm thinking there's a chance that some of the local fonts in ~/.fonts are causing issues, and it might be one bad font causes the whole thing to come tumbling down, so avoiding importing them into the snap might be helpful.

Is there a proper way to debug 'bad fonts'?

Woohoo! Progress at last :)!
Just to confirm, is it exclusively  <cachedir prefix="xdg">fontconfig</cachedir> that needs to be removed to get everything working? I.E, I could just tell people to run sed -i '/<cachedir prefix="xdg"/ d' ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.config as a magic one liner for people with the issue?
I'm not exactly sure how to debug this further, but I think this is worth following up with Sergio in https://github.com/MrCarroll/joplin-snap/issues/7 and he might have some ideas on how to diagnose you more individually and how to apply it to the Snap ecosystem in general.
From my side, waiting on the core20 migration is still a possible fix but I could potentially also run the sed command for users by default too, it's worth considering.

Woohoo! Progress at last :)!
Just to confirm, is it exclusively  <cachedir prefix="xdg">fontconfig</cachedir> that needs to be removed to get everything working? I.E, I could just tell people to run sed -i '/<cachedir prefix="xdg"/ d' ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.config as a magic one liner for people with the issue?
I'm not exactly sure how to debug this further, but I think this is worth following up with Sergio in https://github.com/MrCarroll/joplin-snap/issues/7 and he might have some ideas on how to diagnose you more individually and how to apply it to the Snap ecosystem in general.
From my side, waiting on the core20 migration is still a possible fix but I could potentially also run the sed command for users by default too, it's worth considering.

Just to confirm, is it exclusively  <cachedir prefix="xdg">fontconfig</cachedir> that needs to be removed to get everything working? I.E, I could just tell people to run sed -i '/cachedir prefix="xdg"/ d' ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.conf as a magic one liner for people with the issue?

It seems like it. I just 'resetted' everything and got the font bug again. I stopped Joplin, removed the cachedir prefix and everything was readable again.
I don't understand the relations between those but it seems indeed to work.

Just to confirm, is it exclusively  <cachedir prefix="xdg">fontconfig</cachedir> that needs to be removed to get everything working? I.E, I could just tell people to run sed -i '/cachedir prefix="xdg"/ d' ~/snap/joplin-james-carroll/current/.config/fontconfig/fonts.conf as a magic one liner for people with the issue?

It seems like it. I just 'resetted' everything and got the font bug again. I stopped Joplin, removed the cachedir prefix and everything was readable again.
I don't understand the relations between those but it seems indeed to work.

Thanks for all your help here. I know this problem has persisted with you for a long time and most people would probably have abandoned snaps by now as a result of it, so you've gone above and beyond here, sincereley, thanks a lot!
There's a good chance this would probably still work for super-productivity and others even if it isn't using the extensions, it might have a bit more of an obvious delay since it won't have at least some of the caches in /var, but hopefully its something.

Thanks for all your help here. I know this problem has persisted with you for a long time and most people would probably have abandoned snaps by now as a result of it, so you've gone above and beyond here, sincereley, thanks a lot!
There's a good chance this would probably still work for super-productivity and others even if it isn't using the extensions, it might have a bit more of an obvious delay since it won't have at least some of the caches in /var, but hopefully its something.

Thanks for all your help here.

No, I have to thank you!
PS: Are you maintaining all of those Snaps in your free time?

Thanks for all your help here.

No, I have to thank you!
PS: Are you maintaining all of those Snaps in your free time?

Thanks for the kindness :)
I do maintain all these in my free time, but fortunately it doesn't take much overall, and it gives me a hobby and something to write about on my CV's so it's all good.

Thanks for the kindness :)
I do maintain all these in my free time, but fortunately it doesn't take much overall, and it gives me a hobby and something to write about on my CV's so it's all good.

This might be a strange idea:
Can you test whether removing the cachedir thingy is doing any harm in your tests?
If it doesn't: would it make sense to automatically remove this line when executing Joplin until this issue is solved globally?
Something like sed …; …/bin/JoplinApp?

This might be a strange idea:
Can you test whether removing the cachedir thingy is doing any harm in your tests?
If it doesn't: would it make sense to automatically remove this line when executing Joplin until this issue is solved globally?
Something like sed …; …/bin/JoplinApp?

It's exactly what I was considering, however I'm holding back hoping that Core20 with the new extensions might improve things first, since I'm hopeful it might be available soon. https://github.com/snapcore/snapcraft/pull/3407
Currently, people will likely try the snap, see its broken, and either look for and acquire a fix or avoid the snap entirely. I think this is probably better than implementing a temporary fix now, doing the Core20 transition, and then possibly breaking them after they've already made some commitment.
If/when Core20 drops, assuming it doesn't fix the problem for you, I'd make the sed default. The slowdown from the lack of font caches isn't going to be noticable, but the broken fonts certainly are.
Unfortunately I've just pushed a new revision to stable tonight so you'll have to run sed again soon. But depending how quickly 1.7 and the Core 20 extension drops, it might be the last :)

It's exactly what I was considering, however I'm holding back hoping that Core20 with the new extensions might improve things first, since I'm hopeful it might be available soon. https://github.com/snapcore/snapcraft/pull/3407
Currently, people will likely try the snap, see its broken, and either look for and acquire a fix or avoid the snap entirely. I think this is probably better than implementing a temporary fix now, doing the Core20 transition, and then possibly breaking them after they've already made some commitment.
If/when Core20 drops, assuming it doesn't fix the problem for you, I'd make the sed default. The slowdown from the lack of font caches isn't going to be noticable, but the broken fonts certainly are.
Unfortunately I've just pushed a new revision to stable tonight so you'll have to run sed again soon. But depending how quickly 1.7 and the Core 20 extension drops, it might be the last :)

I've pushed a short lived branch of core20, would you mind giving it a go and seeing if it works with your fonts?
You can access it with sudo snap refresh joplin-james-carroll --channel=stable/core20-beta and it should transition back onto the normal stable releases when I pull it from the store.

I've pushed a short lived branch of core20, would you mind giving it a go and seeing if it works with your fonts?
You can access it with sudo snap refresh joplin-james-carroll --channel=stable/core20-beta and it should transition back onto the normal stable releases when I pull it from the store.

It seems to work out of the box. :+1:
How can I migrate back to the stable release?

It seems to work out of the box. :+1:
How can I migrate back to the stable release?

When the next revision is pushed you'll migrate back to the same channel as everybody else automatically, aside from the working fonts I wouldn't imagine it to be any different to the current main stable release.
Otherwise I think the snap revert command can help you, but it'll disable automatic updates until you return the next refresh manually, and would revert any modifications made to your notes, so generally I'd imagine you're fine being on core20 until I push everybody else on it too for 1.7
Glad to hear this is eventually working for you out of the box :)!

When the next revision is pushed you'll migrate back to the same channel as everybody else automatically, aside from the working fonts I wouldn't imagine it to be any different to the current main stable release.
Otherwise I think the snap revert command can help you, but it'll disable automatic updates until you return the next refresh manually, and would revert any modifications made to your notes, so generally I'd imagine you're fine being on core20 until I push everybody else on it too for 1.7
Glad to hear this is eventually working for you out of the box :)!


Barcode scanner scanning invalid barcode

Hi
I have some scannig issue with this plugin that i am not able to scan some QRCode or Barcode properly throgh vision-camera. Please let me know if you have any solution.
Below i have added QR Code image which is not being scanned. When i scan it, it takes 'I' as a prefix
QR Code Image :

Below i have added Barcode image which is not being scanned

Here i have added a video.
https://user-images.githubusercontent.com/25951058/223137167-401d2884-ed1b-456e-8c24-d90f99415e5a.mp4

Try this https://www.youtube.com/watch?v=sE0MEyFA7E4&list=PLQhQEGkwKZUrempLnmxjt7ZCZJu1W3p2i&index=7 & https://www.youtube.com/watch?v=BFkIIIKgjnE&list=PLQhQEGkwKZUrempLnmxjt7ZCZJu1W3p2i&index=80


Only featured asset is shown

Reproduction

go Vendure /admin/catalog/products/1 (laptop)
add 2nd asset i.e 22
two assets are in place, /shop-api:

{
  product(id: "1") {
    assets {
      id
    }
  }
}
{
  "data": {
    "product": {
      "assets": [
        {
          "id": "1"
        },
        {
          "id": "22"
        }
      ]
    }
  }
}

only the first asset is shown /p/1/laptop in the storefront

Will be solved with #196


Cannot load projects in VS 2019

Prerequisites

[x] I have written a descriptive issue title
[x] I have verified that I am running the latest version of Nancy
[x] I have verified if the problem exist in both DEBUG and RELEASE mode
[x] I have searched open and closed issues to ensure it has not already been reported

Description
In Visual Studio 2019 I cannot load any of the projects in solution
Steps to Reproduce
Clone repo, open in fresh installation of Visual Studio 2019 - all projects are in "load failed" state.
Error says:
C:\git\NancyFX\src\Nancy\Nancy.csproj : error  : The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found.
Detailed Information:
Unable to locate the .NET Core SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.
System Configuration
VS Professional 2019 v 16.1.0; SDKs installed:
2.1.602
2.1.700
2.2.202
2.2.300

Is your visual studio configured for .NET Core projects?  It is an
additional feature you have to select when installing visual studio.
On Thu, May 23, 2019 at 10:42 AM duginov<EMAIL_ADDRESS>wrote:

Prerequisites

I have written a descriptive issue title
I have verified that I am running the latest version of Nancy
I have verified if the problem exist in both DEBUG and RELEASE mode
I have searched open https://github.com/NancyFx/Nancy/issues and
closed
https://github.com/NancyFx/Nancy/issues?q=is%3Aissue+is%3Aclosed
issues to ensure it has not already been reported

Description
In Visual Studio 2019 I cannot load any of the projects in solution
Steps to Reproduce
Clone repo, open in fresh installation of Visual Studio 2019 - all
projects are in "load failed" state.
Error says:
C:\git\NancyFX\src\Nancy\Nancy.csproj : error : The project file cannot
be opened by the project system, because it is missing some critical
imports or the referenced SDK cannot be found.
Detailed Information:
Unable to locate the .NET Core SDK. Check that it is installed and that
the version specified in global.json (if any) matches the installed
version.
System Configuration
VS Professional 2019 v 16.1.0; SDKs installed:
2.1.602
2.1.700
2.2.202
2.2.300
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/NancyFx/Nancy/issues/2964?email_source=notifications&email_token=ABASFFQRJ5LL24LAKO6DB4TPW3CQDA5CNFSM4HPIMBYKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GVQL6MQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABASFFX2O4BFUPPNKIEA4OTPW3CQDANCNFSM4HPIMBYA
.

--
Jonathon Koyle

Everything that could be (even remotely) related is already installed:
https://i.imgur.com/8vSXb2c.png

The global.json requires 2.1.4 of the sdk so you'll need to make sure that's installed for the projects to load.
https://dotnet.microsoft.com/download/dotnet-core/2.0#sdk-2.1.4

Thanks. I didn't realize that SDK versions are misaligned with .NET Core/Runtime versions (2.0.x vs 2.1.x)


Multi-chain ecosystem new line

Currently looks like:

Should be Figma:

Same for

Fixed in https://github.com/NEARBuilders/gateway/commit/c454d0dd2e7aa445773d46bd1dbd0fbec9689500


Feature lint and docs

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


docs: add Install, Use, Learn, & Contribute

Copied How it Works from current https://raen.dev/admin
Copied Install and Use from https://raen.dev/docs, with some additions
from https://near-sdk.io/
Added a "Contribute" section stub

@willemneal thinking about it more, it feels unusual for a CLI project's GitHub README to link away for installation instructions. I decided to copy both installation instructions and usage instructions from current https://raen.dev/docs to this README, with some extra detail copied from https://near-sdk.io. It's very common for project READMEs to include all of these as well as a Contribute section, so I also added a "Contribute" stub at the end. If you like it all living here, we could stop linking to /docs and link here instead, and eventually remove the docs repo.

Yeah I figured that the docs section could also cover things like common errors and more technical details.  But I'm definitely down to keep the install directions front and center.

Yeah, /docs could be a great place for more advanced information, but I think for install and basic usage we could link to this repo. I'll change current links to /docs to this project instead, for now, and we can start linking to /docs when it becomes a more useful deep-dive into various topics.

Do you approve the current README, @willemneal?


Refactor/project structure

This PR looks weird to me right now, so let's close and have a better plan for project structure


Add highlights for week ending September 08, 2022

Add highlights for week ending September 08, 2022
Please remember to

[ ] Give the PR a meaningful title -- it will be shown in the release notes
[ ] Add (or remove) user questions associated with any updated docs

@weatherhog @marians @anvddriesch anything from your teams?

nothing from atlas and cabbage

nothing from Phoenix

@marians @kuosandys I am a bit confused: I see a reference to kubectl-gs 2.21 while i see that last release of kubectl-gs is 2.20: this is going out today in 1 hour, is there something I am missing or this announcement about this feature should be kept for next week?

Since there is only one item under "User Interfaces", I would remove the bullet.

@kuosandys @stone-z @marians @piontec can someone pls review the changes so that I can merge this?


Consider moving signal descriptions to a project markdown file

Re:#522, #530 implements a method of authoring signal descriptions using a Google Doc with markdown-like content.
We should investigate using a local project markdown file so this content can be properly versioned and remove a network call from the build process.  It'd be a bummer if we couldn't build a release if we couldn't pull down the doc for whatever reason.
We'll just have to consider the authoring experience, but GitHub already has a good support for previewing markdown.

we we merge this with https://github.com/cmu-delphi/www-covidcast/issues/522?

My thought was that we could close #522 out with #530 since it's an improvement, and discuss enhancements from that here.

As context, the main motivation with using a Google Doc is to facilitate commenting and discussion. Often we argue about the best wording to describe an indicator, or the wording that most accurately reflects the source, and do so in comments on the doc.
Any replacement should facilitate discussion, and do so with a fairly low barrier to entry. (For example, I don't think @RoniRos wants to have to clone the repo and open a PR just to suggest a wording change, even if review comments on PRs do allow for discussion.)
So I agree with the desire for a better solution, but it has to fit with the needs of the stakeholders in these signal descriptions.

@RoniRos has a strong preference for group-edited documents like this to be in Docs, so that we can use the suggest changes & comment threading features there to reach consensus asynchronously. Using the comment/suggest changes PR mechanism on a project asset is substantially more restrictive and difficult to read, particularly if you have multiple suggested changes pending, which Docs handles seamlessly. GitHub markdown previews are great, but aiui they don't support previews of suggested changes.

Once consensus is made, how often are changes made?  If there are few changes after a signal goes live, an alternative would be to collaborate on the signal description in a design document until consensus, at which point it's pulled into the markdown file when the signal is enabled.
At first glance such a workflow may not seem like much of an improvement over having the signal descriptions in the constants.js file, but it would still be much easier to read and edit than the previous JSON file.

Thanks for the background.  Since my concerns with the #530 approach as hypothetical (brittleness, etc), it seems prudent to stick with this approach if it's a better user experience for collaborating on descriptions.
One, idea: can we "compile" the doc into a markdown file that is then saved as an asset that is version controlled?
That would protect against the failure scenario of losing the master doc for some reason; we'd be able to easily re-create it from the last release.  This also has the by-product of seeing for sure what the content differences were between versions as opposed to doing some possibly-out-of-sync versioning in the doc as well.

can we "compile" the doc into a markdown file that is then saved as an asset that is version controlled?

ooooh yes, we absolutely should!

Great! Let's merge this with #522 and add this as part of #530.

Duplicate of #522


Skipped page (file content is empty) warning is not useful for type-only TypeScript files with esbuild

Version
2.4.3
Platform
Windows
What steps will reproduce the bug?
I have a TypeScript file which just centralizes some type definitions.
Whenever I build my Lume site, I get an unhelpful warning telling me that the corresponding .js file is empty and will be skipped. But this should not be a warning; this is expected.
How often does it reproduce? Is there a required condition?
Full repro:
deno.json
{
  "imports": {
    "lume/"<EMAIL_ADDRESS>  },
  "tasks": {
    "lume": "echo \"import 'lume/cli.ts'\" | deno run -A -",
    "build": "deno task lume",
    "serve": "deno task lume -s"
  },
  "compilerOptions": {
    "types": [
      "lume/types.ts"
    ]
  }
}

_config.ts
import lume from "lume/mod.ts";
import esbuild from "lume/plugins/esbuild.ts";

const site = lume({
  src: "./src",
});

site.copy([".html"]);

site.use(esbuild({
  extensions: [".ts"],
  options: {
    bundle: false,
    minify: false,
    treeShaking: false,
    keepNames: false,
  },
}));

export default site;

src/types.ts
export type StringAlias = string;

src/test.ts
import { StringAlias } from "./types.ts";

const string: StringAlias = "Hello, world!";

document.body.innerHTML = string;

src/index.html
<!DOCTYPE html>
<meta charset="utf-8">
<title>Test</title>

<script type="module" src="test.js"></script>

What is the expected behavior?
When running deno run build, I'd get something like
$ deno run build
Task build deno task lume
Task lume echo "import 'lume/cli.ts'" | deno run -A -
Loading config file file:///C:/Users/d/OneDrive%20-%20domenic.me/Code/WIP/lume-test/_config.ts
🔥 /test.js <- /test.ts
🔥 /index.html <- /index.html
🍾 Site built into ./_site
  3 files generated in 0.03 seconds

What do you see instead?
I get
$ deno run build
Task build deno task lume
Task lume echo "import 'lume/cli.ts'" | deno run -A -
Loading config file file:///C:/Users/d/OneDrive%20-%20domenic.me/Code/WIP/lume-test/_config.ts
WARN [Lume] Skipped page /types.js (file content is empty)
🔥 /test.js <- /test.ts
🔥 /index.html <- /index.html
🍾 Site built into ./_site
  3 files generated in 0.03 seconds

Additional information

It'd be ideal if this situation could be detected and handled without me having to manually annotate the files in _config.ts.

It's a little strange the message says "Skipped page" because a JavaScript file is not a page.

/cc @bryophyta who seems to have originally implemented this warning in https://github.com/lumeland/lume/pull/221.

That's not a bug. Lume pages are not only html pages. Learn about html pages and asset pages. It's just the way to tell you that Lume won't save a file with no content.
I understand the issue but I don't know if it's easy to fix. It's like if you have a javascript file with all code commented (and removed by a minifier). The best way to do this is ignoring the file renaming it to _types.ts or in the _config.ts file adding the site.ignore("types.ts").
Maybe, due it's only a file with types declarations, you can rename it to types.d.ts. I'm not sure if Lume ignored the .d.ts files but definitely it should. I can make Lume to ignore this extension by default. What do you think?

I'd never used personally-written .d.ts files before, and the documentation doesn't make it seem like it would work. But I just tested renaming my file to use that extension, and it seems to work well! So I think this is a pretty good solution.


Propagate loadBalancerAddress

@bjorncs fyi

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:testCompile (default-testCompile) on project config-model: Compilation failure: Compilation failure:
[ERROR] /source/config-model/src/test/java/com/yahoo/config/model/MockModelContext.java:[81,33] <anonymous com.yahoo.config.model.MockModelContext$1> is not abstract and does not override abstract method loadBalancerAddress() in com.yahoo.config.model.api.ModelContext.Properties
[ERROR] /source/config-model/src/test/java/com/yahoo/vespa/model/VespaModelFactoryTest.java:[164,41] <anonymous com.yahoo.vespa.model.VespaModelFactoryTest$2$1> is not abstract and does not override abstract method loadBalancerAddress() in com.yahoo.config.model.api.ModelContext.Properties
[ERROR] -> [Help 1]

@gjoranv I've fixed the build and addressed the comments. ptal

@tokle Merge conflict btw.

👍  Merge at will


Conditional triggering of build in watch mode

Feature request
Would be cool to have one more property under watchOptions:
watchOptions: {
  condition: async () => {
    // Called on each files batch change, after aggregateTimeout debouncing.
    // Check that all other watch-build tools, like tsc, succeeded.
    // Return true to trigger webpack watch-build and false to skip it this time.
  }
}

What is the expected behavior?
Before triggering a watch-build, be able to run a custom code and ignore files changes if some condition is met.
What is motivation or use case for adding/changing the behavior?
An example: sometimes webpack is used to bundle artifacts generated by other tools (e.g. tsc in a large monorepo with cross-dependencies between packages, where tsc generates dist/ folders with *.js, and then webpack uses these dist/*.js and dist/*.map to build public/ and not waste time on dependent packages rebuild from their sources).
The problem is that, when the monorepo is large, there can be multiple processes of tsc --watch (one per each monorepo package), and the set of tsc builds does not settle immediately after git pull affecting multiple packages. E.g. if there are A -> B -> C packages dependencies in the monorepo, they all start watch-building after the pull, and until e.g. C is fully built, A and B builds may fail. The status of a package build is reflected in tsconfig.buildinfo file, and eventually everything in tsc settles, but - there is a time period when we're not yet ready to tell webpack to start the watch-build.
For such cases, the new condition option may be written to verify that all tsconfig.buildinfo files are clean and do not contain errors. If they do, then there is no sense in triggering a watch-build (it burns lots of CPU cycles and freezes the laptop in a large monorepo project, especially when there are multiple webpack built packages involved!); instead, it's better to wait until all tsconfig.buildinfo files have no errors, i.e. all monorepo packages are watch-build by tsc successfully.
How should this be implemented in your opinion?
There can be an additional check after chokidar (or whatever is used for watching) unfreezes.
Are you willing to work on this yourself?
yes

I don't think we need this, it is very exotic and requires a lot of code rewriting

requires a lot of code rewriting

Why so? In Watchpack, there is _onTimeout method which is called on every timer aggregation event (aggregateTimeout). It's already a part of the logic. My proposal is to be able to add an additional callback here which checks the condition (e.g. checks that all tsc projects in the monorepo were built successfully based on tsconfig.buildinfo file; this buildinfo dependent code can be user-defined, not a part of webpack itselt) and, if the condition is false, don't run the timer code; instead, just reschedule the timer.

it is very exotic

Most likely I haven't done a good job explaining the usecase above. Monorepos are very common, and mutually-dependent packages in these monorepos are common too, definitely not exotic.

It appeared that this feature is very easy to implement via just the regular plugins API. Here is the implementation:
https://www.npmjs.com/package/conditional-aggregate-webpack-plugin


HCF-516: Make the name of the CCNG hostname configurable

This allows HCF to not depend on consul to do DNS resolution. Also it's the
only hardwired hostname in cf. Works with ccng PR https://github.com/cloudfoundry/cloud_controller_ng/pull/544

Hi @ericpromislow
How exactly do you plan on using this?  I believe this internal hostname is handed over to Diego to tell it where to get app bits, buildpacks, and blobs when CC requests a staging or app running.  Do you plan on running some other DNS that the Diego Cells can use to take the given internal hostname and have it resolve to all the CCs?

Yes, we're using a different DNS to resolve the location of the CCs, and it needs a different value.

Thanks @ericpromislow,
I'll ask the Cloud Controller team if they can take a look.
Best,
Amit

merged on develop


Upgrade RTD Theme to 0.2.5b1

I say we just wait and release 0.2.5 then.
On Mon, Nov 27, 2017 at 11:32 AM, Anthony<EMAIL_ADDRESS>wrote:

@agjohnson requested changes on this pull request.
I don't think this is necessarily how we want to handle the beta releases
of the theme on RTD. Once we lose the beta designation we can bump this
though.
Alternatively, we've been using project feature flags for testing large
changes to the code. Perhaps we start there with this.
See projects.models.Feature as an example, the code in the
doc_builder.environment uses this feature to determine if we're forcing a
later version of setuptools and sphinx.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rtfd/readthedocs.org/pull/3313#pullrequestreview-79228065,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOeua8x6gCjtG5xcp6Cn2M9v_nmgXFZ3ks5s6uQLgaJpZM4Qqire
.

Actually paying attention to this change, this should be fine. My notes above of adding a Feature to start testing the beta version stands though. I think it might be a good way to weed out some issues with the theme -- though it's not as easy to test because things won't just fail. Changes to the styling won't surface as easily because of this.

I think some stuff still needs to be done on the server side correct?
Aaron Carlisle
Picture taker | Bit cruncher | Pixel pusher | Document writer |
Project administrator for the Blender 3D Documentation Project
On Mon, Nov 27, 2017 at 11:38 AM, Anthony<EMAIL_ADDRESS>wrote:

Merged #3313 https://github.com/rtfd/readthedocs.org/pull/3313.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rtfd/readthedocs.org/pull/3313#event-1359631046, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOeuawMMpc_dG3vzLvJ7r9cd498IELJ9ks5s6uWQgaJpZM4Qqire
.

I think some stuff still needs to be done on the server side correct?

For what? To use the beta release on our docs?

I think I was supposed to run gulp. Unless we do not want to use the beta
release. I do not see why that would be because there is nothing that is
"beta" about.
On Tue, Nov 28, 2017 at 12:45 PM, Anthony<EMAIL_ADDRESS>wrote:

I think some stuff still needs to be done on the server side correct?
For what? To use the beta release on our docs?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rtfd/readthedocs.org/pull/3313#issuecomment-347605185,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOeuaxm_Df1Swk7cspR_bnWvTkxEVFKsks5s7EbKgaJpZM4Qqire
.

--
Aaron Carlisle
Picture taker | Bit cruncher | Pixel pusher | Document writer |
Project administrator for the Blender 3D Documentation Project


[Feature Request] - add loading length to TextViewKoleton

The problem is  that sometimes the TextView's text is coming from api call and until that the text is empty and when I set skeleton on it the skeleton is not visible. I can set a dummy text on it until network response but I think this is an ugly solution.
It would be great if We can add an option to set a loading length on TextView skeleton.

Hi @TurKurT656 👋,
It is not necessary to set text in your xml. You just have to set length for skeleton to work well.
textView?.loadSkeleton(length = 20)
Please try out 0.8.5 version.

Thank you a lot


Ballista: Implement scalable distributed joins

Which issue does this PR close?

Closes #63.
This PR removes previous hacks around partitioning and now faithfully translates the DataFusion query plan, including RepartitionExec. I have tested with TPC-H query 12 and see consistent results between DataFusion and Ballista with the 100GB data set, where each table has 8 partitions. I have tested with multiple executors as well as single executors.
There is more work to do but I think this is at a good point to merge since it fixes some correctness issues.
Rationale for this change

Ballista cannot scale well without this because work is duplicated across all partitions to load the entire left side of the join into memory currently.
What changes are included in this PR?

Enables RepartitionExec in Ballista query plans and translate them to shuffles
Removes previous hacks intended to detect changes in partitioning

Are there any user-facing changes?

Query plans will change.

@edrevo fyi


Correctly interrogate child process status

@seelabs, @JoelKatz

:+1:

Current coverage is 54.56%

Merging #1495 into develop will increase coverage by +0.10% as of 63ee877

@@            develop   #1495   diff @@
=======================================
  Files           954     954
  Stmts         66336   66342     +6
  Branches          0       0
  Methods           0       0
=======================================
+ Hit           36128   36200    +72
  Partial           0       0
+ Missed        30208   30142    -66

Review entire Coverage Diff as of 63ee877

Powered by Codecov. Updated on successful CI builds.

Merged 08e518af73c6febe8d30d93c1763dd49056f7052


chore: disable prefer-const rule for deno

https://github.com/remix-run/remix/actions/runs/3716871751/jobs/6303686481
Signed-off-by: Logan McAnsh<EMAIL_ADDRESS>
Closes: #

[ ] Docs
[ ] Tests

Testing Strategy:

#4913 is the proper fix I think

#4913 is the proper fix I think

depends, we use let for non user facing code generally

True, but Deno doesn't have a rule to enforce that as far as I know
Also: this won't enforce const in the deno template


Container view receiving no nodes

From a Weave Cloud user on Intercom, trying to run Scope standalone on Kubernetes:

What you expected to happen?
See some containers in a graph (as the logs below suggest).
What happened?
No container nodes were displayed in the browser.
How to reproduce it?
Set up Scope via Weave Cloud instructions for K8s: https://www.weave.works/docs/scope/latest/installing/#k8s
kubectl create -f "https://cloud.weave.works/k8s/scope.yaml?k8s-version=$(kubectl version | base64 | tr -d '\n')"

pod=$(kubectl get pod -n weave --selector=name=weave-scope-app -o jsonpath={.items..metadata.name})

kubectl port-forward -n weave $pod 4040

Anything else we need to know?
Need more info:
Cloud provider? Hardware? How did you configure your cluster? Kubernetes YAML, KOPS, etc.
Versions:
Need more info:
$ scope version
$ docker version
$ uname -a
$ kubectl version

Logs:
The pods seem to be running normally:
kubectl get pods
NAME READY STATUS RESTARTS AGE
weave-scope-agent-6n76d 1/1 Running 0 166m
weave-scope-agent-9bw66 1/1 Running 0 166m
weave-scope-agent-9p6dq 1/1 Running 0 166m
weave-scope-agent-cj7pd 1/1 Running 0 88m
weave-scope-agent-h5gsm 1/1 Running 0 166m
weave-scope-agent-h7jc2 1/1 Running 0 166m
weave-scope-agent-pq6hh 1/1 Running 0 166m
weave-scope-app-5989b9c6d7-v6hwd 1/1 Running 0 166m

kubectl logs weave-scope-app-5989b9c6d7-v6hwd -n weave
<app> INFO: 2019/01/16 12:32:00.875288 app starting, version 1.10.1, ID 23ad7eaeb98eff5d
<app> INFO: 2019/01/16 12:32:00.875439 command line args: --mode=app
<app> INFO: 2019/01/16 12:32:00.880032 Basic authentication disabled
<app> INFO: 2019/01/16 12:32:00.880115 listening on :4040
<app> WARN: 2019/01/16 12:32:00.902821 Error updating weaveDNS, backing off 20s: Error running weave ps: exit status 1: "Link not found\n". If you are not running Weave Net, you may wish to suppress this warning by launching scope with the `--weave=false` option.
<app> WARN: 2019/01/16 12:32:20.928754 Error updating weaveDNS, backing off 40s: Error running weave ps: exit status 1: "Link not found\n". If you are not running Weave Net, you may wish to suppress this warning by launching scope with the `--weave=false` option.

Note: I was personally unable to reproduce the problem.

I'm getting the same. I have containers running in GKE in different namespace and I'm not seeing any of the containers in the UI. Using GKE version 1.11.7-gke.4.
I did kubectl logs on the agent and here's the output
kubectl logs weave-scope-agent-4fzpt -n weave
time="2019-02-27T17:37:37Z" level=info msg="publishing to: weave-scope-app.weave.svc.cluster.local:80"
<probe> INFO: 2019/02/27 17:37:37.268590 Basic authentication disabled
<probe> INFO: 2019/02/27 17:37:37.312886 command line args: --mode=probe --probe-only=true --probe.docker=true --probe.docker.bridge=docker0 --probe.kubernetes.role=host weave-scope-app.weave.svc.cluster.local:80
<probe> INFO: 2019/02/27 17:37:37.313182 probe starting, version 1.10.2, ID 1ba1bd3ae38f9a86
<probe> WARN: 2019/02/27 17:37:37.460470 Cannot resolve 'scope.weave.local.': dial tcp <IP_ADDRESS>:53: connect: connection refused
<probe> WARN: 2019/02/27 17:37:38.008016 Error collecting weave status, backing off 10s: Get http://<IP_ADDRESS>:6784/report: dial tcp <IP_ADDRESS>:6784: connect: connection refused.  If you are not running Weave Net, you may wish to suppress this warning by launching scope with the `--weave=false` option.
<probe> ERRO: 2019/02/27 17:37:50.641730 Error fetching app details: Get http://<IP_ADDRESS>:80/api: dial tcp <IP_ADDRESS>:80: i/o timeout
<probe> ERRO: 2019/02/27 17:37:58.641367 Error fetching app details: Get http://<IP_ADDRESS>:80/api: dial tcp <IP_ADDRESS>:80: i/o timeout
<probe> WARN: 2019/02/27 17:38:08.039502 Error collecting weave status, backing off 40s: Get http://<IP_ADDRESS>:6784/report: dial tcp <IP_ADDRESS>:6784: connect: connection refused. If you are not running Weave Net, you may wish to suppress this warning by launching scope with the `--weave=false` option.
<probe> ERRO: 2019/02/27 17:38:08.640444 Error fetching app details: Get http://<IP_ADDRESS>:80/api: dial tcp <IP_ADDRESS>:80: i/o timeout
<probe> ERRO: 2019/02/27 17:38:18.638126 Error fetching app details: Get http://<IP_ADDRESS>:80/api: dial tcp <IP_ADDRESS>:80: i/o timeout

Hi,
I have the same problem. Do you find the solution.
In my case cluster is on AWS EKS.
Best Regards


Can I save an initial command to the REPL?

Hello there! I've been using Proto REPL to connect to Figwheel, and so every time I start Proto REPL, I need to input the same command:
(do (use 'figwheel-sidecar.repl-api) (start-figwheel!) (cljs-repl))

...is there any way to save this such that it gets automatically run whenever I start Proto REPL?
Also, apologies if this is not actually a Proto REPL-specific question.

Closing this issue, the answer is documented here:
https://github.com/jasongilman/proto-repl/blob/master/extending_proto_repl.md