node-gyp rebuild failed on installation

gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/debby/.nvm/versions/node/v6.6.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 3.16.0-4-amd64
gyp ERR! command "/home/debby/.nvm/versions/node/v6.6.0/bin/node" "/home/debby/.nvm/versions/node/v6.6.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/debby/Documents/dev/bot/app/bot/src/node_modules/zmq
gyp ERR! node -v v6.6.0
gyp ERR! node-gyp -v v3.3.1
gyp ERR! not ok
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/home/debby/.nvm/versions/node/v6.6.0/bin/node" "/home/debby/.nvm/versions/node/v6.6.0/bin/npm" "install" "zmq" "--save"
npm ERR! node v6.6.0
npm ERR! npm  v3.10.3
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the zmq package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild

I have had the same problem. What I found http://stackoverflow.com/questions/21365714/nodejs-error-installing-with-npm
It says you may not need VS, but need Python.
I don't want any of those for my app.

If you want zeromq yet don't want to have to bother with building with node-gyp, use zmq-prebuilt.

I wanted just a single nodejs package which can do a job. Your prebuilt package still has too many dependencies

Ok, good luck!

Same error for
$ npm install zmq
versions:
node v7.0.0
npm v3.10.8
zmq: 2.15.3
python 2.7.10
gnu make: 3.81
gcc: clang: 8.0.0
system: Darwin 16.1.0 Darwin Kernel Version 16.1.0: Thu Oct 13 21:26:57 PDT 2016;
root:xnu-3789.21.3~60/RELEASE_X86_64 x86_64

/bin/sh: pkg-config: command not found
gyp: Call to 'pkg-config libzmq --libs' returned exit status 127 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: gyp failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/opt/node-v7.0.0-darwin-x64/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:305:16)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Darwin 16.1.0
gyp ERR! command "/opt/node-v7.0.0-darwin-x64/bin/node" "/opt/node-v7.0.0-darwin-x64/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /not-shown/node_modules/zmq
gyp ERR! node -v v7.0.0
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
npm ERR! Darwin 16.1.0
npm ERR! argv "/opt/node-v7.0.0-darwin-x64/bin/node" "/opt/node/bin/npm" "install" "zmq"
npm ERR! node v7.0.0
npm ERR! npm  v3.10.8
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild
npm ERR! Exit status 1
427 error Darwin 16.1.0
652 428 error argv "/opt/node-v7.0.0-darwin-x64/bin/node" "/opt/node/bin/npm" "install" "zmq"
653 429 error node v7.0.0
654 430 error npm  v3.10.8
655 431 error code ELIFECYCLE
656 432 error<EMAIL_ADDRESS>install: node-gyp rebuild
657 432 error Exit status 1
658 433 error Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.

Same error here on CentOS 6:
gyp ERR! System Linux 2.6.32-642.el6.x86_64
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /root/node-projects/test/node_modules/zmq
gyp ERR! node -v v7.3.0
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm ERR! Linux 2.6.32-642.el6.x86_64
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" "zmq"
npm ERR! node v7.3.0
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!

@rgbkrk I had tried both commands, and both failed with the same error message. The library was not installed.
using the command npm install --save zeromq on my CentOS 6 system:
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 2.6.32-642.el6.x86_64
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /root/node-projects/test/node_modules/zeromq
gyp ERR! node -v v7.3.0
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm ERR! Linux 2.6.32-642.el6.x86_64
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" "--save" "zeromq"
npm ERR! node v7.3.0
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `prebuild-install || (npm run build:libzmq && node-gyp rebuild)`
npm ERR! Exit status 1
npm ERR!

/cc @lgeiger

It looks like the prebuilds didn't install for you and it's going back to a source based installation. Sadly the traceback doesn't say much about what the missing pieces might be. We have a guide for building from source which would be good to cross reference to see if you have all the dependencies.

@Parasin A PR adding a note to the installation instructions on zeromq would be super helpful :)

@Parasin that worked perfectly as well.  finally after a year or something of dealing with this problem heh... not the most ideal fix but at least there is a fix.


feat: external DB support

PostgreSQL would be a good candidate IMO

PostgreSQL would be a good candidate IMO

I agree but I think the best consideration is to support ORM, something like SQLAlchemy ORM. As long as we adhere to Object Relational Mapper compatible statements, many major databases could be supported! SQLAlchemy presently supports a variety of dialects including PostgreSQL, MySQL and MariaDB, SQLite, Oracle, and Microsoft SQL Server.

@lainedfles I am in full agreement that we need a more flexible solution to data storage, but I get real nervous about ORMs, heard too many horror stories of absolutely unhinged monstrosities of queries full of JOINS being emitted by them. They can make writing the code easier, but it's usually at the cost of efficiency.

Postgres would be the best use case here.

Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?

Any update on this one? Where is the data being handled to be stored in database? at /rag/utils.py ?
Not sure whether you are talking about storing the information relating to connecting to the database but I do not believe this path has any relation to that.

I am currently looking at creating relational diagram based off of the models located at backend\apps\web\models. I also believe SQLAlchemy ORM is the best option to implement this from a relational database perspective.
Would there also be considerations for something like Mongo in the future?

Would there also be considerations for something like Mongo in the future?
@sfn-git

IMO, MongoDB isn't appropriate for the practical use case here as Open WebUI database is well defined


Add ilab sysinfo command

Changes
Description of your changes:
The new ilab sysinfo command prints various system information related to the operating system, PyTorch, accelerators and llama-cpp. The output is useful for debugging issues.
$ ilab sysinfo
instructlab.version: 0.14.1.dev152+g3e610c1.d20240508
sys.version: 3.11.7 (main, Jan 22 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)]
sys.platform: linux
os.name: posix
platform.system: Linux
platform.release: 5.14.0-362.8.1.el9_3.x86_64
platform.machine: x86_64
os-release.ID: rhel
os-release.VERSION_ID: 9.4
os-release.PRETTY_NAME: Red Hat Enterprise Linux 9.4 (Plow)
torch.version: 2.3.0+cu121
torch.backends.cpu.capability: AVX512
torch.version.cuda: 12.1
torch.version.hip: None
torch.cuda.available: True
torch.backends.cuda.is_built: True
torch.backends.mps.is_built: False
torch.backends.mps.is_available: False
torch.cuda.bf16: True
torch.cuda.current: 0
torch.cuda.0.name: NVIDIA A100 80GB PCIe
torch.cuda.0.free: 78.7
torch.cuda.0.total: 79.1
torch.cuda.0.capability: 8.0
llama_cpp_python.version: 0.2.55
llama_cpp_python.supports_gpu_offload: True

Thanks for this submission, I think it's going to provide great value for the project overall and it's going to be helpful when debugging!


enable the --strict option in kubeval

$ kubeval --help
Validate a Kubernetes YAML file against the relevant schema

Usage:
  kubeval <file> [file...] [flags]

Flags:
      --additional-schema-locations strings   Comma-seperated list of secondary base URLs used to download schemas
  -d, --directories strings                   A comma-separated list of directories to recursively search for YAML documents
      --exit-on-error                         Immediately stop execution when the first error is encountered
  -f, --filename string                       filename to be displayed when testing manifests read from stdin (default "stdin")
      --force-color                           Force colored output even if stdout is not a TTY
  -h, --help                                  help for kubeval
      --ignore-missing-schemas                Skip validation for resource definitions without a schema
  -i, --ignored-filename-patterns strings     A comma-separated list of regular expressions specifying filenames to ignore
      --insecure-skip-tls-verify              If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
  -v, --kubernetes-version string             Version of Kubernetes to validate against (default "master")
      --openshift                             Use OpenShift schemas instead of upstream Kubernetes
  -o, --output string                         The format of the output of this script. Options are: [stdout json tap]
      --quiet                                 Silences any output aside from the direct results
      --reject-kinds strings                  Comma-separated list of case-sensitive kinds to prohibit validating against schemas
  -s, --schema-location string                Base URL used to download schemas. Can also be specified with the environment variable KUBEVAL_SCHEMA_LOCATION.
      --skip-kinds strings                    Comma-separated list of case-sensitive kinds to skip when validating against schemas
      --strict                                Disallow additional properties not in schema
      --version                               version for kubeval

Enabled --strict in kubeval to detect the specification of properties that do not exist in the schema.
Checklist

[x] Chart Version bumped

Results of running lint on all charts:
https://app.circleci.com/pipelines/github/chatwork/charts/451/workflows/263d84e4-25d7-4333-9019-cd79b0e651a3/jobs/1749

If add strict, I think it will cause an error in the resources that use CRD, but in that case, I don't need to add an strict in that application, right?

@cw-sakamoto
cw-ozaki: ~/Projects/charts/argoproj-crd (docker-desktop/test) [git:add-lint-kubeval-strict]
$ helm template . | kubeval --additional-schema-locations https://raw.githubusercontent.com/cw-ozaki/kubernetes-json-schema/master/ --kubernetes-version ${KUBERNETES_VERSION:-"1.18.8"} --exit-on-error
ERR  - argoproj-crd/templates/appproject.yaml: Failed initializing schema https://kubernetesjsonschema.dev/v1.18.8-standalone/appproject-argoproj-v1alpha1.json: Could not read schema from HTTP, response status is 404 Not Found
Failed initializing schema https://raw.githubusercontent.com/cw-ozaki/kubernetes-json-schema/master//v1.18.8-standalone/appproject-argoproj-v1alpha1.json: Could not read schema from HTTP, response status is 404 Not Found

CRD is not supported by kubeval.
This is because the schema file does not exist.
If you want to use CRD, you should not use kubeval.

@cw-ozaki
--ignore-missing-schemas , so if you have a CRD and a regular manifest, it looks like you can add this.
https://github.com/instrumenta/kubeval/issues/47

