Add links to issues and pull requests next to repo title

When working in organization with multiple repos... the org home page lists all the repos. clicking on the repo name will take to code and then we click on issues / pull requests. Being a maintainer, most of the times I work on issues / prs. It would be very handy if I can directly go on the repo's issues / prs page from the organization home page.
One way to do is to have links to /issues and /pull requests next to the repo name itself.

Let me know your comments and suggestions. Would be happy to do a pr 😄

Looks a big cluttered. If this is added, it should probably be just the PR and Issue icons on the third line, not large text next to the title

@bfred-it Adding icons is a good idea, just wondering if we can add them next to the title 🤔

There is a user script with similar functionality for issues.

That sounds great, did a small mockup!

Bugs Icon should list the issues count and clicking it should take to issues page
PR Icon should list the open pr count and clicking it should take to pull requests page.

That’s a misiconer (misnomer), not all issues are bugs. It’s best to use the regular icon.
For the counts you need API calls, one per repo, unless someone adds the API key to the options and uses the GraphQL API

@bfred-it

Sure, what would be the regular icon for issues ?
Others usage may vary but I usually don't depend on the count of issues or pr, am happy with just the link.

Sure, what would be the regular icon for issues

https://octicons.github.com/icon/issue-opened/

Thanks for the link @hkdobrev.
Here is the latest mockup!

Can you try sending a PR?

@bfred-it on it 👍

Make sure to also send this feature request to GitHub<EMAIL_ADDRESS>

Has this been addressed or is it still outstanding? I would also like to see this (and having the counts included would be glorious as well!, but direct links would also be better than current).

It will look very congested when more details are present. e.g.

I've prepared a small adhoc change to display issues and PR. I've kept the look and feel same as displayed in the navbar. How about this?

OMG I love it.

What do you think about it? @bfred-it

Honestly I think we can just replace that X issues need help and display it there instead. It's not a very useful copy now that everyone uses the label as "up for grabs" rather than "we actually need someone who knows more than us to fix it".

Hello - has this not been done by GitHub?

I'm not seeing it on profiles: https://github.com/sindresorhus?tab=repositories&type=source
Only on organizations: https://github.com/h5bp?type=source
Maybe soon!

Ah yes you're right, I thought we were talking about orgs only here.


Guzzle Http is abandoned.

guzzle/guzzle 5 is not a valid package.

It's guzzlehttp/guzzle not guzzle/guzzle, I added it in my PR #310 as well.


Ana not supported.

I no longer play Overwatch nor maintain this library so for the foreseeable future anyone who plays Ana will no longer be processed by the API.

Switched from static typing over to dictionaries only so the API should remain functional regardless of any updates or changes Blizzard make.


Using a css style on html element

Challenge Name

https://www.freecodecamp.com/challenges/use-a-css-class-to-style-an-element
Issue Description

Browser Information

Browser Name, Version: chrome 53.0.2785.124
Operating System: android 5.0
Mobile, Desktop, or Tablet: mobile

Your Code

Screenshot

Visit help section first before creating a new issue.

ITS PRETTY SIMPLE !!

CatPhotoApp
Kitty ipsum dolor sit amet, shed everywhere shed everywhere stretching attack your ankles chase the red dot, hairball run catnip eat the grass sniff.

@eirholvhan428
Thank you for reporting this issue.
This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the "Help" button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our full list of official chatrooms.
If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.


Fix Windows symlink EPERM error

Based on work by @josenicomaia in https://github.com/prisma/serverless-plugin-typescript/pull/24, @EugeneDraitsev in https://github.com/prisma/serverless-plugin-typescript/pull/100, and discussion in https://github.com/prisma/serverless-plugin-typescript/pull/103 this should resolve the EPERM issue when packaging on Windows.
I've tested this by spinning up a Windows 10 Pro VM and running serverless package with the code in example/ (adding/removing includes as well). It runs successfully while correctly copying the node_modules folder and package.json files. Mac and Linux should still work as normal with symlinked directories, tested on Arch Linux.
Also includes an update to the build script to use rimraf as rm -rf is not available on Windows, this should help Windows devs contribute future fixes/features.
It would be great to get someone else to pull this down and give it a go :smile:

LGTM, if someone involved in this issue can also confirm that this fixes related issues for them, I am happy to merge this.

@divyenduz I can confirm that @EugeneDraitsev fixed the symlink issue for me.  I combined @GhostfromTexas third parameter fix into my personal fork for good measure.
As stated before, while this resolved symlink issues, on my other machine and my colleague's machine, we were still running into a scandir issue after utilizing this fix, which is a separate issue and was resolved by installing the scandir library globally with npm install scandir -g -- so the error was very misleading and shouldn't be confused with the symlink issue.

@JackCuthbert : Do you want to address the issue about scandir in @maplion's comment before I merge this or after? I am fine with both as this PR already provides some value :)

@divyenduz I couldn't repro the scandir issue in my Win10 VM that @maplion was encountering :( Installing it globally made no difference both before and after this fix was applied. I did encounter the EPERM issue before applying the fix though, so I feel that this definitely solves another part of the problem.
Perhaps we can get some more info about why scandir is erroring? Is it definitely related to using this plugin under Windows?

@JackCuthbert Yes, it is definitely related to using the plugin under Windows, but there is some additional variable on our enterprise machines that makes it not work when my home computer worked after the symlink fix alone.  I tested anti-virus, permissions (running as admin), and other possible culprits and nothing worked until a colleague found a Reddit post talking about scandir in an unrelated topic with a similar error and needing to install it globally.  The only thing I can think of that might be different still is something to do with the Windows profile.

@divyenduz I'm happy to merge this one as it solves the symlink issue and we can close out a bunch of other issues/PRs. By the sound of it the scandir issue may not isolated to this plugin only if a similar error is happening in an unrelated context. Could you open a more specific issue for this @maplion?

@JackCuthbert When I get a moment, sure.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Files included that should be ignored

Hi there!
When using this plugin, it appears nested files that should be ignored by glob "not patterns" are still included.
Example app structure:
/src/app.js
/src/app.test.js
/src/route/example.js
/src/route/example.test.js

Example build script:
const { build } = require("esbuild");
const { globPlugin } = require("esbuild-plugin-glob");

build({
	entryPoints: ["src/**/!(*.test).js"],
	format: "cjs",
	minify: true,
	outdir: "dist",
	platform: "node",
	plugins: [globPlugin()],
	target: "node14",
}).catch(() => process.exit(1));

When executing the above build script, it creates the following outdir structure:
/dist/app.js
/dist/route/example.js
/dist/route/example.test.js

The top level .test.js file is excluded but not the nested .test.js file.
Potential cause
From playing around with glob modules in an attempt to diagnose this, it seems that tiny-glob is the issue.
The following example, using the glob dependency, will remove all JS files besides test files (as expected):
const glob = require("glob");
const files = glob.sync("dist/**/!(*.test).js");
await Promise.all(files.map((file) => fs.unlink(file)));

The following, using tiny-glob, removes every JS file apart from a top level test file, instead of only removing test files:
const glob = require("tiny-glob");
const files = await glob("dist/**/!(*.test).js");
await Promise.all(files.map((file) => fs.unlink(file)));

Hey @Fdawgs,
Thanks for this well-researched issue! I'll look into switching to glob instead of tiny-glob today. Seems like not to big of change to solve this issue.

I've created a pr for this change and added tests based on your example. I haven't been able to replicate the issue though. Would you be able to take a look to see if I missed anything? I know the tests are a bit complex, let me know if you need more information about what's going on there.

Great @waspeer, thanks!
I'm on holiday atm but should be able to test when back on 17th.

Oh wait, I'm just now seeing that this test failed in the matrix tests on node 16 on windows. Is that by any chance what you're rocking? I'm on node 16 on mac atm. Platform differences might be the cause of this issue.

Oh wait, I'm just now seeing that this test failed in the matrix tests on node 16 on windows. Is that by any chance what you're rocking? I'm on node 16 on mac atm. Platform differences might be the cause of this issue.

Yeah, sorry forgot to state platform in original issue.
Node 16.17.1 on Windows 10.

Should be fixed in the new version!

Works a treat, thanks!


General question about bazel

System information

OS Platform and Distribution (e.g., Linux Ubuntu 18.04): 18.04
Apollo installed from (source or binary):
Apollo version (3.5, 5.0, 5.5, 6.0): 6.0, 5.0
Output of apollo.sh config if on master branch:

Steps to reproduce the issue:
I have installed both apollo-6.0 and apollo-5.0 in my computer. However I notice that only in apollo-5.0 those bazel documents exist. Will that influence the functionality of apollo-6.0? And should I do something to fix this?
Supporting materials (screenshots, command lines, code/script snippets):

As a general user, you should do nothing with Bazel.
Thank you.


REDSHIFT_IN_TRAILING_MAINTENANCE_TRACK

Please review the gherkin and let me know for any changes.
REDSHIFT_IN_TRAILING_MAINTENANCE_TRACK.txt
We will be using the "describe-clusters" call with the filter  "--cluster-identifier" to get the Maintenance trackname of each of the cluster.
Link for the API call : https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-clusters.html

Please post the Gherkin directly. Not as a file.
Please double confirm that this rule doesn't cover what we want: https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-maintenancesettings-check.html

Any update on that?


Initial Release

This is set to be our initial release of rytest.  I've done the following ahead of it:

Bumped the version to 0.1.0.  Yay!
Switched our release system to just use maturin's auto-generated GHA.
Added a document to record how to do a release, so we don't forget.

This should be everything that's needed, but we'll see.  :)

Closed in favor of #40


"Plugin not selected"

