bracket pair colorization slow to start, fast once it is running

Version: 1.61.0-insider (user setup)
Commit: 5991e3c4b97eca5568069bf3e0910ab693ad3549
Date: 2021-09-27T05:16:11.989Z
Electron: 13.4.0
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19043

open a really big file, i use TypeScript's src/compiler/checker.ts
right click on the checker.ts editor tab, choose Split in Group so you have two views onto the file
Scroll to the bottom on one of them so you can see the closing bracket
Now, change/edit the opening bracket on line 2
expect that the closing bracket at end of file will immediately change, but it doesn't.

If i keep making edits, it doesn't change color.
If i then leave it alone for a few seconds (not sure how long), then the colorization starts to work. Once it starts, its instant, its just the first time.

Bracket pair colorization is always fast ;) Try inserting {{{ (or more) to see that it updates immediately, even in the first couple of seconds.
The thing is that there are no token information available during the first couple of seconds (on my machine up to 15 seconds).
The bracket pair colorization feature does its best and just interprets every bracket-character as bracket (even in strings and comments).
Unfortunately, in checker.ts, there are some unpaired "(", ")" and "}".
Thus, the initial pair tree is unbalanced and probably overclosed (until it reprocesses the document when all token information are available).
When adding { to the beginning of the file, it (most likely; the file is too large for me to do bracket counting myself) closes some unopened "}" - thus, the change is not reflected at the end.


remove the unused check in selectable_text

Since #76349 has been merged, I think the check of selection in selectable_text is unused now, and suggest removing them.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Hi, @chunhtai and @LongCatIsLooong. Would you like to help to review this PR?

Hi, @LongCatIsLooong. Could you help to check why the google testing and luci-flutter CI are always pending? I can't open the link.

@LucasXu0 Can you rebase and try again? it looks like the infra doesn't pick up this pr


Issue with exposed Plex API Token

Hi there, I noticed that the Plex API token is being logged straight to the console. I would love to expose this to my friends so they could use it but unfortunately this is too much of a security risk for me.

Hi, I will hide it.

It is fixed in v3.1.1


use viewport + fix meta tags + update .gitignore

use viewport in metatag and viewport relative height/width in body
fix meta tags by removing „self“ closing tag because  is a void
element
add npm-debug.log file to .gitignore

I'm not sure if style="height:100vh; width:100vw;" on the body should be there as default, so please discuss this internally. Probably it's better the library developer uses something like this from case to case, like I did it now in my lib...


OTG Test - TE-13.2: gRIBI route DELETE during Failover

OTG conversion for _TE-13.2: gRIBI route DELETE during Failover _
Resolves #1193

Waiting for #1320 merge

/gcbrun

@octpetre : Still the one question on interface naming, would appreciate incorporate the two lines from https://github.com/openconfig/featureprofiles/commit/d81ec97ead8c338c767def269e41e460cae85dad as well.

/gcbrun


can not generate swagger spec

Problem statement
I run following command to generate swagger spec but it just prints 3 lines of yaml to swagger.yaml
command: swagger generate spec -o ./swagger.yaml
yaml output:
info: {}
paths: {}
swagger: "2.0"
comments added to main file:
// Package classification Petstore API.
//
// the purpose of this application is to provide an application
// that is using plain go code to define an API
//
// This should demonstrate all the possible comment annotations
// that are available to turn go code into a fully compliant swagger 2.0 spec
//
// Terms Of Service:
//
// there are no TOS at this moment, use at your own risk we take no responsibility
//
//     Schemes: http, https
//     Host: localhost
//     BasePath: /v2
//     Version: 0.0.1
//     License: MIT http://opensource.org/licenses/MIT
//     Contact: John<EMAIL_ADDRESS>http://john.doe.com
//
//     Consumes:
//     - application/json
//     - application/xml
//
//     Produces:
//     - application/json
//     - application/xml
//
//     Security:
//     - api_key:
//
//     SecurityDefinitions:
//     api_key:
//          type: apiKey
//          name: KEY
//          in: header
//     oauth2:
//         type: oauth2
//         authorizationUrl: /oauth2/auth
//         tokenUrl: /oauth2/token
//         in: header
//         scopes:
//           bar: foo
//         flow: accessCode
//
//     Extensions:
//     x-meta-value: value
//     x-meta-array:
//       - value1
//       - value2
//     x-meta-array-obj:
//       - name: obj
//         value: field
//
// swagger:meta
Environment
swagger version: v0.30.2
go version: 1.19.1
OS:   macOS monterey 12.6

Same problem here, same Environment. In my case though, only the definitions are empty.
It works fine on the same files with go-swagger version: v0.28.0 and go version 1.18.

Can you assign me this

Also send me the gituhb link to the project and file so I can do a pull request after I fix it

We need more context on the failure, do you have a repo that we can look at?

It seems that we faced same problem once we updated to version 0.30.2. After update our swagger.json became empty. We already reverted this change, but here is original PR: https://github.com/percona/pmm/pull/1192
You can use our repo to reproduce the problem: https://github.com/percona/pmm
cd tools
go get -u github.com/go-swagger/go-swagger
go mod tidy
cd ..
make init
make gen

Then check api/swagger/swagger.json file content, it's empty.

apparently, the issue doesn't occur in 0.30.0 which is essentially the same code. The main difference is that it is built on github actions instead of on circle ci.
https://github.com/go-swagger/go-swagger/compare/v0.30.0...v0.30.2

Same issue here, spec generation working in 0.30.0, broken in 0.30.2.

I can't reproduce this at all.  We only support the last 2 versions of golang. This is how I tested:
td=$(mktemp -d)
cd $td

go mod init swaggertest

cat << 'EOF' > main.go
// Package petstore Petstore API.
//
// the purpose of this application is to provide an application
// that is using plain go code to define an API
//
// This should demonstrate all the possible comment annotations
// that are available to turn go code into a fully compliant swagger 2.0 spec
//
// Terms Of Service:
//
// there are no TOS at this moment, use at your own risk we take no responsibility
//
//	Schemes: http, https
//	Host: localhost
//	BasePath: /v2
//	Version: 0.0.1
//	License: MIT http://opensource.org/licenses/MIT
//	Contact: John<EMAIL_ADDRESS>http://john.doe.com
//
//	Consumes:
//	- application/json
//
//	Produces:
//	- application/json
//
// swagger:meta
package main

import (
	"time"
)

func main() {

}

// swagger:model pet
type Pet struct {
	// The id of the pet.
	//
	// required: true
	ID int64 `json:"id"`

	// The name of the pet.
	//
	// required: true
	// pattern: \w[\w-]+
	// minimum length: 3
	// maximum length: 50
	Name string `json:"name"`

	// The photo urls for the pet.
	// This only accepts jpeg or png images.
	//
	// items pattern: \.(jpe?g|png)$
	PhotoURLs []string `json:"photoUrls,omitempty"`

	// The pet's birthday
	//
	// swagger:strfmt date
	Birthday time.Time `json:"birthday"`
}
EOF

Then I use a golang container for a clean environment:
docker run --rm -it -v $PWD:/app -w /app golang:1.19

or for 1.18
docker run --rm -it -v $PWD:/app -w /app golang:1.18

Inside the container I do:
go install github.com/go-swagger/go-swagger/cmd/swagger@latest

swagger generate spec --scan-models

In both go 1.18 and go 1.19 this results in:
{
  "consumes": [
    "application/json"
  ],
  "produces": [
    "application/json"
  ],
  "schemes": [
    "http",
    "https"
  ],
  "swagger": "2.0",
  "info": {
    "description": "the purpose of this application is to provide an application\nthat is using plain go code to define an API\n\nThis should demonstrate all the possible comment annotations\nthat are available to turn go code into a fully compliant swagger 2.0 spec",
    "title": "Petstore API.",
    "termsOfService": "there are no TOS at this moment, use at your own risk we take no responsibility",
    "contact": {
      "name": "John Doe",
      "url": "http://john.doe.com",
      "email"<EMAIL_ADDRESS>    },
    "license": {
      "name": "MIT",
      "url": "http://opensource.org/licenses/MIT"
    },
    "version": "0.0.1"
  },
  "host": "localhost",
  "basePath": "/v2",
  "paths": {},
  "definitions": {
    "pet": {
      "type": "object",
      "required": [
        "id",
        "name"
      ],
      "properties": {
        "birthday": {
          "description": "The pet's birthday",
          "type": "string",
          "format": "date",
          "x-go-name": "Birthday"
        },
        "id": {
          "description": "The id of the pet.",
          "type": "integer",
          "format": "int64",
          "x-go-name": "ID"
        },
        "name": {
          "description": "The name of the pet.",
          "type": "string",
          "maxLength": 50,
          "minLength": 3,
          "pattern": "\\w[\\w-]+",
          "x-go-name": "Name"
        },
        "photoUrls": {
          "description": "The photo urls for the pet.\nThis only accepts jpeg or png images.",
          "type": "array",
          "items": {
            "type": "string",
            "pattern": "\\.(jpe?g|png)$"
          },
          "x-go-name": "PhotoURLs"
        }
      },
      "x-go-name": "Pet",
      "x-go-package": "swaggertest"
    }
  }
}

I stand corrected. I can reproduce it with the binaries that you download.  So to fix it in your local env you can just install swagger with
go install github.com/go-swagger/go-swagger/cmd/swagger@latest

The culprit seems to be building with -trimpath

I created a new release v0.30.3 that should address this issue

@casualjim Unfortunately it didn't help: https://github.com/percona/pmm/pull/1257

Same for me, still not working. Tried different Go versions as well, no luck (18.6 and 19.1)

I stand corrected. I can reproduce it with the binaries that you download. So to fix it in your local env you can just install swagger with
go install github.com/go-swagger/go-swagger/cmd/swagger@latest

This worked for me now though.

@artemgavrilov I gave your repo a go, when I use the make init and  make gen route, the content of api/swagger/swagger.json is indeed {}
However when I do this:
GOBIN=$PWD/bin go install github.com/go-swagger/go-swagger/cmd/swagger@latest

and I then run
bin/swagger mixin --output=api/swagger/swagger.json \
		api/swagger/header.json \
		api/serverpb/json/serverpb.json \
		api/userpb/json/userpb.json \
		api/inventorypb/json/inventorypb.json \
		api/managementpb/json/managementpb.json

The spec does contain content.
pmm on  dependabot/go_modules/tools/github.com/go-swagger/go-swagger-0.30.3 [!] via 🐹 v1.19.2 via 🐍 v3.10.7 with  took 1m22s
❯ cat api/swagger/swagger.json
{}%

pmm on  dependabot/go_modules/tools/github.com/go-swagger/go-swagger-0.30.3 [!] via 🐹 v1.19.2 via 🐍 v3.10.7 with 
❯ bin/swagger mixin --output=api/swagger/swagger.json \
                api/swagger/header.json \
                api/serverpb/json/serverpb.json \
                api/userpb/json/userpb.json \
                api/inventorypb/json/inventorypb.json \
                api/managementpb/json/managementpb.json
2022/10/08 10:04:34 args[0] = api/swagger/header.json
2022/10/08 10:04:34 args[1:] = [api/serverpb/json/serverpb.json api/userpb/json/userpb.json api/inventorypb/json/inventorypb.json api/managementpb/json/managementpb.json]
2022/10/08 10:04:34 format =  json

pmm on  dependabot/go_modules/tools/github.com/go-swagger/go-swagger-0.30.3 [!] via 🐹 v1.19.2 via 🐍 v3.10.7 with 
❯ head api/swagger/swagger.json
{
  "consumes": [
    "application/json"
  ],
  "produces": [
    "application/json"
  ],
  "schemes": [
    "https",
    "http"

I have a similar issue
go file :
package pack

// swagger:model
type Str struct {
	Label              string    `json:"label"`
}

swagger generate spec -m model.go
result :
{
  "swagger": "2.0",
  "paths": {},
  "definitions": {
    "Str": {
      "x-go-package": "command-line-arguments"
    }
  }
}

done to reproduce :
#on macos
brew install go-swagger
swagger generate spec -m model.go

We have the same issue. Runs fine on local mac os w/ golang 1.19.3 and goswagger 0.30.3. In CI, with same go version, and same goswagger, the properties in our model definitions are empty.

FWIW, just running this swagger generate spec -m -o swagger.json
bad one:
 "keystore_KeyDefinition": {
      "description": "KeyDefinition TBD",
      "title": "KeyDefinition",
      "x-go-name": "KeyDefinition",
      "x-go-package": "git.rigado.com/cascade/cascade-shared/edgeconnect"
    },

good one

"keystore_KeyDefinition": {
      "description": "KeyDefinition TBD",
      "type": "object",
      "title": "KeyDefinition",
      "required": [
        "type"
      ],
      "properties": {
        "generator": {
          "description": "Specify the generator for the key, if unspecified the key must be set before using\navailable: rand, ecdh-P224, ecdh-P256, ecdh-P384",
          "type": "string",
          "x-go-name": "Generator"
        },
        "generatorConfig": {
          "description": "Configuration to pass to generator",
          "type": "object",
          "additionalProperties": false,
          "x-go-name": "GeneratorConfig"
        },
        "persistent": {
          "description": "Store key in persistent storage?",
          "type": "boolean",
          "x-go-name": "Persistent"
        },
        "type": {
          "description": "Type of key\navailable: secret, keypair",
          "type": "string",
          "x-go-name": "Type"
        }
      },
      "x-go-name": "KeyDefinition",
      "x-go-package": "git.rigado.com/cascade/cascade-shared/edgeconnect"
    },


handle multiple changes in one watch event

Signed-off-by: akihikokuroda<EMAIL_ADDRESS>
Description of the change:
When waiting for the multiple components added in the status, the changes for the operator instance sometimes come in one watch event.  The original test could not handle this case and wait for following watch event that may not come.
Motivation for the change:
Closes #2581
duplicate issue: https://github.com/operator-framework/operator-lifecycle-manager/pull/2665
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive
[ ] Tests marked as [FLAKE] are truly flaky
[ ] Tests that remove the [FLAKE] tag are no longer flaky

@akihikokuroda is this ready for re-review? FYI, I've rebased from this side ^^

closing PR as stale. Please re-open if it's still important.


If a spassman focuses hard enough, they can activate their inside telekinetic powers

Description

Now with a title like that you are probably wondering what the heck it means.
Simply put with two easy-to-replicate setups you can drag around around as far away as you like and still be able to move around. As long as it's draggable you can use your powers to move it!
This may be a buckle shitcode moment
Reproduction

First way:

Grab your item of choice
Sit on a chair
Unbuckle
Try dragging around your item, both the chair and item will move but not you! Telekinesis!

Second way (funniest)

Like above but with a rollerbed
Now only the item moves around! Telekinesis!11!!!

Screenshots

First way: https://youtu.be/TyxP_YZzru8
Second way: https://youtu.be/qJJ-qoZMNwM
Additional context

Bug of the Year 2023 Candidate??!??!?!?!?!?!?11111
I may or may not abused this a lil bit for light amounts of tomfoolery

Could replicate on commit bc6bf05.
Couldn't replicate after reverting #18520, the character just drags himself with the object.
#18520 fixes a funnier exploit though.

I think I saw you as RD abusing having run with this bug. Very funny.

I have not and will not play sci even under gunpoint. But I did discover this off an rd

It must have been the same RD then.


safeUrl() Security refactor

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Resolves: #202
Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is, and anything that describes the before/after state of the project.
This function was updated post-security review in training with @jmanico
The goal of this refactor is to be exclusionary by default as well as tighten up the code ergonomics.
See this POV Commit per this Discussion
https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/release-workflow/pre-releases.md
Type of change:
Please delete options that are not relevant.

[ ] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 3.5.11 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


nix-build error on macos

Hi, looks like nix-build on macos generates:
error: Package ‘lsb_release’ in /nix/store/6gyh8gqb20hn0xnz5a2rifhncnzwicmb-source/pkgs/os-specific/linux/lsb-release/default.nix:16 is not supported on ‘x86_64-darwin’, refusing to evaluate.
any workaround ?

Hi! Indeed, this package won't be found on Mac. For a short workaround you can try deleting this line as the binaries are probably not needed anyway. I'll see if there's a way to fix this permanently as well.

@amichalu , can you check https://github.com/PacktPublishing/Software-Architecture-with-Cpp/pull/52 if it works for you?

It's another error as a result of nix-build:
This derivation is not meant to be built, aborting
error: builder for '/nix/store/7895cas1dyia813sqsd67nkidj170nw1-nix-shell.drv' failed with exit code 1;
       last 4 log lines:
       > nobuildPhase
       >
       > This derivation is not meant to be built, aborting
       >
       For full logs, run 'nix log /nix/store/7895cas1dyia813sqsd67nkidj170nw1-nix-shell.drv'.

mentioned log:
error: experimental Nix feature 'nix-command' is disabled; use '--extra-experimental-features nix-command' to override

Can you give more background into:

which architecture are you running: Intel or M1?
what is the OS version?
what is the Nix version?

Nix:
√ ~ % nix-env --version
nix-env (Nix) 2.6.0
installation verified according to nixos.org doc
macos:
ProductName:	Mac OS X
ProductVersion:	10.15.7
BuildVersion:	19H1615
apple Intel

Thanks! I'll check this after the weekend and see if I can help.

Testing it on 10.15.7 here on Intel as well.
Are you using the direnv allow method or opening nix-shell directly?


[R-package] CRAN fixes

This PR attempts to address many of the issues blocking CRAN deployment of the R package. See #629 for details. Note that all claims below were only tested on MacOS with R 3.4.0. I have reason to believe that many of the fixes were necessary regardless of OS and R version, but I imagine that I'll find additional issues on e.g. Windows in the future.
After this PR, we are down to just one NOTE remaining!!!
To test changes (assuming CMake and g++/gcc available locally):
export CXX=/usr/local/bin/g++-8
export CC=/usr/local/bin/gcc-8

cp -R src R-package/src/
cp -R include R-package/src/
cp CMakeLists.txt R-package/inst/bin/

Rscript -e "devtools::document('R-package/')"
R CMD BUILD R-Package/ --keep-empty-dirs
R CMD INSTALL lightgbm_2.1.2.tar.gz
R CMD CHECK lightgbm_2.1.2.tar.gz --as-cran | tee check.log | cat

Summary of Changes
1. Executables created at build time
Problem:
Found the following executable files:
  src/build/CMakeFiles/3.10.2/CMakeDetermineCompilerABI_C.bin
  src/build/CMakeFiles/3.10.2/CMakeDetermineCompilerABI_CXX.bin
  src/build/CMakeFiles/FindOpenMP/ompver_C.bin
  src/build/CMakeFiles/FindOpenMP/ompver_CXX.bin
  src/build/CMakeFiles/feature_tests.bin
Source packages should not contain undeclared executable files.

Solution: adding those extensions to .Rbuildignore
2. Object files included in package
Problem:
Found the following apparent object files/libraries:
  src/build/CMakeFiles/3.10.2/CompilerIdC/CMakeCCompilerId.o
  src/build/CMakeFiles/3.10.2/CompilerIdCXX/CMakeCXXCompilerId.o
  src/build/CMakeFiles/_lightgbm.dir/src/application/application.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/boosting/boosting.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/boosting/gbdt.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/boosting/gbdt_model_text.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/boosting/gbdt_prediction.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/boosting/prediction_early_stop.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/c_api.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/bin.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/config.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/config_auto.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/dataset.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/dataset_loader.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/file_io.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/json11.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/metadata.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/parser.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/io/tree.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/lightgbm_R.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/metric/dcg_calculator.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/metric/metric.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/network/linker_topo.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/network/linkers_mpi.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/network/linkers_socket.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/network/network.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/objective/objective_function.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/treelearner/data_parallel_tree_learner.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/treelearner/feature_parallel_tree_learner.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/treelearner/gpu_tree_learner.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/treelearner/serial_tree_learner.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/treelearner/tree_learner.cpp.o
  src/build/CMakeFiles/_lightgbm.dir/src/treelearner/voting_parallel_tree_learner.cpp.o
Object files/libraries should not be included in a source package.

Solution: Adding those extensions to .Rbuildignore
3. CMakeLists not being recognized in src
Problem:
Subdirectory ‘src’ contains:
  CMakeLists.txt
These are unlikely file names for src files.

Solution: Put this file in inst/bin/ and then copying it into src/ using install.libs.R at build time.
4. Installation path issues*
Problem: Installation is currently very sensitive to where you run build commands from because of use of relative paths and strict coupling to the repo structure. See for example #421
Solution: Strip "copy source out of repo root into package" stuff from install.libs.R and make it a part of the build process (those cp commands above). I would like to PR in a shell script that does this as well, but didn't add it here since it's Mac-specific.
5. Overlapping and confusing documentation
Problem:
* checking Rd \usage sections ... WARNING
Undocumented arguments in documentation object 'lgb.cv'
  ‘save_name’
Duplicated \argument entries in documentation object 'lgb.cv':
  ‘params’ ‘data’ ‘nrounds’ ‘obj’ ‘boosting’ ‘num_leaves’ ‘max_depth’
  ‘num_threads’ ‘eval’ ‘verbose’ ‘record’ ‘eval_freq’ ‘init_model’
  ‘colnames’ ‘categorical_feature’ ‘early_stopping_rounds’ ‘callbacks’
  ‘...’
Documented arguments not in \usage in documentation object 'lgb.cv':
  ‘boosting’ ‘num_leaves’ ‘max_depth’ ‘num_threads’

Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.

Solution: Instead of routing lgb.cv, lgb.train, and lightgbm to the same Rd with @rdname, I stored the shared params in a separate object and then used #' @inheritParams from Roxygen. This is cleaner and avoids the collisions.
6. Registration of routines
Problem:
File ‘lightgbm/libs/lib_lightgbm.so’:
  Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’

Solution: Added src/R_init.c and src/R_init.h to call these registrations.
7. Misaligned documentation
Problem:
Codoc mismatches from documentation object 'predict.lgb.Booster':
predict.lgb.Booster
  Code: function(object, data, num_iteration = NULL, rawscore = FALSE,
                 predleaf = FALSE, predcontrib = FALSE, header = FALSE,
                 reshape = FALSE, ...)
  Docs: function(object, data, num_iteration = NULL, rawscore = FALSE,
                 predleaf = FALSE, header = FALSE, reshape = FALSE,
                 ...)
  Argument names in code not in docs:
    predcontrib
  Mismatches in argument names:
    Position: 6 Code: predcontrib Docs: header
    Position: 7 Code: header Docs: reshape
    Position: 8 Code: reshape Docs: ...

Solution: Updated docs to reflect the true function signatures.
8. Issues with demo index
Problem:
* checking top-level files ... NOTE
Non-standard files/directories found at top level:
  ‘check.log’ ‘lightgbm_2.1.2.tar.gz’ ‘lightgbm_2.1.2.tgz’
* checking for left-over files ... OK
* checking index information ... WARNING
Demos with missing or empty index information:
  categorical_features_prepare
  categorical_features_rules
  multiclass_custom_objective
Demo index entries without corresponding demo:
  categorical_feature_prepare
  categorical_feature_rules
See sections ‘The INDEX file’ and ‘Package subdirectories’ in the

Solution: Updated 00Index to fix typos (create_feature rule with no "s") and added missing items.
9. Unrecognized global functions
Problem:
Unrecognized global function "set"

Solution: Explicitly namespaced set calls to data.table::set and added #' @importFrom data.table set. While doing this, I also caught one or two other non-namespaced things, namely R6::R6Class.
10. Dependency unused
Problem:
Dependency 'Matrix' is listed in Imports but not imported from.

Solution: I removed Matrix from Imports. I couldn't find any uses of it in the code (by ::) but it's really challenging to find because Matrix overloads a lot of the base R matrix manipulation functions. Please let me know if I was too aggressive with this one. If I was, then we need to be explicit about when we're using e.g. Matrix::t instead of base::t.
Other Comments
After this work, only one NOTE remains for the R package on MacOS:
  Found ‘___assert_rtn’, possibly from ‘assert’ (C)
  Found ‘___stderrp’, possibly from ‘stderr’ (C)
  Found ‘___stdoutp’, possibly from ‘stdout’ (C)
  Found ‘_printf’, possibly from ‘printf’ (C)
  Found ‘_putchar’, possibly from ‘putchar’ (C)
  Found ‘_vprintf’, possibly from ‘vprintf’ (C)

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor the system RNG.
The detected symbols are linked into the code but might come from
libraries and not actually be called.

I don't really know how to fix this. It's weird to me that printf() wouldn't be allowed. We probably need to look on github.com/cran and S/O for how other packages have gotten around this issue. My first search online didn't reveal anything obvious.
Sorry that I had to touch so many files! Please let me know if you have any questions or concerns. Hope we'll make it to CRAN soon!

@jameslamb Visual Studio 2017 or Rtools:
* using log directory 'E:/sandbox/LightGBM/lightgbm.Rcheck'
* using R version 3.5.0 (2018-04-23)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* using option '--as-cran'
* checking for file 'lightgbm/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'lightgbm' version '2.1.2'
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Guolin Ke<EMAIL_ADDRESS>
New submission

License components with restrictions and base license permitting such:
  MIT + file LICENSE
File 'LICENSE':
  The MIT License (MIT)

  Copyright (c) Microsoft Corporation

  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the Software is
  furnished to do so, subject to the following conditions:

  The above copyright notice and this permission notice shall be included in all
  copies or substantial portions of the Software.

   IN NO EVENT SHALL THE
  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.

The Date field is over a month old.
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'lightgbm' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... NOTE
Files 'README.md' or 'NEWS.md' cannot be checked without 'pandoc' being installed.
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking contents of 'data' directory ... OK
* checking data for non-ASCII characters ... OK
* checking data for ASCII and uncompressed saves ... OK
* checking line endings in C/C++/Fortran sources/headers ... WARNING
Found the following sources/headers with CR or CRLF line endings:
  src/build/CMakeFiles/3.8.0/CompilerIdC/CMakeCCompilerId.c
  src/build/CMakeFiles/3.8.0/CompilerIdCXX/CMakeCXXCompilerId.cpp
  src/build/CMakeFiles/FindOpenMP/ompver.c
  src/build/CMakeFiles/FindOpenMP/ompver.cpp
Some Unix compilers require LF line endings.
* checking line endings in Makefiles ... OK
* checking compilation flags in Makevars ... OK
* checking for GNU extensions in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking pragmas in C/C++ headers and code ... OK
* checking compilation flags used ... OK
* checking compiled code ... NOTE
Note: information on .o files for x64 is not available
File 'lightgbm/libs/x64/lib_lightgbm.dll':
  Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'

It is good practice to register native routines and to disable symbol
search.

See 'Writing portable packages' in the 'Writing R Extensions' manual.
* checking examples ... OK
* checking for unstated dependencies in 'tests' ... OK
* checking tests ...
 OK
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without hyperrefs or index ... ERROR
Re-running with no redirection of stdout/stderr.
Hmm ... looks like a package
You may want to clean up by 'rm -Rf C:/Users/Laurae/AppData/Local/Temp/Rtmp4K58mm/Rd2pdf3ab4245c1d2d'
* DONE
Status: 1 ERROR, 2 WARNINGs, 3 NOTEs

@jameslamb Visual Studio 2017, this is the correct run you can check below, it has 3 warnings + 3 notes:

big wall of text
* using log directory 'E:/sandbox/LightGBM/lightgbm.Rcheck'
* using R version 3.5.0 (2018-04-23)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* using option '--as-cran'
* checking for file 'lightgbm/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'lightgbm' version '2.1.2'
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Guolin Ke<EMAIL_ADDRESS>
New submission

License components with restrictions and base license permitting such:
  MIT + file LICENSE
File 'LICENSE':
  The MIT License (MIT)

  Copyright (c) Microsoft Corporation

  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the Software is
  furnished to do so, subject to the following conditions:

  The above copyright notice and this permission notice shall be included in all
  copies or substantial portions of the Software.

   IN NO EVENT SHALL THE
  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.

The Date field is over a month old.
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'lightgbm' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... NOTE
Files 'README.md' or 'NEWS.md' cannot be checked without 'pandoc' being installed.
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking contents of 'data' directory ... OK
* checking data for non-ASCII characters ... OK
* checking data for ASCII and uncompressed saves ... OK
* checking line endings in C/C++/Fortran sources/headers ... WARNING
Found the following sources/headers with CR or CRLF line endings:
  src/build/CMakeFiles/3.8.0/CompilerIdC/CMakeCCompilerId.c
  src/build/CMakeFiles/3.8.0/CompilerIdCXX/CMakeCXXCompilerId.cpp
  src/build/CMakeFiles/FindOpenMP/ompver.c
  src/build/CMakeFiles/FindOpenMP/ompver.cpp
  src/build/CMakeFiles/feature_tests.c
Some Unix compilers require LF line endings.
* checking line endings in Makefiles ... WARNING
Found the following Makefile(s) with CR or CRLF line endings:
  src/build/Makefile
Some Unix 'make' programs require LF line endings.
* checking compilation flags in Makevars ... OK
* checking for GNU extensions in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking include directives in Makefiles ... OK
* checking pragmas in C/C++ headers and code ... OK
* checking compilation flags used ... OK
* checking compiled code ... NOTE
Note: information on .o files for x64 is not available
File 'E:/sandbox/LightGBM/lightgbm.Rcheck/lightgbm/libs/x64/lib_lightgbm.dll':
  Found '_exit', possibly from '_exit' (C)
  Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
  Found 'exit', possibly from 'exit' (C), 'stop' (Fortran)
  Found 'printf', possibly from 'printf' (C)
File 'lightgbm/libs/x64/lib_lightgbm.dll':
  Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor use Fortran I/O
nor system RNGs. The detected symbols are linked into the code but
might come from libraries and not actually be called.
It is good practice to register native routines and to disable symbol
search.

See 'Writing portable packages' in the 'Writing R Extensions' manual.
* checking examples ... OK
* checking for unstated dependencies in 'tests' ... OK
* checking tests ...
 OK
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
!pdfTeX error: pdflatex (file ts1-zi4r): Font ts1-zi4r at 540 not found
 ==> Fatal error occurred, no output PDF file produced!
* checking PDF version of manual without hyperrefs or index ... OK
* DONE
Status: 3 WARNINGs, 3 NOTEs

@Laurae2 looking through your wall of text...that's not too bad, right? Definitely a step in the right direction.
I think the ERROR creating the manual and the NOTE about pandoc are related to your local LaTeX install, so not a problem with the code in this repo per se.
The printf and _exit thing is something I'd like to address in a followup PR, mirroring what XGBoost does.
The LICENSE / maintainer NOTE isn't really a NOTE.  It's annoying but won't block publication and doesn't require action from us.
I am surprised to see R complaining about R_RegisterRoutines. I had eliminated that problem on my Mac.
I'm worried that the line-endings warning is related to the fact that you have people developing code and contributing from multiple different OS's (I work primarily on Mac OS, I know a lot of this package's development happens on Windows, I'm guessing other contributors have used Linux flavors like CentOS). I read up on this piece from GItHub about line endings but I don't want to introduce a .gitattributes type of change in this PR, since I don't fully understand the implications of doing that.  I vote we punt the line-ending issue to a follow-up PR.
@Laurae2 is it fair to say, based on the output you provided, that the consensus is "the package is installable on Windows as of this PR, but there are still some R CMD CHECK issues remaining"? If so, I propose that you and @guolinke review the other changes that I've made here (those outside the install process), and that we merge this PR if / when you're comfortable with them.
I could then address the remaining issues (and other tasks from #629 like Travis setup) in followup PRs.

I just pushed a commit updating the build instructions and adding the build_r.sh script. Hope that it helps

@jameslamb good one with the build_r.sh
I think @guolinke would like to be able to build only the package and not install it at the same time. I guess it would be the following:
	set -e
 # for macOS (replace 7 with version of gcc installed on your machine)
# NOTE: your gcc / g++ from Homebrew is probably in /usr/local/bin
#export CXX=/usr/local/bin/g++-8 CC=/usr/local/bin/gcc-8
 # Make a new temporary folder to work in
rm -rf lightgbm_r
mkdir lightgbm_r
 # copy in the relevant files
cp -R R-package/ lightgbm_r
cp -R include lightgbm_r/src/
cp -R src lightgbm_r/src/
cp CMakeLists.txt lightgbm_r/inst/bin/
 # rebuild documentation
Rscript -e "devtools::document('lightgbm_r/')"
 # Build the package
# NOTE: --keep-empty-dirs is necessary to keep the deep paths expected
#       by CMake while also meeting the CRAN req to create object files
#       on demand
R CMD BUILD lightgbm_r/  --keep-empty-dirs

(copy and paste not working well on GitHub web...)

ping @guolinke for the proposal on the new package build.

@guolinke sh is automatically supported for Windows users when Rtools is installed (which is mandatory to install & compile packages for R). It is automatically added to PATH during installation (unless the user declines to modify the PATH).
I think this PR also drops devtools::install_github way of installing, but it is not that useful (I find it better to copy locally the repository and install from there, I know many users tried to install from github and failed).
When this PR is ready, I'll modify accordingly my Laurae2/lgbdl repository.

Agree with everything that @Laurae2 said. The fact that this repo uses the "copy source into Python and R packages" pattern prohibits install_github from effectively working (unless you literally built the tarballs and checked them into the repo).
I think that standardizing on the way to build from source will make maintenance easier and help us speed up the path to CRAN. I actually don't think there are too many more things standing in our way, but I've held off addressing the remaining NOTEs / ISSUEs / WARNINGs because I didn't want this PR to get any larger.
As for sh...I think a shell script is straightforward and to @Laurae2 's point it will become available when you use Rtools. However if it is a big enough concern, another option would be to change to a build_r.R script, since R functions like file.copy and devtools::build() take care of the cross-platform differences under the hood. That would take a bit of work but if you want me too I will implement that instead of the shell script.

@guolinke opinion on the last sentence? I think the .R proposal can handle properly all OSes more easily as said.

One task (check-docs) is failing on Travis. Is it because of this?

https://travis-ci.org/Microsoft/LightGBM/builds/416570793?utm_source=github_status&utm_medium=notification

I added build_r.R at the repo root in my most recent commit. Take a look and see if it works for you!
I was able to run it from inside RStudio and at the command line on Mac OS.
If it works and we decide to move forward with that, I'll remove build_r.sh and update the R-package README

@Laurae2 @guolinke Where do we stand with this PR? I would really like to work on the remaining items to get the R package to CRAN, but am holding off until we come to consensus on this

ping @Laurae2

@jameslamb @guolinke It works here through build_r.R in Windows and Ubuntu.

@jameslamb It's ok for me, I'll check the two other PRs later tomorrow.

@Laurae2 ok great, thanks! The other two are very minor and not dependent on this one explicitly. Just other things I noticed while looking through the project.
Hopefully we can get this one merged this week. Since it breaks some old install patterns (I think for the better), once it's out please feel free to direct people complaining about issues installing the R package to me and I will help them out.

@guolinke @jameslamb I think we can merge this (just need to fix the conflicting files and we can commit this PR).

@Laurae2 ok!! let me fix those conflicts right now

@Laurae2 rebased, fixed conflicts, and pushed!

Thanks for the merge, the patience, and the feedback! Going to get started on the remaining issues.
CRAN here we come!

@jameslamb I will fix my lgbdl R-package probably this weekend or the next week as the R README documentation still points out to obsolete steps to install directly from my R-package. Ideally I don't break old installations.

@Laurae2 ok sounds good!


Software keyboard on mobile devices

Probably this is not a priority, anyway on mobile devices (at least Firefox OS and iOS) the keyboard isn't shown when focusing the app, which makes it unusable. Is there anything that can be done?

It will be nice to have it working on mobile. Let's keep this open :-)

+1

+1, 2 years later.

There's also a weird issue where old text (from the last line) keeps showing on a on when typing…


Improve subsys/settings documentation and sample code

I was looking into using the settings subsystem and was quite confused by the documentation and sample code.
The following verbs are used in the code and documentation when referring to operations on setting values:

append
apply
commit
dump
export
get
load
read
save
set
write

I suspect that some of these are synonyms and some - importantly - aren't, but it isn't really clear.
The distinction between "source" and "destination" also depends on whether we are loading data from non-volatile storage or writing into it. I'm assuming that "target" and "destination" refer to the same thing at least? After re-reading those sections it seems clearer to me now: these word only refer to the non-volatile storage, not the copy in RAM.
What is the "runtime" backend and why would I want to use it or not use it?
From the "Garbage collection" section in the docs:
https://github.com/zephyrproject-rtos/zephyr/blob/b1080ea036caf0ccd1141082030d700405ab8e3c/doc/reference/settings/index.rst#L138-L140
This sounds as if the settings subsystem will randomly declare some of my data "garbage" and delete them. That doesn't sound like something anybody would want, or am I misunderstanding this?
Commenting of the sample code is weird in places, e.g.:
https://github.com/zephyrproject-rtos/zephyr/blob/b1080ea036caf0ccd1141082030d700405ab8e3c/samples/subsys/settings/src/main.c#L24

As an example of what I mean by the verbs:
To me, these are synonyms respectively:

get = load
set = store

But the docs on h_set says:
https://github.com/zephyrproject-rtos/zephyr/blob/b1080ea036caf0ccd1141082030d700405ab8e3c/doc/reference/settings/index.rst#L40-L43
So here set = load?

As an example of what I mean by the verbs:
To me, these are synonyms respectively:

get = load
set = store

But the docs on h_set says:
https://github.com/zephyrproject-rtos/zephyr/blob/b1080ea036caf0ccd1141082030d700405ab8e3c/doc/reference/settings/index.rst#L40-L43
So here set = load?

Could export_func be defined as a typedef, same as for settings_read_cb? That would simplify the definition of settings_handler and settings_handler_static.

Could export_func be defined as a typedef, same as for settings_read_cb? That would simplify the definition of settings_handler and settings_handler_static.

Here's how I understand the settings subsystem after playing around with it for a bit. A diagram like this may be useful in the documentation. Of course mine may still be wrong, and does not include the runtime backend nor multiple backends.
Loading:
application          settings                         settings
     |              subsystem                         backend
     |                  |                                |
     | settings_load()  |                                |
     |----------------->|          csi_load()            |
     |                  |------------------------------->|
     |                  |                                |
     |                  | settings_call_set_handler(...) |
     |    h_set(...)    |<-------------------------------|
     |<-----------------|                                |
     |                  | settings_call_set_handler(...) |
     |    h_set(...)    |<-------------------------------|
     |<-----------------|                                |
     |                  |                                |
     |    h_commit()    |                                |
     |<-----------------|                                |

Saving:
application          settings                         settings
     |              subsystem                         backend
     |                  |                                |
     | settings_save()  |                                |
     |----------------->|      csi_save_start(...)       |
     |                  |------------------------------->|
     |  h_export(...)   |                                |
     |<-----------------|                                |
     |                  |                                |
     | export_func(...) |                                |
     |----------------->|         csi_save(...)          |
     |                  |------------------------------->|
     | export_func(...) |                                |
     |----------------->|         csi_save(...)          |
     |                  |------------------------------->|
     |                  |                                |
     |                  |        csi_save_end(...)       |
     |                  |------------------------------->|

Here's how I understand the settings subsystem after playing around with it for a bit. A diagram like this may be useful in the documentation. Of course mine may still be wrong, and does not include the runtime backend nor multiple backends.
Loading:
application          settings                         settings
     |              subsystem                         backend
     |                  |                                |
     | settings_load()  |                                |
     |----------------->|          csi_load()            |
     |                  |------------------------------->|
     |                  |                                |
     |                  | settings_call_set_handler(...) |
     |    h_set(...)    |<-------------------------------|
     |<-----------------|                                |
     |                  | settings_call_set_handler(...) |
     |    h_set(...)    |<-------------------------------|
     |<-----------------|                                |
     |                  |                                |
     |    h_commit()    |                                |
     |<-----------------|                                |

Saving:
application          settings                         settings
     |              subsystem                         backend
     |                  |                                |
     | settings_save()  |                                |
     |----------------->|      csi_save_start(...)       |
     |                  |------------------------------->|
     |  h_export(...)   |                                |
     |<-----------------|                                |
     |                  |                                |
     | export_func(...) |                                |
     |----------------->|         csi_save(...)          |
     |                  |------------------------------->|
     | export_func(...) |                                |
     |----------------->|         csi_save(...)          |
     |                  |------------------------------->|
     |                  |                                |
     |                  |        csi_save_end(...)       |
     |                  |------------------------------->|

I was looking into using the settings subsystem and was quite confused by the documentation and sample code.
I suspect that some of these are synonyms and some - importantly - aren't, but it isn't really clear.

@sw, the settings subsystem is a quite complex system. The documentation might indeed be lacking to easily understand it, the naming of the subroutines might be strange sometimes but let's take the example of h_set: what is does is provide a routine to set a variable and this routine is called when settings_load() is called. The effect is the loading of the variable, but naming it load would not be correct, it doesn't load anything.

~The distinction between "source" and "destination" also depends on whether we are loading data from non-volatile storage or writing into it. I'm assuming that "target" and "destination" refer to the same thing at least?~ After re-reading those sections it seems clearer to me now: these word only refer to the non-volatile storage, not the copy in RAM.
What is the "runtime" backend and why would I want to use it or not use it?

The "runtime" backend can be used make your own custom backend out of the zephyr tree.

From the "Garbage collection" section in the docs:
https://github.com/zephyrproject-rtos/zephyr/blob/b1080ea036caf0ccd1141082030d700405ab8e3c/doc/reference/settings/index.rst#L138-L140
This sounds as if the settings subsystem will randomly declare some of my data "garbage" and delete them. That doesn't sound like something anybody would want, or am I misunderstanding this?

You are misunderstanding this. Whenever an update of a settings is written to a backend a new entry is written, the garbage collection will remove the old entries as well as any deleted entries.
Your schematic is basically indeed what is done, but it is missing some key features like filtered loading, multiple backends, ...

I was looking into using the settings subsystem and was quite confused by the documentation and sample code.
I suspect that some of these are synonyms and some - importantly - aren't, but it isn't really clear.

@sw, the settings subsystem is a quite complex system. The documentation might indeed be lacking to easily understand it, the naming of the subroutines might be strange sometimes but let's take the example of h_set: what is does is provide a routine to set a variable and this routine is called when settings_load() is called. The effect is the loading of the variable, but naming it load would not be correct, it doesn't load anything.

~The distinction between "source" and "destination" also depends on whether we are loading data from non-volatile storage or writing into it. I'm assuming that "target" and "destination" refer to the same thing at least?~ After re-reading those sections it seems clearer to me now: these word only refer to the non-volatile storage, not the copy in RAM.
What is the "runtime" backend and why would I want to use it or not use it?

The "runtime" backend can be used make your own custom backend out of the zephyr tree.

From the "Garbage collection" section in the docs:
https://github.com/zephyrproject-rtos/zephyr/blob/b1080ea036caf0ccd1141082030d700405ab8e3c/doc/reference/settings/index.rst#L138-L140
This sounds as if the settings subsystem will randomly declare some of my data "garbage" and delete them. That doesn't sound like something anybody would want, or am I misunderstanding this?

You are misunderstanding this. Whenever an update of a settings is written to a backend a new entry is written, the garbage collection will remove the old entries as well as any deleted entries.
Your schematic is basically indeed what is done, but it is missing some key features like filtered loading, multiple backends, ...

@sw

Could export_func be defined as a typedef, same as for settings_read_cb? That would simplify the definition of settings_handler and settings_handler_static.

I think yes, you can open a PR for that. We are using kernel like CS here, which mean zephyr-project recomend not to define  types for need of a while, but in this case I think might be usefully.
Nice diagrams BTW.

@sw

Could export_func be defined as a typedef, same as for settings_read_cb? That would simplify the definition of settings_handler and settings_handler_static.

I think yes, you can open a PR for that. We are using kernel like CS here, which mean zephyr-project recomend not to define  types for need of a while, but in this case I think might be usefully.
Nice diagrams BTW.

@sw, it is also worth noting that the set, get, commit, export functionality are all optional and can be set to null functions.
In the simplest case just the set function would be defined, allowing loading of variables while saving is done using settings_save_one(). A addition to that would be to define the commit function allowing the "use" of variables after all variables have been loaded.
Also it is possible to only use direct loading: i.e. you would never call settings_load(), but instead you call settings_load_subtree() with the name of the variable (if the set function is defined) to load or settings_load_subtree_direct() where you provide your own set routine to settings_load_subtree_direct() and you don't have to register any static or dynamic handler.

@sw, it is also worth noting that the set, get, commit, export functionality are all optional and can be set to null functions.
In the simplest case just the set function would be defined, allowing loading of variables while saving is done using settings_save_one(). A addition to that would be to define the commit function allowing the "use" of variables after all variables have been loaded.
Also it is possible to only use direct loading: i.e. you would never call settings_load(), but instead you call settings_load_subtree() with the name of the variable (if the set function is defined) to load or settings_load_subtree_direct() where you provide your own set routine to settings_load_subtree_direct() and you don't have to register any static or dynamic handler.

As a new Zephyr developer but very experienced embedded guy, I agree that the settings documentation is poor even as of 2.7.  I have found the rest of the docs very good, but not the settings.

Additionally, the example file samples/subsys/settings/src/main.c has a few bugs in my opinion. Something is commented and something else is displayed/done.


docs: fixed broken link in README

Explanation
The Getting Started link in README is broken.
Related issue
Proposed Changes
Checklist

[x] I have read the contributing guidelines.
[x] I have read the PR documentation guide and followed the process including adding proof manifests to this PR.
[ ] This is a bug fix and I have added unit tests that prove my fix is effective.

Further Comments

Good catch, thanks!

/cherry-pick release-0.2


import error

running the following command:
python run.py --exp-config /DATA/hemnani1/habitat-lab/VLN-CE/vlnce_baselines/config/paper_configs/seq2seq.yaml --run-type train
I am getting following error:
File "run.py", line 8, in
from habitat import logger
ModuleNotFoundError: No module named 'habitat'
Can anyone help me resolving this?

Also I have installed habitat-lab as well as habitat sim from stable branches. Where this habitat module is located?


Storage[doc-samples] : Spilt StorageSnippest one per file

Split storage snippets such way that there is one snippet per file.
Example Code:
https://github.com/googleapis/google-cloud-java/blob/master/google-cloud-examples/src/main/java/com/google/cloud/examples/storage/snippets/StorageSnippets.java
~://cc @frankyn

@JesseLovelace has implemented this work AFAIU.
@JesseLovelace please confirm before @athakor continue on this path.

@frankyn these snippets is quite old and i guess it's not in the current standard doc sample format, kindly check the similar issue here.
@JesseLovelace  colud you please confirm on this path.

@JesseLovelace gentle ping

@frankyn, the work I did was to split only the scoped samples, which are the most viewed ones. There are still many samples in the big StorageSnippets file that haven't been split, they remained because they were not scoped as part of the sample gap project. Splitting the rest was intended to be a follow-up.
However, a very great deal of the samples in that file are unpublished and will likely never be published, so the effort to split them could be a waste. I'd rather identify and delete the useless samples first before @athakor goes through the trouble of splitting them, but that's definitely deprioritized for now.

@athakor please don't move forward with this request until @JesseLovelace unblocks the open question raised.

@JesseLovelace @frankyn Thanks for the clarification

Clarifying a comment above — with the addition of "sample browser" and the snippet bot, any eligible samples are now published at least somewhere. So this clean-up work should still probably be done, but I'll leave it to the Storage team to identify when.

The storage samples were all moved by @JesseLovelace in two phases: https://github.com/googleapis/java-storage/pull/1258 to copy samples over and https://github.com/googleapis/google-cloud-java/pull/7822 to delete them here. Closing.


Update test.log

If the message below is truncated, see https://ci.appveyor.com/project/yihui/latex-pass/builds/40321467 for the full version.
The missing packages identified from the LaTeX log are:
siunitx babel-english

If you are an R user using TinyTeX, you may install these packages via:
tinytex::tlmgr_install(c('babel-english', 'siunitx'))

If you use TinyTeX, including LaTeX for Manim (https://chocolatey.org/packages/manim-latex), you may install these packages via command line:
tlmgr install babel-english siunitx

If you do not use TinyTeX (https://yihui.org/tinytex/), you need to figure out how to install them by yourself.


storage-secret-config should have the same parameters as Kserve

Is your feature request related to a problem? If so, please describe.

The json format of the storage-secret-config in ModelMesh expects the default bucket to be specified as follows : "default_bucket":"modelmesh-example-models"
However, this is not consistent with the Kserve implementation, which expects the default bucket to be specified as follows :
"bucket":"modelmesh-example-models".
This mismatch in the key is frustrating. Following a consistent format will allow users to have a better experience across both serving stacks (kserve and modelmesh)
Describe your proposed solution

Match the storage-secret-config that Kserve has. i.e the key should be bucket rather than default_bucket

Hello, thanks for pointing this out!
I think this is actually just a documentation problem
In the adapter code that processes the storage configuration, bucket is supported and takes priority over default_bucket (which is marked as deprecated), see these lines in the adapter repo. So I think it should "just work" if you use bucket, but let me know if you get an error!
If bucket does work, then we should see about replacing default_bucket -> bucket everywhere that it is used in this repo.

I am new to open source, can I start contributing from this issue ?

Sure, @AHB102. @tjohnson31415  gave some insight above, please ask if you need any clarification. More information about the storage-config secret can be found here.

@tjohnson31415 Can you please explain what exactly must be changed ? There are discrepancies with "bucket" and "default_bucket" in the json format of  storage-secret-config in ModelMesh, right ? So we should just make one of them the standard ?

Hi @AHB102, as noted in the issue description, using "bucket" should be the standard to match with KServe, so that is already decided.
In this ModelMesh repo, the documentation and example files are using "default_bucket", see the GH search results to see where we reference it. As I noted in my previous comment, use of "bucket" should already be fully supported in the code.
The changes for this issue would be to modify every place that "default_bucket" is referenced and change it to just "bucket".
As a validation of the change, you should also test that the quickstart install still works after modifying quickstart.yaml to use "bucket" instead of "default_bucket".

@tjohnson31415 Got it, Identify and replace every reference of "default_bucket" with "bucket" and then test quickstart installation to validate it. Can I work on it ?

Hi @AHB102, just wanted to confirm whether you still plan to work on this. I can assign it to you if so!

Yup, I would like to work on it.

Great, thanks @AHB102!

@rafvasq @AHB102
I can take this issue up if no one's currently working on it

@aayushsss1 sure, feel free!


Evaluate improvement of company names set up.

Evaluate possibility to avoid duplication of company names in CD & possibility to change company names
Evaluate resolution of the following 2 problems:

Company names are mentioned in participants.json, in Deploy outputs and in the Verify job. Investigate a solution to have something more dynamic and avoid repeating company names.

Right now, if the user updates the participants.json file to update company names, deployment will work but Verify step will fail in CD. Investigate a solution to avoid breaking Verify step when

These 2 problems are overlapping and have the same root cause.
One potential solution is to output all outputs as a json ${{ toJSON(steps.runterraform.outputs) }} and then parse the json to extract information.
Acceptance criteria

[ ] A follow up story with a solution proposal is created.

One potential solution is to output all outputs as a json ${{ toJSON(steps.runterraform.outputs) }} and then parse the json to extract the information.


Add api.flutter.dev analytics for javadocs and objcdocs

The dartdocs have usage data but the platform APIs docs don't

Triage: what is needed from infra team?

I meant this to be a website infra feature request. Don't know if this is in a Flutter infra team queue. There are currently no google analytics reporting from the non-dart docs on our website.

Are these metrics still useful?


Timeout can set to 0s but failed during taskrun

Since Tekton v0.28+, activeDeadlineSeconds is introduced for the pods and it's calculated based on the timeout. Since activeDeadlineSeconds must be between 1 and<PHONE_NUMBER>s, setting timeout to 0s will cause the following errors
failed to create task run pod "pipeline-15bdb-run-b-jv5wt": Pod "pipeline-15bdb-run-b-gxq8z" is invalid: spec.activeDeadlineSeconds: Invalid value: 0: must be between 1 and<PHONE_NUMBER>, inclusive. Maybe invalid TaskSpec

Expected Behavior
The webhook should give me an error if I set the timeout to 0s.
Actual Behavior
I can apply the taskRun without errors but failed when the controller is trying to create the pod.
Steps to Reproduce the Problem

Set any task's timeout to 0s.
The taskrun will have the above error.

Additional Info

Kubernetes version:
Output of kubectl version:
v1.21

Tekton Pipeline version:
v0.30.0
Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

/cc @pritidesai

thank you @Tomcli for reporting this.
@vdemeester @Tomcli What should be the expected behavior when a timeout is set to 0s?
activeDeadlineSeconds is not directly set from the API and calculated based on the given timeout using this formula:
int64(taskRun.GetTimeout(ctx).Seconds() * 1.5)

And setting the timeout to 0s as NoTimeout so it's not reasonable for a webhook to throw an error.
can we leave setting the activeDeadlineSeconds in this case?

Before Tekton 0.28, timeout can be set to 0s and the pod will never timeout. If activeDeadlineSeconds is not necessary, we can skip the activeDeadlineSeconds if timeout is 0.
At the moment, since timeout with 0s is broken between Tekton 0.28-0.30, we changed our client code to check timeout cannot be <= 0s because the webhook didn't throw any error.

thanks @Tomcli 👍
@Tomcli @vdemeester please take a look at the fix, PR #4450 👀

@Tomcli if the PR is merged, do you want us to cherry pick this fix in the latest pipeline release (https://github.com/tektoncd/pipeline/releases/tag/v0.31.0)? Please note that v0.32.0 is due on January 13th.

We don't need to cherry pick, since it's broken since v0.28.0. We can move onto v0.32 if there are no significant changes.
At the moment we are using Tekton v0.30.0.

thanks @pritidesai for fixing this issue.

The use of activeDeadlineSeconds is mainly to mark pipeline's Pod as Terminating (for quotas, etc..). Not setting it in some cases will be very confusing as we would end up in cases where pods are terminating and cases where they are not, thus sharing different quotas.
I think the alternative here are:

Disallow timeout 0 so that we never run into this (it's kind-of breaking current behavior)
Allow timout 0 and setting activeDeadlineSeconds to its max value
Reverting setting activeDeadlineSeconds (but it move back the pipeline's Pod under the nonterminating quota.. which is unexpected for 99% of users and use cases)
Disallow timeout 0 and have an option/controller flag to allow it with the nonterminating behavior.


Should an Offer always have a planned end date?

Current definition of gist:Offer:
gist:Offer
	a owl:Class ;
	owl:equivalentClass [
		a owl:Class ;
		owl:intersectionOf (
			gist:ContingentObligation
			[
				a owl:Restriction ;
				owl:onProperty gist:hasDirectPart ;
				owl:someValuesFrom gist:CatalogItem ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:hasGiver ;
				owl:someValuesFrom [
					a owl:Class ;
					owl:unionOf (
						gist:Organization
						gist:Person
					) ;
				] ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:hasMagnitude ;
				owl:someValuesFrom gist:Monetary ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:plannedStartDateTime ;
				owl:cardinality "1"^^xsd:nonNegativeInteger ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:plannedEndDateTime ;
				owl:cardinality "1"^^xsd:nonNegativeInteger ;
			]
		) ;
	] ;
	skos:definition "A commitment to buy or sell a described or identified part or service."^^xsd:string ;
	skos:prefLabel "Offer"^^xsd:string ;
	.

It might be right that all offers lapse at some point (even if only after a reasonable period of time), but I wouldn't think it has to be planned for. I see that the latest version of the formal definition for gist:Offer changes gist:plannedStartTime to gist:hasStart. One option is to do the same for the end time. Another option is to remove the end time restriction. I think I would lean towards the latter. Even if, as a matter of law, all offers lapse at some point, having an end time doesn't seem to be part of what it means for something to be an offer.

The version above is the not-yet-released gist 11. gist 10, as you note has restrictions on hasStart and hasPlannedEnd. I'm not sure if the change from planned or actual start to planned start was deliberate or an accident, but it seems like an improvement.

I agree that its wrong to say every Offer has a planned end. Jus tremove that restriciont, is the way to go.

@rjyounes, @dylan-sa

I see that the latest version of the formal definition for gist:Offer changes gist:plannedStartTime to gist:hasStart.

That is no longer the case, it is now plannedStartDateTime.
PROPOSAL: make 3 changes

remove restriction for end time
use startDateTime for the start restriction, (be agnostic on planned vs. actual)
Fix a bug in the definition, it should say product, not part

New version would be this:
gist:Offer
	a owl:Class ;
	owl:equivalentClass [
		a owl:Class ;
		owl:intersectionOf (
			gist:ContingentObligation
			[
				a owl:Restriction ;
				owl:onProperty gist:hasDirectPart ;
				owl:someValuesFrom gist:CatalogItem ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:hasGiver ;
				owl:someValuesFrom [
					a owl:Class ;
					owl:unionOf (
						gist:Organization
						gist:Person
					) ;
				] ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:hasMagnitude ;
				owl:someValuesFrom gist:Monetary ;
			]
			[
				a owl:Restriction ;
				owl:onProperty gist:startDateTime ;
				owl:cardinality "1"^^xsd:nonNegativeInteger ;
			]
		) ;
	] ;
	skos:definition "A commitment to buy or sell a described or identified product or service."^^xsd:string ;
	skos:prefLabel "Offer"^^xsd:string ;
	.

I agree with @uscholdm's proposal. Should we change hasDirectPart to hasPart?

Should we change hasDirectPart to hasPart, just to hedge our bets?

I don't think so. An offer should point directly to thing being offered.

I like @uscholdm's proposal.

I don't think so. An offer should point directly to thing being offered.

Now that you put it like that, I don't think has(Direct)Part is the right predicate. The thing being offered has a more specific connection to the offer than part-whole. I've proposed the introduction of a predicate isOfferOf. It doesn't have to be that, but "part of" just doesn't seem like the right semantic relationship.

@rjyounes

Now that you put it like that, I don't think has(Direct)Part is the right predicate. The thing being offered has a more specific connection to the offer than part-whole. I've https://github.com/semanticarts/gist/issues/528. It doesn't have to be that, but "part of" just doesn't seem like the right semantic relationship.

We don't want to introduce a new predicate unless the current one is clearly wrong or ambiguous.  Its general, but not wrong. I cannot think how ambiguity would arise.  What other meaning could there possibly be to a directPart link to a CatalogItem other than being that which is offered?


escape dot in regex

Turns out this escape is needed. It's a Vim regex, but still a regex, where . means "any character", meaning that my repo in under ~/git/github/ does not load the plugin because its matching /git/ when it should only be matching /.git/

@ldelossa this one


"Contributing Guidelines" link is broken in the README

Under the contributing section of the README.md, the "Contributing Guidelines" link is broken and points to a 404: https://github.com/SKaplanOfficial/PyXA/blob/main/docs/about/contributing_guidelines.html
I'd submit a PR to fix it but not sure what the intended target is.

Thanks, just fixed this. Forgot to change it when I moved the guidelines to the standard markdown file a while back.


Tests are namespaced incorrectly

The unit tests are namespaced incorrectly.
They add themselves into the module they are testing, like this:
module Vcloud
  module Core
    describe ConfigLoader do

And then call that object again explicitly:
       loader = ConfigLoader.new

One side-effect of this is it is then possible to refer to objects without namespacing them correctly, which can then get missed out when refactoring.
It would be cleaner and more rspec-ey to do:
describe Vcloud::Core::ConfigLoader do
…
  it "foo" should
    subject.update(bar)

Refactoring the tests like this can make them easier to read, as well as maintain.
Using subject can also make the tests easier to read. However, you might not want to actually use variable name subject.
Please see a previous example of where we did this.
This can also be combined with using let rather than before. See another example of where we did this.
Further reading:
DRY up your Rspec test files with subject and let
Rspec before vs let

There's actually two things (at least) here:

explicitly reference the namespace in each test
use let to declare facts more globally

I started doing this in https://github.com/gds-operations/vcloud-core/compare/117-refactor-tests.

That branch - https://github.com/gds-operations/vcloud-core/compare/117-refactor-tests - should work fine, but it's messy. Needs a rebase.


Fix package.json scripts

Pipeline was failing because the scripts in the package.json file were incorrect. This includes again the build:prod and build:staging scripts.
Note: Building the app in production will fail because of the filesize budget on the angular.json file. We may have to tweak them in order to properly build the app.
Can you ptal @nkoenig ?

Thanks @nkoenig ! Merging into staging.


fix: fix cse

What type of PR is this?
/kind bug

What this PR does / why we need it:
$? returns 0 forever without this change, thus we can never get the failure output for "curl" command.
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

@anujmaheshwari1 could you take a look? this change lgtm, thanks.


Too much indentation breaks things?

I'm working on making an Ember cheatsheet for folks learning ember, and I've written this "markdown" so far:
# {{t 'layout.application.title'}}

{{t 'layout.application.description-1' htmlSafe=true}}

{{t 'layout.application.description-2' htmlSafe=true}}

<GuideSection @id='generating-files' as |Section|>

    <:example>

      ```bash
      # -gc stands for glimmer component
      ember generate component my-component -gc

      # See the full set of options with:
      ember generate component --help
      ```

    <:/example>

</GuideSection>

But, I get the error:
Template Compiler Error (TemplateCompiler) in ember-octane-vs-classic-cheat-sheet/templates/docs.hbs

Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)

and running with DEBUG=@docfy/*, I get the following log:
log file

=================================================================================

ENV Summary:

  TIME: Sat Sep 18 2021 11:15:21 GMT-0400 (Eastern Daylight Time)
  TITLE: ember
  ARGV:
  - 🏠/.volta/tools/image/node/14.17.6/bin/node
  - /✂/ember-cheat-sheet/node_modules/.bin/ember
  - serve
  EXEC_PATH: 🏠/.volta/tools/image/node/14.17.6/bin/node
  TMPDIR: /tmp
  SHELL: /bin/bash
  PATH:
  - /tmp/yarn--1631978109995-0.8884726619933956
  - /✂/ember-cheat-sheet/node_modules/.bin
  - 🏠/.config/yarn/link/node_modules/.bin
  - 🏠/.yarn/bin
  - 🏠/.volta/tools/image/node/14.17.6/libexec/lib/node_modules/npm/bin/node-gyp-bin
  - 🏠/.volta/tools/image/node/14.17.6/lib/node_modules/npm/bin/node-gyp-bin
  - 🏠/.volta/tools/image/node/14.17.6/bin/node_modules/npm/bin/node-gyp-bin
  - 🏠/.volta/tools/image/yarn/1.22.11/bin
  - 🏠/.volta/tools/image/node/14.17.6/bin
  - 🏠/.volta/bin
  - 🏠/.pythons/Python-3.6.3/bin
  - 🏠/.cargo/bin
  - 🏠/Applications
  - 🏠/apps/phantomjs/bin
  - 🏠/scripts/system-utils
  - 🏠/scripts/git
  - 🏠/scripts/rails
  - 🏠/scripts
  - 🏠/.volta/bin
  - 🏠/.pythons/Python-3.6.3/bin
  - 🏠/.cargo/bin
  - 🏠/Applications
  - 🏠/apps/phantomjs/bin
  - 🏠/scripts/system-utils
  - 🏠/scripts/git
  - 🏠/scripts/rails
  - 🏠/scripts
  - /usr/local/sbin
  - /usr/local/bin
  - /usr/sbin
  - /usr/bin
  - /sbin
  - /bin
  - /usr/games
  - /usr/local/games
  - /snap/bin
  - /snap/bin
  - 🏠/.fzf/bin
  PLATFORM: linux x64
  FREEMEM:<PHONE_NUMBER>4
  TOTALMEM:<PHONE_NUMBER>2
  UPTIME: 5440.65
  LOADAVG: 1.18,0.71,0.58
  CPUS:
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2938
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2231
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2400
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2400
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2938
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2400
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2400
  - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz - 2400
  ENDIANNESS: LE
  VERSIONS:
  - ares: 1.17.2
  - brotli: 1.0.9
  - cldr: 39.0
  - icu: 69.1
  - llhttp: 2.1.3
  - modules: 83
  - napi: 8
  - nghttp2: 1.42.0
  - node: 14.17.6
  - openssl: 1.1.1l
  - tz: 2021a
  - unicode: 13.0
  - uv: 1.41.0
  - v8: 8.4.371.23-node.76
  - zlib: 1.2.11

ERROR Summary:

  - broccoliBuilderErrorStack: SyntaxError: Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)
    at generateSyntaxError (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:11493:17)
    at TokenizerEventHandlers.validateEndTag (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:13427:15)
    at TokenizerEventHandlers.finishEndTag (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:13298:12)
    at TokenizerEventHandlers.finishTag (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:13268:14)
    at EventedTokenizer.endTagName (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:23478:27)
    at EventedTokenizer.tokenizePart (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:23771:19)
    at TokenizerEventHandlers.ContentStatement (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12863:22)
    at TokenizerEventHandlers.acceptNode (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12550:29)
    at TokenizerEventHandlers.Program (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12670:14)
    at TokenizerEventHandlers.acceptTemplate (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12546:29)
  - code: [undefined]
  - codeFrame: Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)
  - errorMessage: ember-octane-vs-classic-cheat-sheet/templates/docs.hbs: Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)
        in /tmp/broccoli-69332AQQgj7RPWki7/out-269-colocated_template_processor
        at TemplateCompiler
  - errorType: Template Compiler Error
  - location:
    - column: [undefined]
    - file: ember-octane-vs-classic-cheat-sheet/templates/docs.hbs
    - line: [undefined]
    - treeDir: /tmp/broccoli-69332AQQgj7RPWki7/out-269-colocated_template_processor
  - message: ember-octane-vs-classic-cheat-sheet/templates/docs.hbs: Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)
        in /tmp/broccoli-69332AQQgj7RPWki7/out-269-colocated_template_processor
        at TemplateCompiler
  - name: Error
  - nodeAnnotation: [undefined]
  - nodeName: TemplateCompiler
  - originalErrorMessage: Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)
  - stack: SyntaxError: Closing tag
 did not match last open tag <:example> (on line 6):

|
|

|

(error occurred in 'ember-octane-vs-classic-cheat-sheet/templates/docs.hbs' @ line 17 : column 2)
    at generateSyntaxError (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:11493:17)
    at TokenizerEventHandlers.validateEndTag (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:13427:15)
    at TokenizerEventHandlers.finishEndTag (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:13298:12)
    at TokenizerEventHandlers.finishTag (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:13268:14)
    at EventedTokenizer.endTagName (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:23478:27)
    at EventedTokenizer.tokenizePart (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:23771:19)
    at TokenizerEventHandlers.ContentStatement (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12863:22)
    at TokenizerEventHandlers.acceptNode (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12550:29)
    at TokenizerEventHandlers.Program (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12670:14)
    at TokenizerEventHandlers.acceptTemplate (/✂/ember-cheat-sheet/node_modules/ember-source/dist/ember-template-compiler.js:12546:29)

=================================================================================

Which points me at this directory:
/tmp/broccoli-69332AQQgj7RPWki7/out-269-colocated_template_processor

which, reveals the following output (routes/docs.hbs):

{{t 'layout.application.title'}}

{{t 'layout.application.description-1' htmlSafe=true}}

{{t 'layout.application.description-2' htmlSafe=true}}

<GuideSection @id='generating-files' as |Section|>

    <:example>

  \`\`\`bash
  # -gc stands for glimmer component
  ember generate component my-component -gc

  # See the full set of options with:
  ember generate component --help
  \`\`\`

<:/example>

</GuideSection>

Do we need to switch to rehype and rewrite remark-hbs for rehype?

Here is a reproduction: https://github.com/NullVoxPopuli/ember-cheat-sheet/pull/1

Seems this breaks, too:
<GuideSection @id='generating-files' as |Section|>

  <:example>
```bash
# -gc stands for glimmer component
ember generate component my-component -gc

# See the full set of options with:
ember generate component --help

<:/example>

```
as well as
```md

  <:example>
# -gc stands for glimmer component
ember generate component my-component -gc

# See the full set of options with:
ember generate component --help

<:/example>

```

omg, I had the : and / swapped on the closing element. :facepalm:

still errors, tho

ok, so this renders, but the indentation is not ideal:
<GuideSection @id='generating-files' as |Section|>

  <:example>

    \`\`\`bash
    # -gc stands for glimmer component
    ember generate component my-component -gc

    # See the full set of options with:
    ember generate component --help
    \`\`\`

  </:example>

</GuideSection>

but, the code block isn't converted to a highlighted codeblock

de-denting the code-snippet gets hljs to run on it:
<GuideSection @id='generating-files' as |Section|>

  <:example>

```bash
# -gc stands for glimmer component
ember generate component my-component -gc

# See the full set of options with:
ember generate component --help

</:example>

```
I guess.. there are a lot of different bugs going on here (2, I guess)

Too much indentation breaks the remark-hbs plugin
Can't have indentation of anything when you go in to markdown mode in a markdown block

Which maybe all boils down to one core issue:

indentation level not stripped in nested components/elements


beacon: main branch: use beacon package as other package

Android version, once published on the store, is crashing.
A new version without beacon package is not crashing.
Hypothesis: having beacon in folder next to AltMe folder is the root cause.
Solution: Using beacon as normal package with a github reference to use our last dev version.

S size


Support ASYNC extra actions

Describe the bug
Custom extraActions works great, as long as they are synchronous functions. Modifying schema or formData objects inside these synchtronous functions effectively updates the schema / formData fields.
The problem comes when trying to use async functions when executing extraActions.
Although async functions can be executed successfully, updating schema or formData objects do not have any effect.
For example, I have an async extraAction that performs an AJAX call and, based on the response, updates the formData object.
Even though the formData object is updated with the AJAX response, no changes are rendered on the form.
I believe the problem comes from the fact rulesRunner.doRunRules calls all the extraAction events in a synchronous way
events.forEach((event) =>       execute(event, schemaCopy, uiSchemaCopy, formDataCopy, extraActions)  );
If any of the "execute" calls is actually an async function , the xxxCopy parameters are updated when doRunRules have actually ended, and the update takes no effect.
Not sure if I'm exactly right about the root cause, but in any case, async extraActions do not work.
Is there any workaround for this, or an easy fix on the library that would allow this scenario to work ?

What sort of a problem are you trying to solve? It is a bit unexpected to have a long running function because at a minimum extra actions should be able to mutate the whole schema in between keystrokes. You could wrap async functionality in a field similar to autocomplete and then change the schema when result comes back, this could be done through custom fields

I'm basically trying to code a typical example of dropdown dependencies :  i.e You choose a Country on one dropdown, and then a dependent City dropdown must be refreshed, only displaying cities of the country selected on the first dropdown. There could even be a third dependent dropdown, i.e sightseeing places, after choosing the city, the sightseeing dropdown must be updated as well.  Now there are different ways to achieve this with JSON schemas.   One approach is to use the "dependencies" JSON keyword to construct a "oneof" dependency tree... as I managed to demo on this code sample here:
https://codesandbox.io/s/fervent-cherry-lokjk?file=/src/App.js
but this makes the JSON schemas kind of complicated, when you have many related dropdowns, and you have to build the entire schema with all the values beforehand.
So I was thinking of using JSON conditionals, to build rules that, given a value on one Select dropdown, would ajax-load the corresponding values of a dependent dropdown (at least the very first time, the response could be cached, so that we don't need to make the ajax call everytime we choose the same value).  This is when I realized the rule engine does not actually support async rules.
Right now I'm solving the problem by "preloading" all the dropdown values I need in different arrays, and then switching between them when needed. (the rule updates the "enum" property of a select input from one of the arrays). This approach works fine so far. But of course I have to preload all the possible values of all the dropdowns.  For small data sets,  this is not a problem.  But if you have to preload hundreds of options before the schema can be rendered... that starts to become a problem.

It seems to be a great feature, unfortunately the module is in a maintenance mode. Furthermore is is not a small feat to refactor code and allow for async execution. I'll keep the issue open for anyone willing to open up a PR with proposed changes to allow async.

Agree.  I did some quick coding, trying to add async capability to the library, but failed miserably.  It's more complicated than expected. Still, as you mention, it would be awesome.

I'll close this due to the inactivity. I have no time to spare here.