@cw-sakamoto
So a flag called --ignore-missing-schema existed on the kubeval!
I'll try and add it.

@cw-sakamoto
=> Validating default value.yaml
helm template . | kubeval --strict --ignore-missing-schemas --additional-schema-locations https://raw.githubusercontent.com/cw-ozaki/kubernetes-json-schema/master/ --kubernetes-version ${KUBERNETES_VERSION:-"1.18.8"} --exit-on-error
WARN - Set to ignore missing schemas
WARN - argoproj-crd/templates/appproject.yaml containing a AppProject (my-project) was not validated against a schema

Fantastic!


Add tagging to formula tests

Instead of the normal test do, tests that only perform trivial behavior
(like checking --version or --help) should use test :trivial do.
This allows coverage of formula to be improved while properly distinguishing
nontrivial checks from trivial ones (Formula#test_trivial?).

cc @UniqMartin @mikemcquaid

I guess I'll have to go quietly if this has been discussed elsewhere but I have some concerns on this.
I understand the reasoning but I'm quite against this implementation, to be honest. I don't think it gains us all that much, and I think it leads to contributors (or you) having to rewrite existing "bad" tests that may never become "good" tests to clarify they are "bad".
We're already really quite explicit in the Cookbook which kinds of tests are good and bad, but despite that in most situations even the maintainers struggle to write "good" tests for a lot of formulae because we're not all that familiar with the formula in question.
I've also pretty much lost count of how many PRs have suddenly gone silent after we've asked for a stronger test. A lot of contributions to Homebrew are "Hey this is popular, I found it, played with it a bit and it seems cool, maybe others want to use it too" - I'd say we get considerably more contributions like that than we do people who know the tool intimately. I'm reluctant to further stigmatise simple tests when we explicitly say simple is better than nothing at all.
This feels like a heavy-handed use of DSL modification & a one-size-fits-all kind of change, where contributors are "taught" version or help are "bad" when sometimes (A bunch of GUI or X11 stuff comes to mind immediately) "bad" is as good as we're going to every get, short of being able to fake interactivity.

@DomT4 There was a partial discussion here: Homebrew/homebrew-core#883
I don't think that the goal with this is to stigmatize version or help tests when those are the only option (e.g. GUIs) or when the contributor isn't familiar enough to write a more complex test (e.g. myself, on several occasions), but to allow Homebrew to differentiate and keep track of tests that could stand some improvement in the future.
The primary benefit in my eyes is that this could be used to dynamically whip up a quick list of testless/trivial-test only formulae as an easy place for new contributors to start. If you think the busywork and added confusion of this change aren't justified, I'm happy to accede on the PR.

Thanks @woodruffw, I'll read through that later today to see the original discussion. For now I should go back to sleep; I got up to grab some water and somehow ended up working on Homebrew stuff. Welp.

I'm personally 👎 on this too. I think it's worth asking: why do we have test blocks and encourage people to create them? The main reason is because we want to ensure the software was built, packaged and installed correctly. A more complex test exercises this more but a --version test honestly catches pretty much all the issues that a more complex one does (and brew linkage does not catch the case that e.g. it's linked fine but segfaults on startup due to missing non-library files or bad compilation). A more useful thing than adding complex tests to all formulae would be trying to add regression tests to formulae that have had packaging issues to make sure we don't provide broken versions in future. As a result I'd rather avoid a DSL element that can already be revealed by grep, would require large amounts of manual work on existing formulae to flag them and honestly doesn't seem to solve any end-user problems.

This reminds me of fails_with do's cause, which now just sits there looking pretty. Using the DSL for documentation purposes seems like an abuse unless it's actually functionally doing something to change behavior. Maybe brew info could be taught to guess what type of test it has?

I'm reluctant to further stigmatise simple tests when we explicitly say simple is better than nothing at all.

@DomT4 Maybe the :trivial tag sounds too derogatory? I think this can be addressed by using a different word.

[…] but to allow Homebrew to differentiate and keep track of tests that could stand some improvement in the future.
The primary benefit in my eyes is that this could be used to dynamically whip up a quick list of testless/trivial-test only formulae as an easy place for new contributors to start.

This. :+1:

This feels like a heavy-handed use of DSL modification & a one-size-fits-all kind of change, where contributors are "taught" version or help are "bad" when sometimes (A bunch of GUI or X11 stuff comes to mind immediately) "bad" is as good as we're going to every get, short of being able to fake interactivity.

Well, they are often bad. Also, GUI-only stuff is rare in Homebrew, we're increasingly pushing for GUI-only stuff to be moved to Cask, and X11 stuff is niche enough to not impact this discussion. And the fact that we can't do better than --version could be easily expressed by using a different tag. The approach is quite powerful and general enough to allow for this kind of flexibility and the point of this discussion is to talk about such cases and flesh out the idea.

I think it's worth asking: why do we have test blocks and encourage people to create them? The main reason is because we want to ensure the software was built, packaged and installed correctly. A more complex test exercises this more but a --version test honestly catches pretty much all the issues that a more complex one does […].

@mikemcquaid That --version will catch this kind of breakage is frequently not true. Just think about formulae implemented in an interpreted language like Python, where most modules won't even be loaded if only the version is queried. The same applies for compiled programs that have a plugin structure. A test that uses some of the actual functionality of a formula won't (and shouldn't) ever replace an upstream test suite, but will give us much more realistic coverage than a simple --version.

A more useful thing than adding complex tests to all formulae would be trying to add regression tests to formulae that have had packaging issues to make sure we don't provide broken versions in future.

Sorry to be this frank, but my feeling is that you're derailing the discussion here. I agree this is a useful thing to have, but that's completely orthogonal to what is being proposed here.

As a result I'd rather avoid a DSL element that can already be revealed by grep, would require large amounts of manual work on existing formulae to flag them […]

What's the issue with making this greppable? I don't see a good alternative to making this part of the DSL if we want to be able to query information about a formula's test (beyond whether it exists or not) from code. But maybe I'm overlooking something. Like with many other changes, I don't see why we wouldn't be able to introduce this incrementally in the course of updating formulae. To facilitate this, the default tag could be :unclassified while :trivial and :nontrivial would be used explicitly. We're in no hurry to update existing tests of formulae that haven't been touched for a long time.

[…] and honestly doesn't seem to solve any end-user problems.

I honestly don't understand this statement. A non-negligible problem of our users is that the software we package ends up being broken. Tests help to ensure it is working properly (which depends on it being installed correctly). Exercising some functionality of the software in the test makes us more confident about that. After all, most users care about the functionality some software provides, not whether <program> --version works.

Using the DSL for documentation purposes seems like an abuse unless it's actually functionally doing something to change behavior.

@ilovezfs I don't agree. A formula's desc is also mostly useless and doesn't affect functionality of brew at all unless you start searching for a description. The same can be said of the proposed test tagging. In its current form, it is exposed via Formula#test_trivial? and could be immediately used in a code snippet like below. (Fleshing this out a bit more and making it a dev-cmd would be easy, but premature and possibly a waste of time—judging by the currently dominant stance towards this PR.)
brew for-each-formula 'puts f.full_name if f.test_trivial?'

@ilovezfs I think that integrating test type into brew info is a good idea, but how would it get that information without some kind of additional information expressed by the test block?

I'm reluctant to further stigmatise simple tests when we explicitly say simple is better than nothing at all.

@DomT4 Maybe the :trivial tag sounds too derogatory? I think this can be addressed by using a different word.

One of the concerns both @DomT4 and @mikemcquaid brought up earlier is that a lot of --version-style tests are currently present in formulae, so maybe a default of :untagged or :unspecified?

And the fact that we can't do better than --version could be easily expressed by using a different tag. The approach is quite powerful and general enough to allow for this kind of flexibility and the point of this discussion is to talk about such cases and flesh out the idea.

:+1: I think this would be a great use of this approaches' generality. test :help and test :version would express the contents of the test even better than test :trivial.

$ cat <(ag '_output' | grep '\-[vV]') <(ag 'assert' | grep '\-[vV]') <(ag 'system' | grep '\-[vV]'| grep bin) | sort | uniq

I wonder how many this misses.

$ cat <(ag '_output' | grep '\-[vV]') <(ag 'assert' | grep '\-[vV]') <(ag 'system' | grep '\-[vV]'| grep bin) | sort | uniq

That's 10 execs, 7 regular expressions, and 8 redirections for a command that won't catch --version, --help, or any command to that effect inside of backticks. Compare that to:
egrep -l "test :(version|help) do" Formula/*
That won't catch untagged formulae (where a heuristic would be useful), but it'll catch 100% of tagged formulae and should be a lot speedier.

Won't catch --version?
 cat <(ag '_output' | grep '\-[vV]') <(ag 'assert' | grep '\-[vV]') <(ag 'system' | grep '\-[vV]'| grep bin) | sort | uniq|grep version|wc -l
     282

Anyway, still definitely :-1: on this.

Martin's talking me in to this. This sounds like it would be genuinely useful, with the main downside being that it adds stuff to the contributor-facing public API for formula DSL, and pushes Homebrew another step towards being more bureaucratic.
(I don't think grepping for stuff in the test implementation is a sufficient substitute, because the tagging really reflects human judgment, and there's so much variation with command line options in the wild.)
But I think we should be awfully conservative about adding stuff to the formula DSL, because once it's in, we're basically stuck with it forever. And this will affect our culture, not just our syntax. Pushing for tests at all seems like it was a substantial effort.
So while I'm now :+1: on the basic idea of this, maybe it's something we should just mull over for a month or two before actually doing anything about.
(And take my opinion with a grain of salt: I come from an enterprise software background, and I love this sort of bureaucracy and introspection. :wink: )

@ilovezfs 11 execs, 8 regexes, 11 redirections and it won't catch --help or -h, much less backticks. I'm usually (aggressively) for constructive pipelines, but there's way too much variation between individual tests to make it an effective approach in this case (IMO).
To further the point, what about utilities that use a subcommand (e.g. /bin/foo version)? What about those that use -? for help? We can't control the features of the programs being packaged, but we can control how their characteristics are exposed in the formulae.

But I think we should be awfully conservative about adding stuff to the formula DSL, because once it's in, we're basically stuck with it forever. And this will affect our culture, not just our syntax. Pushing for tests at all seems like it was a substantial effort.
So while I'm now :+1: on the basic idea of this, maybe it's something we should just mull over for a month or two before actually doing anything about.

@apjanke 100% behind this. I recognize that changing the DSL is a hard sell, especially in a way that requires both new contributors and maintainers to take on additional work. An abundance of review and debate is necessary :bow:

This sounds like it would be genuinely useful

What will you do with it other than generate a list of formulae with the tag and report about the number and percent of formulae that have this or that kind of tag?
@woodruffw I see no need to get the exact list. That was the point.

What will you do with it other than generate a list of formulae with the tag and report about the number and percent of formulae that have this or that kind of tag?

Use it as a TODO list, especially as a "low hanging fruit" list for new contributors. Though the latter could be done about as well by listing formulae with no test do at all.

Using the DSL for documentation purposes seems like an abuse unless it's actually functionally doing something to change behavior.

Agreed.

That --version will catch this kind of breakage is frequently not true. Just think about formulae implemented in an interpreted language like Python, where most modules won't even be loaded if only the version is queried. The same applies for compiled programs that have a plugin structure. A test that uses some of the actual functionality of a formula won't (and shouldn't) ever replace an upstream test suite, but will give us much more realistic coverage than a simple --version.

I'd like a citation here for "frequently not true". While I don't disagree with your theory (that's why I used to push harder for non---version tests everywhere) in practice it hasn't been showed to be true.

Sorry to be this frank, but my feeling is that you're derailing the discussion here. I agree this is a useful thing to have, but that's completely orthogonal to what is being proposed here.

It's not derailing for several reasons:

we have a finite amount of time to spend on Homebrew (and GSoC) and to spend a bunch of time working on something with little or no provable end-user benefit and little maintainer benefit is not a good use of that finite time
it's a way of improving tests that actually addresses issues we've seen in the wild.

What's the issue with making this greppable? I don't see a good alternative to making this part of the DSL if we want to be able to query information about a formula's test (beyond whether it exists or not) from code.

My point here was it's already greppable (as demonstrated in this PR). You could make it more so with TODO: add better test rather than a DSL.

I honestly don't understand this statement. A non-negligible problem of our users is that the software we package ends up being broken. Tests help to ensure it is working properly (which depends on it being installed correctly). Exercising some functionality of the software in the test makes us more confident about that. After all, most users care about the functionality some software provides, not whether  --version works.

Please point me to 2+ end-user filed issues that would have been caught by CI with a non---version test (not a specific regression test but a "good" one like cmake.rb). Otherwise we're in "speculatively fixing bugs" territory which, to repeat my usual speech, is a bad idea because it bloats our code with YAGNI error checking, pushes more effort onto contributors who want to work with our already underdocumented Formula DSL and doesn't appear to have demonstrable user benefit.

A formula's desc is also mostly useless and doesn't affect functionality of brew at all unless you start searching for a description.

This was a feature requested by many end-users for a long time and has several commands that interact with it. Not a good example, I fear.

What will you do with it other than generate a list of formulae with the tag and report about the number and percent of formulae that have this or that kind of tag?

Ultimately, the goal would be to replace version and help tests with more complex ones, programs permitting. As put by @UniqMartin:

That --version will catch this kind of breakage is frequently not true. Just think about formulae implemented in an interpreted language like Python, where most modules won't even be loaded if only the version is queried. The same applies for compiled programs that have a plugin structure. A test that uses some of the actual functionality of a formula won't (and shouldn't) ever replace an upstream test suite, but will give us much more realistic coverage than a simple --version.

Compiling a list of formula that are more susceptible to undetected breakage is certainly a good goal, from a usability perspective.

But I think we should be awfully conservative about adding stuff to the formula DSL, because once it's in, we're basically stuck with it forever. And this will affect our culture, not just our syntax. Pushing for tests at all seems like it was a substantial effort.

Agreed with this. If you look at third-party taps many of them don't use test at all.

Oh, just to clarify. I won't be using my GSoC time on this - it'll be dedicated to ruby-macho and the goals we've set out for it.
This is just a run-of-the-mill suggestion/contribution :smile:

More explicitly, I don't think we should be abusing DSL like this. Adding new DSL is a delicate enough process, let alone modifying active DSL used so widely.
I appreciate the idea, and I'm certainly not intending to bash William on this (who is routinely great), but I'm sharply 👎 on this as-is. I'm seeing minimal user upside, major rewriting of existing tests required with inconsistent application and a general recipe for contributor confusion.

Realized one more thing: since ideally you would have all formulae classified this way, this wouldn't be an odd bit of DSL that one could use just when you need it; it would be present in all formulae. Which means it would be another DSL item that all users and contributors would have to learn in order to understand even basic formulae. It would impose a time and attention cost and make the learning curve a bit steeper. That's significant: given how large our user base is, even a tiny increase in the learning curve turns in to a lot of spent time.
Plus, so many changes to existing formula files to go in the commit history.
Since this is just classification/documentation and doesn't execute during any brew operations, you could mostly implement this using an external data file and tools. The main advantage to having it in the DSL is just prompting contributors to update the tag if needed when they update the test.
Given that and Mike's comments, I'm now talked in to strongly thinking that while I would like and use this functionality, we really should not do it as part of the DSL.
Definitely appreciate the suggestion though.

Given that and Mike's comments, I'm now talked in to strongly thinking that while I would like and use this functionality, we really should not do it as part of the DSL.

If this is the general consensus, I have to agree. I haven't been around for DSL modifications before, but if they're as involved as stated then we should definitely pursue other approaches to getting this sort of information out of tests.

I haven't been around for DSL modifications before, but if they're as involved as stated...

 Thousands of formula files over dozens of repos (including many outside the organization) and probably a hundred thousand or more users who read formula files. Not to be undertaken lightly. :wink:

I'd like a citation here for "frequently not true". While I don't disagree with your theory (that's why I used to push harder for non---version tests everywhere) in practice it hasn't been showed to be true.

I don't have a citation. My assertion is theoretical, thus nothing more than an educated guess.

Please point me to 2+ end-user filed issues that would have been caught by CI with a non---version test (not a specific regression test but a "good" one like cmake.rb). Otherwise we're in "speculatively fixing bugs" territory which, […]

Again, not something I have hard evidence for. I'm just having a hard time getting to grips with the “if it hasn't been reported by a user, it's not broken” mentality (my interpretation, not what you literally wrote).

Oh, just to clarify. I won't be using my GSoC time on this - it'll be dedicated to ruby-macho and the goals we've set out for it. This is just a run-of-the-mill suggestion/contribution.

@woodruffw Thanks for giving this a try! I liked the idea, but I can understand why it's facing this much resistance. (I certainly have some takeaways from this discussion.) I think the outcome of this is pretty clear now, so feel free to close the PR if you agree. And if you feel like it, let's get back to adding tests to formulae that don't have them yet instead of spending more time on this meta issue.

Again, not something I have hard evidence for. I'm just having a hard time getting to grips with the “if it hasn't been reported by a user, it's not broken” mentality (my interpretation, not what you literally wrote).

Just as this is worth elaborating: it's not so much "it's not broken" as "we have a long list of other things that are broken that users want fixed".

Thanks for giving this a try! I liked the idea, but I can understand why it's facing this much resistance. (I certainly have some takeaways from this discussion.) I think the outcome of this is pretty clear now, so feel free to close the PR if you agree. And if you feel like it, let's get back to adding tests to formulae that don't have them yet instead of spending more time on this meta issue.

Thank you too, and to everybody who gave feedback! The benefits of this approach don't seem to outweigh the increased complexity and bureaucracy they'll bring, so I'm closing this PR.

Thank you too, and to everybody who gave feedback! The benefits of this approach don't seem to outweigh the increased complexity and bureaucracy they'll bring, so I'm closing this PR.

Thanks for understanding and for the PR @woodruffw 🙇

Here's an idea for getting some of the functionality this would provide but without altering any DSL: #221. It just adds an option to brew audit to make the output more suitable for grepping.

Here's an idea for getting some of the functionality this would provide but without altering any DSL: #221.

That PR is of course more general, but the result of the example provided therein (find formulae that have no test defined) can already be achieved as follows (and much more quickly as brew audit has quite some overhead). Assuming homebrew/dev-tools has been tapped:
brew for-each-formula 'puts f.full_name unless f.test_defined?'
brew for-each-formula 'puts f.full_name if f.name.start_with?("a") && !f.test_defined?' # Some basic filtering.

Yeah, that's better for checking just the tests. Doing a full audit is kind of slow.


the pretrained model you provide is multiscale or not

My be not , I'm not sure , this is not the same training progress like yolov3 using muti scale , 320 and 512  prior_boxes numbers are  different .


[WIP] Orchestrator Integration

This change is

LGTM

@alainjobart PTAL. The main integration features are there now. What's left is to write documentation, and incorporate it into the local example as well. I can do that after the code freeze.

 cool stuff
Previously, enisoc (Anthony Yeh) wrote…
> @alainjobart PTAL. The main integration features are there now. What's left is to write documentation, and incorporate it into the local example as well. I can do that after the code freeze.

Reviewed 3 of 4 files at r1, 13 of 13 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


navigate back to report details on back from group name

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/45812
PROPOSAL: https://github.com/Expensify/App/issues/45812#issuecomment-2240815972
Tests

Create a group chat
Click on group chat header > Group Name
Refresh page
Click the back button on top
Verify that navigated back to the details page

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
N/A

Android: mWeb Chrome
https://github.com/user-attachments/assets/5e9ebbfc-f4b5-4281-ac99-957c59fb1d88

iOS: Native
N/A

iOS: mWeb Safari
https://github.com/user-attachments/assets/7a2e03ec-6855-4773-a765-7dfef67dc25e

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/a7ee6815-2179-487b-857e-67b489a16f42

MacOS: Desktop
N/A

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/puneetlath in version: 9.0.21-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 9.0.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
failure ❌

🚀 Deployed to production by https://github.com/Beamanator in version: 9.0.21-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Update CONTRIBUTING.md

First pass at https://github.com/caskroom/homebrew-cask/issues/16373
Comments welcome. cc @caskroom/maintainers

Using cask-repair covers https://github.com/caskroom/homebrew-cask/issues/16464 - not sure where else to mention appcast updates, as the rest is really about new casks.

@zmwangx Here's the updated documentation with cask-repair mentioned. Let me know if things seem clear enough here

:+1: LGTM, except one minor thing: cask-repair can't necessarily handle all casks (correct me if I'm wrong; I'm thinking about casks with funny download URLs that not only depends on version — there used to be such casks if memory serves), so maybe a disclaimer should be added.

@zmwangx cask-repair does handle all casks (I started working on it before we started doing version interpolation). In the case where a cask has a non-interpolated URL, you’ll still type the version, but you’ll need the new URL in your clipboard (it automatically detects those cases and adjusts the message).

@vitorgalvao I added a (slight) disclaimer - though cask-repair works almost all the time.

Cool :+1: Just to make sure, are there any half interpolated URLs, e.g., https://example.com/2016/01'07/foo-#{version}.dmg, which would trick cask-repair to think of it as a always up-to-date URL? I think I've seen so something like that, but it might be my illusion, or might be in a PR.

I added a (slight) disclaimer - though cask-repair works almost all the time.

I’m fine with that. But any case cask-repair doesn’t work on I consider a bug (and fix when it is reported).
Also (and to also reply to)

Just to make sure, are there any half interpolated URLs, e.g., https://example.com/2016/01'07/foo-#{version}.dmg, which would trick cask-repair to think of it as a always up-to-date URL? I think I've seen so something like that, but it might be my illusion, or might be in a PR.

Lets not forget cask-repair does allow you to make manual fixes, and even rechecks and audits those for you.
So yes, @zmwangx, cask-repair will be tricked by those, but a half-interpolated URL isn’t useful anyway (i.e. it’s a fault of the cask, not cask-repair), and should be fixed in the cask itself (and you can do so within cask-repair).

should be fixed in the cask itself

Yes.


feat: automate updates of api & sdk docs

Question: Given that the API docs for ~nearlib~ near-api-js are auto-generated, does it make sense for a user to end up at these auto-generated docs when they click the "Edit" link while browsing our docs? (This same question applies to near-sdk-as and near-sdk-rs)
Answer: No. We wouldn't want someone to contribute edits to these auto-generated docs, as their changes would be lost the next time the docs are updated from the source.
So here's what this does
When you run yarn build in this repository:

Shallow clone (or update) each source repository to a location that doesn't get checked into the repo
Run the command to build docs for each of these source repositories
Copy generated docs to main docs folder
Run the build step we've been using
Clean up – remove the auto-generated stuff from the docs folder

Note that this also allows us to stop checking these auto-generated docs files into git. Both here and in the source repositories. Less noise all around! 🎉
This PR also improves the sidebar:

Caveat
Making the "Edit" link on each page link to the relevant file on GitHub requires building a custom Markdown generator to use in each source project. For now, this PR makes the Edit link point to the root repository for each set of auto-generated docs, except for near-sdk-rs. See new add-custom-edit-url script for details.
To do

[x] in build script, fetch directory from source repositories
[ ] set up deploy hook so pushes to source repos kick off a rebuild & deploy this website

near/near-api-js
near/near-sdk-as
near/near-sdk-rs

[x] in render settings, redirect from nearlib to new near-api-js endpoint unimportant; the previous pages/URLs were probably not in wide use
[x] update "Edit" button to link to near-api-js source

build is breaking bc of nearlib links.  once we merge the renaming work asap in #295 then we can rebase off master and merge this.  does that make sense?

I did:
cd website
yarn && yarn build
got
/Users/mike/near/docs/website/bin/replace-snippets.js:17
  from: replacements["replacements"][i]["from"],
        ^

ReferenceError: replacements is not defined
…
error Command failed with exit code 1.

After discussing this with @amgando, we have decided on a much simpler approach to this problem


idiomatic way to handle async requests

I think a very common use case is a component that displays data fetched asynchronously.  Without recompose, one would issue the request in componentDidMount, keep track of its value in state, and ensure that setState isn't called if the component gets unmounted.  Also, user actions could cause a new request to be issued, so we only want the latest.
I think the solution is to use mapPropsStream, but I'm new to rxjs and recompose, so I was wondering if anyone could give some guidance as to the best way to proceed.

here's my first attempt; it seems to be working.  It will only resolve the latest promise and you don't need to worry about component lifecycle.
const ResolvePromise = (key, loadingRender, errorRender) => compose(
  setDisplayName('ResolvePromise'),
  mapPropsStream((props$) => {
    const promise$ = props$
      .pluck(key)
      .map((promise) => promise.then(value => value, err => err))
      .switch()
      .map(value => ({[key]: value}))

    const rest$ = props$
      .map(props => ({ ...props, [key]: undefined}))

    return rest$
      .merge(promise$)
      .scan((x, y) => Object.assign({}, x, y))
  }),
  branch(
    ({[key]: err}) => err instanceof Error,
    errorRender
  ),
  branch(
    ({[key]: value}) => !value,
    loadingRender
  )
)

use it by composing it in with loading and error handlers:
const RequestRenderComponent = ({ request }) =>

request: {request}

const RequestRender = compose(
  setDisplayName('RequestRender'),
  ResolvePromise(
    'request',
    renderComponent(() =>
spinner
),
    renderComponent(({request}) =>
error: {request.message}
)
  )
)(RequestRenderComponent)

then you have a component that you can just pass in a request:
const eventuallyReturnString = async(i: number) => {
  await wait(2000)
  if (i % 2 === 1) {
    throw new Error('error message')
  }
  return `finally returned (${i})!`
}

let i = 0

const TestComponent = ({ request, onClick }: any) =>

    <PromiseRender request={request} foo='bar'/>
    <button onClick={onClick}>click</button>

const Test = compose(
  setDisplayName('Test'),
  withState('request', 'setRequest', () => eventuallyReturnString(i++)),
  withProps(({setRequest}) => ({
    onClick: () => setRequest(eventuallyReturnString(i++))
  }))
)(TestComponent)

No idiomatic ways why for any code must be some idiomatic way ;-),
mapPropsStream is really helpful,
Here I use something similar but with some caching logic etc
https://github.com/istarkov/revue/blob/cbc01375923d2993da41c3c9e808758c2ed8c314/src/CodePresenterContainer.js#L76
In real big projects I prefer to use redux + redux-observable processes for loading data like https://github.com/istarkov/redux-observable-process-fetch (it's very outdated but you can get the idea)

@arolson101 we were in the same situation and my colleague wrote a small package just for that purpose, it's redux-api-call under the hood it uses rxjs to handle request's result streams. Hope it helps (disclaim: I did contribute to package)

Might be related #319 in which we can make some recipe about handling async things.

As @istarkov said, there are many ways to achieve it. It depends on your project's architecture and your preference. I am closing this issue and please follow #319 if you want to share some code.


Theme: Navigation menu with icon driven UI (for users)

Hi there @rostovtsev
First post here - so, first of all - big handshake and wave at you for all your hard work - many thanks and good karma issued in your direction :-)
Next - I am a newbie with webmin/virtualmin, so excuse me if I am not completely accurate about such terminology and such.... but I do want to contribute to the awesomeness that's already been created....
So - with all the positive things said, please allow me to express my wonder at how I have experienced the Usermin and Virtualmin aspects....
I do wish for a simpler interface in Virtualmin.  The Webmin side is really fine for sys-admins (although could do with some re-organisation of placements!).  But Virtualmin is really a bit confusing and not very intuitive for "end-user" (e.g. a web hosting customer) - particularly those coming from cpanel with its polished Graphical User Interface.
I can see from above comment @TomasHurtz mentions icon file and I think the point would be to make a more icon realized dashboard - perhaps taking into consideration to the top most features that a typical end-user is likely to want.
For example, when end-user log into cpanel user account, you have the icons UI laid out nicely in front of you and it's very intuitive to know where to click for the function you need.  e.g. file manager, database manager, email accounts .  Example image:
I guess you can say the same thing for CentosWebPanel or CWP :  Example image
So - building on the great work of Virtualmin - here are some suggested action points:

make dashboard with icon User Interface similar to the above - the icons from your icon file would be great: https://authentic-theme.com/kit/

Have "sections" or "categories" on dashboard where similar functions are grouped (e.g. all the database functions are grouped under the heading "Databases" etc...)

Possible to allow users to drag and drop the sections to be able to customise / personalise the dashboard - and even (as sys-admin) decide which sections to hide in the UI.

when you click on e.g. "Edit Databases" - rather than showing the tabs at the top (Databases / Usernames / Passwords / Remote Hosts etc....) these could be replaced with icons to click on - it's just an aesthetic thing!

Possible to enable access to e.g. roundcube / email from within virtualmin / rather than having to go to usermin - or is that beyond the ability of the theme.

I'm sure others could chime in....  But if you could make the end-user experience a bit more intuitive, it would help enormously.
I am also willing to assist you where possible.
Thank you for listening and for your work.
Originally posted by @solaceten in https://github.com/authentic-theme/authentic-theme/issues/896#issuecomment-531081170

At first, thanks for your kind wishes and words.

Virtualmin is really a bit confusing and not very intuitive for "end-user" (e.g. a web hosting customer)

Do you mean server owner users, not master admins, right?

You have the icons UI laid out nicely in front of you and it's very intuitive to know where to click for the function you need.

In case the answer for previous question is yes, it's more or the less realistic to make it displayed alike (as cPanel) for server owners and Usermin users. The idea behind, as I see it at the moment, is to render left (navigation) menu into separate page, with icons and links, grouped by category; on that new navigation page, clicking on the icon, would open expected module/section.

Have "sections" or "categories" on dashboard where similar functions are grouped (e.g. all the database functions are grouped under the heading "Databases" etc...)

Possible, as logical continuation to new navigation page (just mentioned above) but requires quite a bit of work. :sweat_smile:

When you click on e.g. "Edit Databases" - rather than showing the tabs at the top (Databases / Usernames / Passwords / Remote Hosts etc....) these could be replaced with icons to click on - it's just an aesthetic thing!

That in particular, should be changed/coded on the module side. Doing it on the theme side is possible but completely undesirable.

How to enable access to e.g. roundcube / email from within Virtualmin rather than having to go to Usermin - or is that beyond the ability of the theme.

I am not sure exactly what the question is about? You can make RoundCube link or any other link appear on the navigation menu for easy access, by editing Navigation menu options/Extra entries in theme configuration.
Example:
{
   "extra":[
      {
         "title":"Google Mail",
         "link":"https://gmail.com/",
         "icon":"google",
         "level":"0,1,2,3,4"
      },
      {
         "title":"BIND DNS Server",
         "link":"/bind8",
         "icon":"server"
      }
   ]
}

Speaking about mail, in the near future, you might want to give up other web-mail clients, as I'm actively working on new mail UX.
Thank you for your time and comments.

Hi thank you for opening new thread - easier ;-)
Answers to your points:

Virtualmin is really a bit confusing and not very intuitive for "end-user" (e.g. a web hosting customer)
Do you mean server owner users, not master admins, right?

Correct - "virtual server" or end-user or / webhosting customer in my opinion. Sys-admin is root = master admins... So yes, it is a bit confusing as virtual server owner when you log in to manage your domain or email etc.

... it's more or the less realistic to make it displayed alike (as cPanel) for server owners and Usermin users. The idea behind, as I see it at the moment, is to render left (navigation) menu into separate page, with icons and links, grouped by category; on that new navigation page, clicking on the icon, would open expected module/section.

Yes, it would make sense to have Nav on left and on right would be displayed with category / icons and clicking on any of those will take you to that module.
Let me know if I can help you realize the UX design for template start.

How to enable access to e.g. roundcube / email from within Virtualmin rather than having to go to Usermin - or is that beyond the ability of the theme.
I am not sure exactly what the question is about?

I just think it is good idea to have capability to access email (usermin) from virtualmin - but I was not aware you can make it customised as you've suggested, so please disregard this point - and yes, looking forward to seeing new mail
Let me know what help you need (I am not big programmer, but can help with design ideas :-)

This will be a while though.
Thank you for offering the help. I'll let you know if I need it.
At first I need to finish mail view. It's a large section. Then, I was going to do few things for File Manager, like add ACL support. Afterwards, few things needed to be done for Dashboard, and in the end, I can handle this issue.
I think, I will put all of this to 19.40 release.


why should set profiler.jdbc.postgresql.setautocommit=false

i use pinpoint with spring cloud, and my database is postgresql;
I'm a little confused about agent configuration that in pinpoint-real-env-lowoverhead-sample.config it suggest that
profiler.jdbc.postgresql.setautocommit=false
profiler.jdbc.postgresql.commit=false
profiler.jdbc.postgresql.rollback=false
why should set false in online environment;
can any one tell me the reason?  many thanks!

Hi @bryanYao
setautocommit, commit, and rollbacks are usually automatically handled via transaction.
Since pinpoint-real-env-lowoverhead-sample.config aims to be light weight, the sample configuration turns tracing these methods off. (you can always leave them on if you'd like)
Note that disabling these options does not affect commits and rollbacks of your application. It merely does not trace these methods so they do not show up in Pinpoint Web UI's call stack.


Upload dropzone is shown in the submission if there's no upload section

Describe the bug
If you configure a submission without an upload section, the upload drop zone at the top of the page is still shown.
To Reproduce
Steps to reproduce the behavior:

Configure a collection without an upload section in the submission
Authenticate in the UI
Submit an item to that collection
Verify that you can still see the drop zone.

Expected behavior
I'd expect the upload drop zone only to be visible if the submission has an upload section

Definitely a bug.  Adding to Beta 5 for now, though flagging as "low priority" (as it may not matter if this ends up delayed).  Needs an estimate of the effort.

@tdonohue this can be fixed in 1 hour

@tdonohue this can be fixed in 1 hour

Thanks @atarix83 .  I've added that estimate to the ticket. I'll keep this in Beta 5 since it's such a small change.

Thanks @atarix83 .  I've added that estimate to the ticket. I'll keep this in Beta 5 since it's such a small change.

PR #1053 had to be reverted, as it broke the submission form. Reopening & assigning back to @LotteHofstede

Fixed by #1087


Fix erros in apps/theme

We are currently excluding this folder in the tsconfig, stylelint and eslint config.

Solved in #2130 . Further development will be fixed in separate issues for the theme builder.


feat: turn libscroll_zstd dynamic lib into static

Purpose or design rationale of this PR
Support linux/arm64 images of event-watcher, rollup-relayer, and gas-oracle.
Simplify the building workflow.
Support running unit tests and building rollup_bins in darwin/arm64.
PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

[x] feat: A new feature

Deployment tag versioning
Has tag in common/version.go been updated or have you added bump-version label to this PR?

[x] Yes

Breaking change label
Does this PR have the breaking-change label?

[x] No, this PR is not a breaking change

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

Project coverage is 54.30%. Comparing base (f12e8e3) to head (087b29f).
Report is 1 commits behind head on develop.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #1358   +/-   ##
========================================
  Coverage    54.30%   54.30%
========================================
  Files          156      156
  Lines        11922    11922
========================================
  Hits          6474     6474
  Misses        4953     4953
  Partials       495      495

Flag
Coverage Δ

rollup
59.83% <ø> (ø)

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

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

tested in local test.


Unable to compile

Hi !
I tried MLJFlux two weeks ago on a machine and it was working great.
Now, I have another machine and I am not able to compile MLJFlux. I have tried to reinstall everything, but it doesn't have fixed my issue.
julia> Pkg.clone("https://github.com/alan-turing-institute/MLJFlux.jl")
  Updating git-repo https://github.com/alan-turing-institute/MLJFlux.jl
 Resolving package versions...
  Updating ~/.julia/environments/v1.3/Project.toml
  [094fc8d1] + MLJFlux v0.0.0 [~/.julia/dev/MLJFlux]
  Updating ~/.julia/environments/v1.3/Manifest.toml
  [094fc8d1] + MLJFlux v0.0.0 [~/.julia/dev/MLJFlux]
julia> Pkg.status()
    Status ~/.julia/environments/v1.3/Project.toml
  [b4f34e82] Distances v0.8.2
  [587475ba] Flux v0.8.3
  [c91e804a] Gadfly v1.2.0
  [7073ff75] IJulia v1.21.1
  [add582a8] MLJ v0.9.1
  [094fc8d1] MLJFlux v0.0.0 [~/.julia/dev/MLJFlux]
  [d491faf4] MLJModels v0.8.0
  [91a5bcdd] Plots v0.29.1
  [8162dcfd] PrettyPrint v0.1.0
  [d330b81b] PyPlot v2.8.2
  [ce6b1742] RDatasets v0.6.6
  [2913bbd2] StatsBase v0.32.1
  [fd094767] Suppressor v0.1.1
julia> Pkg.build("MLJFlux")
  Building Rmath ────→ ~/.julia/packages/Rmath/BoBag/deps/build.log
  Building MbedTLS ──→ ~/.julia/packages/MbedTLS/a1JFn/deps/build.log
  Building CodecZlib → ~/.julia/packages/CodecZlib/5t9zO/deps/build.log
  Building NNlib ────→ ~/.julia/packages/NNlib/3krvM/deps/build.log
  Building GR ───────→ ~/.julia/packages/GR/NSt7D/deps/build.log
  Building FFMPEG ───→ ~/.julia/packages/FFMPEG/guN1x/deps/build.log
  Building Plots ────→ ~/.julia/packages/Plots/12uaJ/deps/build.log
  Building Conda ────→ ~/.julia/packages/Conda/3rPhK/deps/build.log
  Building PyCall ───→ ~/.julia/packages/PyCall/kAhnQ/deps/build.log
false
In a Jupyter lab:
using MLJFlux
┌ Info: Precompiling MLJFlux [094fc8d1-fd35-5302-93ea-dabda2abf845]
└ @ Base loading.jl:1273
ERROR: LoadError: UndefVarError: MLJModelInterface not defined
Stacktrace:
 [1] top-level scope at [home]/.julia/packages/MLJModelInterface/BDciB/src/metadata_utils.jl:101
 [2] eval at ./boot.jl:330 [inlined]
 [3] eval(::Expr) at [home]/.julia/dev/MLJFlux/src/MLJFlux.jl:1
 [4] #metadata_model#16(::Type, ::Type, ::Type, ::Bool, ::String, ::String, ::typeof(MLJModelInterface.metadata_model), ::Type) at [home]/.julia/packages/MLJModelInterface/BDciB/src/metadata_utils.jl:110
 [5] (::MLJModelInterface.var"#kw##metadata_model")(::NamedTuple{(:input, :target, :path, :descr),Tuple{UnionAll,UnionAll,String,String}}, ::typeof(MLJModelInterface.metadata_model), ::Type) at ./none:0
 [6] top-level scope at [home]/.julia/dev/MLJFlux/src/MLJFlux.jl:306
 [7] include at ./boot.jl:328 [inlined]
 [8] include_relative(::Module, ::String) at ./loading.jl:1105
 [9] include(::Module, ::String) at ./Base.jl:31
 [10] top-level scope at none:2
 [11] eval at ./boot.jl:330 [inlined]
 [12] eval(::Expr) at ./client.jl:425
 [13] top-level scope at ./none:3
in expression starting at [home]/.julia/dev/MLJFlux/src/MLJFlux.jl:306
Failed to precompile MLJFlux [094fc8d1-fd35-5302-93ea-dabda2abf845] to [home]/.julia/compiled/v1.3/MLJFlux/fHjkl_0WGeG.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] compilecache(::Base.PkgId, ::String) at ./loading.jl:1283
 [3] _require(::Base.PkgId) at ./loading.jl:1024
 [4] require(::Base.PkgId) at ./loading.jl:922
 [5] require(::Module, ::Symbol) at ./loading.jl:917
 [6] top-level scope at In[6]:1
Should I install another package ?

Sorry to hear about your issues. MLJFlux is still very experimental - it does not even have a release yet. It has been in a state of limbo while one of its developers has been busy elsewhere.
In the meantime, you might try the dev branch, which is passing travis tests. You can install it from the REPL with ]add MLJFlux#dev

P.S. Would be good to know if this actually works for you.

Worked for me. Thanks!


Pointer 'hDefn' is NULL in 'OGR_F_Create'

This error gets thrown when I try to use GeoDataFrames.write() with the .gpkg or .shp file formats. I am certain that it is not a problem with the data, as this error occurs even when trying to write a dataframe that has just been read unmodified from a working .gpkg file. Function was previously working, but has broken after I tried to install the Turf.jl package

Thanks for reporting! Maybe something changed in your environment? Can you check you have the latest version with posting the output of Pkg.status() (or ]st) here?
Otherwise, it's probably something special with your data, and posting a file, or describing the schema would help.

Probably the reason is that Turf.jl is not compatible with GeoInterface v1, and therefore downgrading GDAL related packages to a really old version.
I assume there isn't really much we can do besides updating Turf.jl.
https://github.com/philoez98/Turf.jl/blob/v0.2.1/Project.toml

Yeah, looks like installing Turf.jl downgraded me to GeoDataFrames 0.2.4 and ArchGDAL 0.8.6. Updating both packages to their latest versions fixed the issue - although when I tried to do this with ]up GeoDataFrames it didn't work, I had to specify the version with ]add<EMAIL_ADDRESS>


Added source code for fraud detection

Thanks @co9olguy, have had a look at your comments and also added warnings to the user that some of the scripts can take a while to run.


CSP issues

I am trying to make my django project, which is using crispy_bootstrap5, as tight as possible wrt CSP.
However, I noticed one CSP problem inside crispy_forms, which tracks down to a template in crispy_bootstrap5.
In templates/bootstrap5/layout/field_file.html

            {{ field.value.name }}

you use an inline-style, which is strongly would require the strongly discouraged CSP Option:
style-src = 'unsafe-inline'
An alternative to fix this would be to replace the explicit style attribute by an extended class="text-break flex-grow-1" or similar.
Would it be possible to consider this, so that web pages using crispy_forms can be made more secure?
Thanks for the consideration

Thanks for the report, a PR making the change would be welcomed.


Feature  update pill primitive

Issue - https://github.com/tscircuit/tscircuit/issues/208

ok I think the original code is right, width/height is sufficient. The code you wrote here might still be useful for plated hole pills though which we still need


add CLGs for permutation factories

We recently implemented the permutation factory. This functionality should be provided by the CLG collection. That means, creating CLGs handling permutation factory primitives.

Closing in favour of #113.


Fix year on datepicker

Datepicker year defaults to 10 years either side of current year. Need to set it to start 100 years in past (or something) and end in current year.

Awaiting pull request review


Optimize http object creation

Purpose
Optimize the http objects (request, response, caller, etc) creation, by caching the value creator instance of http and mime packages. This avoids having to do a map lookup for every request, to
get the value creator.
From the below jfrs, you can see that java.util.HashMap class was contributing to over 10% of the total execution time previously.
Before:

After:

Check List

[x] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #19603 into ballerina-1.0.x will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           ballerina-1.0.x   #19603   +/-   ##
================================================
  Coverage            15.73%   15.73%
================================================
  Files                   47       47
  Lines                 1265     1265
  Branches               197      197
================================================
  Hits                   199      199
  Misses                1053     1053
  Partials                13       13

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf909b6...3e1875d. Read the comment docs.

good work @SupunS


Ignore the checking of static files when building

Hi there,
I have a project on GitLab that uses a json key for authentication. The key itself isn't in the repo for security reasons so when I run mkdocs build I get an exception that the file in question cannot be found. I'm a bit confused as to why mkdocs needs to check that the file exists - is it possible to override this behaviour? I'd like to use GitLab Pages so building the docs locally before removing the json file and then pushing isn't an option.
Thanks in advance!

Wrong repo :smile: ! This should be opened on the MkDocs repository instead.
You'll probably need to add details about the structure of your project, and the actual MkDocs warning, as without those it's quite hard to understand what you're doing.


librime fail to build on armel

Build log: https://buildd.debian.org/status/fetch.php?pkg=librime&arch=armel&ver=1.2.9%2Bdfsg1-1&stamp=1470661415
[  6%] Building CXX object src/CMakeFiles/rime.dir/service.cc.o
cd /«BUILDDIR»/librime-1.2.9+dfsg1/obj-arm-linux-gnueabi/src && /usr/bin/c++   -DRIME_BUILD_SHARED_LIBS -DRIME_ENABLE_LOGGING -DRIME_EXPORTS -DRIME_VERSION="1.2.9" -I/«BUILDDIR»/librime-1.2.9+dfsg1/thirdparty/include -I/«BUILDDIR»/librime-1.2.9+dfsg1/include  -g -O2 -fdebug-prefix-map=/«BUILDDIR»/librime-1.2.9+dfsg1=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG -fPIC   -std=c++11 -o CMakeFiles/rime.dir/service.cc.o -c /«BUILDDIR»/librime-1.2.9+dfsg1/src/service.cc
In file included from /«BUILDDIR»/librime-1.2.9+dfsg1/src/signature.cc:10:0:
/«BUILDDIR»/librime-1.2.9+dfsg1/include/rime/deployer.h:70:21: error: field 'work_' has incomplete type 'std::future'
std::future work_;
^~~~~
In file included from /«BUILDDIR»/librime-1.2.9+dfsg1/include/rime/deployer.h:10:0,
from /«BUILDDIR»/librime-1.2.9+dfsg1/src/signature.cc:10:
/usr/include/c++/6/future:115:11: note: declaration of 'class std::future'
class future;
^~~~~~
src/CMakeFiles/rime.dir/build.make:137: recipe for target 'src/CMakeFiles/rime.dir/signature.cc.o' failed
make[3]: *** [src/CMakeFiles/rime.dir/signature.cc.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /«BUILDDIR»/librime-1.2.9+dfsg1/include/rime/service.h:16:0,
from /«BUILDDIR»/librime-1.2.9+dfsg1/src/service.cc:10:
/«BUILDDIR»/librime-1.2.9+dfsg1/include/rime/deployer.h:70:21: error: field 'work_' has incomplete type 'std::future'
std::future work_;
^~~~~
In file included from /«BUILDDIR»/librime-1.2.9+dfsg1/include/rime/deployer.h:10:0,
from /«BUILDDIR»/librime-1.2.9+dfsg1/include/rime/service.h:16,
from /«BUILDDIR»/librime-1.2.9+dfsg1/src/service.cc:10:
/usr/include/c++/6/future:115:11: note: declaration of 'class std::future'
class future;
^~~~~~
src/CMakeFiles/rime.dir/build.make:185: recipe for target 'src/CMakeFiles/rime.dir/service.cc.o' failed
make[3]: *** [src/CMakeFiles/rime.dir/service.cc.o] Error 1
make[3]: Leaving directory '/«BUILDDIR»/librime-1.2.9+dfsg1/obj-arm-linux-gnueabi'
CMakeFiles/Makefile2:120: recipe for target 'src/CMakeFiles/rime.dir/all' failed
make[2]: *** [src/CMakeFiles/rime.dir/all] Error 2
make[2]: Leaving directory '/«BUILDDIR»/librime-1.2.9+dfsg1/obj-arm-linux-gnueabi'
Makefile:130: recipe for target 'all' failed
make[1]: *** [all] Error 2

@osfans Did you encounter this error (std::future missing) while building librime for Android?

好像沒有，只遇到過signal的：
408c5bbc0ddaec45f0cf050103bad179c4c058cf

This is confirmed to be an GCC bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
It has been a year without updates, would you like to avoid using std::future, or just leave it there (and remove the armel package from Debian)?

You could also try clang to compile.

Due to the status of libc++ in Debian it's hard to switch using clang++ for librime atm, if acceptable I can disable armel for the moment and add it back when clang is an option, what do you think?

Sounds good to me.
The runtime environment might be unique for armel on Linux. Android NDK (shipped with libstdc++ by default) is reported to work.

Do I have time to release a new version for inclusion in Debian?

@lotem sure, if that does not take weeks to expect, :)

Any progress?

I decide to keep using std::future.
To work-around the failure, perhaps we can try aliasing boost::future as a replacement?

It's up to you unless the build can pass and the application can work.


pfCard Ng-Docs issues

1 - The Parameters show that the "showTopBorder" is false by default, but the Demo, shows the border.  If it isn't the default, i'd suggest it's not shown.  Can the demo be enhanced to allow the option to show/hide the border?
2 - Typo here ... "subtTtle"

Addressed in https://github.com/patternfly/angular-patternfly/pull/44


Performance prefetch for /api/listing

Please review
@lsemesky
@mleeBoeing
@rkenyon1969
@cwilliams2017
Performance increase for api/listing endpoint

Able to confirm the Listing API has improved in performance
Prior:

This branch:

:+1:

Able to confirm improvement in performance with Listing endpoint
This branch:

Master branch:

:+1:

:+1:


Tray icon empty on windows 10

Describe the bug
The windows build of my app does have a tray entry, and its menu items seem to work, but there is no icon, only an invisible rectangle.
I've made built the icons resources through you icon command, so as far as I know, I am fulfilling the requirements outlined in the docs (that is that there needs to exist an *ico file)
Also note the screenshot showing that desktop & title-bar icons work fine & try icon works too in linux
To Reproduce
I'd give more info if I'd know what would help, but at this point I haven't got a clue, but will cooperate if you have an idea what I should try & report back.
I did try a debug built that gave a console window in addition to the app window, but nothing happened there.
Expected behaviour
The tray icon should be visible
Screenshots

Platform and Versions (required):
Operating System - Windows, version 10.0.19043 X64
Webview2 - 94.0.992.31

Node.js environment
  Node.js - 14.17.0
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 6.14.13
  yarn - 1.22.11

Rust environment
  rustc - 1.57.0-nightly
  cargo - 1.57.0-nightly

App directory structure
/src-tauri
/.yarn
/node_modules

App
  tauri.rs - 1.0.0-beta.5
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'

Additional context
tauri.conf
{
  "package": {
    "productName": "Braiins OS Toolbox",
    "version": "0.1.0"
  },
  "build": {
    "distDir": "../../../web-ui/build/js/bundle/toolbox-tauri",
    "devPath": "http://localhost:3001",
    "withGlobalTauri": false
  },
  "tauri": {
    "bundle": {
      "active": true,
      "targets": "all",
      "identifier": "com.tauri.dev",
      "icon": [
        "icons/32x32.png",
        "icons/128x128.png",
<EMAIL_ADDRESS>        "icons/icon.icns",
        "icons/icon.ico"
      ],
      "resources": [],
      "externalBin": [],
      "copyright": "",
      "category": "Utility",
      "shortDescription": "",
      "longDescription": "",
      "deb": {
        "depends": [],
        "useBootstrapper": false
      },
      "macOS": {
        "frameworks": [],
        "minimumSystemVersion": "",
        "useBootstrapper": false,
        "exceptionDomain": "",
        "signingIdentity": null,
        "entitlements": null
      },
      "windows": {
        "certificateThumbprint": null,
        "digestAlgorithm": "sha256",
        "timestampUrl": ""
      }
    },
    "updater": {
      "active": false
    },
    "systemTray": {
      "iconPath": "icons/icon.png",
      "iconAsTemplate": false
    },
    "allowlist": {
      "all": true,
      "notification": {
        "all": true
      }
    },
    "windows": [
      {
        "title": "Braiins OS Toolbox",
        "resizable": true,
        "fullscreen": false
      }
    ],
    "security": {
      "csp": "default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'"
    }
  }
}

Stack Trace
None seen anywhere

Yep, just tried it with a release build (no --debug flag) on next.

Also, as a sidenote: notifications still have the Windows Powershell title…

Yep, just tried it with a release build (no --debug flag) on next.

hmm, imo it looks like something specific to your icon tbh. (the tauri icon command is a little unfriendly at times :/ )
Can you try other icons/image editors/export methods? No idea otherwise, sorry.

Also, as a sidenote: notifications still have the Windows Powershell title…

Whoops my bad. Looks like it's tied to the msi installation (So if you distribute your app via the msi, it should be fine)

hmm, imo it looks like something specific to your icon tbh. (the tauri icon command is a little unfriendly at times :/ )
Can you try other icons/image editors/export methods? No idea otherwise, sorry.

OK, I'll try a random different file. It is pretty strange though that it works in every other place except this one.

Whoops my bad. Looks like it's tied to the msi installation (So if you distribute your app via the msi, it should be fine)

I see, it indeed is, and it also has an icon of the app

So, I've tried

a different PNG, converted it by the tauri icon tool & got the same thing ... it worked everywhere except try area

downloaded a random ico file from the internet and replaced the generated one, and now it works in the tray area too (albeit a bit rough around the edges, but that is not the point for now)

ico is from here: https://findicons.com/icon/64873/download

this is the second png I've tried:

Now, as far as I can tell just by hindsight, the difference seems to be that the ico you are generating is compressed.
Might that be the core of the problem?

Can the compression be disabled and left to users to pngcrush the png images?

I tested a lot of PNG->ICO libraries and methods (one online conversion site worked, one didn't) and png2icons is definitely not working so well here. I tried https://github.com/steambap/png-to-ico and it works nice, so I made a PR to use that instead.
Can you test that @kubijo ?

Sure thing, first thing in morning... What do I do? cargo update, build and see?

You'll need to clone the repo, build the tooling/CLI.js package and run the icon command from it.

Sorry for the delay… slow day both for me and for the computer it seems…
Anyway, the update seems to have worked nicely! :+1:

If this was an application to be deployed, my next effort in this regard would be to solve the icon quality in these small dimensions.
It is tangential to this issue, but it would by interesting to known if you plan to address that in some way as well, or if that is to be solved by users themselves.
The only way to solve this I see would be to generate an ico file with hand-designed sizes because scaling can only do so much…

It seems that this might also be accomplished by ImageMagick (available cross-platform): https://superuser.com/a/683203

I think I can skip resizing if the image is squared. Otherwise there's not much to do.

That is not the whole story though ... the point is to have an ico file with multiple sizes where potentially any of them can be custom designed because you can't use a design for 256256 scaled down 1616 and expect it to look nice

It would, however, be understandable if this was considered out of the scope for that script since there is potentially a lot of complexity that you might not want to tackle...
… so I'm basically just saying that this is an issue that needs to be addressed in one way or another if Tauri user wants nice looking windows icons & it's a question if you want to address that in your tooling and/or documentation


Evaluate Gitlab CI Fuzz testing

Gitlab CI has introduced support for fuzz testing as a service. Their service integrates with go-fuzz which is the library we are using to fuzz test Horizon.
Gitlab supports fuzzing jobs which execute for a user defined timeout and they also support continuous fuzzing which run for a much longer duration. It seems that short fuzzing jobs would be appropriate to run against PRs and continuous fuzzing would be useful to run against master or Horizon release branches.
One useful aspect of Gitlab's fuzzing service is that whenever you run a fuzzing job Gitlab will extend the fuzz corpus with any new interesting cases that are found during the test run. The corpus is shared between multiple test runs and each test run can possibly improve the corpus.
If we were to use Gitlab fuzzing it seems that we would need to have CI job defined for every fuzzing target. This is an important point to consider because we plan on having fuzz tests for every ingestion processor. But we may run into issues by having so many fuzz jobs running for each PR.
To evaluate Gitlab's fuzzing service we should verify that it's possible to run Gitlab CI on GitHub repos (according to https://about.gitlab.com/solutions/github/ it should be possible). Then we can start by having a fuzzing job which invokes the claim predicate fuzz test

My initial tests with Gitlab's fuzzing service have been promising. I was able to get a fairly substantial prototype up and running.
There are still some questions we need to figure out which I have listed in the checklist below. We need to check off all the high priority and medium priority tasks before we can close the issue and move on to writing fuzz targets for Horizon ingestion processors.

[ ] Trigger email notifications whenever a fuzz job finds a crash (high priority)
[ ] Make the visibility of security issues discovered by fuzz jobs private to only Horizon team members (high priority)
[ ] Discuss creating an SDF Gitlab account with Ops team (medium priority)
[ ] Streamline defining gitlab CI jobs for each fuzz target (optional / low priority)

https://github.com/google/oss-fuzz provides the fuzzing service which will provide all the things that Gitlab provides.
It is easy to integrate.

I can help with this.


feat: add metadata and parent columns to inscriptions table

:tada: This PR is included in version 2.3.0-beta.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Tips/tricks for sending 1600 DMs for a survey? (rate limit increase request as well)

Hey Slack dev relations team 👋
We have a customer that has 1600 employees and they want to send surveys to them in Slack. We're quickly running into rate limits so our solution now is to slow down the sending of the DMs which results in it taking ~7 minutes to send 1600 messages. I have two questions:
1. Can I apply for a rate limit increase somehow? We're listed as an essential app and have 4.7 stars on G2 so we're a pretty successful app and growing
2. Are there tips/tricks for sending 1600 DMs? This is the skeleton of what we're going to do:
const sendMessageAndUpdate = async (user, index) => {

    const published_pulse_res = await postChatMessage({
        token: token,
        channel: user,
        text: `New Survey!`,
        blocks: blocks,
    });

    const ts = published_pulse_res.success ? published_pulse_res.data.ts ?? null : null;

    if (ts) {
        await db.pulse_answers.create({
            data: {
                team_id,
                pulse_id: pulse.id,
                responder_id: user,
                slack_ts: ts,
                user_group_id: group,
                responder_alias,
                reply_hash,
            },
        });
    } else {
        return user;
    }
};

// Function to split audience into batches
const splitIntoBatches = (array, batchSize) => {
    const results = [];
    while (array.length) {
        results.push(array.splice(0, batchSize));
    }
    return results;
};

// Split the audience into batches of 400
const batches = splitIntoBatches(audience, 400);

// Handle each batch
for (const batch of batches) {
    const batchPromises = batch.map(sendMessageAndUpdate);
    const rejectedUsers = await Promise.all(batchPromises);
    rejected.push(...rejectedUsers.filter(user => user));
}

Hi @MattB543,
Thank you for your question!

Can I apply for a rate limit increase somehow?

Unfortunately, we do not provide options to customize the rate limit for 3rd party apps.

Are there tips/tricks for sending 1600 DMs? This is the skeleton of what we're going to do:

I'd like to share a few tips:

The chat.postMessage API is in a special tier, allowing one request per second per channel and several hundred messages per minute. So, you don't need to worry too much about rate limits. You can send 1.6K DMs in about 2-3 minutes at the fastest pace.
The conversations.open API is in Tier 3, allowing more than 50 requests per minute. I recommend calling this method at a slower pace in advance. If you need to open DMs to 1.6K new people, it could take approximately 30 minutes.

Our Java SDK offers a smart rate limiter for bulk API calls. You can find more information about it here: https://slack.dev/java-slack-sdk/guides/web-api-basics#rate-limits. Many major customers use this module at a large scale, so it's stable enough for production-grade usage. If you're open to using the Java SDK solely for the DM sending logic, it could be a good option. Even if you prefer not to use it for your app, you can learn from its code:

https://github.com/slackapi/java-slack-sdk/blob/main/slack-api-client/src/main/java/com/slack/api/rate_limits/WaitTimeCalculator.java
https://github.com/slackapi/java-slack-sdk/blob/main/slack-api-client/src/main/java/com/slack/api/methods/impl/AsyncMethodsRateLimiter.java
https://github.com/slackapi/java-slack-sdk/blob/main/slack-api-client/src/main/java/com/slack/api/methods/impl/AsyncRateLimitExecutor.java

I hope this information is helpful!


Improve resolving paths

This PR aims to improve the usability of resolving key paths.
With this pull request you can resolve nested paths like this;
XCTAssertEqual(json.path("school.clubs.0.detail.name"), "DC")
    XCTAssertEqual(json.path("school.clubs.0.detail.people.0.first_name"), "Clark")
    XCTAssertEqual(json.path("school.clubs.0.detail.people.0.age"), 78)
    XCTAssertEqual(json.path("school.clubs.0.detail.people")!, [
      [
        "first_name": "Clark",
        "last_name": "Kent",
        "age" : 78
      ],
      [
        "first_name": "Bruce",
        "last_name": "Wayne",
        "age" : 77
      ]
      ])

It can achieve this with the refactoring done in PathAccessible to introduce method overloading for the path method.

This still needs some pushes to work properly.

@onmyway133 On the second thought, I think this should work 😁

@zenangst is it done for merging?

@onmyway133 yeah I think so 😁 we can improve it other pull requests to not have this grow out of proportion.

🎸 🎵 🎵


fix: keyboard issues on my collection edit profile screen

The type of this PR is: fix

This PR resolves CX-2374
Description

Fix keyboard issues on my collection edit profile screen

Before
https://user-images.githubusercontent.com/11945712/155292732-c5d17ceb-4199-4332-a1bf-c8bfa16165c2.mov
After
https://user-images.githubusercontent.com/11945712/155292671-e67204a0-de95-4d69-a88b-610f57d84e3c.mov

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Fix keyboard issues on my profile edit screen - mounir

iOS user-facing changes

Android user-facing changes

Dev changes

This PR contains the following changes:

Cross-platform user-facing changes (Fix keyboard issues on my profile edit screen - mounir)

  Generated by :no_entry_sign: dangerJS against d3425130bf4a31779563bc1f88dca4702aeacfab


Add CHANGELOG

Documenting version bumps:

API changes
Behavior changes
Link to issues and next milestones

Super nice: https://github.com/jfmengels/elm-review-simplify/blob/main/CHANGELOG.md


build(deps): remove recompose

Signed-off-by: Mike<EMAIL_ADDRESS>

Closing this for now to avoid switching to Hooks

Closing this for now to avoid switching to Hooks


Action to validate requirements and run regression

This action run the regression test script:
.github/regression_test_scripts/regression_test_action.sh
This will attempt to pip install everything in the requirements.txt, including any linked files
such as distiller etc.
If this is successful pytest is run:
pytest test_*.py

Closing due to inactivity.


Bug With ruby2.2.0:/usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- md5 (LoadError)

when I setup whatweb on Ubuntu14.04,it's install successfully,but when I used it,I get error:
~$ whatweb www.google.cn
/usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in require': cannot load such file -- md5 (LoadError) 	from /usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in require'
from /usr/bin/whatweb:55:in `'
I don't know how to dealwith it,I need help

Hi, and thanks for reporting this! Unfortunately, this tracker is for bugs in Bundler, and the error that you are seeing has nothing to do with Bundler. Since the error is coming from whatweb, I suggest opening a ticket on the whatweb tracker instead.
On Tue, Jun 23, 2015 at 9:59 AM, beruhan<EMAIL_ADDRESS>wrote:

when I setup whatweb on Ubuntu14.04,it's install successfully,but when I used it,I get error:
~$ whatweb www.google.cn
/usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in require': cannot load such file -- md5 (LoadError) 	from /usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in require'
from /usr/bin/whatweb:55:in `'
I don't know how to dealwith it,I need help
Reply to this email directly or view it on GitHub:
https://github.com/bundler/bundler/issues/3778


Write strategy for setting weights to erc721 tokenId's by range

Enable certain erc721 tokenId's to have different weights by defining tokenId ranges.

"tokenIdWeightRanges": [
    { "start": 0, "end": 3000, "weight": 1 },
    { "start": 3001, "end": 6000, "weight": 2 }
  ]

Done, thanks @bonustrack


Create a dist folder

It would help a lot if you create a folder /dist with all files generated and will be used on the web (today they are in two separate folders /js and /css).
Like https://github.com/twbs/bootstrap/tree/master/dist
That way we can configure the assets managers to load all the files from the folder /dist.

Closing this issue as PR #1185 introduced a dist directory with all js/css files


Install timed out but app deployed and can't upgrade

Output of helm version:
version.BuildInfo{Version:"v3.2.2", GitCommit:"a6ea66349ae3015618da4f547677a14b9ecc09b3", GitTreeState:"clean", GoVersion:"go1.13.12"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"
gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.5", GitCommit:"e0fccafd69541e3750d460ba0f9743b90336f24f", GitTreeState:"clean", BuildDate:"2020-04-16T11:35:47Z", GoVersion:"go1.13.9", Compiler:"
gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Kubernbetes in Rancher on vSphere
I am deploying a Windows container and since this is the first time I am deploying to the cluster the full image needs to download which takes a while. I ran the following command...
helm upgrade toggleservice .\ToggleService-1.0.30.tgz --install --wait --description "Manual deploy"

The result was...
Release "toggleservice" does not exist. Installing it now.
Error: timed out waiting for the condition

So after a while the image downloaded and the pods started fine.
When I get the helm history I see this...
REVISION        UPDATED                         STATUS  CHART                   APP VERSION     DESCRIPTION
1               Sun Jun  7 09:44:20 2020        failed  ToggleService-1.0.30    1.0.133         Release "toggleservice" failed: timed out waiting for the condition

That is expected but when I try deploying using the command from above I get the error:
Error: UPGRADE FAILED: "toggleservice" has no deployed releases

So I thought maybe I need to use install but when I do I get the error...
Error: cannot re-use a name that is still in use

So I can't install nor can I upgrade. I need to delete and then redeploy.
What I want to happen is if I run upgrade it works.

I believe this has been fixed in #7653 which was released in 3.2.1.
However, I can't find it in the 3.2.2 release.  I will follow-up on this.
In the mean time, you may be interested in trying with 3.2.1 to see if it works as you need.

We seem to have an issue. Change from v3.2.1 have been dropped from the v3.2.2 release. I'm investigating. Expect a v3.2.3 release this week with fixes. I have found other things missing as well.

Please try release v3.2.3 and let us know if the issue persists.

Is it possible to clarify whether the fix should

help us get out of this situation once we are in it (from a different helm version)
help avoid the issue happening again?

I have gotten into a very similar state as well (using helm 3.1.2), and 3.2.3 did not fix it for me (I am still in this state). However, I suspect that deleting the secrets associated with the release will help me resolve the issue.
To clarify, the way I got into this state was by hitting CTRL+C during the initial deploy of a chart. I have a secret for the release but no actual release helm list --all-namespaces does not return this release.

To clarify, the way I got into this state was by hitting CTRL+C during the initial deploy of a chart.

Maybe this is a different issue?

Yeah this may seem like a separate issue. Can you please open a new ticket? If you still have the output of helm history available that would be helpful to determing if #7653 can solve this for you.

Is it possible to clarify whether the fix should
* help us get out of this situation once we are in it (from a different helm version)

* help avoid the issue happening again?

#7653 allows you to upgrade a release that is stuck in the FAILED state, so it should help in both cases.

The issue described by the OP has been solved in Helm 3.2.3, so this ticket can be closed. Please upgrade to 3.2.3 to take advantage of this feature. Thank you!

I installed helm v3.2.3 and it fixes the issue. Thanks!


 This ensures the calling
class retains control and allows code coverage to operate normally.

It is more complete! :+1:

Very nice!!!

:+1:


Update geo data to 2022g

this is the new url https://github.com/evansiroky/timezone-boundary-builder/releases/tag/2022g
closes #13

fixed in https://github.com/noandrea/geo2tz/releases/tag/v2.1.0