resolve paths relative to tsconfig.json

Relative paths in tsconfig.json (such as rootDir) are resolved relative to Gruntfile.js instead of tsconfig.json.
As mentioned in issue #397, this causes problems when tsconfig.json is used by other tools, such as an IDE. There are more comments in pull #399.
I am afraid to say that I could not follow the reasoning in either thread and apologize if this is repetitious. I will offer two reasons to think that the current behaviour is a bug and not a feature.
First, the Typescript documentation seems not to be explicit on resolution of relative paths (what am I missing?) except when it discusses inheritance:

All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.

However, tsc implements resolution relative to tsconfig.json. It would seem to me that grunt-ts should compile tsconfig.json correctly iff tsc -p path/to/ tsconfig.json does (when tsc is called from the parent directory of the Gruntfile). This is currently not the case.
Second, the following possible work-around is cumbersome:

Author tsconfig.json with paths relative to tsconfig.json.
Create an extension tsconfig.grunt.json that modifies paths for the benefit of grunt-ts.

For example, let:
projectdir/
  |-Gruntfile.js
  |-subdir/
      |-tsconfig.json
      |-tsconfig.grunt.json
      |-ts/
          |- ... ts files to compile

tsconfig.json:
{
	"compilerOptions": {
		"rootDir": "ts",
                ...
	}
}

tsconfig.json would compile correctly for use by IDE or tsc -p subdir/tsconfig.json where tsc is called from the project directory projectdir/.
tsconfig.grunt.json:
{
	"extends": "./tsconfig",
	"compilerOptions": {
		"rootDir": "subdir/ts"
	}
 }

tsconfig.grunt.json is referenced in grunt-ts via tsconfig: 'subdir/tsconfig.grunt.json'.
Many thanks for your great work!

As a workaround, I opted to call tsc directly using "grunt-exec": "3.0.0" as shown below. To be sure, this creates some difficulties when working cross-platform but the direct use of only tsconfig.json is appealing.
			exec : {
				ts : {
					cmd : './target/node/node node_modules/typescript/bin/tsc -p tsconfig.json'
					// for windows:
					// cmd : '.\\target\\node\\node node_modules\\typescript\\bin\\tsc -p tsconfig.json'
				},
				rollup : {
					cmd : './target/node/node node_modules/rollup/bin/rollup -c rollup.config.js'
					// for windows:
					// cmd : '.\\target\\node\\node node_modules\\rollup\\bin\\rollup -c rollup.config.js'
				}
			},

An important complication is the determination of the node path to use (cf. "./target/node/node") since this may differ from the system installation. We use the above on Linux and Windows.

@MatthiasHild Thanks! I started going that route but then decided to use the tsconfig.grunt.json workaround as it was simpler and to not loose the nice console output that grunt-ts provides.

I do not want to detract from the benefits of using a dedicated tsc wrapper!
FYI, base output from exec as below. Additional output via tsconfig.json properties:
	"diagnostics": true,
	"traceResolution": false,
	"listFiles": false,
	"listEmittedFiles": false

Sample output:
Running "exec:ts" (exec) task
Verifying property exec.ts exists in config...OK
File: [no files]

./target/node/node node_modules/typescript/bin/tsc -p tsconfig.json
buffer   : disabled
timeout  : infinite
killSig  : SIGTERM
shell    : true
command  : ./target/node/node node_modules/typescript/bin/tsc -p tsconfig.json
args     : []
stdio    : [ignore,pipe,pipe]
cwd      : /home/m/dev/web/web-standard
exitcodes: 0
pid     : 12531
Files:           269
Lines:         50469
Nodes:        233666
Identifiers:   75811
Symbols:       59992
Types:          8294
Memory used: 113657K
I/O read:      0.01s
I/O write:     0.04s
Parse time:    0.58s
Bind time:     0.27s
Check time:    0.83s
Emit time:     0.42s
Total time:    2.10s
>> Exited with code: 0.

@MatthiasHild Ah ok, great! I missed those settings in tsconfig.json. Thanks again.


PHOENIX-6710 Revert PHOENIX-3842 Turn on back default bloomFilter for Phoenix Tables

+1 LGTM @ankitsinghal

Thanks, @chrajeshbabu, for the review, Unit test failures are unrelated.


Seeing a lot: API rate limit has been exceeded, suspending polling for 900 seconds, lately

Since a couple of days I see above message multiple times in the logs. I am wondering if they are related to these preceding messages:
2018-11-07 10:56:57 ERROR (MainThread) [homeassistant.core] Error doing job: Unclosed client session
2018-11-07 10:59:41 WARNING (Thread-4) [custom_components.evohome] Failed to obtain higher-precision temperatures via the v1 api. Continuing with v2 temps for now.
2018-11-07 10:59:41 WARNING (Thread-4) [custom_components.evohome] API rate limit has been exceeded, suspending polling for 900 seconds, & increasing 'scan_interval' from 300 to 300 seconds.
These messages happened less then 10 minutes after I restarted hass after specifying scan_interval 300.  Has Honeywell put the brakes on v1 calls lately ? Let me know if I can get you more information.

I could say a lot about this (but I will try to be brief)...
I have found no documentation about specific API rate limits as imposed by Honeywell. TBH, they aren't really developer-friendly (although the developer of the evohome client API, which my component uses, may have more to say/add).
The old honeywell climate component, which I will eventually submit a PR to kill off (specifically the evohome half of - it is an awkward hybrid of UA & EMEA & uses two distinct client APIs), uses (from memory) two v1 API calls per zone per cycle, with a minimum scan_interval of 300 secs.
My evohome component uses one V2 API call (per location) per cycle, plus two
Given that I never got a complaint with 8 zones (i.e. 16 API calls per 300 secs, or 1 per 18 secs), I thought that 1 per 60 secs wouldn't trip anything, and thus 1 per 180 secs (the current minimum) would be OK.
TBH, I was always running 1 per 60 sec during development & more often than that & only rarely got an API rate exceeded message.
Recently, I have noticed more API rate exceeded messages, and (to my mind) it seems more so with the v1 API than the v2 API.  Also, I notice that when I do get one such messages, it clears when I restart HA, even if I do so immediately!!
So I am not sure what is going on, and without documentation from Honeywell (which doesn't look likely), or metrics from my component (which I don't think HA would ever permit), we'll be hard-pressed to understand.
Please don't rush to blame my component for this - the older honeywell component never tracked / reported these errors & they may have been happening, but we just never noticed (or could ever notice).  My component reports such errors only because the developer of the underlying API kindly accepted some PRs from me so that this is now possible.


Update README.md

Corrects the link to the default configuration options.
If you decide to merge #67 before approving this one, then this one can be closed. I don't mind either 👍

For the time being, this one is helpful. Thank you @canihavesomecoffee !


refactor(experiment): Add pod memory hog default memory consumption

Signed-off-by: Udit Gaurav<EMAIL_ADDRESS>What this PR does / why we need it:

Add pod memory hog default memory consumption in the job spec

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Checklist