it keeps alerting me with "plugin not selected" also if i created and repeatedly clicked over a new (created with the builder) plugin

This should have been fixed in v1.0.2?

i just installed the plugin by "settings" tab.. i just noticed it's only 1.0.1

I confirm it's fixed in 1.0.2,
the backend installs the old version, then is necessary to launch the "upgrade plugin" to get the last one..
i close the issue


interface ModelOptions should have optional property old

According to https://vincit.github.io/objection.js/#modeloptions old object should be an optional attribute of ModelOptions. Happy to open a PR to add old?: any; to the ModelOptions interface.

Sure, I'd merge it :+1:


Update sbt-scalajs, scalajs-compiler, ... to 1.10.0

Updates

org.scala-js:sbt-scalajs
org.scala-js:scalajs-compiler
org.scala-js:scalajs-library
org.scala-js:scalajs-library_2.13
org.scala-js:scalajs-test-bridge
org.scala-js:scalajs-test-bridge_2.13
org.scala-js:scalajs-test-interface
org.scala-js:scalajs-test-interface_2.13

from 1.7.1 to 1.10.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-js" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

needs adjustment:
[error] /home/runner/work/nanotest-strawman/nanotest-strawman/js/src/main/scala/verify/platform/package.scala:25:68: The global execution context in Scala.js is based on JS Promises (microtasks).
(https://github.com/scala/nanotest-strawman/runs/5825351635?check_suite_focus=true#step:5:813)


Fix sonar code smells

Closes #69

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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 97.262%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
746

Relevant Lines:
767

💛  - Coveralls


[BUG] Data Card Encoder can write data to a stack of data cards at once

Description:
Data Card Encoder can write data to a stack of data cards at once, which is terribly unbalanced.
Steps to Reproduce:

Put a stack of data cards in the encoder.
Fill it with some ores and modifiers.
Click write and receive a whole stack of data cards.
???
Profit

Technical Information:

Minecraft: 1.18.2
Fabric API: 0.55.1
Industrial Revolution: 1.14.0-BETA
Modpack: -

Logs:
Not relevant.
Screenshots:

And the MIning Rig is able to use a whole stack of cards at once too (meaning card "usage" is written to all cards simultaneously, rather than one by one).

this becomes a huge exploit when writing to 64 cards at once and mining them one-by-one


Can't rearrange requests

Expected Behavior
User can drag and drop requests in custom order or sort by using the button at the top
Actual Behavior
Drag and drop doesn't work and sort does not as well
Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2023.5.5
What operating system are you using?
macOS
Operating System Version
MacOS Ventura 13.4.1
Installation method
download from insomnia.rest
Last Known Working Insomnia version
No response

Duplicate of https://github.com/Kong/insomnia/issues/6284


gpu-screen-recorder{,-gtk}: Update to unstable-2024-07-05 (+ systemd unit and capabilities)

Description of changes
Non-NixOS related changes can be found here. Relevant changes start from 2024-05-21 for gpu-screen-recorder and from 3.7.6 for gpu-screen-recorder-gtk.
NixOS-specific changes include the following:

Switch from the script-based build system to meson
Install the upstream-provided systemd user service file
Create programs.gpu-screen-recorder to host an option for generating setcap wrappers
Return gpu-screen-recorder-gtk to using tarballs instead of Git (as the developer explicitly asked for that in #268443)

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

https://git.dec05eba.com/gpu-screen-recorder-gtk/tree/com.dec05eba.gpu_screen_recorder.appdata.xml there is a changelog for the larger changes (this is the changelog used by the flatpak)

Changes since last push:

Rebased onto current master to resolve gpu-screen-recorder-gtk-related conflicts.
Update gpu-screen-recorder-gtk in lockstep. This includes returning to an un-"tagged" revision to match gpu-screen-recorder.
Switch gpu-screen-recorder-gtk to the Meson build system (direct result of previous entry).
Return to tarball downloading for gpu-screen-recorder-gtk as originally requested by the maintainer in #268443.
Uprev from 2024-07-04 to 2024-07-05.

Looks great. Thanks for making this! I've been meaning to make something for this but never got around to it.
Could the work well with the unstable updater? gpu-screen-recorder in the past has been lacking updates in nixpkgs.

Could this work well with the unstable updater? gpu-screen-recorder in the past has been lacking updates in nixpkgs.

It doesn't appear to be compatible without any changes, and given that we ideally want to keep using snapshot tarballs and since there are no usable tags anyways (which appears to account for roughly 50% of unstable updater code), it's most likely easier to just script something separate.


Test logger where debug is set to true

Description
Test logger where debug is set to true
Type of change

Unit tests (no changes in the code)

Testing steps
Done on CI.
Checklist

[ ] make before_commit passes
[ ] updated documentation wherever necessary
[ ] added or modified tests if necessary
[ ] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report
Patch coverage has no change and project coverage change: +0.45 :tada:

Comparison is base (cc81840) 95.42% compared to head (5b3dd44) 95.87%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #297      +/-   ##
==========================================
+ Coverage   95.42%   95.87%   +0.45%
==========================================
  Files          40       40
  Lines        1332     1332
==========================================
+ Hits         1271     1277       +6
+ Misses         44       40       -4
+ Partials       17       15       -2

see 1 file with indirect coverage changes

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


relay: rate limiting

I am guessing we will eventually want to rate limit how much bandwidth a user can use. I am writing this issue so we don't forget about it.
Any ideas on how that rate limiting should work? Same limits for every user? Fair-use policy / day? Do we need ad-hoc limiting from the portal? Do we want to limit just bandwidth or also maximum traffic i.e. speed vs data cap.

Blocked on #2044
Blocked on #3353
Todo

[ ] Create separate Relay tiers depending on plan
[ ] Refactor STUN-only codepaths in portal to instead select appropriate relays
[ ] Create fair bandwidth policy with tc on both tiers of Relays, and test bandwidth sharing

Some quick research suggests that it is possible using tc to dynamically limit the bandwidth a single IP can consume. This would allow us to still deploy the relay's to bigger machines but limit, how much traffic a single IP (i.e. user) can use.

I think the consensus here so far is to have "colored" relays that are sent to clients depending on the account tier they're in. Can save for a bit later.

This hasn't really been an issue since simply throwing more relays at the problem in general seems to be a cost-effective and simple way to achieve this. Closing for now, but can re-open if needed.


[CDS-58000] Add more details about terraform provisioner identifier

CDS-58000 Add more details about terraform provisioner identifier
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

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


npm start     give me problem

0 info it worked if it ends with ok
1 verbose cli [ 'C:\Program Files\nodejs\node.exe',
1 verbose cli   'C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js',
1 verbose cli   'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info prestart<EMAIL_ADDRESS>6 info start<EMAIL_ADDRESS>7 verbose unsafe-perm in lifecycle true
8 info<EMAIL_ADDRESS>Failed to exec start script
9 verbose stack Error<EMAIL_ADDRESS>start: npm run server:dev
9 verbose stack Exit status 1
9 verbose stack     at EventEmitter. (C:\Program Files\nodejs\node_modules\npm\lib\utils\lifecycle.js:217:16)
9 verbose stack     at emitTwo (events.js:87:13)
9 verbose stack     at EventEmitter.emit (events.js:172:7)
9 verbose stack     at ChildProcess. (C:\Program Files\nodejs\node_modules\npm\lib\utils\spawn.js:24:14)
9 verbose stack     at emitTwo (events.js:87:13)
9 verbose stack     at ChildProcess.emit (events.js:172:7)
9 verbose stack     at maybeClose (internal/child_process.js:827:16)
9 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
10 verbose pkgid<EMAIL_ADDRESS>11 verbose cwd E:\Angular2\AdminTemplate\ng2-admin
12 error Windows_NT 10.0.10240
13 error argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "start"
14 error node v4.4.5
15 error npm  v2.15.5
16 error code ELIFECYCLE
17 error<EMAIL_ADDRESS>start: npm run server:dev
17 error Exit status 1
18 error Failed at the<EMAIL_ADDRESS>start script 'npm run server:dev'.
18 error This is most likely a problem with the ng2-admin package,
18 error not with npm itself.
18 error Tell the author that this fails on your system:
18 error     npm run server:dev
18 error You can get information on how to open an issue for this project with:
18 error     npm bugs ng2-admin
18 error Or if that isn't available, you can get their info via:
18 error
18 error     npm owner ls ng2-admin
18 error There is likely additional logging output above.
19 verbose exit [ 1, true ]

Hi @krushnachandra, please update your npm as per requirements here https://github.com/akveo/ng2-admin/blob/master/package.json#L132 and try installing and running the package again. Thanks.

0 info it worked if it ends with ok
1 verbose cli [ 'C:\Program Files\nodejs\node.exe',
1 verbose cli   'C:\Users\CGM\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js',
1 verbose cli   'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 silly lifecycle<EMAIL_ADDRESS>no script for prestart, continuing
7 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>8 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
9 verbose lifecycle<EMAIL_ADDRESS>PATH: C:\Users\CGM\AppData\Roaming\npm\node_modules\npm\bin\node-gyp-bin;E:\Learning\node_modules.bin;C:\Program Files\nodejs;C:\Users\CGM\bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\local\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Users\CGM\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files\Microsoft SQL Server\110\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Skype\Phone;C:\Users\CGM.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Git\cmd;C:\Program Files\nodejs;C:\Users\CGM.dnx\bin;C:\Users\CGM\AppData\Roaming\npm;C:\Program Files\Git\usr\bin\vendor_perl;C:\Program Files\Git\usr\bin\core_perl
10 verbose lifecycle<EMAIL_ADDRESS>CWD: E:\Learning
11 silly lifecycle<EMAIL_ADDRESS>Args: [ '/d /s /c', 'npm run server:dev' ]
12 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
13 info lifecycle<EMAIL_ADDRESS>Failed to exec start script
14 verbose stack Error<EMAIL_ADDRESS>start: npm run server:dev
14 verbose stack Exit status 1
14 verbose stack     at EventEmitter. (C:\Users\CGM\AppData\Roaming\npm\node_modules\npm\lib\utils\lifecycle.js:245:16)
14 verbose stack     at emitTwo (events.js:87:13)
14 verbose stack     at EventEmitter.emit (events.js:172:7)
14 verbose stack     at ChildProcess. (C:\Users\CGM\AppData\Roaming\npm\node_modules\npm\lib\utils\spawn.js:24:14)
14 verbose stack     at emitTwo (events.js:87:13)
14 verbose stack     at ChildProcess.emit (events.js:172:7)
14 verbose stack     at maybeClose (internal/child_process.js:827:16)
14 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
15 verbose pkgid<EMAIL_ADDRESS>16 verbose cwd E:\Learning
17 error Windows_NT 10.0.10240
18 error argv "C:\Program Files\nodejs\node.exe" "C:\Users\CGM\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js" "start"
19 error node v4.4.5
20 error npm  v3.9.5
21 error code ELIFECYCLE
22 error<EMAIL_ADDRESS>start: npm run server:dev
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>start script 'npm run server:dev'.
23 error Make sure you have the latest version of node.js and npm installed.
23 error If you do, this is most likely a problem with the ng2-admin package,
23 error not with npm itself.
23 error Tell the author that this fails on your system:
23 error     npm run server:dev
23 error You can get information on how to open an issue for this project with:
23 error     npm bugs ng2-admin
23 error Or if that isn't available, you can get their info via:
23 error     npm owner ls ng2-admin
23 error There is likely additional logging output above.
24 verbose exit [ 1, true ]

still i am not able to start the project any help

mine stop at this

Hi @ikhsan017, what do you mean by "stops"? From the image attached it's up and running, just open http://localhost:3000 as per the documentation.

ah my bad :smile: , using ng2-quickstart it usually open the browser automatically :smile: , so I was waiting for the browser to be opened, lol

@krushnachandra have you resolved the issue? Have you tried to go through all of the installation steps again?

No Still i am not able to run the project @nnixaa

I fellow the Installation Guidelines step by step to install the package,but still couldn't finish the installation successfully.
npm ERR! Linux 4.4.11-23.53.amzn1.x86_64
npm ERR! argv "/home/ec2-user/.nvm/versions/node/v5.10.0/bin/node" "/home/ec2-user/.nvm/versions/node/v5.10.0/bin/npm" "run" "build:prod"
npm ERR! node v5.10.0
npm ERR! npm  v3.8.3
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>build:prod: `webpack --config config/webpack.prod.js  --progress --profile --colors --display-error-details --display-cached --bail`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build:prod script 'webpack --config config/webpack.prod.js  --progress --profile --colors --display-error-details --display-cached --bail'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the ng2-admin package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     webpack --config config/webpack.prod.js  --progress --profile --colors --display-error-details --display-cached --bail
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs ng2-admin
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls ng2-admin
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/ec2-user/ng2-admin/npm-debug.log

please tell how can I install the ng2-admin successfully

Same problem here with ng2-admin HEAD.


[suggestion] directly input vgg.json for training from scratch or finetuning

A good suggestion would be an option to directly input a vgg.json for training from scratch or finetuning
perhaps even add an option to input multiple vgg.json files at once.
--input_json ./input/*.json

I think this feature is less a priority but might be good to have at some point


revised volatility metric

this introduces a revised volatility metric, and converts wei to a 61x64 int for more natural fixedpoint math.

Will leave judging the math to Sara, but seems reasonable - my understanding is that this wouldn't be exposed as is but would be wrapped on top of Checkpointing logic as a simpler interface where the user just reads volatility

that's how this works.  The logic in this contract pulls the checkpoints into an array and calculates the volatility as an aggregation of the checkpoints.  I tagged you where the array is built.


fix to insure that when a StateSpace and a LinearIOSystem are combined, the result is a LinearIOSystem

Previously, when a StateSpace and a LinearIOSystem were combined, the result was not a LinearICSystem because StateSpace systems did not have _rhs and _out methods that could be used to re-linearize the system. This has been fixed.

By the way, numeric re-linearization of the system like this is convenient, but probably introduces inaccuracy. Probably the right way to do it in a future PR would be to correctly combine the constituent systems using their A, B, C, and D matrices using the connect function.

Coverage decreased (-0.0008%) to 94.766% when pulling 19bf7f079326efe76018f5fc85c7699f3b135649 on sawyerbfuller:interconnect-ss into beb629b9efc0f7c57c84ed0ec77f5d2116b98db1 on python-control:main.

I'm not sure this is the best way to fix this issue.  If I understand it correctly, it essentially starts putting member functions from the InputOutputSystem class into the StateSpace class.  But that is what the LinearIOSystem class is for => we are essentially replicating what is already there.
The StateSpace class is intended to be a "low level" class that is typically not seen by the user (if you use the ss factory function, you get an LinearIOSystem object, which inherits from both InputOutputSystem and StateSpace).  The StateSpace class is mainly there for legacy purposes and because I thought there might be some speed advantages (though I'm not sure this is in fact the case).
I need to think a bit more about how else this might be done, perhaps also thinking through the role of the LinearICSystem class, as described in issue #786.  Some alternatives would be to "eliminate" the StateSpace class completely (probably by just having it be another name for LinearIOSystem) or converting a StateSpace object to a LinearIOSystem object for any operation with an InputOutputSystem object.
Also, there are a lot of changes that are part of this PR that seem to be related to previous commits.  I'm not sure if the changes are based on the main branch or not.

Also, there are a lot of changes that are part of this PR that seem to be related to previous commits. I'm not sure if the changes are based on the main branch or not.

Seems that a rebase/merge has gone wrong.

Fixed by force-pushed rebase.
@sawyerbfuller you need to reset your local branch before continuing to work on this.

I'm not sure this is the best way to fix this issue. If I understand it correctly, it essentially starts putting member functions from the InputOutputSystem class into the StateSpace class. But that is what the LinearIOSystem class is for => we are essentially replicating what is already there.
The StateSpace class is intended to be a "low level" class that is typically not seen by the user (if you use the ss factory function, you get an LinearIOSystem object, which inherits from both InputOutputSystem and StateSpace). The StateSpace class is mainly there for legacy purposes and because I thought there might be some speed advantages (though I'm not sure this is in fact the case).

I agree having duplicate methods doesn't make much sense. To that end, and following the idea that StateSpace should be a low-level class, the recent commit leaves  _rhs and _out in StateSpace but takes them out of LinearIOSystem. Instead, references to the methods already in StateSpace are added in to to override the empty stubs that are defined in InputOutputSystem. This is consistent with the idea that StateSpace be a low-level class -- maybe one that that contains numerical methods. Let me know what you think.

I need to think a bit more about how else this might be done, perhaps also thinking through the role of the LinearICSystem class, as described in issue #786. Some alternatives would be to "eliminate" the StateSpace class completely (probably by just having it be another name for LinearIOSystem) or converting a StateSpace object to a LinearIOSystem object for any operation with an InputOutputSystem object.

Might make sense to eventually merge StateSpace and LinearIOSystem classes somehow.

Also, there are a lot of changes that are part of this PR that seem to be related to previous commits. I'm not sure if the changes are based on the main branch or not.

Fixed, I think. Syncing issues. Thanks @bnavigator

So I looked through this PR a bit more carefully.  It looks to me like there are three different things going on:

Update StateSpace class so that interconnect will allow LinearIOSystem and StateSpace objects to be combined correctly.
Add params as a keyword to dynamics and output.
Update the way "static gain" is determined.

I have comments and questions for each, plus an alternative PR #788 that fixes the first two.
StateSpace updates
I think the issue being addressed here is that if you try to use interconnect with a list of systems that includes a mixture of LinearIOSystem objects and StateSpace objects, it doesn't work correctly, even though the operator overloading for those combinations handles things properly.
The proposed fix is to update the StateSpace class to have some of the methods that normally go with an InputOutputSystem object and then use those in the LinearIOSystem object.  That will work, but it messes around with the class structure in a somewhat spaghetti like way and leads to some inconsistencies.  For example, the fix does not allow you to interconnect a TransferFunction with a LinearIOSystem, even though operator overloading on that case works.  In principle we could add _rhs and _out to the TransferFunction class to fix that, but of course it really doesn't make sense for a transfer function to have a right-hand side. It's just that it needs to be converted to a LinearIOSystem object via some realization (which is what the operator overloading implementation does).
I think that a better short term fix is to update the interconnect function so that it recognizes StateSpace and TransferFunction objects and properly converts them to LinearIOSystem objects.  I did that in PR #788 by adding 4 lines of code (and some more extensive unit tests).
In the long term, we might want to combine StateSpace and LinearIOSystem into a single class, since after the addition of the NamedIOSystem class in PR #721, these two are largely redundant.  We might also think about removing the LinearICSystem class as discussed in issue #786.  But see the comments below regarding the param keyword for a counterargument.
Also, as a note, I don't think the included unit tests actually expose the functionality that was broken (they use operator overloading, which works in the current version [I checked]).
Adding params to dynamics, output
The dynamics() and output() functions for InputOutput systems were not accepting a params keyword, which was a clear bug.  I'm surprised this bug hadn't popped up before, but I think it was because we haven't been using dynamics() and output() for input/output systems in any of our unit tests.
Note that _rhs and _out should not take params as an input.  Rather, these are passed by setting current_params, which are then accessed by _rhs and _out.  This was done this way because the ODE integration routines from SciPy don't have parameter values and so you have to store them someplace before passing _rhs to scipy.integrate.solve_ivp.
Also note that in the current implementation, a LinearIOSystem does not have parameter values since it was originally intended to just be a way to turn a StateSpace system into an InputOutputSystem while retaining the linear structure (eg, A, B, C, and D matrices).  This might actually speak to a case where we want to leave LinearIOSystem and StateSpace as separate classes, with the idea that a LinearIOSystem might have parameter values while a StateSpace system wouldn't.  That would require some rewriting of the classes, since currently a LinearIOSystem is a subclass of StateSpace, but we would need it the other way around if a StateSpace system was treated as a special case of a LinearIOSystem.  I'd have to noodle on that for a bit...
PR #788 fixes up the parameter processing and adds some unit tests that expose the current bug.
Static system determination
I can't quite tell what the intention was in changing around some of the code associated with "static" systems, but in looking through the code before and after the change, I think there are some inconsistencies.
I think the definition of a "static" system should be that it is a system with no internal state.  This is allowed in both the StateSpace and InputOutputSystem classes by setting nstates to zero.  So, for example, a static gain can be declared via
sys1 = ct.StateSpace([]. [], [], 2)

This is different than the following declaration, which shows up in the proposed unit tests:
sys2 = ct.Statespace(0, 0, 0, 2)

Strictly speaking, sys2 is not a static system.  It is a 1 state system that is both unobservable and uncontrollable.  Confusingly, the existing sys2._isstatic() method will return True and the proposed unit tests tries to confirm that definition, even though I don't think it is correct.
Also, there is a another problem with the current code, which defines a system to be static if the A and B matrices are zero.  That sort of makes sense in continuous time (the state would remain unchanged), but it is not actually correct in discrete time (you would want A to be the identity matrix). And even for a continuous system you could get odd behavior if the C matrix is nonzero and there is a nonzero initial condition (the system is "static", but the input/output response is now affine).  I think the proper fix here is to use nstates == 0 as the proper definition of a static system.
@sawyerbfuller: Can you provide more info on what the issue was here and your thoughts on how we should define a "static" system?  Depending on your response, we can figure out how to fix things.

StateSpace updates
I think the issue being addressed here is that if you try to use interconnect with a list of systems that includes a mixture of LinearIOSystem objects and StateSpace objects, it doesn't work correctly, even though the operator overloading for those combinations handles things properly.
The proposed fix is to update the StateSpace class to have some of the methods that normally go with an InputOutputSystem object and then use those in the LinearIOSystem object. That will work, but it messes around with the class structure in a somewhat spaghetti like way and leads to some inconsistencies. For example, the fix does not allow you to interconnect a TransferFunction with a LinearIOSystem, even though operator overloading on that case works. In principle we could add _rhs and _out to the TransferFunction class to fix that, but of course it really doesn't make sense for a transfer function to have a right-hand side. It's just that it needs to be converted to a LinearIOSystem object via some realization (which is what the operator overloading implementation does).
I think that a better short term fix is to update the interconnect function so that it recognizes StateSpace and TransferFunction objects and properly converts them to LinearIOSystem objects. I did that in PR #788 by adding 4 lines of code (and some more extensive unit tests).

Sounds good.

In the long term, we might want to combine StateSpace and LinearIOSystem into a single class, since after the addition of the NamedIOSystem class in PR #721, these two are largely redundant. We might also think about removing the LinearICSystem class as discussed in issue #786. But see the comments below regarding the param keyword for a counterargument.

I agree on the idea of merging them.

Adding params to dynamics, output
The dynamics() and output() functions for InputOutput systems were not accepting a params keyword, which was a clear bug. I'm surprised this bug hadn't popped up before, but I think it was because we haven't been using dynamics() and output() for input/output systems in any of our unit tests.

Yes, I agree that was a bug - by me.

Note that _rhs and _out should not take params as an input. Rather, these are passed by setting current_params, which are then accessed by _rhs and _out. This was done this way because the ODE integration routines from SciPy don't have parameter values and so you have to store them someplace before passing _rhs to scipy.integrate.solve_ivp.

I see, makes sense.
What is the difference between self._current_params and self.params, i.e. what is the reason that self._update_params only updates _current_params and not params?

Also note that in the current implementation, a LinearIOSystem does not have parameter values since it was originally intended to just be a way to turn a StateSpace system into an InputOutputSystem while retaining the linear structure (eg, A, B, C, and D matrices). This might actually speak to a case where we want to leave LinearIOSystem and StateSpace as separate classes, with the idea that a LinearIOSystem might have parameter values while a StateSpace system wouldn't. That would require some rewriting of the classes, since currently a LinearIOSystem is a subclass of StateSpace, but we would need it the other way around if a StateSpace system was treated as a special case of a LinearIOSystem. I'd have to noodle on that for a bit...

My inclination would be to keep things simple and assume that if somebody wants to update matrix entries, they can do that by creating new A, B, C, D matrices and creating a new StateSpace system, but there may be use cases I am not aware of.

PR #788 fixes up the parameter processing and adds some unit tests that expose the current bug.

Great : )

Static system determination
I can't quite tell what the intention was in changing around some of the code associated with "static" systems, but in looking through the code before and after the change, I think there are some inconsistencies.
I think the definition of a "static" system should be that it is a system with no internal state. This is allowed in both the StateSpace and InputOutputSystem classes by setting nstates to zero. So, for example, a static gain can be declared via
sys1 = ct.StateSpace([]. [], [], 2)

This is different than the following declaration, which shows up in the proposed unit tests:
sys2 = ct.Statespace(0, 0, 0, 2)

Strictly speaking, sys2 is not a static system. It is a 1 state system that is both unobservable and uncontrollable. Confusingly, the existing sys2._isstatic() method will return True and the proposed unit tests tries to confirm that definition, even though I don't think it is correct.

Glad this exposed a bug in how a static system is defined. Makes sense to me.

Also, there is a another problem with the current code, which defines a system to be static if the A and B matrices are zero. That sort of makes sense in continuous time (the state would remain unchanged), but it is not actually correct in discrete time (you would want A to be the identity matrix). And even for a continuous system you could get odd behavior if the C matrix is nonzero and there is a nonzero initial condition (the system is "static", but the input/output response is now affine). I think the proper fix here is to use nstates == 0 as the proper definition of a static system.

Good catch regarding discrete-time static state-space systems. I agree.

@sawyerbfuller: Can you provide more info on what the issue was here and your thoughts on how we should define a "static" system? Depending on your response, we can figure out how to fix things.

The primary motivation of which I am aware for detecting static systems is to make it convenient to connect them to either  discrete-time or continuous-time systems, because they are simply a gain. Currently, any StateSpace system that is detected to be static is set to have dt=None by default, to give this behavior.
But I imagine it is possible that there are pitfalls to this, and it is not that much to ask that a user always make sure dt values are compatible. But on the other hand, without any specific examples of problems that arise out of this choice, my inclination is to make things as easy as possible and leave this behavior in.

What is the difference between self._current_params and self.params, i.e. what is the reason that self._update_params only updates _current_params and not params?

For posterity: self.params is the default parameter values when the system is defined.  But you can pass new parameters when you run a simulation using input_output_response and self.current_params stores those values, if specified.


Suggestion: app cleanup on current user

I'd recommend adding this line:
Get-AppxPackage | Where-Object {$_.Name -NotMatch $WhitelistedApps} | Remove-AppxPackage -ErrorAction SilentlyContinue
Right after this line:
Get-AppxPackage -AllUsers | Where-Object {$_.Name -NotMatch $WhitelistedApps} | Remove-AppxPackage -ErrorAction SilentlyContinue
This will remove apps from the currently logged in user account.

Thanks, but looking at the script and the git history I don't see that you've added this line? Did you push the changes?


Add Private Internet Addresses

There already exists public_ip_v4_address as a way to create public ip addresses. Looking for a way to similarly generate private ip addresses.

@paguilera The public_ip_v4_address method generates private address like <IP_ADDRESS> or <IP_ADDRESS> . Do you want a method that only returns those types of ips?

My understanding was the public_ip_v4 did not return such addresses.
However, yes, I'm requesting a method that only returns those types of ips.

@paguilera Is there any list of known private ips? I think that it depends on the configuration of the network. There are some common ones like the ones I mentioned before but it could be any

There's a list from RFC 1918 that shows this:

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
 <IP_ADDRESS>        -   <IP_ADDRESS>  (10/8 prefix)
 <IP_ADDRESS>      -   <IP_ADDRESS>  (172.16/12 prefix)
 <IP_ADDRESS>     -   <IP_ADDRESS> (192.168/16 prefix)

The ability to configure additional ones would be a nice addition, but I think having these would be a great starting point.

Oh thats okay then. I will take a look to the existent public_ip_v4_address and then submit a PR

That's great. Thank you.

@paguilera I submitted https://github.com/stympy/faker/pull/591 for this. What do you think?

Looks good to me. Thanks!

Closed in #591


Insert locale-dependent document into db

I am currently trying to insert a different document into objectDb depending on the users locale.
In short, my code currently goes like:
void main() async {
  // get document directory using path_provider plugin
  Directory appDocDir = await getApplicationDocumentsDirectory();

  String dbFilePath = [appDocDir.path, 'user.db'].join('/');

  // initialize and open database
  db = ObjectDB(dbFilePath);

  // delete old database file if exists
  File dbFile = File(dbFilePath);

  // check if database already exists
  var isNew = !await dbFile.exists();

  db.open();
  if (isNew) {
    //insert first document
    final document =
        r'[{"insert":"Welcome"}];
   db.insert({
      'document': document,
      'key': randomKey,
    });
  }
}

Now I am wondering: Is it possible to insert a different document into the db depending on the user devices locale? My first try was using Localizations.localeOf(context); which however didn't work because the main() function does not have a context. Is there any other way of achieving this?
PS: Sorry for asking a simple question as an issue, I just didn't find any other place to ask. Thanks a lot for the awesome database! :+1:

Check out the objectdb_flutter example. You can insert data before returning the root component.
You could ask the question on StackOverflow ;)
& feel free to send me a pm via Twitter @marioreggiori if i don't respond soon.

Feel free to reopen if there are more questions related to this topic.


Not all pending calls are retried if multiple calls return 401

In my React app, when a particular component is activated, I immediately use Axios to make three independant API calls. When my token is expired, all three calls return 401 as expected. As soon as one of the calls returns a 401, the refresh interceptor kicks off a call to refresh the token. When the refresh call succeeds, the original call is retried, but the other two original failing calls are not retried. It seems like any calls that return 401's while the refresh is happening should be retried after the refresh succeeds. I expected this library to already handle this. Perhaps it does, and I'm misinterpreting what I'm seeing? Any guidance/feedback would be very much appreciated.

Here is an implementation in Angular that uses an RxJS BehaviorSubject as a semaphore to block and release requests during the refreshing.
https://angular-academy.com/angular-jwt/#refresh-token

Hi, thanks for opening the issue. This will be the default behaviour in the next major version.
For now, check the skipWhileRefreshing option, please. Library by default prevents refreshing from multiple simultaneous calls to not enter the interceptor-loop in case any of them return 401 again. You can turn off the skipWhileRefreshing option while initialising the interceptor and use skipAuthRefresh flag for refreshing request to prevent that behaviour manually.

Glad to hear that will be the default behavior in the future. Perhaps skipWhileRefreshing should be renamed to something like queuePendingCallsWhileRefreshing or something like that. While I did read through the README, I never considered that skipWhileRefreshing would get me the behavior that I was seeking.

Yeah, that I agree with.

Hi, I've encountered a similar issue but have had no luck so far getting it to work with skipWhileRefreshing: false while not spamming calls afterwards.

Hi, I've encountered a similar issue but have had no luck so far getting it to work with skipWhileRefreshing: false while not spamming calls afterwards.

Remember that skipWhileRefreshing is an interceptor option.
You need to set on createAuthRefreshInterceptor
I was using it like an axios request option the first time, maybe your doing the same

Yes, skipWhileRefreshing option needs to be set when initialising the interceptor. Then, as skipWhileRefreshing flag is stopping the default prevention from interceptors' loop, you should set skipAuthRefresh flag to any request that you're calling from the refreshing function in order for the library to know that this request is a process of refreshing and if it fails again, it should not be retried.
The skipWhileRefreshing flag has an unfortunate name and I apologise for that. In case you're wondering why the library works like that at all, here's the quick explanation:

When I created the library, I wanted it to be implemented as easy as possible. I believed that the authentication process which runs in the callback function (called refreshAuthLogic in docs) may not always be dependent on an API call, and also, I believed developers may not always read the docs and implement something like skipAuthRefresh flag to the refreshing calls (which is why it was not implemented at all in the first few versions). Because of that belief, pausing the whole instance seemed like a good idea to prevent any kind of unexpected bugs with interceptor loops, when the authentication logic fails.

It turns out I was wrong, more and more developers use the skipWhileRefreshing option to disable the default prevention. Of course, I don't know if they use skipAuthRefresh flag afterwards in order to prevent the interceptor loops (hope they are), but it seems like a good idea to remove it or at least make it easier to implement.
So the plans for the future of this library are quite simple. I will try to figurate out an easy and safe way to disable the default prevention mechanism and will probably leave it up to developers to use flag skipAuthRefresh on their calls while refreshing, to prevent the loop. I would also like to find a way to, at least, warn the developers who do not use the flag and/or create the fallback to default prevention mechanism in that case. But, to be honest, I'm not sure if there's a way to do that without any crazy logic. Of course, any help would be much appreciated. Also, might be worth to mention that this would surely introduce a breaking change, so expect this to be in version 3.x.x.

Any updates on this facing the same issue. Maybe you could document an example with the skipWhileRefreshing flag for the time being. Thanks

@Flyrell I use my implemented axiosInstance that used in the whole app and pass it to createAuthRefreshInterceptor to catch 401 status code. Then use plain axios to use in refreshAuthLogin func. So if the axios in refreshAuthLogin``` fails again, another trying shouldn't happen.
I think it might prevent infinite loop. doesn't?

This change will be published in v3.0.0 [PR #105]. I hope to publish it soon.

Using the
const [slider, package, banner, announcement] = await Promise.all([
      app.$api.widget.slider(),
      app.$api.widget.package(),
      app.$api.widget.banner(),
      app.$api.widget.announcement(),
]);

for fetch data, together with skipWhileRefreshing: false, refresh requests fail:

Is there anything you can do about this?

@niqitosiq sorry I must have overlooked your comment in e-mails. How are you binding the token? If you use the interceptor to bind the newest token dynamically this shouldn't be an issue, as each "repeated" request should get newest token.
Example:
// Obtain the fresh token each time the function is called
function getAccessToken() {
    return localStorage.getItem('token');
}

// Use interceptor to inject the token to requests
axios.interceptors.request.use(request => {
    request.headers['Authorization'] = `Bearer ${getAccessToken()}`;
    return request;
});

Thank you, now all is working.
I have used
config.headers.common['Authorization'] = ...
instead
config.headers['Authorization'] = ... 😅

Version v3.0.0 is now out and should deal with the issue discussed here. See change-log section section to see what's changed. Feel free to reopen if the issue persists.


Unordered lists have line break, possible regression?

I am experiencing the same issue described in https://github.com/kovetskiy/mark/issues/52
When I create a bullet list, like this:
- level 1
    - level 2a
    - level 2b
        - level 3

It renders like this:

level 1

level 2a

level 2b

level 3

But I'm running the most recent release:
mark --version
6.2

Also in 8.0.

Seeing the same thing.
This Markdown:
* A1
    * B1
        * C1
        * C2
    * B2
        * C3
        * C4
    * B3
* A2

Produces this result:

If you try to use HTML instead, you'll get a 400 response from the API because it seems to be interpreting the tabs as code.
For example, this produces a 400:

A1

B1

C1

C2

B2

C3

C4

A2

But if you condense it all so that nested items are on one line and there are no tabs, it works:

A1

B1

C1

C2

B2

C3

C4

A2

Result:

I've run into this same issue myself, specifically with nested lists similar to the examples above.

:wave: Hey all, I encountered a similar issue in v8.4 which I was able to resolve with some adjustments to my markdown file.
Not ideal:

rendering:
markdown:

Better, notice the line break:

rendering:
markdown:

Me too!
Just as described by @gshel.


Sharing is Caring Power App Sample - Shaheer Ahmad

Category

[x] New Sample

What's in this Pull Request?
Power Apps Calendar Component

@shaheerahmadch  thanks for your sample! You rock!!!


Submit-CertificateRequest issue with a wrong method name

There is an issue with the function Submit-CertificateRequest:
Method invocation failed because [PKI.CertificateServices.CertificateAuthority] does not contain a method named 'PingRequest'.
In fact the available method is Ping and not PingRequest. Can you change this ?
Regards,
Stéphane

Actually, there is such method: https://github.com/PKISolutions/pkix.net/blob/808db9c106679544744be762bd50e02ce3c2850d/PKI/CertificateServices/CertificateAuthority.cs#L414. I've updated reference libraries.

Thanks for the update :)


🧑💻 :  Want to improve method.html

:red_circle: Title : User Guide and Support
:red_circle: Enhancement Aim : Enhancing User Experience and Accessibility
:red_circle: Changes :
Header Navigation, User Instructions , FAQs, User Interaction, Footer Section
Screenshots 📷

✅ Details to Include When Taking the Issue:
Name : Jahnavika gopal
Participant Role (Specify the Open Source Program name, e.g., GSSOC, Hacktoberfest, etc.):
GSSOC, Hacktoberfest

Happy Contributing! 🚀
Wishing you all the best on your open source journey. Enjoy! 😎

@iamrahulmahato Thank you for assigning me. I will let you know the update soon.

@iamrahulmahato I have submitted a pull request. Please take a moment to review it. Thank you!


I understand what there is no built-in ability to change spannable text colour on the fly, but it's would be very helpful function.

Merged.


[bug] Application Fails to Start (0xc0000005) on Windows 7 with Rust 1.78.0

Describe the bug
As the title states, when using rust 1.78.0, it cannot run normally on Windows 7
The screenshot content is: The application cannot start normally (0xc0000005). Please click OK to close the application.

Reproduction

Compile the application with Rust 1.78.0.
Run the compiled application on Windows 7 SP1.

Target machine information:

Windows 7 SP1 x64
Webview2 109
Latest VC Redist

I tested with both Tauri 1.6.5 and 2.0.0-beta.19. Both versions run normally when compiled with Rust 1.77.2. However, upon switching to Rust 1.78.0, the error occurs.
Expected behavior
No response
Full tauri info output
### Rust 1.78.0
[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 124.0.2478.97
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
    ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.10.0
    - pnpm: 8.12.1
    - yarn: 1.22.21
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 2.0.0-beta.19
    - tauri-build [RUST]: 2.0.0-beta.15
    - wry [RUST]: 0.39.5
    - tao [RUST]: 0.28.0
    - tauri-cli [RUST]: 2.0.0-beta.17
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.17

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ./ui

### Rust 1.77.2
[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 124.0.2478.97
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: 1.77.2-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.10.0
    - pnpm: 8.12.1
    - yarn: 1.22.21
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 2.0.0-beta.19
    - tauri-build [RUST]: 2.0.0-beta.15
    - wry [RUST]: 0.39.5
    - tao [RUST]: 0.28.0
    - tauri-cli [RUST]: 2.0.0-beta.17
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.17

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ./ui

Stack trace
No response
Additional context
No response

1.78 dropped support for windows 7 and 8. You need to stick with 1.72.2 if your app needs to work on windows 7.

Oh，NO。。。。。1.78 dropped support for windows 7 and 8


Add fluent-template for template rendering stack + i18n

Opening this as a rough draft as part of #329 just to get some feedback. Not sure:

how any of this should be named
how tests should be done
how config should be documented
how errors should be handled
what else I've missed

So there's more work to be done here 😄 But figured I'd open up a draft PR and start getting input before I go way off in the wrong direction.

This looks good for assessing the effort required, looks achievable!
I can give you a few pointers:

Start working from examples/demo, this will help you place assets (locales, templates) in a non-framework source tree, and then, once you have something working, think about "how do i extract functionality into the framework"
Extracting into the framework means pieces of code that would be generic in their behavior (nothing specific to a specific app), and also -- picking the right name, module name, source file names, is important (we can help with that)

I figured creating a PR of what I mean would be easier (managed to remove a few panics/edge cases, etc. in the original code too, so review the code itself too):
https://github.com/loco-rs/loco/pull/389
let's move to work there, I also made sure to document all the design questions, etc. so we can get your thoughts there as well

@jondot ah that's awesome! Will close this so and move over there. Nice one!


Test Server Not Available - Wordpress

Have installed PlugnMeet on Wordpress and would like to test.
Using default settings:
https://demo.plugnmeet.com
plugnmeet
zumyyYWqv7KR2kUqvYdq4z4sXg7XTBD2ljT6
Client load: Remote
I receive the message: app.verification-failed-title
app.token-not-valid
Is this an installation issue?
Have not found any clues how to deal with the problem.

You're trying to access without token. Correct: https://demo.plugnmeet.com/login.html
https://www.plugnmeet.org/docs/api/intro


[otbn] Produce end-to-end performance numbers for RSA and ECDSA

We have spread out over various forums performance numbers for RSA encrypt/decrypt of various key sizes, as well as ECDSA P-256 and P-384 numbers. Confirm those with the most recent version of OTBN, and add them to the tracking spreadsheet.
Depends on an end-to-end test for ECDSA P-384 first, tracked in https://github.com/lowRISC/opentitan/issues/6448

Collecting here but also adding to the spreadsheet:
P-384:
Curve point test:
OTBN executed 421 instructions in 441 cycles.
The execution stalled for 20 cycles (4.8 percent).
The execution would take 0.00 ms @ 100 MHz.

Base point multiplication:
OTBN executed 1679280 instructions in 1720044 cycles.
The execution stalled for 40764 cycles (2.4 percent).
The execution would take 17.20 ms @ 100 MHz.

ECDSA verify:
OTBN executed 1266058 instructions in 1294428 cycles.
The execution stalled for 28370 cycles (2.2 percent).
The execution would take 12.94 ms @ 100 MHz.

ECDSA sign:
OTBN executed 1753898 instructions in 1794680 cycles.
The execution stalled for 40782 cycles (2.3 percent).
The execution would take 17.95 ms @ 100 MHz.

P-256:
todo: let's add those after the current OTBN sprint, since we are making fundamental changes to the P-256 lib
RSA:
1024 bit verify/encrypt:
OTBN executed 115852 instructions in 129346 cycles.
The execution stalled for 13494 cycles (11.6 percent).
The execution would take 1.29 ms @ 100 MHz.

1024 bit sign/decrypt:
OTBN executed 2302414 instructions in 2439771 cycles.
The execution stalled for 137357 cycles (6.0 percent).
The execution would take 24.40 ms @ 100 MHz.

1024 bit verify/encrypt:todo
1024 bit sign/decrypt: todo
2048 bit verify/encrypt:todo
2048 bit sign/decrypt: todo
3072 bit verify/encrypt:todo
3072 bit sign/decrypt: todo
4096 bit verify/encrypt:todo
4096 bit sign/decrypt: todo

@imphil Do you think we should add standalone tests for the larger RSA keys to the code-snippets dir?
I have them lying around, just large assembly files due to the baked in keys...


:sparkles: Add Upsync controller (replaces PR #2214)

Summary
This PR implements the Upsyncer controller inside the Syncer.
It is a replacement of the initial PR that had to be reworked and rebased.
Related issue(s)
Fixes #1980

Still missing:

add unit tests to check the cases when the status is changed
add unit tests to check the case when the UpSync labels are not there
e2e tests

Finally we kept initial PR for the continuation of the work.
Closing this one then.


[MINOR] refactor: use general method to check the remote storage existence

What changes were proposed in this pull request?
In #259 , we introduce some general method to check the storage types. So
this patch is to refactor the remaining part of this.
Why are the changes needed?
Refactor to optimize the remote storage checking.
Does this PR introduce any user-facing change?
No.
How was this patch tested?

Existing UTs

Codecov Report

Merging #980 (f91dca8) into master (bb61efb) will increase coverage by 12.40%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master     #980       +/-   ##
=============================================
+ Coverage     44.23%   56.64%   +12.40%
- Complexity        0     2199     +2199
=============================================
  Files            20      321      +301
  Lines          2360    14150    +11790
  Branches          0     1296     +1296
=============================================
+ Hits           1044     8015     +6971
- Misses         1245     5697     +4452
- Partials         71      438      +367

Impacted Files
Coverage Δ

...va/org/apache/uniffle/client/util/ClientUtils.java
61.36% <0.00%> (ø)

...a/org/apache/uniffle/storage/util/StorageType.java
93.75% <0.00%> (ø)

... and 339 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Could you help check the Tez unit test failure? @lifeSo I think this is not related with this PR.

@lifeSo Could you take a look at the failure test?

@lifeSo Could you take a look at the failure test? If it is a flaky test, you can create an issue to track it and try to solve it.

It seems a flaky test. Let crease an flaky test issue for @lifeSo . Let merge this pr first. Thanks all.

@zhengchenyu Could you help take a look at the failure case?

Could you help take a look at the failure case?

Seems the failed test is caused by storageType == null.


Get Distance 12C vs PWM Issue

I am running a LidarLite (Blue Label) on an Arduino Uno board, wired up exactly as pictured in the diagrams on this site (minus the capacitor).
I used the PWM GetDistance code located on this site with no issues. But when I use the I2C version (wired appropriately), all I get is a series of zeroes. The sensor is brand new and works with the PWM set up, so I don't think it's a sensor problem. And the wiring is pretty simple so I'm confident I have it wired up correctly. I am plugging in the unaltered code from this site directly into the Arduino IDE (Mac), so I'm wondering if there is something I need to do with the code to make it work correctly. Is there any reason I should be getting a string of zeros as opposed to the distance data?

I'm running into this same issue exactly as described above. My LidarLite (blue label) works fine using the LIDARLite_Wire_Library_GetDistance_ContinuousRead sketch but i2C returns nothing but zeroes.

One important note... this library only works with LIDAR-Lite v1 (silver label). The I2C master library by DSS circuits was written specifically to do repeated starts during I2C reads and unfortunately is not compatible with LIDAR-Lite v2 (blue label) which requires a stop then a start during reads. So sorry for any confusion.


Inconsistent (and unexpected) redirects

Prerequisites

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

Description
I have a URL with a GET parameter in the address (which I can verify is the correct address) that gets called from the frontend of my application. Sometimes the call is successful and the request goes through correctly and the JsonResponse is returned.
Other times a 303 response comes back and, either the controller method doesn't get hit and the redirect is almost instant and goes to the set redirect url; or the method does get hit but at some point before returning, the redirect occurs and it ends up inside the default redirect route. This results in returning the HTML of a page.
Steps to Reproduce

System Configuration
Running Nancy 1.4.3 and Nancy Authentication Forms 1.2.0, hosted with ASP.NET on Windows.
(Installed via NuGet)

Nancy version:
Nancy host

[x] ASP.NET
[ ] OWIN
[ ] Self-Hosted
[ ] Other:

Other Nancy packages and versions:
Nancy Authentication Forms 1.2.0
Environment (Operating system, version and so on):
Windows (both server 08/12 and desktop 8)
.NET Framework version:
4.0 or 4.5
Additional information:

What happened to the issue template?

The only place in the Nancy codebase where we use 303 (See Other), besides returning a RedirectResponse (possibly through Response.AsRedirect), is when logging a user in through forms authentication. Sure you're not doing anything funky with the forms auth?

@CuriousCain :watch:

Thanks for the reply. It's an inherited codebase and I can't see anything immediately bizarre about how forms auth is used, but I've switched to using nancy from source instead of from nuget packages and I'm attempting to debug the application that way.


Laravel MongoDB No suitable servers found ('serverSelectionTryOnce' set) PHP 5.6

I try to connect laravel with mongodb but i've got error "no suitable servers found"
Here's my machine
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty

PHP Version => 5.6.31-2+ubuntu14.04.1+deb.sury.org+1

System => Linux work-vbox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php/5.6/cli
Loaded Configuration File => /etc/php/5.6/cli/php.ini

MongoDB support => enabled
MongoDB extension version => 1.2.11
MongoDB extension stability => stable
libbson bundled version => 1.5.5
libmongoc bundled version => 1.5.5
libmongoc SSL => enabled
libmongoc SSL library => OpenSSL
libmongoc crypto => enabled
libmongoc crypto library => libcrypto
libmongoc crypto system profile => disabled
libmongoc SASL => disabled

Do you have MongoDB driver? Try installing it:
sudo apt-get install php-mongodb
or
sudo apt-get install php56-mongodb
depending on you PHP setup.
Or maybe the mongod server is not running?
sudo service mongodb start


Massive dependabot upgrade

This PR resolves a large collection of dependabots, 29 in total.
Test Steps:

Run test suites

Changes

Dependencies updated (see commit messages or linked issues for which)

Checklist
Testing

[x] Tested locally?
[x] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?

Linked Issues

Fixes #13566
Fixes #13565
Fixes #13549
Fixes #13548
Fixes #13547
Fixes #13490
Fixes #13489
Fixes #13460
Fixes #13459
Fixes #13418
Fixes #13417
Fixes #13416
Fixes #13415
Fixes #13337
Fixes #13335
Fixes #13332
Fixes #13243
Fixes #13148
Fixes #13091
Fixes #13085
Fixes #13056
Fixes #12795
Fixes #12794
Fixes #12743
Fixes #12739
Fixes #12489
Fixes #12391
Fixes #12387
Fixes #12313

@thetaurean Please add https://github.com/CDCgov/prime-reportstream/pull/13426


Update to InterPro v100.0

https://www.ebi.ac.uk/interpro/release_notes/

That's done now.  I'll add a news item then close the issue.


termusic: 0.6.15 -> 0.7.1

Description of changes
updated package, tested and added my self as maintainer
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[x] (Package updates) Added a release notes entry if the change is major or breaking
[x] (Module updates) Added a release notes entry if the change is significant
[x] (Module addition) Added a release notes entry if adding a new NixOS module
[x] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 185010 run on x86_64-linux 1

1 package built:

termusic


libc: add support for reallocarray

Summary
This commit adds support for reallocarray function. The functionality is the same as for standard realloc, but the function also checks for multiplication overflow and fails safely in case it occurs. This is not POSIX, however the function is part of standard C library.

Ok, I will do manual overflow control instead.


Upgrade pre-commit hooks

Ran pre-commit autoupdate to upgrade tools.
I recommend setting up pre-commit.ci on the repo. This will run hooks on every PR, like the deprecated pre-commit/action currently in use, and will make autoupdate PRs.

coverage: 100.0%. remained the same
when pulling a64e321dc97f1364424c4c76fa282e95eee5361c on adamchainz:upgrade_pre_commit_hooks
into d2145409226525bd21ac4a08ef502a68561a6c1c on django-import-export:main.


Added full stack docker container as drop-in replacement for the pipeline scripts

Looks like this pull request may be problematic. Let me know if you want me to refork.

I think this is related to merging of unrelated histories with git.bioconductor.org. But we really appreciate the pull request and would like to merge it. I am guessing your actual changes are not so major, in which case the easiest solution may be to re-fork and issue a new pull request.

Yep. I'll do that. Go ahead and close the request and I'll fix.
On Fri, Sep 15, 2017 at 6:13 PM, Levi Waldron<EMAIL_ADDRESS>wrote:

I think this is related to merging of unrelated histories with
git.bioconductor.org. But we really appreciate the pull request and would
like to merge it. I am guessing your actual changes are not so major, in
which case the easiest solution may be to re-fork and issue a new pull
request.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/waldronlab/curatedMetagenomicData/pull/97#issuecomment-329916403,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFpE0uy0ZeD0hiGWzkDxz_KPY6ZAaHPks5sivaMgaJpZM4PZhLZ
.

--
Sean Davis, MD, PhD
Center for Cancer Research
National Cancer Institute
National Institutes of Health
Bethesda, MD 20892
https://seandavi.github.io/
https://twitter.com/seandavis12


Removes deprecated fields and methods

Summary

Removes those items marked deprecated that will be removed at the next major version release.
Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[x] I have reviewed the styleguide for guidance on my code quality.
[x] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

I think https://github.com/paketo-buildpacks/packit/blame/7bb8ed3b5351b8c6a2e55a3eb591f0d9cc87e8a6/build.go#L64 also needs to be ripped out.

This shouldn't have been marked as deprecated to begin with. We still support it for those versions of the spec that use the field. I have removed the "Deprecated" comment from that field.


Adding BITS constants to match inbox primitive types.

Since 1.53.0, rust added the new constant BITS with type as u32, so it might be helpful to add it in uX crate as well for writing uniformed code.
Should be a straight-forward change, hence I have forked the repo and created a branch here: https://github.com/r12f/uX/tree/add-bits. Please let me know, how it looks! And if it makes sense to you, I can send out the PR for update.

If you're interested, check out my overhaul project https://github.com/JonathanWoollett-Light/ux2 where this is implemented e.g. https://docs.rs/ux2/latest/ux2/struct.i10.html#associatedconstant.BITS.

@r12f (or @JonathanWoollett-Light) this makes sense to me and if you want to open a PR for this I'll review it.  If not I'll probably take a look at adding it myself soon--I've needed this in a lib of mine that uses uX as well and ended up writing an extension trait for it, would be nice to have it in the lib).


Fails to download preview when the first "sample image" is animated (mp4/webm)

When the first preview image set by the model author is an animation, the extension fails to download a preview image.
What it should do: download the first preview image that is not an animation.
Example Lora where this happens: https://civitai.com/models/214538
For most of my Lora/Checkpoints it works as intended.
Many thanks for this extension as it makes browsing large local model stores a lot easier :)
-- update 10.59
Let me rephrase that, the extension downloads the mp4 but renames it to .png, which can't be displayed by gradio.
It should still download the first available png :)

If it helps someone else, I've made a quick correction to the python script so it works in most cases.
It's dirty, there are better ways to do it but I don't use python and I don't know the civitai framework, so it will do until someone more knowledgeable saves the day.
In scripts/preview.py
change the line:
image_url = images[0]['url']
into:
if (images[0]['type'] != "image"):
image_url = images[1]['url']
else:
image_url = images[0]['url']

A minor annoyance is that the api returns incorrect url for images - everything is .jpeg. The type property check is the correct approach (except for animated gif, not sure what it does there), would only use a while instead of just the second image (multiple animations happen). A list comprehension will do that neatly.
# Remove this line: if (len(images) == 0): continue
image_urls = [image['url'] for image in images if image['type'] == "image"]
if len(image_urls) == 0: continue
image_url = image_urls[0]
# Etc.


Grebe / Search templates broken in production

http://amigo.geneontology.org/grebe
Regardless of which template is chosen, filling in a value has no effect. It takes you to a page with all annotations in golr

Confirmed and serious. Closing code will need to add unit test.

Is this functionality also broken on amigo2-test.stanford.edu or does it work properly there?

Borked on test as well. Probably something trivial... Grump grump...

The new query bookmark, oddly, never seems to make it to the live search page. Some error in construction / liftoff on the generating page then.

Re-merged from master to try and get the latest fixes.

@stuartmiyasato I'm not going to have a complete testing platform for a bit (nakama is reloading, and I'm not sure it will take). Could you get the latest 2.4.x onto amigo2-test so I could take a whack at it before promoting the (very small change) to production?

@kltm I just installed the latest 2.4.x on amigo2-test.  I did not reload data so that is kind of old, but that shouldn't affect your ability to test the code, correct?  Let me know if you need a new data load as well.

GOOSE still loads slowly and the counts are off, but those are expected. This is now ready for production.
That said, we now have a new "hotfix" issue to deal with, so give me a few minutes to make that update before a production push. #364


[Dialog][AlertDialog][Popover][DropdownMenu] Prevent pointer-events reenabling prematurely (mobile)

Fixes #631
Fixes #761
Fixes #762
Fixes #763
I managed to fix these all in one go eventually.
@benoitgrelard  I believe I've also managed to provide a solution that merges both of our suggestions. My main concern was to keep the fix within useBodyPointerEvents since the issue is a side-effect of pointer-events enabling too soon, but I've only enabled the delay on pointerdown (because like you say, that's when it's an issue) and it's a touch or pen pointer.
Happy to continue to discuss alternate solutions as well if we have any because obviously, setTimeouts are never ideal.

UPDATE: Delay has been removed in favour of waiting for click event. I gave myself the idea here https://github.com/radix-ui/primitives/pull/767#issuecomment-874220750 😅

Alternatively, we change onPointerDownOutside to onClickOutside. I know that will make closing feel a bit slower but I'm not sure that making it feel more instantaneous is worth these side effects/timers.

Love this!

does this also negate the need for the change I have made in DismissableLayer's usePointerDownOutside?

Just for my benefit, are we talking about this?

One thing I've been wondering: does this also negate the need for the change I have made in DismissableLayer's usePointerDownOutside?

@benoitgrelard Potentially, I'll try replicate the issue you were experiencing and confirm.

@benoitgrelard Yep, looks like it's fixed there too 🎉

Spoke to Benoit about his issue and we think the fix there is still required since the fix in this PR will only apply to modal things.


itemHeight null value is not available

As per docs it states
If null, then the menu item heights will vary according to each menu item's intrinsic height.

The default value is [kMinInteractiveDimension], which is also the minimum height for menu items.

If this value is null and there isn't enough vertical room for the menu, then the menu's initial scroll offset may not align the selected item with the dropdown button. That's because, in this case, the initial scroll offset is computed as if all of the menu item heights were [kMinInteractiveDimension].

However the type of itemHeight is double, not double?, so I can't make each item different height.
Am I missing something?

I'll update the doc of this part.
Actually, itemHeight can't be null. If you've not used itemHeight parameter, it'll be the default kMinInteractiveDimension which is 48.0

So there's no way to set dynamic height to dropdown element?

Ok, thanks for answer, that makes sense. Basically I just have a list of elements which I need to display differently. IS there or do you plan for supporting known but different height elements? Like allow each DropdownMenuItem to have its own, known beforehand height prop ?

Let me think if we could add dynamic but predefined heights proper scrolling to the selectedItem.


Remove error log when parsing malformed JSON body

Addresses #1350

Yep, good point. Awesome, thank you! :rocket: :tada: :coffee:


Sc-6149 : Improve the application routing

Scope of changes
Sc-6149 : Improve the application routing
Type of change

[x] bug fix
[ ] new feature
[ ] documentation
[x] other (describe)

Acceptance criteria
Sc-6149 : Improve the application routing
Author checklist

[ ] I have manually tested the change and/or added automation in the form of unit tests or integration tests
[ ]  I have updated the dependencies list
[ ]  I have recompiled and included new protocol buffers to reflect changes I made
[ ]  I have added new test fixtures as needed to support added tests
[ ]   Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
[x]  I have moved the associated Shortcut story to "Ready for Review"

Reviewer(s) checklist

[ ] Any new user-facing content that has been added for this PR has been QA'ed to ensure correct grammar, spelling, and understandability.

Codecov Report

Merging #593 (66386e2) into main (b377917) will decrease coverage by 7.93%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #593      +/-   ##
==========================================
- Coverage   45.92%   37.98%   -7.94%
==========================================
  Files         510      154     -356
  Lines       14675     2427   -12248
  Branches     1171      614     -557
==========================================
- Hits         6740      922    -5818
+ Misses       6913     1329    -5584
+ Partials     1022      176     -846

Impacted Files
Coverage Δ

web/gds-user-ui/src/application/routes/index.tsx

...-user-ui/src/components/Sidebar/SidebarContent.tsx

...eb/gds-user-ui/src/components/StatusCard/index.tsx

web/gds-user-ui/src/hooks/useAuth.ts

...eb/gds-user-ui/src/modules/auth/callback/index.tsx

web/gds-user-ui/src/modules/auth/login/index.tsx

...s-user-ui/src/modules/dashboard/overview/index.tsx

web/gds-user-ui/src/utils/axios.ts

...b/gds-user-ui/src/components/ui/SuccessMessage.tsx

...r-ui/src/components/CollaboratorsSection/index.tsx

... and 345 more

Continue to review full report at Codecov.

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


Our Contributors dosent look good in README

i will make it like this

@vishanurag  plz assign me this


Add new builtin to check if currently in user or kernel mode

kstack will be empty if a probe (e.g. profile) fires while the CPU was in user-mode. Adding a builtin to check what mode we were in will make it easier to filter out invalid stacks.
See #1124
Platform-dependent solution: https://github.com/iovisor/bpftrace/issues/1124#issuecomment-582347103

Per @tyroguru, dtrace encoded this as arg1 for profile/interval probes vs. a separate builtin: https://docs.oracle.com/cd/E19253-01/817-6223/chp-profile/index.html
We can also go with that approach as well!

hmm. kstack should never be empty. bpf prog always runs in the kernel context.

There was the bug Yonghong fixed for kstack in syscall tracepoint right?

There was the bug Yonghong fixed for kstack in syscall tracepoint right?

yeah. original "lack of stack" issue could have been that bug.

Yonghong's patch fixed kstack in syscall tracepoints specifically (#442), but that's not the same as the issue here, which is that profile probes (and similar perf_events probe types, e.g. hardware:cpu-cycles) can return empty kernel stack traces.
I can still get empty kernel stack traces today with this repro:
#include <stdio.h>

double foo(double a, double b)
{
  return a/b;
}

int main()
{
  while(1)
    foo(999999999.0,<PHONE_NUMBER>343.0);
}

profile:hz:99 /comm=="a.out"/ { @[kstack, ustack] = count() }

Output shows various ustack values but kstack is always empty:
@[
,
        main+4
        __libc_start_call_main+128
]: 9
@[
,
        main+28
        __libc_start_call_main+128
]: 15
@[
,
        f1+19
        main+33
        __libc_start_call_main+128
]: 18
@[
,
        f1+4
        main+33
        __libc_start_call_main+128
]: 19
@[
,
        f1+24
        main+33
        __libc_start_call_main+128
]: 21


chore(Python): add paint the chess table algorithm

PR Checklist:

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is on refer on the language README.md file
[x] My addition does not have a spelling problem
[x] My submission has a proper and user-friendly description of the algorithm
[x] My submission has the time complexity of the algorithm
[x] My submission has sample input-output of the program (NOT FOR PYTHON)

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] New algorithm
[ ] Optimization in previous algorithms
[ ] Code style update
[ ] Refactor
[ ] Documentation
[ ] Other, please describe:

Briefly describe the changes in this PR

Other information:

Hi @Kochouseph26John,
Please rename the file from Chess color to Chess


NodeJS server fails to handle serialization errors during a unary response

The server's sendUnaryResponse does not call handleError correctly (it doesn't pass the call argument).  A server that tries to respond with an invalid message will produce this error instead of returning a status 13 to the client:
Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined
      at handleError (src/server.js:81:12)
      at sendUnaryResponse (src/server.js:135:5)
      at sendUnaryData (src/server.js:506:9)
      at Object.unary (test/server_test.js:120:11)
      at Object.wrapper [as func] (/Users/dduke/newtmp/projs/grpc/node_modules/lodash/lodash.js:4968:19)
      at src/server.js:499:13

Here's a test which reproduces the problem:
var grpc_client = require('../src/client.js');
var grpc = require('..');

var test_proto = grpc.load(__dirname + '/test_service.proto');
var test_service = test_proto.TestService.service;

describe('server', function() {
  it('handles serialization errors', function(done) {
    var test_server = new grpc.Server();
    test_server.addProtoService(test_service, {
      unary: function (call, callback) {
        call.sendMetadata(call.metadata);
        callback(null, {valid: false});
      }
    });
    var server_credentials = grpc.ServerCredentials.createInsecure();
    var test_port = test_server.bind('localhost:0', server_credentials);
    test_server.start();
    var TestClient = grpc_client.makeProtobufClientConstructor(test_service);
    var insecureCreds = grpc.credentials.createInsecure();
    var client = new TestClient('localhost:' + test_port, insecureCreds);
    client.unary(true, function(err) {
      assert.equal(err.message, '.Response#valid is not a field: undefined');
      test_server.forceShutdown();
      done();
    });
  });
});

Thank you for reporting this, but it was actually previously reported in #9554, and fixed in #9456. The v1.1.x branch will eventually be merged into master, and those changes will appear in any future releases of the Node library.

In fact, that fix should already be in the latest version of the Node gRPC library: 1.1.2.


Optimize STF generated paths to keep test paths as short as possible

Background
Windows platform's MAX_PATH restrictions have sporadically been causing STF based system tests to fail due to generated path lengths > MAX_PATH.
We have already been shortening some system test names as a fix.
However, to avoid such issues in future, we should investigate ways to optimize STF generated paths to keep them as short as possible.
Possible options to consider:

Timestamp: When STF based system tests are run coupled with TKG, there are two timestamp values added in the test paths-- one from TKG and one from STF (e.g. F:/Users/jenkins/workspace/Test_openjdk11_j9_sanity.system_x86-64_windows_mixed_cm_Nightly_testList_1/openjdk-tests/\TKG\test_output_16076325439603\MauveSingleInvocationLoadTest_OpenJ9_0/20201210-145632-MauveSingleInvocationLoadTest/generation/generation.st). Could we remove the STF generated timestamp?
1.1) Pro: It gives us test paths with only one timestamp in TKG runs.
1.2) Con: It violates the STF use-case of running tests locally using system test make layer - when the STF generated timestamp is essential to distinguish between multiple runs of a particular test.

STF appends the current tests's name after timestamp. This is useful when STF tests are run locally using the make layer, as we then get generated paths such as /tmp/stf/20201215-130158-MixedLoadTest/ - which clearly signify which test they belong to. However, when STF is used coupled with TKG (e.g. in Jenkins builds), we are already in a working directory that contains the test name, so the test folder name under that may not need the test name signifier again (e.g., ../MauveSingleInvocationLoadTest_OpenJ9_0/20201210-145632-MauveSingleInvocationLoadTest - which is unnecessary). Can we simply not append the test name in stf.pl ?
2.1) Pro: This gives us a shorter path in Jenkins runs.
2.2) Con: This means the local run using system test make layer would end up with paths without test name in them (e.g. /tmp/stf/20201215-130158).

@llxia @lumpfish

I run locally a lot, and find the current STF output naming system works very well.
Isn't the TKG name actually the playlist test target name (as opposed to the STF plugin test name).
The way this has been fixed before (and the preferable way imo) is to use using the Windows subst command to assign a drive letter to the root of the test output directory - e.g.
subst /s "T:" "F:/Users/jenkins/workspace/Test_openjdk11_j9_sanity.system_x86-64_windows_mixed_cm_Nightly_testList_1/openjdk-tests/\TKG\test_output_16076325439603\MauveSingleInvocationLoadTest_OpenJ9_0"

and from that point on use T: to refer to that location.
See https://github.com/AdoptOpenJDK/stf/pull/43 for more history.  The subst option appers to have been disabled because of cygwin.  Perhaps fixing that issue might be the best solution.

Have we tried mklink? Something like
mklink /J myShortDir F:/Users/jenkins/workspace/Test_openjdk11_j9_sanity.system_x86-64_windows_mixed_cm_Nightly_testList_1/