[ ] Does this PR have a corresponding GitHub issue?
[ ] Have you included relevant README for the chaoslib/experiment with details?
[ ] Have you added debug messages where necessary?
[ ] Have you added task comments where necessary?
[ ] Have you tested the changes for possible failure conditions?
[ ] Have you provided the positive & negative test logs for the litmusbook execution?
[ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
[ ] Have you used non-shell/command modules for Kubernetes tasks?
[ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
[ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
[ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
[ ] Do the artifacts follow the appropriate directory structure?
[ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
[ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
[ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
[ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
[ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
[ ] Can you suggest the minimal resource requirements for the litmusbook execution?
[ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
[ ] Has the litmusbooks been linted?

Special notes for your reviewer:

/merge


Frame Accurate Seeking

OpenCV's video reader suffers from an issue where frames after setting CAP_PROP_POS_FRAMES might either be invalid, or inaccurate (e.g. seeking to frame 1022 might actually seek to frame 1005). For some projects, this might not be a huge deal, but for projects that need to be synchronized with other data, this could be a huge silent bug.
While not a complete solution (I'm not too familiar with EVA's codebase), linked below is an easy-to-use, frame-accurate video reader using PyAV. PyAV has ffmpeg builtin, so it doesn't add any additional external non-python dependencies that could complicate installation. Its (mostly) a drop in for the opencv reader.
https://gist.github.com/BrianPugh/8de1a6f124516ec2a2a61caadcdf039a
Unrelated self-promotion: For managing your different readers, storage-backends, etc; consider checking out my AutoRegistry project. Basically if your abstract base classes inherit from Registry instead of ABC/ABCMeta, child classes can be easily accessed via strings (from a config file, or other).

@BrianPugh Nice catch! Thanks for raising the issue. We are aware of the incorrect frame seeking in OpenCV. Based on our prior discussions, I recall we found another library decord that provides an accurate frame seeking out of the box. However, we did not change the storage engine as we were considering moving to a time-based seeking instead of frame based. IMO, time-based seeking seems intuitive to use in queries compared to frame-based. However, we might have to support both.
Anyways, for frame-based seeking, OpenCV has to go. PyAVsolution looks neat and can easily replace OpenCV. I guess it boils down to performance metrics and stable support.
AutoRgistry sounds interesting. I'll check it out and consider the possibility of using it in eva.

@dungnmaster Is this issue fixed with our decord based reader?

@jarulraj This should be fixed with the decord based reader but we are currently using it only for IFRAMES based queries. Should be a small change to switch every query to decord reader.


DO NOT MERGE -- FOR REVIEW -- Use puppet-server nightly repos for testing AIO agent

This is kinda what should happen (dont know for sure, cant test for now)
I wanted to get this out so that folks can see what should work for installing puppet-server from nightly repos once @waynr has puppet-server promoting to them. /cc @johnduarte @kylog @haus

CLA signed by all contributors.

These changes have been pulled into the aio2 integration branch, see https://github.com/puppetlabs/puppet/commit/912baa91cda89d7543dea4df842f4802840c4e61, closing this PR.


Instructions for publishing

The readme does not currently document how to publish to or otherwise use the caesium-based crate registry.

You publish to caesium using cargo, see alternative registry rfc for details. You will need to use nightly cargo to do it though I am afraid.

No links, no examples.
How do you test it ?
Is there hard to describe two three commands in code block ?


Create BMI Calculator

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[x] I have updated the documentation accordingly.
[x] I have added a new Project.
[x] I have added a README.md file for the Project.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

LGTM, Leave a 🌟 and try to contribute more projects.


fix angle after death

Angle after death now correctly correspond to angle before death.
fix invulnerability: invulnerability know only applies after getting hit by circles and triangles
switch to new sprite (player) instead of mc_sprite
New Issue: angle of movement must be adjusted to the new player sprite

Changes

Angle after death now correctly correspond to angle before death.

Fix invulnerability: invulnerability know only applies after getting hit by circles and triangles

Switch to new sprite (player) instead of mc_sprite

Issues

Angle of movement must be adjusted to the new player sprite


[DynamoDB] How about remove atom value

From this commit:
Add atom to dynamize_value
It makes the atoms available for input attribute values, that sounds awesome.
However, it also brings some ambiguities:
-type in_expected_item() :: {attr_name(), false} | condition().
-type condition() :: {attr_name(), not_null | null} |
                     {attr_name(), in_attr_value()} |
                     {attr_name(), in_attr_value(), comparison_op()} |
                     {attr_name(), {in_attr_value(), in_attr_value()}, between} |
                     {attr_name(), [in_attr_value(),...], in}.

We have special values false, not_null and null here, which mixed with in_attr_value().

In the case of condition, they're special value: not exists, not null (equals exists), null (equals not exists).
In the case of input item, they're string value: {"S": "false"}, {"S": "not_null"} and {"S": "null"}.

But its not the end yet.
As we all know, in Erlang record, default value of non-specified property is undefined.
We could put the undefined value as {"S": "undefined"} into database by mistake so easily.
I suppose we should take this into consideration.

Good catch - I wish I had thought of that before accepting the commit. However changing it now would break backwards compatibility which I don't want to do. It does look like the ambiguities you found are all in legacy parameters, so hopefully will not be too much of an issue going forward.


Allow execution of sudo command on hosts

$ lsi host-filter -u sshUser -i myKey.pem -c "cd /usr/local/bin; sudo ln -s /usr/bin/python mylink"
[host-filter1 (xx.x.xxx.xxx)]: sudo: sorry, you must have a tty to run sudo
[host-filter2 (xx.x.xxx.xxx)]: sudo: sorry, you must have a tty to run sudo
[host-filter3 (xx.x.xxx.xxx)]: sudo: sorry, you must have a tty to run sudo
[host-filter4 (xx.x.xxx.xxx)]: sudo: sorry, you must have a tty to run sudo

This is caused by the sudo command requiring a tty to run a command.  We have typically disabled this feature

Didn't mean to close this and my comment was incomplete.  This is caused by sudo on some OSes being configured to require a tty to run.  We could modify lsi to run ssh with a pseudo-tty (-t) but this can cause other problems.  Considering that newer versions of redhat/centos removed this requirement (https://bugzilla.redhat.com/show_bug.cgi?id=1020147) we usually just updated the sudo configuration to remove the tty requirement.


Add correct editorjs initialisation for multiple editorjs fields in an inline

Currently only the first field is properly initialised.
This should resolve #32

Thanks!


Add shooted-seed documentation

How to categorize this PR?
/area documentation
/kind enhancement
/priority normal
What this PR does / why we need it:
Documentation to create shooted-seeds with the annotation shoot.gardener.cloud/use-as-seed
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:
NONE

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

/ok-to-test

/needs rebase

@dergeberl can you please squash the commits into a single one to make the PR ready for merge?

Unfortunately, there are still conflicts that must be resolved via rebase.


Commas, Periods and Tokens

This isn't technically an issue, but I thought posting this here could help alleviate an issue some people might face.
Because of the way Paint with Words is implemented, you cannot use commas in your prompt for the reasons mentioned in the description of this GitHub. This can be an issue since commas are commonly used to separate tokens in a prompt. As such, a prompt without commas can have drastically less tokens, and thus the image generated can be both drastically less detailed, and drastically worse quality than an image with commas, as the model has less information to work with. In my testing without PWW enabled, the tokens used in the prompt I was testing went from 52 to 34 tokens after removing commas, and the output was far lower quality.
However, simply replacing your commas with periods seems to act perfectly fine as a substitute, and results in an equal number of tokens as when using commas. Further, whilst there is a tiny difference in very small details of the generation (clouds and other background details can be moved slightly, and other small, inconsequential changes) the image generated with the same seed is almost exactly the same, with the quality of the image being about equal as a result.
Importantly, with this change you can then also implement the exact text with periods into the PWW obj field without it throwing up an error like it does if you use commas.
I thought I would bring this up since it isn't mentioned in the description of the GitHub, as the description simply says "don't use commas". I think modifying the description to instead say "replace commas with periods in both prompt and obj field" could be a much more helpful to people who don't know about this workaround.

Thanks for your great suggestion.
I had replace "," by "@" in the latest version.
Please let me know if there's other comments :)


No enum component example

How can Bevy's documentation be improved?
The ecs_guide example doesn't seem to include an example for enum components.
Since updating an enum component's variant requires a dereference (i.e. *foo = Foo::Bar), it can be confusing to first-time users. This should be included either in that example or a dedicated enum component example.
It would also be worth demonstrating how to pattern match against a mutable enum component as well.

Same is true for updating an entire resource at once.


delta coding performance

Pull request checklist
Improves the performance of delta coding, as covered on the mailing list:
<EMAIL_ADDRESS>Unit tests are included in
https://github.com/tukaani-project/xz-java/pull/10
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[ ] Build was run locally and without warnings or errors
[ ] All previous and new tests pass

Pull request type

Please check the type of change your PR introduces:

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

What is the current behavior?

Related Issue URL:
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

I've been preparing a few unrelated changes and including this Delta filter improvement among those. I hope the changes get to master tomorrow. (This is a special case and not the normal way in the project. Sorry.)
I benchmarked the Delta filter changes. Encoding time was reduced by 60-70 % when distance=1 and over 50 % with long distances. That makes sense as with longer distances more bytes go via the history buffer.
Decoding time reduced up to 50 % with long distances but only 5 % with distance=1. It's still a clear improvement. I suppose short distance is slower because buf[off + i] += buf[off + i - distance]; has dependency on the previous iteration; it cannot parallelize like with longer distances.
I wonder if JVM is smart enough to vectorize the decoder loops when distance is large enough and appropriate multiple of a power of two. For example, distance=240 is a little faster than 248.
In any case, thanks for the improvement and sorry that it has taken three years to get it included.

I wonder if JVM is smart enough to vectorize the decoder loops when distance is large enough and appropriate multiple of a power of two. For example, distance=240 is a little faster than 248.

It might be. I also used the DeltaEncoder and DeltaDecoder as a means of playing with the Vector api functionality in https://openjdk.java.net/jeps/338, which still has not been fully released. I definitely recall on the encoder side seeing further improvements beyond what was in this PR. (It actually worked the opposite direction, I observed something like 50:1 improvement in performance, on hardware where 32:1 should have been theoretical max. This caused me to revisit the original implementation to see if it could be improved without use of vectors.) While I also worked on the decoder, I do not remember actual performance numbers.

In any case, thanks for the improvement and sorry that it has taken three years to get it included.

Just glad to see it making it :)


Improve error reporting from fetch_worker_metadata

Previously the platform name was not reported if there was an exception.
Signed-off-by: Tim Waugh<EMAIL_ADDRESS>

Release note added:

Improve error message when fetching a worker metadata fails by reporting the failing platform name


Schedule compliance purging

Compliances should be purged, it's on a weekly daily basis just the same as  things mentioned in https://github.com/ManageIQ/manageiq/pull/19264#discussion_r321800058 but honestly I don't even know anything at all about how often it should happen so feel free to argue
For https://bugzilla.redhat.com/show_bug.cgi?id=1733641 but really it's just up because I want to get people talking about it. @gtanzillo @yrudman @jrafanie maybe @kbrock, I dunno

@miq-bot remove_label wip
@miq-bot add_label enhancement, performance

we can merge and backport to 5.8 for the issue that LJ and Jared were looking at yesterday
:trollface:

@miq-bot add_label changelog/yes

@d-m-u can this be ivanchuk/yes?

@simaishi : should be fine as long as you take the bug that's fixed in 19326 too.
@miq-bot add_label ivanchuk/yes

Ivanchuk backport details:
$ git log -1
commit 7a50e8eba2eebcea1e8a26e8afab989353d6feb2
Author: Gregg Tanzillo<EMAIL_ADDRESS>Date:   Tue Sep 10 09:28:14 2019 -0400

    Merge pull request #19264 from d-m-u/schedule_compliance_purge_or_whatever

    Schedule compliance purging

    (cherry picked from commit 87935ce0e85cad7dd6f9554136fdc5f69f200d12)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1767808


Do not create OidcAuthenticator instance in renewUserProfile

In order to use custom Authenticator when getting new access token, I suggest to use OidcAuthenticator from getAuthenticator  instead of creating new instance of OidcAuthenticator each time

Thanks for your contribution


Optimized model update

This PR adapts db_client_reader code to the changes in get_statements_by_paper function introduced in https://github.com/indralab/indra_db/pull/49

:+1:


Run sanity and integration tests with CSI driver deployed on minikube

What type of PR is this?

What this PR does / why we need it:

Added script changes to run the azuredisk driver on minikube for sanity and integration tests
Added a new set of helm charts to be used for deploying csi driver on minikube

Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

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

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build 727910312

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 73.34%

Totals

Change from base Build 727737750:
0.0%

Covered Lines:
2187

Relevant Lines:
2982

💛  - Coveralls


Add backup and restore feature

A suggestion : changing the existing base.odex, base.vdex name to base..bak.
When user wants to restore to original state, simplfy delete patched ones and rename them back to base.


Unable to build using anchor: solana-frozen-abi 1.9.0

I have this problem:
$ anchor build
BPF SDK: /home/antoniomuso/.local/share/solana/install/releases/1.8.2/solana-release/bin/sdk/bpf
Running: rustup toolchain list -v
Running: cargo +bpf build --target bpfel-unknown-unknown --release
error: failed to download `solana-frozen-abi v1.9.0`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `/home/antoniomuso/.cargo/registry/src/github.com-1ecc6299db9ec823/solana-frozen-abi-1.9.0/Cargo.toml`

Caused by:
  feature `edition2021` is required

  consider adding `cargo-features = ["edition2021"]` to the manifest

I fix it by upgrading to Solana 1.9.0, Sorry for the issue.


[5.5][Refactoring] Support refactoring to async if callback is @convention(block)

Cherry-picks https://github.com/apple/swift/pull/37071.

We already have special logic to extrac the closure for closures with capture lists, add the same kind of logic for closures that are marked @convention(block) etc.
Resolves rdar://75301524 [SR-14328]

@swift-ci Please test

@swift-ci Please test Windows


Distort display

The result from TECNO W2, a MediaTek SoC : mt6580 device .
anyway to solve this issue ?

Could you try with a different size:
scrcpy -m 800

Or with screenrecord:
adb shell screenrecord /sdcard/file.mp4
adb pull /sdcard/file.mp4

@rom1v i have changed my device, using a new device and now it works perfect
.
On the other hand, scrolling frame rate is a bit laggy, any fix ?

On the other hand, scrolling frame rate is a bit laggy, any fix ?

Over USB?
How many fps? (Ctrl+i to print fps in the console)

Over USB?

Yes

How many fps? (Ctrl+i to print fps in the console)

Ctrl+i ( crtl + i ) is not woking , am running Ubuntu 18.04

Ctrl+i does not print something like "fps counter started" ? Then, it should print fps every second (but only if there are changes on the screen).

pressed Ctrl+i but nothings shows up.

Nothing happens in the window, but what is the output in the terminal from where you started scrcpy?

@rom1v , first of all am sorry for the delay but finally i got the FPS.
i noticed that i have to press Ctrl+i+i  for it to capture the  FPS

INFO: FPS counter started
INFO: 12 fps
INFO: 12 fps
INFO: 11 fps
INFO: 14 fps
INFO: 15 fps
INFO: 15 fps
INFO: 15 fps
INFO: 15 fps
INFO: 15 fps
INFO: 14 fps
INFO: 11 fps

and so on ...

I'm closing for inactivity (and you don't have the problem anymore https://github.com/Genymobile/scrcpy/issues/33#issuecomment-376654598).


Update pipeline-faq.md

Q4 FAQ
Description

Please describe your changes: Q4 FAQ

PRs must meet these requirements to be merged:

[x] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://67609c823f219a7aa5077b10--harness-developer.netlify.app


QA: Local development issue

We will run random commands in this QA. Some commands will be written invalid on purpose to test the correct response.
First, tests will be performed in a single yarn build && yarn start with disable-analytics": false.
The reason is testing previously failing analytics functions on localhost:
await htmlImage(summaryInfo);
await compositeImage();
await processTelegram(dataPadded);

After this, some tests will be performed with disable-analytics": true

/help

/wallet 0x1F9FCc0E84dc2094499b848AE37Cd6a51db03Ff2

/assign

/assign

/assign

/start

/stop

/help

/wallet

/help

/wallet

/wallet 0x1F9FCc0E84dc2094499b848AE37Cd6a51db03Ff2

/wallet 0x1F9FCc0E84dc2094499b848AE37Cd6a51db03Ff2


Add neverball

Project: https://github.com/Neverball/neverball
Unfortunately the configuration isn't movable, see https://github.com/Neverball/neverball/pull/184

Thanks!


feat: use ssm to connect db through private bastion FGR3-3367

Vyzkoušel jsem to přímo v Circlu:

Your orb has been published to the CircleCI Orb Registry.
You can view your published orb on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/figure/node-ecs?version=2.6.0


Add hightlight.js styling for docs

ref #69

Thanks.
I think we should put this in a separate css file, included "I don't no where but not in the current file" :D
Maybe a highlightjs.css file included in an entry point?

Pushed new commit. Hightlight.js style is in it's own file

Thanks, that's better with these colors! I will probably tweak those in the future, but better than it was.


MicroProfile Config 2.0 Specification Review

Specification issue template
When creating a specification project release review, create an issue in the MicroProfile-WG repository repo with the content defined as follows.

[x] Specification name and version
[x] Add the label Release Review
[x] Naming conventions for artifacts:

[x] Specification PDF in the form of microprofile-project-spec-version.pdf
[x] Specification HTML in the form of microprofile-project-spec-version.html
project is the microprofile specification short project name (config, health, ...)
version is the two digit x.y version of the specification

[x] The Nexus Staging links (orgeclipsemicroprofile-NNNN where NNNN is the staging repository id) (eg, https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-NNNN/org/eclipse/microprofile/config/) which contain all the binaries and relevant documentation:

[x] Staging Repo
[x] Spec PDF
[x] Spec HTML
[x] Javadoc
[x] API Jar
[x] TCK Jar

[x] A link in the Eclipse downloads sections is still available for specs and apidocs:

[x] https://download.eclipse.org/microprofile/staging/microprofile-config-2.0/
[x] An apidocs directory containing the javadoc associated with the API jar.

[x] Summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification:

[x] Compatible Certification Request

[ ] Release Review

[x] Follow governance process and create/update release record

Component Release Record

[x] Email to PMC
[x] Start release review by emailing EMO (Track the bug issue created by EMO after the email)
[ ] send microprofile-wg for voting

+1

/cc @jclingan @ederks85 @emecas

Received +1 from PMC
Gunnar Wagenknecht<EMAIL_ADDRESS>via eclipse.org | Gunnar Wagenknecht<EMAIL_ADDRESS>via eclipse.org | Wed, Nov 18, 7:00 PM (1 day ago)
+1
Gunnar Wagenknecht<EMAIL_ADDRESS>via eclipse.org

https://bugs.eclipse.org/bugs/show_bug.cgi?id=568938

https://bugs.eclipse.org/bugs/show_bug.cgi?id=568938

Can you add the link into the description, so it gets more visibility?

+1
I have reviewed the materials for this Config 2.0 release and all looks good.  I will initiate the ballot review shortly.

+1

We forgot to include the final step, the Result Ballot notification after the initiated ballot is sent.
can you add the step to Metrics? https://docs.google.com/document/d/1wISp-yRzQZNOHULNekxxg1U18be3v-3CRUswklcpmr8/edit
Thank YOU! the general template needs to be adjusted as well. :)

+1 for Jelastic

Making a similar comment that I did on the Metrics #15 and Health #14 Issues...  We need the Compatible Implementation that is used to verify the CCR to be more "permanent".  There is a reference to SmallRye Config 2.0.  Is this available in Maven or some permanent download location?  A link would be good, if that's the case.  Otherwise, we should create the SmallRye Config 2.0 artifact, store it, and provide a link.  Thanks.

Hey @kwsutter. It is available as a commit in the repo:
https://github.com/smallrye/smallrye-config/commit/679c438dd7e3902e7be36133a08add0ac46e5494
The issue here is somehow the same you have with dependent specs. We can't really do a release of the implementation without having the API publicly available. Once the API is out, we cut a release from the same codebase but without the staging repo reference and publish it in Maven Central. The link can then be replaced by the permanent binary in Central. Is this acceptable?

Hey @kwsutter. It is available as a commit in the repo:
smallrye/smallrye-config@679c438
The issue here is somehow the same you have with dependent specs. We can't really do a release of the implementation without having the API publicly available. Once the API is out, we cut a release from the same codebase but without the staging repo reference and publish it in Maven Central. The link can then be replaced by the permanent binary in Central. Is this acceptable?

@radcortez, the commit tag is not sufficient.  This would still require someone to download the exact code and build it in the exact same way in order to produce the binary.  As time goes on, these processes will get muddled and the building will become more difficult.
Any Compatible Implementation needs to have a long life.  It could be a Milestone driver, or a Release Candidate driver, or even a Snapshot driver -- as long as the binary has some repository where it will live and not accidentally get deleted.  The best location is Maven.  But, other long-lived download repos will also suffice.
I agree that it's a chicken-and-egg problem.  We struggle with this at Jakarta as well.  But, we need to have a long-lived CI that can be used at a later time to verify the compatibility.  As an example, Jakarta EE 9 used Glassfish 6.0-RC2 as the CI.  Some of the embedded implementations used by Glassfish had not finalized their versions yet.  As soon as all of these are completed, then Glassfish v6.0 (final) will be used to re-certify as the CI.  A new CCR will be filed and the data for the Jakarta EE 9 CI will be updated with the new information.

Ok, updated the CCR with a RC release available in Central.

I double checked the released and confirmed the release used the staged Config 2.0 api (see here) and passed the TCK.

This is not on Maven Central: https://repo1.maven.org/maven2/org/eclipse/microprofile/config/microprofile-config-api/2.0/


Broken link for "Why I created this image: Simple mail server with Docker"

I get that https://tvi.al/simple-mail-server-with-docker/ redirect to itself.

Hi @np, you're right, a ghost did that but did not had time to dig into...
I will this week.
Thanks for reporting this.

Resolved. Changed HTTPS config on nginx.


Root detection mechanism is bypassed by Run unrootbeer Xposed module script

hi
I saw this question from StackOverflow that posted an issue that can bypass root detection.
https://stackoverflow.com/questions/65625001/android-app-root-detection-method-was-bypassed-by-focusing-specifically-on-the-r

@chengstone Root detection and root detection bypassing is a bit of a game of cat and mouse. The advantage is always in the favour of the bypassing side, as they have root permissions so can naturally do more things.
One way to at least partially combat this would be to implement tamper detection, such as a signature check. This would defeat the method you've linked to as the bypassing requires that the application is rebuilt and the new signature the attackers use would not match one of the expected (typically your release / debug key)


Development - Screenreader component

Summary: Development of the Screenreader component.
Develop on component branch, push to staging and push to prod when approved.
Acceptance Criteria:

[ ] Component kickoff
[ ] Sync with Design
[x] Requirements documentation
[ ] Requirements doc: Consider edge cases
[ ] Requirements doc: Describe component properties
[ ] Review of requirements doc
[ ] Develop the component according to the requirements doc and design specs
[ ] Add component to storybook
[ ] Write draft of dev guidance
[ ] Sync dev properties with Figma properties (design + dev)
[ ] Handoff from draft dev guidance to documentation author/lead
[ ] WCAG Goal can be completed using a screen reader.
[ ] WCAG Visual elements observe color contrast requirements.
[ ] WCAG Manual accessibility testing meets WCAG 2.1 AA requirements.
[ ] Provides equal service in French and English.
[ ] Comparison with official policy, documented reasons for deviation if any
[ ] Final sync with Design
[ ] Policy review
[ ] Code review
[ ] After PR approval, merge component to staging
[ ] Review from Design
[ ] Review from Policy
[ ] Note: reviews could be done on Storybook staging
[ ] Push to prod

Will need to have some discussion around the component/element name, screenreader content is too specific and doesn't reflect that this text can be used by other assistive technologies.
Will look to book a dev/design sync in new sprint to discuss. This sprint was meeting heavy so I didn't want to add a new one to people's calendars.

After some discussion and voting, the component is going to be renamed to Screen reader only gcds-sr-only


Fix tests + add CI

fixed the data csv file location and moved it back to the test folder where it belongs
added path updates to test file for getting the correct paths of all modules (this fixes the import errors which appear when running tests)
add a test runner for github actions based on pytest to recognise our tests
add coverage tool to requirements for CI installations
add new step in the github actions workflow to

run tests

run tests and generate coverage report of each file in the source folder

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@e913672). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #45   +/-   ##
=======================================
  Coverage        ?   74.92%
=======================================
  Files           ?       15
  Lines           ?      327
  Branches        ?        0
=======================================
  Hits            ?      245
  Misses          ?       82
  Partials        ?        0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


All container-init output should use standard logging format

The wget command error is not using the logger.

One general approach for this would be to write a console app or script that would read lines from STDIN and then write them to STDOUT with the standard format.
Then, we’d pipe the output from commands like WGET to this app.
We wouldn’t be able determine log level but perhaps we could do this via a command line option, for example if only actually errors or warnings are going to STDERR, we could pipe that to the app with —error and then pipe STDOUT to another instance of the app with —info

@marcusbooyah: What was this relating to?  Is some service doing wget in its Docker startup script?

This came up when Marcus tried to workaround the Istio/Envoy sidecar delay.  This is addressed now by NeonService service dependencies.


Merge node boilerplate with this repo

This generator should allow you to configure whether or not the lib needs to run in the browser or not

Closing in favor of #263


Blocky monospaced fonts in Spyder Mac OS Catalina

Spyder (4.1.5) displays monospaced fonts in a weird "bold" and blocky format under Mac OS Catalina. Other applications display the same monspaced fonts without this issue. (Proportionally spaced fonts in the Help pane in Spyder also look OK to me.)
These blocky monspaced fonts in Spyder materially reduce readability and seem undesirable to me. I recognize that this is partly a matter of personal preference.
What appears to be a previous report of this issue was closed on October 23, 2018 with the comment that Qt 5.12 will fix this. (See "Spyder fonts have changed and are now too blocky #8132". https://github.com/spyder-ide/spyder/issues/8132)
I have installed the latest version of Anaconda Python 3.8.1 under Mac OS X 10.15.6 but still see what I presume to be the same issue. Anaconda installed Qt 5.9.7. Maybe Qt 5.12 is still a long time away.
In the meantime, using a very thin monospaced font makes Spyder look much better. Spyder still makes the font fatter; but starting with a very thin font makes the final display in Spyder look OK.
I have had success with Google Roboto Mono (https://fonts.google.com/specimen/Roboto+Mono). Spyder only shows a single Roboto Mono font, even if several weights are installed. Uninstalling or disabling the heavier styles forces Spyder to use the lighter weights.  Since there are several weights in the package, it is possible to keep and use the one that looks best.
Here is Andale Mono in Spyder

Here is Andale Mono in BBEdit, for comparison

Here is Roboto Mono (Light) in Spyder

All fonts sizes are 14pt in the screenshots above.

Hey @LudgerHentschel, thanks for reporting. I also think this is an issue with Qt, hence something we can't fix directly. We just need to wait until Anaconda publish packages for more recent Qt versions, sorry.


Ignore adding scope hash when styles are not scoped

<AbellComponent>
<template>

</template>
</AbellComponent>

<AbellComponent>
<template>

</template>

</AbellComponent>

Problem:
In both of the above cases, CSS is not needed to be scoped. Above components will add abell-data-<hash> attribute to all html elements inside template.
And thus, it outputs:

data-abell-<hash> is required to scope CSS. But since in above examples, styles are not scoped, we can ignore adding hash to HTML elements.
Expected:
Component with this code is not required to be scoped so does not need those abell-data attributes. So they are expected to output.

This is the function that adds those hashes to HTML output https://github.com/abelljs/abell-renderer/blob/main/src/parsers/component-parser.js#L158
We have to ignore calling this function if-


SD v2 and Dreambooth, concept not working

Hi,
I tried training using the v2 512px model with my face, training completed without issue, but when I use the model, with basic thing like "portrait of "my_concept_keyword" I have nothing looking like me. Everything work fine with the 1.5 version tho. Any tricks to do to have it working ?
Thank you

I had a similar problem. I haven't found a solution yet. It seems that the output does not follow the orders of my training images.

the V2 is completely different from te V1, I'm at the moment working on finding the right learning rate for the V2 as the default one doesn't seem to be aggressive enough.

the V2 is completely different from the V1, I'm at the moment working on finding the right learning rate for the V2 as the default one doesn't seem to be aggressive enough.

Kaliyuga db v2 use this settings; i dont know if is good
!accelerate launch train_dreambooth.py
--pretrained_model_name_or_path=$MODEL_NAME
--pretrained_vae_name_or_path="stabilityai/sd-vae-ft-mse"
--output_dir=$OUTPUT_DIR
--revision="fp16"
--with_prior_preservation --prior_loss_weight=1.0
--seed=1337
--resolution=512
--train_batch_size=1
--train_text_encoder
--mixed_precision="fp16"
--use_8bit_adam
--gradient_accumulation_steps=1
--gradient_checkpointing
--learning_rate=4e-6
--lr_scheduler="constant"
--lr_warmup_steps=0
--num_class_images=50
--sample_batch_size=4
--max_train_steps=5000
--save_interval=500
--save_sample_prompt="a very good dog, art by [yourname]"
--concepts_list="concepts_list.json"

the V2 is completely different from the V1, I'm at the moment working on finding the right learning rate for the V2 as the default one doesn't seem to be aggressive enough.

From what other users of other repos are reporting, the problem is in the text-encoder and not in the learning rate. Some report that perhaps the best is to completely remove the text-encoder, while others report that the ideal is to set it to 100%
I believe that any of these two is the solution we are looking for.

captioning the images helps a lot, I'm still experimenting

@TheLastBen I just tested with the text-encoder to 0% and the model started following the training images. Maybe the problem was really that. In my previous test was at 15% and was not replicating.

I'm adding a new conversion script that will fix the problem


"kubectl get events" returns empty unless namespace is specified

kubectl get events returns no results unless namespace is specified.
If no namespace is specified, it should return all events recursively.
(@preillyme ran in to this)

AFAICT it returns events from 'default' namespace, not no results. I'm not convinced that current behavior is bad. If anything I'd consider adding explicit --all_namespaces flag or sth, but I'm not sure if even this is a good idea.

kubectl get events (without specifying a namespace) returns only the default namespace events.
The REST call api/v1beta1/events (without specifying a namespace) returns events for all namespaces.
The behavior should be consistent between the two, whether it is to return all or default name space only.

Spoke with @thockin, and he agrees with @gmarek, this is functioning as intended.
For the REST calls (api/v1beta1/events, api/v1beta1/pods, etc.) returning all events/pods/etc. (regardless of namespace) is intended behavior. For kubectl commands, when no namespace is specified, returning the default namespace is intended behavior.
Closing issue.

In the future, I am supportive of passing * as a way of asking to run the across all namespace calls, but it should only be allowed on kubectl get.
----- Original Message -----
From: "Saad Ali"<EMAIL_ADDRESS>To: "GoogleCloudPlatform/kubernetes"<EMAIL_ADDRESS>Sent: Thursday, February 26, 2015 1:45:26 PM
Subject: Re: [kubernetes] "kubectl get events" returns empty unless namespace is specified (#4796)
Closed #4796.

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/4796#event-242865410


Request for wandb report to compare loss curves

Hi, Thank you for sharing this great work!
We have started to train this model on a multi-lingual dataset, including Japanese, and would be happy to compare it with the loss curve of the model trained for the paper to see how the learning progresses.
Would it be possible for you to share the wandb report?
Best regards.

Thank you very much for the quick response!
Comparing the shared loss curve with the one from my model, it seems that the training is progressing smoothly :)

Thank you again!

Oh, one thing might matters.
If your multilingual training set includes both ZH and JA, I have no idea if there would be confusion of model facing same formed Hanzi or Kanji (as we just leverage characters and do not distinguish them from different languages)

I took that into consideration when writing the preprocessing and dataset class, so I think it should be fine ;)


add react hooks for accessing redux store state and dispatching redux actions

As discussed in the hooks API design issue, here is an implementation that could be used as an alpha.
There are a couple of open points:

are tests for HMR required? (the corresponding tests in connect.spec.js are skipped)
I added inline documentation to the hooks, but other code doesn't have this (instead, the docu is in the types); not sure what you want to do here
I haven't updated the docs yet to mention hooks
naming of hooks could change depending on the API design issue

Awesome. Initial thoughts:

Yeah, I'd still like to have the HMR tests updated at some point, but that's @theKashey 's area of expertise.  I've pinged him a couple times on that and haven't gotten anything.
Totally fine with having some inline documentation for now.
We can hold off on actually updating the docs for the moment while this is still in alpha .  I know @wgao19 set up versioned docs, but I'm not clear yet on how to handle the "current" vs "next" docs content.
Per the naming: I still rather like useSelector, but on the flip side, the poll at https://twitter.com/acemarke/status/1118952682025377792 says a lot more people like useReduxState().  Doesn't mean we have to do that, but it's a data point.
I did actually kinda want useRedux(selector, actions) in there because of the strong parallel with connect(), to make it as easy as possible for folks to migrate if they want.  I know it's also basically a 2-liner, so anyone could write it if they so choose, but it seems reasonable to include it.
I have slightly mixed feelings about exporting useReduxContext().  We've danced on the line of whether or not that sort of thing is actually part of our public API.  On the one hand, the "Accessing the Store" docs page explicitly says "this isn't part of our public API".  On the other hand, we do export ReactReduxContext, and if that's exported, than obviously anyone can just do useContext(ReactReduxContext).

Also, not sure whether it's better to merge straight into master and publish the alpha from there, or set up a hooks-alpha branch instead and iterate on that.  May be dependent on the versioned docs thing.  @timdorr , @wgao19 , thoughts?

@markerikson

useRedux(selector, actions)

I like the idea of only needing to import one hook.  Only trade-off I can think of is possible confusion or needless bikeshedding by giving people two very similar ways to do something.

useReduxState

I didn't like it at first, but I actually like that it's more explicit about what the hook is doing.  This may be especially helpful for beginners.  I was a fan of useSelect, myself.

Hi @markerikson,

To update docs for "next" version, make changes to the docs under project root's docs/ directory.
To update docs for "current" version, or any previous stable versions, make changes to website/versioned_docs/ in their respective subdirectories.
When this alpha version becomes stable release, run Docusaurus' version command to copy root docs/ into versioned_docs, and further changes should happen there from thereon.

I've checked Docusaurus' docs regarding versioned docs on other branches, it seems they cannot associate a version to a specific branch. The changes to docs should happen on master.

Per the naming: I still rather like useSelector, but on the flip side, the poll at https://twitter.com/acemarke/status/1118952682025377792 says a lot more people like useReduxState(). Doesn't mean we have to do that, but it's a data point.

In my POC I also had useReduxState, so I am definitely in favor of that naming. Just let me know if you want me to change it.

I did actually kinda want useRedux(selector, actions) in there because of the strong parallel with connect(), to make it as easy as possible for folks to migrate if they want. I know it's also basically a 2-liner, so anyone could write it if they so choose, but it seems reasonable to include it.

I'll add a useRedux hook.

I have slightly mixed feelings about exporting useReduxContext(). We've danced on the line of whether or not that sort of thing is actually part of our public API. On the one hand, the "Accessing the Store" docs page explicitly says "this isn't part of our public API". On the other hand, we do export ReactReduxContext, and if that's exported, than obviously anyone can just do useContext(ReactReduxContext).

Yeah, I had the same thoughts. However, since this hook can easily be written by anyone themselves and in the spirit of keeping the exposed API minimal, I'll remove the export of this hook.

My one concern here is swallowing errors when the component doesn't re-render.
Perhaps it's worth considering that "window of opportunity" approach from easy-peasy again?

The window of opportunity (as implemented in easy-peasy) would also only throw the error if the component gets re-rendered. I still argue that for transient errors or for unmounted components it simply does not matter. The selector is a pure function without side-effects. Therefore, why would you care about an error that never has any observable effect (quantum scientists would argue that any component is always in an error state as long as you don't render it ;) )?

The other downside is potentially losing some of the stack trace pointing back to the dispatched action.

Yeah, I hadn't thought about that. I have set up a sandbox that shows how it would currently look like. In the example you don't get the dispatch in the stack trace, only the click event that triggered the dispatch. I have prototyped a solution for this here and you can see it in action in this sandbox. Basically, if in a render following an error in the subscription callback another error occurs, we put the merge the errors. This way you get both stack traces. What do you think?

Well, the latest poll between just useSelector and useReduxState started off at about 70% for useReduxState, but has since narrowed down to a tossup - 51/49.
So, I'm inclined to stick with useSelector for now.

Yeah, I'd still like to have the HMR tests updated at some point, but that's @theKashey 's area of expertise. I've pinged him a couple times on that and haven't gotten anything.

There would be some problems with HMR, and probably not only with it.

useActions has no dependency on actions, and could not have, as long as it's a unique object every time.
in the same time useSelector is "free" from this effect, as long as the "current" selector is stored in ref.

There is a simple way to mitigate useAction - use JSON.stringify(actions) as a key for useMemo(only in dev mode).
Another way to fix the problem - do nothing, as long as it's impossible to manually fix each and every library, so the problem should be fixed from the other side

@MrWolfZ : I think I was worried that there might still be a case where an error is caught, the component doesn't re-render, and the user never sees it, but I think that's handled with the catch(e) {}  forceRender() sequence.
Yeah, lemme pull over the error handling changes you made for that POC.

Let's put this on an alpha branch for now.  That way if we have to iterate on this any, we can still put out minor builds from master in the meantime.
I know any alpha docs do have to go in master, and that's okay, since it's versioned.

Well, green means go, right?

A couple quick observations as I work on docs:

useRedux() doesn't allow you to pass a deps array for actions
We probably oughta tweak the error message for useReduxContext() a bit
Do we need that same "didUnsubscribe" check in useSelector() that we have in connect()?
Do we want to make an empty deps array the default for useActions()?  How often would you actually want to recreate those every time?

@markerikson I worked a bit with the hooks on the weekend, and also made an observation. Currently, the selector in useSelector is re-created every time. That means if you use a memoizing selector you need to memoize the selector itself yourself. This could be fixed by also passing a deps array into useSelector.
Now my comments to your observations:

useRedux() doesn't allow you to pass a deps array for actions

Indeed, I completely missed this. It would be easy enough to add this parameter, but if we decide to add deps to useSelector as mentioned above, then things get messy. Do we only use a single deps for useRedux? Or pass in two of them? I think this is an argument for removing this hook after all.

Do we need that same "didUnsubscribe" check in useSelector() that we have in connect()?

I intentionally removed this, since it was only required to ensure the selector never sees inconsistent state and props. Basically, with my implementation it does not matter whether the subscription callback is called after the component was unmounted. The only thing that happens is potentially a forceRender call that does nothing. Also, based on this issue the didUnsubscribe guard doesn't seem to be enough to prevent the callback to be called after unmounting anyways. On the flip side it doesn't hurt to have that check in there and it could give minimal performance improvements by not calling the selector when we know we don't need to. I prefer having a simpler implementation (and not having to write a test for it ;) ), but feel free to add it back in.

Do we want to make an empty deps array the default for useActions()? How often would you actually want to recreate those every time?

I strongly argue to not make an empty deps array the default. Firstly, to be consistent with how useEffect, useMemo, and useCallback work. Secondly, if we were to do this, it might lead to very subtle bugs with stale props inside the actions that are incredibly hard to debug. By leaving the default undefined the worst thing that can happen is slightly worse performance and that can easily be fixed by just adding the deps yourself.

const boundAC = useActions(actionCreator : Function, deps : any[])

const boundACsObject = useActions(actionCreators : Object<string, Function>, deps : any[])

const boundACsArray = useActions(actionCreators : Function[], deps : any[])

Unless there is a compelling reason for both, I think it would be good to drop either the 2nd or 3rd version of useActions. I'd rather have just one way to create multiple actionCreators.
I probably prefer the object one as it is more auto-documenting within the hook. The hooks that use arrays like useState etc. are different because it is for a single thing and the two array elements usually have a single name i.e. [count, setCount]. If also lets users name them easily rather than {state: count, setState: setCount}. You don't have that problem with useActions.

Do we only use a single deps for useRedux? Or pass in two of them? I think this is an argument for removing this hook after all.

Personally I think useRedux isn't very hooksy. Either people will write their action creator and selector logic within the useRedux call and then it's quite verbose, or they will write them outside and then what is actually being usefully added by useRedux? Maybe there are some more advanced scenarios it could cater for if added later but I don't think it should be added if it's just for familiarity with connect as it's just an added layer over the other hooks.

I have created a new PR that adds deps to useSelector. Let's continue any discussion there.

I've opened up #1252 for discussion of the alpha itself. Please offer feedback there.

And just to be clear:  WE'VE GOT AN ALPHA!
https://github.com/reduxjs/react-redux/releases/tag/v7.1.0-alpha.0


Cloud SQL proxy would close all active connections and exits and returns 0

By default 30s,Cloud SQL proxy would close all active connections and exits and returns 0
Is this feature supported in version 1.15 and 1.16?

Hi @dshetty312 - can you clarify what you are looking for?


Allow force-close of LN-DLC channel at any point

See https://github.com/p2pderivatives/rust-dlc/issues/113.

Tibo is currently working on this on our behalf.

@luckysori reckons that we should wait first until Tibo adds new states for rust-dlc, as that work is well underway.


Change repository to non-SSB link

Problem: I'm working on a project that doesn't use Git-SSB and I want to be able to git clone the source code for all of my dependencies.
Solution: Use a non-Git-SSB repository URI. I ran npm init and it resolved the problem(s) in package.json.

On second thought, it looks like maybe the repository link is fine but npm just needs a publish?

Crap, sorry for the noise -- this was supposed to be for pull-looper.


Add automate testing with LXC/LXD

Build a automate testing solution with LXC/LXD.

When config the LXD in Ubuntu 16.04, the $LXD_DIR environment variable will cause the LXD service wait forever. It looks like creating unix.socket not follow $LXD_DIR .


Update GempakToCF to run stand alone

Wrapper should inherit from ReformatGriddedWrapper

It looks like the wrapper should NOT inherit from ReformatGriddedWrapper since RGW uses var list which is not necessary for GempakToCF. You can copy run_at_time() from RGW, put it into GempakToCF wrapper, and remove any mention of var list.

Completed and merged into develop


Fix infinite loop

When running imgur-screenshot -e, shift 2 fails, resulting in an infinite loop trying to parse the -e.

Other flags likely have similar problems, notably -oilaAkd

Ideally I would like to preserve the imgur-screenshot -e functionality that was present until a few versions ago, which necessitates an if or a case statement (preference?) in the true|false cases.
For the non- true|false flags, it doesn't seem like esac||echo&&exit works as expected, instead calling exit on success.

I removed the -e flag and replaced it with -e <true|false> because it didn't allow to easily change to false, if default in your config was true. Supporting the old and new style is inconsistent, which I'd like to avoid.
It would cause trouble when a user tries to upload files called true or false, which may be uncommon but is not impossible.

Sorry for the wrong example, it should have been as follows:
esac || { echo "Failed to parse options" >&2 && exit 1; }

That way the error message is printed before it exits, and only does so when the last command in any of the case statements fails, which is usually shift.


Attr_accessor documentation of @param broke in 436fae5

The changes introduced in 436fae5 messed up the following:
# @param [String] value
# @return [String] The string’s value
attr_accessor :string

as attr_accessor’s reader won’t have a parameter.  This should really be fixed, either by reverting 436fae5 (and erring on the side of not generating spurious warnings) or by adjusting the code in AttributeHandler to first add the parameters before the call to #register, then removing them (which will appease the check and still generate a correct result).
What do you think?

That isn't valid documentation; YARD is correct to warn you here. When documenting an attr_accessor, you should be documenting the getter portion, i.e., only the @return tag. YARD will typically fill in the setter for you, but if you want your own setter documentation, you should use an @overload tag instead:
# @overload string
#   @return [String] the string's value
# @overload string=(value)
#   @param value [String] the value to set
attr_accessor :string

This isn't well documented, unfortunately, so I understand the confusion. Documenting attrs should have their own callout in the guide.

I have some documentation improvements coming in the guide for this.

OK, thanks.  As using @overloads felt a bit verbose, I create the missing @param tag programmatically in my template for attribute writers instead.


Use of Wait class outside a workflow should thrown an exception

To be clear, the test should be that the class is used within a workflow - NOT that it is processed by an agent. So locally executing a workflow is still perfectly fine.
A specific Zenaton error should be thrown and documented.

Update : This is probably not possible, but we can forbid usage of Wait in tasks processed by Agent

I close this as it's no more revant with the v0.7


Can FairMOT directly detect vehicles without training

Hi !
I am a novice in MOT，I have a question?
Can I directly use the original model(FairMOT) to detect the vehicle?

@Ckq-Sugar Of course you can, some scripts to prepare for training data added in this repo compared to FairMOT such as script to convert UA_DETRAC dataset.

@CaptainEven  can you tell me details about modifying the FairMOT ,so that FairMOT can test the vehicle?
thank you very much!

You need to train a new MOT tracker to track vehicles, for details, you can just refer to the readme of this repo. Am i miss-understand you by "original model"(Is it refered to a trained checkpoint file .pth or just use original FairMOT to train a vehicle mot tracker)?

@CaptainEven The original model which I mentioned above is FairMOT 's Pretrained models Baseline model.
so if I  only want detect and track vehicles without thinking accuracy, I can use  FairMOT 's Pretrained models Baseline model?

@Ckq-Sugar I'm afraid not. Because the pre-trained model of FairMOT is just for person MOT tracking.

OK,I do know. thank you!
I also am interested in you reps (MCMOT and FairMOTVehicle)
I am tring to reproduce your MCMOT, I find that I dont download model when run model_down_script.sh.
could you provide other links?
if you provide it ,I will be very grateful！！！

The details of MCMOT training including dataset preparation will be released in the future.


Design and Implementation: Textogram

Ground up implementation of the plot design(We named it Textogram). Will be used in multiple stages to analyze and visualize.

accept my pull request

I dont see any pull requests

try to fix the resolution part

I'll work on it


Subdomains need url variable for site search to work

Site search did not respect the subdomains until I added url back as a variable.
url:       process.env.GITHUB_ACTIONS &&       'https://vickytnz.github.io/xgov-accessibility/',

Hopefully the fix in bc13140 addresses this; seems to work on the documentation site, but will release an update and we can confirm.


Fix: python3 startup script signature

SUMMARY
When nifcloud.py is provided startup_script on python3, signature is incorrect value.
Python3 sample code
>>> startup_script = 'aa'
>>> startup_script.encode('utf-8')
b'aa'
>>> startup_script_bytes = startup_script.encode('utf-8')
>>> startup_script_bytes
b'aa'
>>> user_data = base64.b64encode(startup_script_bytes)
>>> user_data
b'YWE='
>>>
>>> str(user_data)
"b'YWE='"

see:
https://github.com/nifcloud/ansible-role-nifcloud/blob/master/library/nifcloud.py#L207
https://github.com/nifcloud/ansible-role-nifcloud/blob/master/library/nifcloud.py#L129
str(user_data) is string "b'YWE='" on python3. but the correct value is "YWE=".
I fixed it.
RELATED ISSUE
none
HOW TO VERYFY IT
see test

Coverage decreased (-0.4%) to 93.899% when pulling 85b664829af141dd816a9a293cbc6b4acff1d4ad on heriet:fix/python3_startup_script_signature into 86d6267a71e25393c659c5d478231ac28cfb0eec on nifcloud:master.


Using model LLM local for Q&A in PyGwalker Visualization

I need to use PyGwalker locally and don't want to use OpenAI for Q&A. However, I can also run LLM models locally. How can I combine that local model with PyGwalker Q&A?

Related discussion here: https://github.com/Kanaries/pygwalker/issues/454
Besides, if you want to have more customization of AI + data visualization, try graphic-walker, which provides more API for local integration.


would you release your training code?

Please pay attention to the update

Hello , can you share the ultra-high precision model you trained? and training code to to me?my email:
<EMAIL_ADDRESS>thanks!

<EMAIL_ADDRESS>

能分享高精度训练模型和代码到<EMAIL_ADDRESS>吗？谢谢！

Hello , can you share the ultra-high precision model you trained? my email:
<EMAIL_ADDRESS>thanks!

Hello , can you share the ultra-high precision model you trained and training code to to me?
my<EMAIL_ADDRESS>thanks!

Hello , can you share the ultra-high precision model you trained and training code to to me?
my<EMAIL_ADDRESS>thanks!

Hello, thank you for your contributions!
Can you share the ultra-high precision for me
my email<EMAIL_ADDRESS>best

Hello, thank you for your contributions!
Can you share the ultra-high precision for me
my email<EMAIL_ADDRESS>best

Hello, thank you for you great work!
Now, I learn some thing about this,
Can you share the ultra-high precision model to me？
my email<EMAIL_ADDRESS>ple!

<EMAIL_ADDRESS>谢谢！

<EMAIL_ADDRESS>谢谢！


Remove velocities argument from IDT function

Description
Removed velocities argument from idt function since the velocities are not nesessary for the idt algorithm.
Implemented changes

[x] Remove velocities from function header and all code lines checking the value of this argument
[ ] Remove the velocity calculation in the idt test functions

Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

This was implemented in #152 and is needed for #159 to work properly.
I know this solution was not 100% optimal but the easiest one to implement for now.
Please create an issue to discuss how we can do this in the future.

Or maybe it's better that I reopen this again, we can have the discussion here too.

Ahh okay, thanks for the update. I missed this. I was just starting to do an example for idt and tought I initialy just copy/pasted the function header from ivt with the additional argument.

No problem, it is actually a good idea to improve on this, and I already feared a bit that this will create usability issues.
But to fix the issue, we would now also need a more clever way of passing the arguments in this line:
https://github.com/aeye-lab/pymovements/blob/c833d5a74b6b3ee9e050db7619d6507cfecf2015/src/pymovements/datasets/dataset.py#L430
You could try to check the actual expected keyword arguments of the passed function via inspect.getargspec()
Moreover, I have defined an EventDetectionCallable protocol here:
https://github.com/aeye-lab/pymovements/blob/c833d5a74b6b3ee9e050db7619d6507cfecf2015/src/pymovements/events/events.py#L32-L56
If this protocol seems unpractical we can either get rid of it again or create two more protocols for velocity and position only detection methods.

As this PR is now very behind the current main I created an separate issue for the broader case and close this PR


feat: sparse config

Summary
Adding a new flag called --sparse-config. Mostly used in a monorepo.
Assuming monorepo file structure as follow:
-- monorepo
 |- packages
     |- foo
        |- .lintstagedrc.json
     |- bar
        |- .lintstagedrc.json

if git stage files are

packages/foo/index.js
packages/foo/lib.js
packages/bar/utils.js

With --sparse-config, packages/foo/index.js and packages/foo/lib.js uses config file at packages/foo/.lintstagedrc.json. while packages/bar/utils.js uses config file at packages/bar/.lintstagedrc.json
If no lint-staged config can be loaded from staged file, nothing happens.
Outputs like
        LOG [STARTED] Preparing...
        LOG [SUCCESS] Preparing...
        LOG [STARTED] Running tasks...
        LOG [STARTED] Running tasks for *.js under package/a
        LOG [STARTED] echo \\"package A\\"
        LOG [SUCCESS] echo \\"package A\\"
        LOG [SUCCESS] Running tasks for *.js under package/a
        LOG [SUCCESS] Running tasks...
        LOG [STARTED] Running tasks...
        LOG [STARTED] Running tasks for *.js under package/b
        LOG [STARTED] echo \\"package B\\"
        LOG [SUCCESS] echo \\"package B\\"
        LOG [SUCCESS] Running tasks for *.js under package/b
        LOG [SUCCESS] Running tasks...
        LOG [STARTED] Applying modifications...
        LOG [SUCCESS] Applying modifications...
        LOG [STARTED] Cleaning up...
        LOG [SUCCESS] Cleaning up..."

How is tested
Add test cases and tested in a local repo.

This is great! Setting up lint-staged in monorepos is a pita now. Could you also please update the readme.md and update the monorepo section there?

@chengcyber could you please check out the failing test?

Very nice! Definitely add a full integration test in test/integration.spec.js.
One thing I'm wondering is if it would be nicer to have an explicit config syntax, for example:
lint-staged --workspace packages/a --workspace packages/b --workspace packes/subdir/*

What do you think @chengcyber and @okonet? I guess this current solution is easier for the user, if it auto-discovers all lint-staged config files in subdirectories. Is it slow in very large repositories?

@okonet @iiroj
Changes applied:

Fix test in windows
Add a intergration test case for sparseConfig

lint-staged --workspace packages/a --workspace packages/b --workspace packages/subdir/*

--workspace can not guide lint-staged which config file should be used for a specified file. This leads to make multi config file list kinda meaningless.

The README.md should be updated here:
https://github.com/okonet/lint-staged/blob/a230b0350885194e5f07be667312316ad869b7fc/README.md#L70
and probably also here:
https://github.com/okonet/lint-staged/blob/a230b0350885194e5f07be667312316ad869b7fc/README.md#L163
https://github.com/okonet/lint-staged/blob/a230b0350885194e5f07be667312316ad869b7fc/README.md#L642

@iiroj Thanks you for such many valuable suggestions! Will check them when i reach my laptop.

Changes applied:

Update readme
New function loadConfigAndValidateWithCache, refactor load config logic
Impove await in for loop into Promise.all
Warn multiple config in no sparse config mode
Fixes test cases, back to 100% coverage

@iiroj Could you kindly take another look~

After reading the code for a while I had a few thoughts:

Do we really need to resolve configs via files? I believe the only practical use case is a monorepo where the structure of packages is known upfront. What do you think of making if a configuration first rather than discoverable in run-time? This will also allow currently not supported case of configs in the package.json or even a single nested config. WYT?

What do you think of making this feature a default behavior instead of putting it under a flag? I think the benefits of it are huge and can be utilized by all our users, esp. the ones with monorepos. I'm not sure why we should require them to learn about this feature by reading the docs instead of "just doing the right thing". Thoughts?

@okonet yes, this feature is basically the same as eg. ESLint uses, it auto-discovers the nearest configuration file for every individual file. Maybe it doesn't need a flag.
I think it's pretty elegant in the sense that we typically have only relatively few staged files, so it makes sense to discover individual config files for those. I believe ESLint also does this; for every linted file it finds the "flattened config array":
see: https://github.com/eslint/eslintrc/blob/0187c0459d31b13b2d647ef22d24b115381f90a3/lib/cascading-config-array-factory.js#L285

Do we really need to resolve configs via files?

Yes

What do you think of making if a configuration first rather than discoverable in run-time? Maybe something similar to workspaces?

I am one of contributors in microsoft/rushstack. A very critial philosophy in rushstack is avoiding top-level node_modules to eliminate the phantom depdencies issues.
So i prefer settle down lint-staged config under individual packages rather than top-level big configuration.

What do you think of making this feature a default behavior instead of putting it under a flag?
I'm not sure why we should require them to learn about this feature by reading the docs

Orignially, the idea to create a feature behind the --sparse-config is to prevent breaking changes to current user. So the logic about load sparse config files is totally inside a if statement. Normally, it helps to speed up release progress :)
And, thank for your(@okonet, @iiroj) quick reply! I believe we can fine-tune this PR before merging to carefully design a default behaviour.
Technically, the answer must be "YES", and the main concern would be like It might be a breaking change. Is it acceptable to involve a breaking change, If so, i am willing to do a further step to remove --sparse-config!

nested config?
Should we also merge all the nested config files?

Merging configuration is a VERY error-prone feature. We need answer serval questions before providing it.

Another CLI for debugging should be provided to display which config files are involved. For example:

lint-stage show-configs --file packages/a/index.js

Expected ouputs:
.lintstagerc.json <- ... <- packages/a/package.json
{
  "*.js": "prettier"
}

The scope of nest config

monorepo
  |- .lintstagedrc.json
  |- a/
      |- .lintstagedrc.json
      |- b/
          |- .lintstagedrc.json
          |- c/
             |- .lintstagedrc.json
             |- index.js

In this case, which config files should be merged? "root" and nearest or all .lintstagedrc.json files? Idk

A config to specify stop search parent folder should be provided, Like root in eslint config

Performance hurt

Normally, in a monorepo, i am 100% carefully to setup eslint configs. because its auto discoverable logic can hurt performance a lot. Because config is loaded for each stage file individually, loading config costing can be a hot path now.
In summary, i prefer to leave lint-staged config not mergeable for now, but i am open to provide a merging config feature if it's well designed.

We can always extend using JS-config, we purposefully made the config format simpler in the past.

Currently the task log looks something like this:
❯ Running tasks...
  ↓ No staged files match *.js [SKIPPED]
  ❯ Running tasks for *.{json,md}
    ⠧ prettier --write

How about we make it look something like this instead (with bold or something instead of the backticks):
❯ Running tasks...
  ❯in `./`
    ↓ `*.js` — no matching files [SKIPPED]
    ❯ `*.{json,md}` — 1 file
      ⠧ prettier --write
  ❯ in `./packages/a`
    ❯ `*.{json,md}` — 3 files
      ⠧ prettier --write

Currently the task log looks something like this:
❯ Running tasks...
  ↓ No staged files match *.js [SKIPPED]
  ❯ Running tasks for *.{json,md}
    ⠧ prettier --write

How about we make it look something like this instead (with bold or something instead of the backticks):
❯ Running tasks...
  ❯in `./`
    ↓ `*.js` — no matching files [SKIPPED]
    ❯ `*.{json,md}` — 1 file
      ⠧ prettier --write
  ❯ in `./packages/a`
    ❯ `*.{json,md}` — 3 files
      ⠧ prettier --write

Happy new year to you! I have been bit of lost to the scope of this PR. Could you help me to make it clear about the next step on code changes before merging?

Happy new year to you! I have been bit of lost to the scope of this PR. Could you help me to make it clear about the next step on code changes before merging?

I don't think we need the flag, lets make this the default behavior. I also don't think it needs to be a breaking change because running multiple lint-staged hasn't been supported so far.
I'll look over this and clean it up a bit next week.
Great work!

I don't think we need the flag, lets make this the default behavior. I also don't think it needs to be a breaking change because running multiple lint-staged hasn't been supported so far.
I'll look over this and clean it up a bit next week.
Great work!

Happy new year, everyone!
I agree that we should make this a default behavior. I also don't see a reason for a breaking change so we're good with a feature release.
I really like the suggestion @iiroj made about how we could print tasks progress to make it clear which config is applied.
Again, great work @chengcyber and thanks for moving this forward. I think that working with monorepos is the biggest pain point at the moment so huge thumbs up 👍 from my side.

Happy new year, everyone!
I agree that we should make this a default behavior. I also don't see a reason for a breaking change so we're good with a feature release.
I really like the suggestion @iiroj made about how we could print tasks progress to make it clear which config is applied.
Again, great work @chengcyber and thanks for moving this forward. I think that working with monorepos is the biggest pain point at the moment so huge thumbs up 👍 from my side.

@okonet  and @chengcyber: I took a stab at creating a general solution for supporting multiple config files and it turned out pretty nice and simple. I'll open a new PR tomorrow, so thanks again @chengcyber for the initial implementation and inspiration!


Documentation menu changes depending on the active site

The Getting started item seems to be gone when the user is on the Wrapper page.

Seems to be a caching issue


Update ui-router legacy import

Hey guys!
It came to my attention (way back, actually) that the import done on the generator/component/temp.js file, which serve as scaffold to generate new components, is using a outdated module name.

Refer to this: angular-ui/ui-router/CHANGELOG.md

For the sake of keeping the project updated, changing it from:
import uiRouter from 'angular-ui-router';

to
import uiRouter from '@uirouter/angularjs';

would be right.
The reason I'm opening a issue for it, instead of a PR, is to discuss the impact of this change before going for it.

Hey @bernardocs I am using ui.router version 1.0.8 in a large scale application ( more than 100K LOC ) and from my experience I can say that latest ui.router is very powerful but documentation is bit weak. Other than that it's wise decision to update the project to use latest version of ui.router


unpredictable OCR

Environment

Tesseract Version:  4.0.0-beta.1 leptonica-1.75.3  libgif 5.1.4 : libjpeg 8d (libjpeg-turbo 1.5.2) : libpng 1.6.34 : libtiff 4.0.9 : zlib 1.2.11 : libwebp 0.6.1 : libopenjp2 2.3.0
Platform: Ubuntu 18.04/Python 2.3/Opencv2 3.4.0

Current Behavior:
I am using two different text detection algorithms. They detect the text location with only a small difference of one pixel.  Attached you will find the original image sign.jpg and the 2 cropped pictures  based on the 2 different text detection algorithms. The coordinates of the text box is described in the filename. Before applying the OCR I downscale the cropped image from 80 pixels high to 25 pixels high cv2.resize and proportionally scale the length. However tesseract detects for crop_sign_x1=125_y1=106_x2=318_y2=186.png "Ten" while for the other file crop_sign_x1=124_y1=107_ x2=317_y2=185.png it detects the correct text "ALTO". Pictures are available at the following link and are also attached
in python I execute the following code:

config = ("-l eng --oem 3 --psm 6")
ocr_text = pytesseract.image_to_string('crop_sign_x1=125_y1=106_x2=318_y2=186.png', config=config)
print ocr_text
u'Ten'
ocr_text = pytesseract.image_to_string('crop_sign_x1=124_y1=107_ x2=317_y2=185.png', config=config)
print ocr_text
u'ALTO'

https://drive.google.com/drive/folders/1XenYjZ05zsSrQPvnfhsSynxp0uoZpOHs?usp=sharing

Expected Behavior:
tesseract should return for both images the correct text "ALTO".
Suggested Fix:
for both pictures tesseract should return the correct text "ALTO"

I get "ALTO" for both images by using an older revision of the tessdata repo.
https://tesseract-ocr.github.io/tessdoc/Data-Files.html#data-files-for-version-400-november-29-2016

Thx.  Are you saying I should be be using LSTM instead of EAST oem=0?
Can you please provide a link to instructions on how to install eng.traineddata for tessreact 4.0.0 Beta?
Thx

What you are using currently is eng.traineddata from the tessdata_fast repo.
With eng.traineddata from the older revision of the tessdata repo, you can use --oem 3, but oem 0, 1, 2 also outputs "ALTO" for the two images.
With eng.traineddata from the current revision of the tessdata repo, only --oem 0 outputs "ALTO" for the two images.
This is my observation. I don't know if changing the traineddata will work better than your current traineddata with other images.
Please use the forum to ask about installing another traineddata on your system.

Thx. I replaced eng.traineddata and indeed I got the same results


Migrate to the ixdtf crate for datetime parsing

Right now the ixdtf crate is just a placeholder, but @nekevss migrated the parser to the ICU4X repo on https://github.com/unicode-org/icu4x/pull/4646. We should migrate to that when the next version of ixdtf releases.

Unblocked since<EMAIL_ADDRESS>has been published :)

@nekevss are you planning to work on this?

@nekevss are you planning to work on this?

Yeah, I'll migrate us over.
I don't think I had realized it was part of the most recent release and unicode-org/icu4x#4918 is still up for review :sweat_smile: The core API shouldn't change though to much, so it should be fine to implement.


Drop support for Python 3.4

Python 3.4 has reached end-of-life on 2019-03-08 and has largely been phased out by now.
I also do not publish binary distributions for 3.4, nor do I run unit tests, so support for it is already quite spotty.
Remove any compatibility backports that were added to fix #14 #15 #16
@Muffo any concerns? You had originally opened #14 and #15.

No problem from my side. I am not actively using the project at the moment, but thanks for asking.


Can't reinstall react-native-video on android (no variant found for :react-native-video

Bug

Platform

Which player are you experiencing the problem on:

Android

Environment info

React native info output:
 System:
    OS: macOS 12.5
    CPU: (10) arm64 Apple M1 Max
    Memory: 3.04 GB / 64.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.6.0 - /opt/homebrew/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 8.18.0 - /opt/homebrew/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
    Android SDK: Not Found
  IDEs:
    Android Studio: 2021.1 AI-211.7628.21.2111.8309675
    Xcode: 13.4/13F17a - /usr/bin/xcodebuild
  Languages:
    Java: 18.0.1 - /opt/homebrew/opt/openjdk/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.2 => 17.0.2
    react-native: 0.68.1 => 0.68.1
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Library version: 5.2.0
Steps To Reproduce

Have issue with react-native-video after gradle clean (no variant found for :react-native-video)
uninstall / invalidate cache / delete node_modules/yarn.lock
reinstall
issue persists (app builds and syncs without react-native-video. Fails with it included
...

Expected behaviour

Successful Gradle sync/build

Reproducible sample code

I'm not sure what else will be helpful, but I will provide anything I can to help. I'm not exactly sure what the issue is. Every other package installed fine after the clean except for react-native-video. I'm unsure of where the problem originated or how to fix it. Thanks!

can you send a log of the output ?
which version version of react-native-video do you install ?

Hello, I have the same issue, on react-native-video 5.2.0.
These are the logs:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:checkDebugAarMetadata'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not find com.google.android.exoplayer:exoplayer:2.13.2.
     Searched in the following locations:
       - file:/Users/olivier.freyssinet/.m2/repository/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
       - file:/Users/olivier.freyssinet/Workspace/ledger-live/apps/ledger-live-mobile/node_modules/react-native/android/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
       - https://repo.maven.apache.org/maven2/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
       - https://dl.google.com/dl/android/maven2/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
       - https://jitpack.io/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
       - file:/Users/olivier.freyssinet/Workspace/ledger-live/apps/ledger-live-mobile/node_modules/detox/Detox-android/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
       - file:/Users/olivier.freyssinet/Workspace/ledger-live/apps/ledger-live-mobile/node_modules/expo-camera/android/maven/com/google/android/exoplayer/exoplayer/2.13.2/exoplayer-2.13.2.pom
     Required by:
         project :app > project :react-native-video
   > Could not find com.google.android.exoplayer:extension-okhttp:2.13.2.
     Searched in the following locations:
       - file:/Users/olivier.freyssinet/.m2/repository/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
       - file:/Users/olivier.freyssinet/Workspace/ledger-live/apps/ledger-live-mobile/node_modules/react-native/android/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
       - https://repo.maven.apache.org/maven2/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
       - https://dl.google.com/dl/android/maven2/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
       - https://jitpack.io/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
       - file:/Users/olivier.freyssinet/Workspace/ledger-live/apps/ledger-live-mobile/node_modules/detox/Detox-android/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
       - file:/Users/olivier.freyssinet/Workspace/ledger-live/apps/ledger-live-mobile/node_modules/expo-camera/android/maven/com/google/android/exoplayer/extension-okhttp/2.13.2/extension-okhttp-2.13.2.pom
     Required by:
         project :app > project :react-native-video

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 16s

    at makeError (/Users/olivier.freyssinet/Workspace/ledger-live/node_modules/.pnpm/execa@1.0.0/node_modules/execa/index.js:174:9)
    at /Users/olivier.freyssinet/Workspace/ledger-live/node_modules/.pnpm/execa@1.0.0/node_modules/execa/index.js:278:16
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async runOnAllDevices (/Users/olivier.freyssinet/Workspace/ledger-live/node_modules/.pnpm/@react-native-community+cli-platform-android@7.0.1/node_modules/@react-native-community/cli-platform-android/build/commands/runAndroid/runOnAllDevices.js:109:5)
    at async Command.handleAction (/Users/olivier.freyssinet/Workspace/ledger-live/node_modules/.pnpm/@react-native-community+cli@7.0.4_oxdc6pm5g5rdvpaycf2kzdj6te/node_modules/@react-native-community/cli/build/index.js:192:9)

This is the same issue as https://github.com/react-native-video/react-native-video/issues/2611.
In the meantime I have this in android/build.gradle:
allprojects {
    /* (...) */
    configurations.all {
        resolutionStrategy {
            /**
             * the following exoplayer config is for react-native-video
             * cf:
             *  https://github.com/react-native-video/react-native-video/issues/2611
             *  https://github.com/react-native-video/react-native-video/issues/2821
             *
             */
            force 'com.google.android.exoplayer:exoplayer:2.13.3'
            force 'com.google.android.exoplayer:extension-okhttp:2.13.3'
        }
    }
}

release 5.2.1 should fix this issue, let me  know if it is ok ?


Prepare monitor exporter release 1.0.0b16

API change check
API changes are not detected in this pull request.


Profile stats reorder

based on community feedback, let's reorder the stats in the profile

lets put max sold price under listed, and the highest buy/amount spent under number of buys

👋


node_modules checked in?

Why is node_modules checked into the repo?

@jeffreyhawkins because of how GitHub Actions works, you're required to check in node_modules unless you're doing a bundling step.

@bnb it's probably wise to use ncc to bundle as outlined in the GifHub Action documentation. Including the node_modules is a red flag for our organization for the simple fact we've seen binaries in the node_modules from various dependencies.


Updating  GraalVM to 23-ea doesn't pull the necessary EA version

The job https://github.com/olyagpl/langchain4j-searchbot/actions/runs/9479855945/job/26119305292?pr=2 pulled Oracle GraalVM 23-dev+23.1 instead of JDK 23 EA BUILD 13 introduced in https://github.com/graalvm/oracle-graalvm-ea-builds/commit/42ac13ece6ced5072ab199f7007e97ff8f8e1abd.

EA build 13 is 23-dev+23.1 so you did get the right version. I know it's a bit confusing, hopefully we can clean this up soon.


ServeStaticModule serves non-existing paths

I'm submitting a...
[ ] Regression
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior
When using the @nestjs/serve-static module, the server serves any path and does not return a 404 error even if the requested resource does not exist.
Project folder structure
.
├── client
│   └── index.hml
├── src
│   ├── app.module.ts

Input Code
// src\app.module.ts
import { ServeStaticModule } from '@nestjs/serve-static';
import { join } from 'path';

imports: [
  ServeStaticModule.forRoot({ rootPath: join(process.cwd(), 'client') })
],

Testing
Request an existing resource
GET / HTTP/1.1
Host: localhost:3000

Response
HTTP/1.1 200 OK

Request a nonexistent resource
GET /foo HTTP/1.1
Host: localhost:3000

Response
HTTP/1.1 200 OK

Expected behavior
Request a nonexistent resource
GET /foo HTTP/1.1
Host: localhost:3000

Response
HTTP/1.1 404 Not Found

Minimal reproduction of the problem with instructions

nest new testcase
npm install --save @nestjs/serve-static
Import ServeStaticModule.forRoot({ rootPath: join(process.cwd(), 'client') }) in app.module.ts
Create folder testcase/client
Create index file index.html under the testcase/client
npm run start
Make request at curl --location --request GET 'localhost:3000/foo'
Got response HTTP/1.1 200 OK but expected HTTP/1.1 404 Not Found

What is the motivation / use case for changing the behavior?
In general, "serve-static" should follow the usual logic while serving files. If requested resource does not exists, an error is returned. Or in documentation should have a place where described this behavior and provided some instruction for handling that situations.
Environment
Nest version: 7.2.0

For Tooling issues:
- Node version: v12.16.3
- Platform: Windows

Others:

We're tracking this here https://github.com/nestjs/docs.nestjs.com/issues/1153

@kamilmysliwiec Since you referenced that issue here, there's been no activity on that issue other than it getting closed 5 months later.

@kamilmysliwiec Since you referenced that issue here, there's been no activity on that issue other than it getting closed 5 months later.


update minikube version

fix #1403
Note: DefectDojo is now on Python3 and Django 2.2.1 Please submit your pull requests to the 'dev' branch as the 'legacy-python2.7' branch is only for bug fixes. Any new features submitted to the legacy branch will be ignored and closed.
When submitting a pull request, please make sure you have completed the following checklist:

[x] Your code is flake8 compliant
[ ] If this is a new feature and not a bug fix, you've included the proper documentation in the ReadTheDocs documentation folder. https://github.com/DefectDojo/Documentation/tree/master/docs or provide feature documentation in the PR.
[ ] Model changes must include the necessary migrations in the dojo/dd_migrations folder.
[ ] Add applicable tests to the unit tests.

on updating version, it passes all test on my DD repo travis but fails to launch again in some of the tests don't know why.

@dr3dd I'm going to close and reopen this to wake Travis again. Want to ensure these tests passed because of your changes and not luck.

yeah, but if it is working correctly sometime and sometime not then maybe it is an issue in minikube not in our programme. I saw some issue on minkube like this and it is related to some sort of network problem maybe don't know but will figure it out.

btw, you can restart the Travis build without closing it there is functionality for that.

@dr3dd589 That's the point of testing twice :)
Whats the secret of restarting without open/close?

you can go to Travis build page and the right upper corner there is an option to restart or rebuild the test. without closing the PR.

All I have in that little drop down is "requests". Maybe I don't have permission to restart some one else's  build?

that's strange I can restart and rebuild any of the PR again.

like just one did for https://github.com/DefectDojo/django-DefectDojo/pull/1405

you are right it's failing again in PostgreSQL test.

Looks you're my guy with the connections then.
Postgres tests failed on this build. Looks like it is an issue on their end like you said. I guess we can wait it out and just monitor incoming PR's and rerun until they pass

we can create an issue on their repo about this?

I have not seen any minikube issues in the last few days. Think it's fixed? Should we upgrade anyway?

yeah, I don't think so. we can close this one. We can do this in future if there is any problem.


VS Code won't open with Linux Kernel 5.2.4

VSCode Version: 2213894e (from Ubuntu store)
OS Version: Ubuntu 19.04

Steps to Reproduce:

Run "code" in the command line
Output is...

/snap/code/11/electron-launch: line 28: /snap/code/11/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: No such file or directory
/snap/code/11/usr/share/code/bin/code: line 44: /snap/code/11/usr/share/code/bin/../code: No such file or directory

Does this issue occur when all extensions are disabled?: Yes

Can you try downloading the Linux zip and see whether that runs?
http://update.code.visualstudio.com/latest/linux-x64/stable

@joaomoreno this happened to me with the snap as well. The tarball runs fine.

I just reverted back to Linux 5.1.21, but I would like to able to update when my programs will run. Perhaps this isn't a Code issue. Spotify, Code, and Telegram all would not start.

I am using manjaro and my kernel is 5.2.4-1-MANJARO.
my vscode installed from https://www.archlinux.org/packages/community/x86_64/code/
no problem at all. smooth as usual.

Spotify, Code, and Telegram all would not start.

Then it's snap related.