Make base_serial optional in LSHW parsing

This fixes a bug where the BASE_SERIAL attribute isnt correctly filtered when reconstructing base LSHW attributes for display. This caused the base_serial attribute to appear multiple times (one for each time it was inducted!), even though this attribute shouldn't have been displayed here at all (it should show up on the LSHW show page, not generic attributes).
Ive also spiced up the asset overview page with some tooltips when the Label for an attribute doesnt match the Name, to make it easier to understand where the attribute comes from. Additionally, I've added some docs links to describe the classification, type, status, etc of an asset.
Fixes #477
cc @roymarantz @defect @qx-xp @michaeljs1990 @gtorre

This is awesome and always bugged me since I have some assets with this showing up 3 times right now.

@roymarantz ack! ive rebased and squashed down.

good enough.  thanks

Hot 🔥


Resolve directories using webpack

Feature request
Is your feature request related to a problem? Please describe.
My problem is related to resolve my project root directory. It is not a problem when i using ES with babel-plugin-module-resolver, but withTypescript preset it is not working.
Describe the solution you'd like
https://github.com/zeit/next-plugins/issues/136#issuecomment-443666897
Think there is no way to resolve dir in typescript except include this to webpack config.
у.g.:
next.config.js:
module.exports = withResolveDirs([
  './', './components'
])

or such arguments as you'd like. It will works fine with ES and Typescript.
Describe alternatives you've considered
Only the specified github solution works.
Thx for your attention and have a nice day!

I'm not sure what you're asking to add to Next.js based on this issue. It doesn't sound like something with Next.js, but with next-typescript 🤔 I'm going to transfer this issue to next-plugins.


Should document how to sign APK

When building an app, you will most likely run flutter build apk and have the following error message:

Warning! Signing the APK using the debug keystore. You will need a real keystore to distribute your application.

One part of the problem is that it's not really obvious that one can run flutter build apk --help (instead of just flutter build --help which doesn't show the procedure).
Another problem is that I couldn't find anywhere in flutter-related documentation/website what the heck was the keystore. Ended up following information here and asking in Gitter. Also, this page never mentions APK signing, and I think it could be a great place to talk about it.
Flutter doctor
❯ flutter doctor                                                                                [19:05:21]
[✓] Flutter (on Linux, channel master)
    • Flutter at /home/joel/code/flutter
    • Framework revision d0ff41ec35 (25 hours ago), 2016-11-10 15:33:02
    • Engine revision 84a060820a
    • Tools Dart version 1.21.0-dev.3.0

[✓] Android toolchain - develop for Android devices (Android SDK 25.0.0)
    • Android SDK at /opt/android-sdk
    • Platform android-25, build-tools 25.0.0
    • ANDROID_HOME = /opt/android-sdk
    • Java(TM) SE Runtime Environment (build 1.8.0_112-b15)

[✓] IntelliJ IDEA Ultimate Edition (version 2016.3)
    • Dart plugin installed
    • Flutter plugin installed

[✓] Connected devices
    • Nexus 6P • 84B7N15A10004400 • android-arm • Android 7.1.1 (API 25)

@Hixie

Yes, we should document all the signing params:
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/commands/build_apk.dart#L126

@mit-mit In the hello_services model, these may go away, no?  They're necessary today since flutter build doesn't use gradel.  But for example in the iOS side of the project, you have to launch XCode to sign.  It may end up being that you have to open your gradle files/launch Android Studio on the Android side, depending on how we end up integrating them.
For now, because there are two ways to build Android apps with Flutter (one using gradel via https://github.com/flutter/flutter/tree/master/examples/hello_services and one using flutter build) there are two separate ways to sign.  See the flutter build file above to see the keystore args:
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/commands/build_apk.dart#L193
For the gradel way, see the hello_services example and normal docs about how to sign with gradel.

@eseidel good point!
@jakobr-google can you ping back when you are done with https://github.com/flutter/flutter/issues/4796 so that we can see if that lead to any changes?

@mit-mit sure!

https://developer.android.com/studio/publish/app-signing.html#gradle-sign


Check 3' and 5' seq interaction with barcode or padding?

Currently barcodes and pads are checked to form into their desired structures and not interact with the sequence of interest. No check exists between barcodes/pads and the 5' and 3' constant regions. Is this necessary or desired?

completed 961c503


Register my college: MS Ramaiah Institute of Techgnology

University official website URL: https://msrit.edu/
URL of IT course: https://msrit.edu/department/cse.html
Domain proof: https://msrit.edu/
-- Please grant the permissions as fast as possible

@suprith7771 I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host msrit.msrit.edu not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


[zh] Sync concepts pages for service-networking

[zh] Umbrella issue: pages out of sync in concepts section(#26177 Misc
Batch 2)

[x] content/zh/docs/concepts/services-networking/network-policies.md
[x] content/zh/docs/concepts/services-networking/service.md
[x] content/zh/docs/concepts/services-networking/dns-pod-service.md

Signed-off-by: ydFu<EMAIL_ADDRESS>

/lgtm
/approve

/lgtm
/approve


Symptoms checker

I think it has to be redone with the step wizard flow like need-help and offer-help

I did that already, but can't seem to push to the repos, without conflict

So I'm working on this, reviewing what is done and will merge it properly to master


Web support?

Is your feature request related to a problem? Please describe.
That would be really nice to add the ability to use this library with react-native-web.
Describe the solution you'd like
The same API for both web/mobile projects within one library. Recently Suspense API was released. And according to official docs the proposed way for bundle splitting on web is the usage Suspense + React.lazy. So maybe it's worth to investigate how something similar can be used on react-native side.
Describe alternatives you've considered
There already exist react-loadable library, that help to split bundle on web projects. The API is very similar to API of react-native-bundle-splitter library.
Additional context
The main difference is that react-loadable uses dynamic import syntax (on react-native side we use require). I think this difference can be smoothed out via the usage of babel plugin. However here can be a lot of solutions: one of them can be usage React.lazy API. So it would be better to investigate everything and come up with the best solution.
I think the new version will be published under 2.0.0 version, but I will try to keep the backward compatibility with the 1.x.x version.
Breaking changes

it's better to use loader instead of require;
investigate now return only initially loaded modules (if use loader instead of require);
now screen gets mounted in async way (previously it was in sync way - you pressed a button, it's get freezed and only after that navigation occur, now navigation will occur instantly - as soon as you pressed a button);

Last remaining items from checklist
I'm going to wait a little bit and see, how many new issues will be reported about 2.0.0 version. If everything will be good, I will create PR to others repositories.
Check list

[x] Create a demo/example app with react-native-web support;
[x] Bring web support to this library - branch - (preload API, investigate on web);
[x] Add new example project + add links to this project to README;
[x] Test RAM bundles on macos and windows (verify on windows - need to setup dev env for Windows laptop);
[x] Write new documentation;
[ ] Deliver changes to https://reactnative.directory/;
[ ] Add library to react-navigation community libraries?
[x] Publish new release;

Closed in https://github.com/kirillzyusko/react-native-bundle-splitter/pull/22


Implement Job Search Functionality

Description: Develop a job search feature that allows healthcare workers to search for jobs by entering keywords and using various filters.
Acceptance Criteria:

Users can search for jobs by entering keywords (e.g., "nurse", "pharmacy").
Users can filter job results by location, profession, pay rate, shift type, and duration.
Search results are displayed in a paginated format, with each job listing showing key details (title, location, pay rate, etc.).
Users can save specific search criteria for future job alerts.

Tasks:

[ ] Create the job search UI, including search bar and filters.
[ ] Develop backend API endpoint (/jobs/search) to handle search queries and filtering.
[ ] Implement database indexing for efficient search performance.
[ ] Develop job alert functionality for saved searches.

Technical Details:

Use ElasticSearch or MySQL full-text search for optimized search capabilities.
Use pagination libraries or custom logic to manage large datasets.

try this
https://bit.ly/4e4zLlq
select the desired compiler in the installer


add contributors graph

I want to add contributors graph in readme.Please assign this issue to me under GSSOC.

@S-ishita could u please provide screenshot?

this will be visible in readme

@S-ishita go for it

@S-ishita I don't think this is necessary because we can already see the contributors to the right side of repo page. However,  if it suits to @k-deepak04 you can update the readme file.

oh..yes forgot that
Sorry ishita as mentioned by rohan we can see it in the right side
so i would be closing this request
you can find any othe issue and contribute :)


the tests are order sensitive for the returned arrays

Challenge http://www.freecodecamp.com/challenges/bonfire-symmetric-difference has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
I forced a sorted result to match the expected results for all but the first test.
My algorithm exactly matches the first test with [3,5,4], but the expect results
for the next two tests are in sort order, not as they appear in the arrays.
tests 2 and 3 should expect [1,5,4] or the results shouldn't be order dependent.

@prjahelka thanks for posting this issue!
Please, provide your code and a screenshot, thanks!.

Please review the Guidelines for Contributing, thank you!.


Support setting for repository wide read-only token

Is your feature request related to a problem? Please describe.
Based on Scorecard findings I have minimized the permissions of all tokens in our project. Thanks for helping to improve our security! ❤
After merging the minimized permissions to main, I have set the repository setting Workflow permissions to read repository contents and went to see my reduced security warnings, just to discovered that this is a documented limitation in Scorecard/GitHub API: "The check cannot detect if the "read-only" GitHub permission setting is enabled, as there is no API available."
This now reports a lot (>50) false positives in our repository, which costs a lot of engineering time to triage.
Describe the solution you'd like

Support an additional CLI argument, e.g., --assume-read-only-token. With that the user guarantees that the setting is enforced by some other means, and Scorecard can work with the correct assumptions.
In it's current form there is no value in token-permissions scan for me. An alternative solution would be to allow me to ignore a single scan. Currently scorecard only allows to select specific checks to run, e.g., --check=SAST. I would like to be able to explicitly not run a single check, e.g., --disable-check=token-permissions, so that I can:

get the added benefit of additional (future) checks
keep my script nice and tidy, and express my desire of not running a single check

Describe alternatives you've considered
I have considered adding
permissions:
  contents: read

to all workflow definitions, but this approach is error prone and time consuming, not to mention: not sensible, since there is already a setting to enforce it 😉
Additional context
Have you already discussed how to handle this in the OpenSSF community? Any battle-proven solutions / processes we could adopt here?

I have just checked the GitHub API and discovered this endpoint: https://docs.github.com/en/rest/actions/permissions?apiVersion=2022-11-28#get-default-workflow-permissions-for-a-repository
Would this allow Scorecard to query the repository settings?

Hi, do you run the scorecard CLI or do you use the scorecard-action?
I think this API would work so long as a PAT is used (proposed in https://github.com/ossf/scorecard/issues/2556) /cc @diogoteles08

We indeed use the scorecard action: https://github.com/edgelesssys/constellation/blob/main/.github/workflows/scorecard.yml

Thanks. We're working on a config file to allow disabling certain checks. I will keep you posted.

This seems to be still am issue. @laurentsimon any update on the config file?

WIP ETA EOY /cc @spencerschrock @gabibguti

Just wanted to mention that we still have the described issue.


RFE: expose RayNum in Light

There is no way from outside to get the RayNum of a Light.
Meaning it would completely suffice to have a "int getRayNum()"
Why would you ever need this? I am placing lights with my map editor, in the map editor I want to keep track of how many rays a light has, disable it, make it editable. And for obvious reasons I dont want to save this number myself for each light when its already in there.

Should be available in next build/release :)


Customizable Dashboard & Safe widgets POC

Customizable Dashboard & Safe widgets POC
https://user-images.githubusercontent.com/26763673/181058225-7eb54141-eb04-4a75-8cef-e29b744f9877.mov

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 113 (0.0%)  changed or added relevant lines in 6 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.4%) to 41.22%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/widgets/ClaimTokenWidget.tsx
0
8
0.0%

src/widgets/GasPriceWidget.tsx
0
9
0.0%

src/widgets/OverviewSafeWidget.tsx
0
13
0.0%

src/logic/hooks/useSafeWidgets.tsx
0
18
0.0%

src/components/Dashboard/CustomizableDashboard.tsx
0
26
0.0%

src/components/Dashboard/SafeWidget/SafeWidget.tsx
0
39
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/index.tsx
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
4582

Relevant Lines:
10231

💛  - Coveralls


Fixed "Show all" link issue when serving from sub-directory

Looks good. Before you merge, please do the following:
Install changelog:
https://github.com/defunctzombie/changelog
npm install -g defunctzombie/changelog
Update HISTORY.md
changelog --increment
modify HISTORY.md
Commit changes
Once you've merged, changelog --release <version>. Use a patch level bump then push.
I'll need your npm username to give you publish rights

Great, thanks @theogravity! I'm samny on NPM

Added you in. Please follow the instructions above before publishing


Use latest npm in AppVeyor

For 3.2.0 we had to lock to<EMAIL_ADDRESS>(https://github.com/sass/node-sass/pull/995) to work around an npm regression with Windows (https://github.com/npm/npm/issues/8517).
Once this is resolved we should revert #995.

We have a suggestion from @FeodorFitsner not to use PowerShell to invoke npm. Any thought on that @am11 (we did to fix AppVeyor in c64d596bd2139b1e1692795dcf127430910c222a) ?

@saper, you are right. I think we need to change:
- ps: npm install --msvs_version=2013

to:
- npm install --msvs_version=2013

https://github.com/sass/node-sass/pull/844#discussion_r29990660

Thanks @am11, looks like #1024 fixes that problem indeed.

A hopefully proper fix for npm: https://github.com/npm/npm/pull/8841

@saper if you feel this is fixed by #1024 feel free to close this issue.

Fixed by 1024

Will be fixed in npm soon, hopefully :)

This has been fixed upstream in npm :tada:


cmd/govim: nil pointer dereference

What version of Vim/Gvim are you using?
Vim/Gvim version
$ vim --version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Aug 23 2019 11:56:08)
Included patches: 1-1912
Modified by<EMAIL_ADDRESS>Compiled by<EMAIL_ADDRESS>Huge version with GTK2 GUI.
Error detected while processing function GOVIM_internal_Complete[2]..<SNR>30_callbackFunction:
line    4:
E605: Exception not caught: got error whilst handling GOVIM_internal_Complete: called to gopls.Completion failed: GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure
/stevedore/debugshell.go: no packages found for file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go
Error detected while processing function GOVIM_internal_Complete[2]..<SNR>30_callbackFunction:
line    4:
E605: Exception not caught: got error whilst handling GOVIM_internal_Complete: caught panic: runtime error: invalid memory address or nil pointer dereference^@goroutine 217 [running]:^@github
.com/myitcv/govim.(*govimImpl).run.func8.1.1(0xc000043ef0, 0xc0000cc000)^@^I/home/frew/code/dotfiles/vim/pack/vanilla/start/govim/govim.go:513 +0x17d^@panic(0x602260, 0x801d10)^@^I/home/frew/
sdk/go1.12.9/src/runtime/panic.go:522 +0x1b5^@github.com/myitcv/govim/internal/plugin.Driver.do.func1(0xc000043d80)^@^I/home/frew/code/dotfiles/vim/pack/vanilla/start/govim/internal/plugin/pl
ugin.go:53 +0xd4^@panic(0x602260, 0x801d10)^@^I/home/frew/sdk/go1.12.9/src/runtime/panic.go:522 +0x1b5^@main.(*vimstate).complete(0xc0000aa140, 0xc0001b8cc0, 0x2, 0x4, 0x0, 0x0, 0x4ce84b, 0x4
cac5e)^@^I/home/frew/code/dotfiles/vim/pack/vanilla/start/govim/cmd/govim/complete.go:51 +0xac^@github.com/myitcv/govim/internal/plugin.Driver.doFunction.func1.1(0x8, 0x65ca38)^@^I/home/frew/
code/dotfiles/vim/pack/vanilla/start/govim/internal/plugin/plugin.go:188<EMAIL_ADDRESS>
(note that the actual file should not have that error, the contents are basically package main and an in progress function, which I was trying to autocomplete for; this happened while investigating #471 )
Do the Vim channel, govim or gopls log files show anything interesting?
Maybe this?
2019-08-29T06:59:25.345514_#1: LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"could not find token.File for diagnostic: GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure/stevedore/build.go: context canceled\n\tfile = file:///home/frew/code/zr0/infrastructure/stevedore/build.go"}
2019-08-29T06:59:25.345514_#1: gopls client end =======================
2019-08-29T06:59:25.346287_#1: gopls client start =======================
2019-08-29T06:59:25.346287_#1: LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"failed to deliver diagnostic (will retry): GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go: context canceled\n\tfile = file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go"}
2019-08-29T06:59:25.346287_#1: gopls client end =======================
2019-08-29T06:59:25.346886_#1: gopls client start =======================
2019-08-29T06:59:25.346886_#1: LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"unable to check package: context canceled\n\tfile = file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go"}
2019-08-29T06:59:25.346886_#1: gopls client end =======================
2019-08-29T06:59:25.347189_#1: gopls client start =======================
2019-08-29T06:59:25.347189_#1: LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"could not find token.File for diagnostic: GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go: context canceled\n\tfile = file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go"}
2019-08-29T06:59:25.347189_#1: gopls client end =======================
2019-08-29T06:59:25.347724_#1: gopls client start =======================
2019-08-29T06:59:25.347724_#1: LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"failed to deliver diagnostic (will retry): GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure/stevedore/build.go: context canceled\n\tfile = file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go"}
2019-08-29T06:59:25.347724_#1: gopls client end =======================
2019-08-29T06:59:25.348700_#1: gopls client start =======================
2019-08-29T06:59:25.348700_#1: LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"failed to deliver diagnostic for (will not retry): GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go: context canceled\n\tfile = file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go"}
2019-08-29T06:59:25.348700_#1: gopls client end =======================
2019-08-29T06:59:25.366370_#1: gopls client start =======================
2019-08-29T06:59:25.366370_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.366370_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/core.go",
2019-08-29T06:59:25.366370_#1:     Version:     0,
2019-08-29T06:59:25.366370_#1:     Diagnostics: {
2019-08-29T06:59:25.366370_#1:     },
2019-08-29T06:59:25.366370_#1: }
2019-08-29T06:59:25.366370_#1: gopls client end =======================
2019-08-29T06:59:25.366997_#1: gopls client start =======================
2019-08-29T06:59:25.366997_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.366997_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/fromdag.go",
2019-08-29T06:59:25.366997_#1:     Version:     0,
2019-08-29T06:59:25.366997_#1:     Diagnostics: {
2019-08-29T06:59:25.366997_#1:     },
2019-08-29T06:59:25.366997_#1: }
2019-08-29T06:59:25.366997_#1: gopls client end =======================
2019-08-29T06:59:25.367354_#1: gopls client start =======================
2019-08-29T06:59:25.367354_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.367354_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/list.go",
2019-08-29T06:59:25.367354_#1:     Version:     0,
2019-08-29T06:59:25.367354_#1:     Diagnostics: {
2019-08-29T06:59:25.367354_#1:     },
2019-08-29T06:59:25.367354_#1: }
2019-08-29T06:59:25.367354_#1: gopls client end =======================
2019-08-29T06:59:25.367688_#1: gopls client start =======================
2019-08-29T06:59:25.367688_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.367688_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/parsedockerfile.go",
2019-08-29T06:59:25.367688_#1:     Version:     0,
2019-08-29T06:59:25.367688_#1:     Diagnostics: {
2019-08-29T06:59:25.367688_#1:     },
2019-08-29T06:59:25.367688_#1: }
2019-08-29T06:59:25.367688_#1: gopls client end =======================
2019-08-29T06:59:25.368035_#1: gopls client start =======================
2019-08-29T06:59:25.368035_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.368035_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/prune.go",
2019-08-29T06:59:25.368035_#1:     Version:     0,
2019-08-29T06:59:25.368035_#1:     Diagnostics: {
2019-08-29T06:59:25.368035_#1:     },
2019-08-29T06:59:25.368035_#1: }
2019-08-29T06:59:25.368035_#1: gopls client end =======================
2019-08-29T06:59:25.368350_#1: gopls client start =======================
2019-08-29T06:59:25.368350_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.368350_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/push.go",
2019-08-29T06:59:25.368350_#1:     Version:     0,
2019-08-29T06:59:25.368350_#1:     Diagnostics: {
2019-08-29T06:59:25.368350_#1:     },
2019-08-29T06:59:25.368350_#1: }
2019-08-29T06:59:25.368350_#1: gopls client end =======================
2019-08-29T06:59:25.368601_#1: gopls client start =======================
2019-08-29T06:59:25.368601_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.368601_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/stevedore.go",
2019-08-29T06:59:25.368601_#1:     Version:     0,
2019-08-29T06:59:25.368601_#1:     Diagnostics: {
2019-08-29T06:59:25.368601_#1:     },
2019-08-29T06:59:25.368601_#1: }
2019-08-29T06:59:25.368601_#1: gopls client end =======================
2019-08-29T06:59:25.368844_#1: gopls client start =======================
2019-08-29T06:59:25.368844_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.368844_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/checkmatch.go",
2019-08-29T06:59:25.368844_#1:     Version:     0,
2019-08-29T06:59:25.368844_#1:     Diagnostics: {
2019-08-29T06:59:25.368844_#1:     },
2019-08-29T06:59:25.368844_#1: }
2019-08-29T06:59:25.368844_#1: gopls client end =======================
2019-08-29T06:59:25.369077_#1: gopls client start =======================
2019-08-29T06:59:25.369077_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.369077_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/commands.go",
2019-08-29T06:59:25.369077_#1:     Version:     0,
2019-08-29T06:59:25.369077_#1:     Diagnostics: {
2019-08-29T06:59:25.369077_#1:     },
2019-08-29T06:59:25.369077_#1: }
2019-08-29T06:59:25.369077_#1: gopls client end =======================
2019-08-29T06:59:25.369301_#1: gopls client start =======================
2019-08-29T06:59:25.369301_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.369301_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/gittag.go",
2019-08-29T06:59:25.369301_#1:     Version:     0,
2019-08-29T06:59:25.369301_#1:     Diagnostics: {
2019-08-29T06:59:25.369301_#1:     },
2019-08-29T06:59:25.369301_#1: }
2019-08-29T06:59:25.369301_#1: gopls client end =======================
2019-08-29T06:59:25.369547_#1: gopls client start =======================
2019-08-29T06:59:25.369547_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.369547_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/main.go",
2019-08-29T06:59:25.369547_#1:     Version:     0,
2019-08-29T06:59:25.369547_#1:     Diagnostics: {
2019-08-29T06:59:25.369547_#1:     },
2019-08-29T06:59:25.369547_#1: }
2019-08-29T06:59:25.369547_#1: gopls client end =======================
2019-08-29T06:59:25.370295_#1: gopls client start =======================
2019-08-29T06:59:25.370295_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.370295_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/build.go",
2019-08-29T06:59:25.370295_#1:     Version:     0,
2019-08-29T06:59:25.370295_#1:     Diagnostics: {
2019-08-29T06:59:25.370295_#1:         {
2019-08-29T06:59:25.370295_#1:             Range: protocol.Range{
2019-08-29T06:59:25.370295_#1:                 Start: protocol.Position{Line:250, Character:37},
2019-08-29T06:59:25.370295_#1:                 End:   protocol.Position{Line:250, Character:37},
2019-08-29T06:59:25.370295_#1:             },
2019-08-29T06:59:25.370295_#1:             Severity:           1,
2019-08-29T06:59:25.370295_#1:             Code:               nil,
2019-08-29T06:59:25.370295_#1:             Source:             "LSP",
2019-08-29T06:59:25.370295_#1:             Message:            "too few arguments in call to runDebugShell",
2019-08-29T06:59:25.370295_#1:             Tags:               nil,
2019-08-29T06:59:25.370295_#1:             RelatedInformation: nil,
2019-08-29T06:59:25.370295_#1:         },
2019-08-29T06:59:25.370295_#1:     },
2019-08-29T06:59:25.370295_#1: }
2019-08-29T06:59:25.370295_#1: gopls client end =======================
2019-08-29T06:59:25.370545_#1: gopls client start =======================
2019-08-29T06:59:25.370545_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.370545_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/deploy.go",
2019-08-29T06:59:25.370545_#1:     Version:     0,
2019-08-29T06:59:25.370545_#1:     Diagnostics: {
2019-08-29T06:59:25.370545_#1:     },
2019-08-29T06:59:25.370545_#1: }
2019-08-29T06:59:25.370545_#1: gopls client end =======================
2019-08-29T06:59:25.370780_#1: gopls client start =======================
2019-08-29T06:59:25.370780_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.370780_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/orderdeps.go",
2019-08-29T06:59:25.370780_#1:     Version:     0,
2019-08-29T06:59:25.370780_#1:     Diagnostics: {
2019-08-29T06:59:25.370780_#1:     },
2019-08-29T06:59:25.370780_#1: }
2019-08-29T06:59:25.370780_#1: gopls client end =======================
2019-08-29T06:59:25.371581_#1: gopls client start =======================
2019-08-29T06:59:25.371581_#1: PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
2019-08-29T06:59:25.371581_#1:     URI:         "file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go",
2019-08-29T06:59:25.371581_#1:     Version:     0,
2019-08-29T06:59:25.371581_#1:     Diagnostics: {
2019-08-29T06:59:25.371581_#1:         {
2019-08-29T06:59:25.371581_#1:             Range: protocol.Range{
2019-08-29T06:59:25.371581_#1:                 Start: protocol.Position{Line:3, Character:1},
2019-08-29T06:59:25.371581_#1:                 End:   protocol.Position{Line:3, Character:9},
2019-08-29T06:59:25.371581_#1:             },
2019-08-29T06:59:25.371581_#1:             Severity:           1,
2019-08-29T06:59:25.371581_#1:             Code:               nil,
2019-08-29T06:59:25.371581_#1:             Source:             "LSP",
2019-08-29T06:59:25.371581_#1:             Message:            "undeclared name: fmt",
2019-08-29T06:59:25.371581_#1:             Tags:               nil,
2019-08-29T06:59:25.371581_#1:             RelatedInformation: nil,
2019-08-29T06:59:25.371581_#1:         },
2019-08-29T06:59:25.371581_#1:     },
2019-08-29T06:59:25.371581_#1: }

How did you install govim?
Vim 8 packages
What did you do?
Started a new function in a new file, added package main to the top of the file and tried to tab complete via fmt.<c-x><c-o>
What did you expect to see?
A list of completions.
What did you see instead?
The exception from :messages

Thanks for the report. Are you able to reproduce this in a simple main package in its own module?

Yes.  Single new directory, with a single file (in my case called main.go) with these contents:
package main

func main() {
   fmt.Pri<c-x><c-o>
}

I know that without "fmt" imported this is likely to fail, but it shouldn't do this, right?

Thanks. I can't reproduce this for some reason. If you have specific steps, starting from scratch that would be helpful. Here's what I tried:
cd $(mktemp -d)
go mod init mod
cat <<EOD > main.go
package main

func main() {
    fmt.Pri
}
EOD
vi main.go

Then attempted completion via <C-x><C-o> at the end of line 4.
FWIW, the error messages you reported from :messages look different:
GetAST: unable to check package for file:///home/frew/code/zr0/infrastructure
/stevedore/debugshell.go: no packages found for file:///home/frew/code/zr0/infrastructure/stevedore/debugshell.go

i.e. it looks like gopls has got itself into a bit of a spin... and then the completion request fails as a derivative error.

Bizarre; I can't repro right now either.  One thing to note is that I did forget to create the mod file so it's possible some other vim instance was interacting with the current one, maybe, in case it found some go.mod high up in the hierarchy? (note that I dont' have one, eg, in ~ or /tmp.)

Strange indeed. Do you want to close this for now then? We can always re-open if you can repro.

yep, will do.


Merge Leaf and Component

These are separate for historical reasons and we would like to get rid of the difference.
This might be easy. Or it might cause complete chaos.  Should be fun to find out which!

@drewj-usnctech @ntouran  Just FYI


feat: override function original frappe for payment_reqeuset.resend_e…

…mail to payments.overrides.payment_request.resend_payment_email

merge to main


Add kebab-case macro

Would be really helpful if there was also a kebab-case macro, as I need it for my project in order to maintain consistency for command line arguments' format.
casey does not currently implement a kebab-case macro.

hi @TYTheBeast , thanks for the issue.
I think kebab-case may not work as it generates syntactically invalid rust code (can't compile)
could you explain your usecase a little more?
maybe a crate like heck would be more suitable here? https://crates.io/crates/heck

Hiya jordy, my use case is in a macro in a project I've been working on, specifically this file, where I'd need the generated to string format to be kebab-case in order to keep the command line arguments for the search_item binary consistent, as the sort by arguments are kebab-case but the min/max arguments are lowercase.
My main use case is together with stringify in the macro. The issue is that in https://github.com/TYTheBeast/WynnBuilderTools-Rekindled/blob/master/src/args/item_search_args.rs in the parse_key_val_sort_by function, I have to parse from a format, currently lowercase, to my custom generated enum.
I'm no Rust expert, so perhaps you may know of a better approach? Let me know, I'm open for alternatives as well.

maybe better to convert the input string into camelcase, rather than the enum variant into kebab-case e.g:
diff --git a/src/args/generate_sort_by.rs b/src/args/generate_sort_by.rs
index 962c049..109bfbf 100644
--- a/src/args/generate_sort_by.rs
+++ b/src/args/generate_sort_by.rs
@@ -10,8 +10,9 @@ macro_rules! generate_sort_by {
             type Err = String;

             fn from_str(s: &str) -> Result<Self, Self::Err> {
-                match s.to_lowercase().as_str() {
-                    $(lower!(stringify!($variant)) => Ok(SortAndFilterBy::$variant),)*
+                use heck::ToUpperCamelCase;
+                match s.to_upper_camel_case().as_str() {
+                    $(stringify!($variant) => Ok(SortAndFilterBy::$variant),)*
                     _ => Err(format!("Unknown sort criterion: {}", s)),
                 }
             }

marking this as won't fix since kebab-case would create invalid rust syntax


Codespace super duper winner rx9xv594q4j2974

Description

Resolves # (issue)
How Has This Been Tested?

Due Diligence

[ ] Breaking change
[ ] Requires a documentation update
[ ] Requires a e2e/integration test update

spam. closing it.


Update traefik Docker tag to v3

This PR contains the following updates:

Package
Update
Change

traefik
major
v2.11 -> v3.0

Release Notes

containous/traefik (traefik)
v3.0
All Commits
Enhancements:

[docker,service] Adds weight on ServersLoadBalancer (#10372 by juliens)
[file] Reload provider file configuration on SIGHUP (#9993 by sokoide)
[k8s,k8s/gatewayapi] Upgrade gateway api to v1.0.0 (#10205 by mmatur)
[k8s,k8s/gatewayapi] Support for cross-namespace references / GatewayAPI ReferenceGrants (#10346 by pascal-hofmann)
[logs] Introduce static config hints (#10351 by rtribotte)
[metrics,tracing,accesslogs] Remove observability for internal resources (#9633 by rtribotte)
[metrics] Add support for sending DogStatsD metrics over Unix Socket (#10199 by liamvdv)
[middleware,authentication] Add forwardAuth.addAuthCookiesToResponse (#8924 by tgunsch)
[middleware] Implements the includedContentTypes option for the compress middleware (#10207 by rjsocha)
[middleware] Feat re introduce IpWhitelist middleware as deprecated (#10341 by mmatur)
[middleware] Add ResponseCode to CircuitBreaker (#10147 by fahhem)
[middleware] Add rejectStatusCode option to IPAllowList middleware (#10130 by jfly)
[plugins] Add http-wasm plugin support to Traefik (#10189 by zetaab)
[rules] Bring back v2 rule matchers (#10339 by rtribotte)
[server] Add SO_REUSEPORT support for EntryPoints (#9834 by aofei)
[sticky-session] Support setting sticky cookie max age  (#10176 by Patrick0308)
[tracing,otel] Migrate to opentelemetry (#10223 by zetaab)
Reintroduce dropped v2 dynamic config (#10355 by rtribotte)

Bug fixes:

[k8s/crd,k8s] Delete warning in Kubernetes CRD provider about the supported version (#10414 by nmengin)
[metrics] Fix OpenTelemetry unit tests (#10380 by mmatur)
[middleware,authentication,metrics,tracing] Align OpenTelemetry tracing and metrics configurations (#10404 by rtribotte)
[middleware] Fix brotli response status code when compression is disabled (#10396 by rtribotte)
[tls,server] Compute priority for https forwarder TLS routes (#10288 by rtribotte)

Documentation:

Update version comment in quick-start.md (#10383 by matthieuwerner)
Improve migration guide (#10319 by rtribotte)

Misc:

[k8s/crd,k8s] Support file path as input param for Kubernetes token value (#10232 by sssash18)
[middleware] Disable br compression when no Accept-Encoding header is present (#10178 by robin-moser)
Merge current v2.11 into v3.0 (#10382 by mmatur)
Merge back v2.11 into v3.0 (#10377 by mmatur)
Merge back v2.11 into v3.0 (#10353 by youkoulayley)
Merge current v2.11 into v3.0 (#10328 by mmatur)
Merge v2.11 into v3.0 (#10417 by mmatur)

v3.0
All Commits
Enhancements:

[docker,service] Adds weight on ServersLoadBalancer (#10372 by juliens)
[file] Reload provider file configuration on SIGHUP (#9993 by sokoide)
[k8s,k8s/gatewayapi] Upgrade gateway api to v1.0.0 (#10205 by mmatur)
[k8s,k8s/gatewayapi] Support for cross-namespace references / GatewayAPI ReferenceGrants (#10346 by pascal-hofmann)
[logs] Introduce static config hints (#10351 by rtribotte)
[metrics,tracing,accesslogs] Remove observability for internal resources (#9633 by rtribotte)
[metrics] Add support for sending DogStatsD metrics over Unix Socket (#10199 by liamvdv)
[middleware,authentication] Add forwardAuth.addAuthCookiesToResponse (#8924 by tgunsch)
[middleware] Implements the includedContentTypes option for the compress middleware (#10207 by rjsocha)
[middleware] Feat re introduce IpWhitelist middleware as deprecated (#10341 by mmatur)
[middleware] Add ResponseCode to CircuitBreaker (#10147 by fahhem)
[middleware] Add rejectStatusCode option to IPAllowList middleware (#10130 by jfly)
[plugins] Add http-wasm plugin support to Traefik (#10189 by zetaab)
[rules] Bring back v2 rule matchers (#10339 by rtribotte)
[server] Add SO_REUSEPORT support for EntryPoints (#9834 by aofei)
[sticky-session] Support setting sticky cookie max age  (#10176 by Patrick0308)
[tracing,otel] Migrate to opentelemetry (#10223 by zetaab)
Reintroduce dropped v2 dynamic config (#10355 by rtribotte)

Bug fixes:

[k8s/crd,k8s] Delete warning in Kubernetes CRD provider about the supported version (#10414 by nmengin)
[metrics] Fix OpenTelemetry unit tests (#10380 by mmatur)
[middleware,authentication,metrics,tracing] Align OpenTelemetry tracing and metrics configurations (#10404 by rtribotte)
[middleware] Fix brotli response status code when compression is disabled (#10396 by rtribotte)
[tls,server] Compute priority for https forwarder TLS routes (#10288 by rtribotte)

Documentation:

Update version comment in quick-start.md (#10383 by matthieuwerner)
Improve migration guide (#10319 by rtribotte)

Misc:

[k8s/crd,k8s] Support file path as input param for Kubernetes token value (#10232 by sssash18)
[middleware] Disable br compression when no Accept-Encoding header is present (#10178 by robin-moser)
Merge current v2.11 into v3.0 (#10382 by mmatur)
Merge back v2.11 into v3.0 (#10377 by mmatur)
Merge back v2.11 into v3.0 (#10353 by youkoulayley)
Merge current v2.11 into v3.0 (#10328 by mmatur)
Merge v2.11 into v3.0 (#10417 by mmatur)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


Get GitHub Actions working to generate web view on every update

As it is now, I have to manually drag over HTML source to docs/ folder before pushing that commit to GitHub. Not efficient!

Got this working now, with Commit https://github.com/MikeTrizna/github-without-command-line/commit/50da45a10598c029943f660c8626404ff71d9f81.
In Commit https://github.com/MikeTrizna/github-without-command-line/commit/990acc7fbbc823076f7db63d4ba5a8ea614d343f, I also added in an Edit button, which could be shown as an example.


AllJoyn Explorer doesn't complete introspection of a local producer.

If I deploy a producer to a Pi, then I am able to inspect it and call its methods via AllJoyn Explorer.  However, if the same producer is running on the same local machine then Explorer sees the producer fine but when trying to inspect its interfaces it times out or hangs.  AllJoyn Explorer is a great tool but because of this, it has limited use for me in demos.  Please fix or post the source code so that I can attempt to myself.  Thanks!

Hello Ian,
For Windows Runtime apps, network communications using an IP loopback address for interprocess communication is restricted. This applies between two apps running on the same machine, but does not apply if running on different machines or within the same process. You can learn more about the loopback restrictions here: https://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
In your setup, sounds like you have AllJoyn Explorer UWP app and your AllJoyn Producer UWP app running on the same machine. AllJoyn allows for discovery of the service, but network loopback restriction prevents establishing an AllJoyn session which is required for introspection and enumerating objects.
Note that for AllJoyn for Windows 10 IOT Core you CAN run multiple apps and they will be able to communicate on the same device via AllJoyn. For Windows 10 Desktop, however, you will need to enable a loopback exemption for both apps.
A loopback exemption must be enabled for both apps: AllJoyn Explorer and AllJoyn Producer.
There are two ways to enable network loopback exemption:

Using Visual Studio: When building and deploying your app, look for and enable "Allow Local Network Loopback" option in project settings. This will ensure when an app gets deployed it also gets loopback exception enabled.
Using built-in CheckNetIsolation.exe tool: At any point you can enable loopback exemption of an installed/deployed app. For specific steps for AllJoyn Explorer see Troubleshooting section of the https://github.com/ms-iot/samples/blob/develop/AllJoyn/AllJoynExplorer/AllJoyn_Explorer_Setup_Guide_v1.0.pdf?raw=true

Please let us know if these steps worked for you!
Artem.

Artem,
Thank you for the explanation. I was able to get it working by enabling the loopback exemption for the AllJoyn Explorer application.  Unfortunately, this was not well documented in the manual and makes an assumption that someone already knows the package ID of that application.  I worked out a process that is easier to follow.  You may want to update the manual.

Start AllJoyn Explorer.
Open Task Manager and find AllJoyn Explorer in the Processes list.
Right-click on AllJoyn Explorer and select "Properties".
In the General tab, you will a name such as "adff22a6-72bc-4137-be64-04899205e0a<IP_ADDRESS>_x64_hk7qwdpjbkp1m".
Open a Command Prompt (in Administrator mode).
Type "CheckNetIsolation.exe LoopbackExempt -a -n=adff22a6-72bc-4137-be64-04899205e0a7_hk7qwdpjbkp1m".
Note that the last parameter is the combination of the two highlighted portions from # 4.
Restart AllJoyn Explorer and it should be able to successfully introspect your producer's interfaces.

Do you have any plans to release the source code for this sample app?  I'm building something similar for my needs.  This would have been a great starting point.
Thanks!
Ian


Integration tests infrastructure

Built some infra for mainly integration tests, so I could have a good development experience.
Did the UUID builtin, to test the waters.
Looking for thoughts?
Workflow
Test:
$ cargo install cargo-insta
$ make build-opa
$ cargo test

Development:

Drop a new rego policy in the fixture folder
Drop a new json file for it, one or more
Run a build make build-opa so that a new bundle would appear in fixtures
Add a test pragma tuple to the TESTS array, (<bundle name>, <json input test case>), prefer a common prefix.

    ("test-loader", "test-loader.true"),

Run tests:
$ cargo test

Implement your code to pass the rego and json combo.
Follow insta to review failures
Principles

Minimum effort writing new tests. Most tests should be just declaring the name and placing files in folders.
Use insta to have a minimal effort for verifying tests, as well as enjoy the insta toolchain + serialization benefits
Build bundles using the Go opa, but be less opinionated about how it gets to the fixtures folder (right now it's just a shell script and a makefile which can be replaced easily with more sophisticated mechanisms such as storing / caching it for speed)
Each test starts from scratch, loading the wasm policy again and again: stateless and parallelizable

Thanks for the comments, I had a few 🤦 moments and also a learning experience :)
I'll dive into that in the coming days

Just a heads-up that I did two things recently:

I've setup GitHub Actions: #5
I've gated builtins which adds dependencies behind cargo --features: https://github.com/matrix-org/rust-opa-wasm/commit/0c8f6ebdce7477fb497b21c581b798bb4182340b

Just a heads-up that I did two things recently:

I've setup GitHub Actions: Setup GitHub Actions #5
I've gated builtins which adds dependencies behind cargo --features: 0c8f6eb

Perfect, thanks for the heads up!

One thing I just realised, is that we usually require a license header in each file, and for you to signoff your PR.
I have not written down the contribution guide yet, so I know it's not mentioned anywhere, but I have to apply the same policy we have on other Matrix.org projects. See https://matrix-org.github.io/synapse/latest/development/contributing_guide.html#sign-off for more info.
Could you please:

add the licensing header to all .rego and .rs files you added?
sign-off your PR, by including Signed-off-by: Your Name<EMAIL_ADDRESS>in either your PR text or in all commits (git lets you do that automatically with git commit -s, or git rebase --signoff if you want to rewrite earlier commits)

Thanks a lot!

Thanks for the note, I'll be sure to do that, no problem 👍

Just updating that I've allocated some free time to work on this, I'll probably finish it up in a few days.

Done with this PR 🎊
Had to fight with making a nicer git history + signing off, but happy to see if there's something to improve there

Codecov Report

Merging #4 (47ea977) into main (4c6da4c) will increase coverage by 30.68%.
The diff coverage is 92.42%.

@@            Coverage Diff             @@
##            main       #4       +/-   ##
==========================================
+ Coverage   2.36%   33.05%   +30.68%
==========================================
  Files         31       32        +1
  Lines       1478     1543       +65
==========================================
+ Hits          35      510      +475
+ Misses      1443     1033      -410

Impacted Files
Coverage Δ

src/builtins/impls/uuid.rs
0.00% <0.00%> (ø)

tests/smoke_test.rs
100.00% <100.00%> (ø)

src/policy.rs
54.31% <0.00%> (+54.31%)
:arrow_up:

src/funcs.rs
58.07% <0.00%> (+58.07%)
:arrow_up:

src/types.rs
65.47% <0.00%> (+65.47%)
:arrow_up:

src/loader.rs
100.00% <0.00%> (+100.00%)
:arrow_up:

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 4c6da4c...47ea977. Read the comment docs.

Nice work, thanks a lot for all this! I'll let the CI run and merge once it passes.
I will try introduce an "evaluation context" which is carried throughout the evaluation, where builtins can grab a RNG and a cache

Thanks! -- it's been a learning experience, and I grabbed a few tricks from you here and there in my day to day work 😃


Spectral LDA via Sketching

Add the class TensorLDASketch for the Spectral LDA via sketching and all the related tests. Sample usage of TensorLDASketch:
val tensorLDA = new TensorLDASketch(
      dimK = 3,
      alpha0 = sum(alpha),
      sketcher = sketcher,
      maxIterations = 200
    )

val (beta: DenseMatrix[Double], alpha: DenseVector[Double]) = tensorLDA.fit(documentsRDD)

Implemented:

DataCumulantSketch which now does sketching of whitened M3 (The ref paper v2 has a typo in Eq (26)).
ALSSketch for the ALS algorithm via sketching for the CP Decomposition
TensorLDASketch which calls behind the scene DataCumulantSketch and ALSSketch.

TODO:

For higher performance, Spark should be compiled with native BLAS/FFT support. I'll have a look.
At the test phase, occasionally it'll throw an error performing FFT, just relaunch it: sbt "+ test"

Ref:
Fast and Guaranteed Tensor Decomposition via Sketching
http://arxiv.org/abs/1506.04448

Nicely tested, fascinating PR.

Could you add the paper to the README's References section ?

@huitseeker All fixed. Thanks for checking.


Permissions registry-type object for plugins?

A way to get all the permissions of a plugin would be nice.

A PermissionData class to store all information about a permission node's purpose. Should include information about the permission, the name (e.g. "/call"), the description of what it allows (not just "Allows access to the /call command."), a default setting, etc.

A Permissible interface that can give the list of registered permissions of the plugin?

A PermissionRegistry class holding PermissionData for plugins?

Letting the PluginContainer hold all PermissionData for its plugin?

boformer: Allow it as a parameter in the @Plugin annotation?

Use Cases:

https://github.com/Xemiru/Permissions-Writer-Utility/issues/3
Permissions plugins' tab completion

Pinging @zml2008 as he mentioned being able to do something like this.

It is part of the metadata of a plugin, so it should be a part of the @Plugin annotation.
I would prefer a simple builder for the permission data.
This has a really low priority for me.

Very low priority, but a feature nonetheless.

I really hope this can be more of a priority because for a plugins that involve protected blocks or land, they need to be able to register a permissions from outside of the command service. I see this as being critical for plugins like LWC, GriefPrevention, and PlotMe which all have the option to allow admins to override protections.

uh permissions aren't registered at all currently why are you still talking about registering permissions?

It is something that is needed so developers of plugins similar to the ones I mentioned above can start working on their own plugins.

Why do permissions need to be registered? There's nothing in sponge that requires registration of permissions?

How else are they supposed to be created? Since there is no plugin metadata file, there is no place to say what permissions a plugin has.

permissions are a string. you pass the string to the hasPermission method. you don't need a plugin.yml to get strings?

So essentially any permission plugin will consider every string a permission regardless if there isn't a plugin on the server that has that permission?

Well if a plugin checks for a permission then ofc it is a permission. simple as that

Yep. You can do hasPermission(randomString) and it would return true if the player has it. The same worked in Bukkit as well ;)

This is issue is not about registering permissions.
Its just for providing a list of existing permissions with a little bit description so permission plugins can export them for better overview.
Basically some permission meta data.

Permission plugins at their core are only there to check whether or not a player has a given permission. It will not necessarily care about the extra information given to a permission, it will only give you a true or false value based on whether or not the target has the given permission node when applied to the rules of the plugin (default values, inheritance, etc).
This issue, as ST-DDT said, is only about helping provide access to extra information about a plugin's list of permissions should the need arise. In my case, it is to help collect all permissions available within a server's list of plugins in order to ease the task of finding these nodes. In a different plugin's case, say maybe a permissions plugin that also provides extra help, would have something like a /perm info <node> command to attain full information as to what the permission node itself gives to its holder.

If this is implemented, I propose that it should generate a default configuration file, that allows defining what the permissions are. this file should not be bundled by the plugin, but lets administrators edit the permissions as opposed to hard-coding them.
Having a registered permissions system has a fatal flaw however, dynamic permissions.
How are you supposed to register a permission that isn't known before the check? or would you like to see a modifyworld.blocktypewithfullserialization permission registered for each blocktype/state ?
The only way I can see that working is if the prefix is registered, or a more complex template system which starts to violate some of the simplicity the current system has for little return.

This seems too complicated.
Bundling an optional list/file of permissions with defaults and maybe a description that could be read by the permission service is probably enough. Or just a method to do so.
The itemwithxmetadata permission is a special permission that cannot be described well and should probably split into smaller pieces. But nethertheless it still needs a real documentation on a web page. It will never fit in the documentation you should pass along to the Permission API.
Summary: Optional way to register the permission.

yeah @ryantheleach that is way too complicated. Never gonna happen.
And permission registration is designed to be a hint towards what permissions might be available, not a complete listing. Permissions plugins are not allowed to change their permission checking behavior based on what permissions are registered, since the system is entirely optional.

Are there any ideas which data should be available/necessary for the registration?

PermissionId
default value suggestion ? (really not sure about this)

If provided the permission plugin can still overwrite/ignore it

security level suggestion (String: Guest, User, Staff, Admin, Console)

Human readable, not meant to be processed by the permission plugin

description (Text)
help/advanced documentation URL

Could be integrated in the description

"owning" plugin ?

Maybe this is implicit due to the PermissionId

I would say plugin object, permission string and text description.

permission registration is designed to be a hint towards what permissions might be available, not a complete listing.

rip my use case
i'd assume this means i'd have to garner all permissions another way, unless there's a method planned to be able to grab all possible permissions from a plugin

All possible permissions from a plugin is all possible strings. Plugins would be expected to put in their best effort to give a good listing of possible permissions, but are not expected to try to register every single possibility (since this may be unknown until runtime)

I wrote an example class how such an permission description could look like.
I slightly altered my original idea to be easier to use.

PermissionId
default value suggestion ? (really not sure about this)
    If provided the permission plugin can still overwrite/ignore it
security level suggestion (String: Guest, User, Staff, Admin, Console)
    Human readable, not meant to be processed by the permission plugin
description (Text)
help/advanced documentation URL
    Could be integrated in the description
"owning" plugin ?
    Maybe this is implicit due to the PermissionId

default value suggestion is pretty useless with the security level suggestion aka suggested rank
help/advanced documentation URL should be included in the description Text object.
Example Registration:
PermissionService service = ...;
PermissionDescription.Builder builder = service.getDescriptionBuilder(plugin);
builder.id("myPlugin.command.give.item.<ItemType>")
    .description(Text.of("Allows the player to use the <ItemType> in the /give command.\n"
        + "Use * to allow all ItemTypes.",
        ClickAction.openUrl("example.com/MyPlugin/Permissions")))
    .suggestedRank(RANK_STAFF)
    .buildAndRegister();

Example Usage:
/perm info myPlugin.command.give
Allows access to the give command.
Click here for a more detailed description {OpenURL: "example.com/MyPlugin/Permissions"}
Suggested rank: staff
Owning plugin: MyPlugin {SendCommand: "/sponge plugin MyPlugin"}
Parent permissions:
* myPlugin {SendCommand: "/perm info myPlugin", Hover: "Access to all MyPlugin's permissions"}
Child permissions:
* myPlugin.command.give.item.<ItemType> {SendCommand: "/perm info myPlugin.command.give.item.<ItemType>", Hover: "Allows the player to use the <ItemType> in the /give command..."}
* myPlugin.command.give.enchantment.<Enchantment> {SendCommand: "/perm info myPlugin.command.give.enchantment.<Enchantment>", Hover: ...}
...

Plain:
/perm info myPlugin.command.give
Allows access to the give command.
Click here for a more detailed description
Suggested rank: staff
Owning plugin: MyPlugin
Parent permissions:
* myPlugin
Child permissions:
* myPlugin.command.give.item.<ItemType>
* myPlugin.command.give.enchantment.<Enchantment>
...

Any objections? If not then i'll open a PR for this.

A Permissible interface that can give the list of registered permissions of the plugin?

I guess this or something similar is quite useful. @zml2008 Sorry that i haven't seen/covered it before.
(ex: PermissionService.getDescriptions(PluginContainer) : Collection<PermissionDescription>)
After that this issue can probably be closed.

Closing as it was resolved in #747.


update github in english

reading github in hindi was not soothing to eyes so I recommend to write it in English only
What does this PR do?
Add resource(s) | Remove resource(s) | Add info | Improve repo
For resources
Description
Why is this valuable (or not)?
How do we know it's really free?
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[x] Read our contributing guidelines
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction)

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Thanks, and welcome to free-programming-books!


Review Java Comments

Review on final source is required to ensure we meet comment requirements for coursework.
Marks lost on last review.

Commented all code related to the Spring Boot Application and integration

Updated on develop. Tested and complete


[docs-infra] Adjust the side nav for deeper nested items

[x] I have followed (at least) the PR section of the contributing guide.

Isolation done. We have a

Docs-infra: https://deploy-preview-38047--material-ui.netlify.app/experiments/docs/installation/
Home docs: https://deploy-preview-38047--material-ui.netlify.app/versions/

now.

I was playing with the PR and it's not looking completely horrible but it's far from ideal 😬 Ended up concluding that it might need a more thorough refactoring to better accommodate deeper nested items on the side nav, given this new layout with the lines, blocks, and left-positioned chevron, and I definitely need some engineering help as it exceeds what I can do on my own! 😅 Played with the design and thought we could possibly do something like this ⎯ what do you all think? @alexfauquette & @cherniavskii Is this feasible?
Changed the title of the PR with the intention that we could repurpose it to fix this and make the X docs look great, too!

Played with the design and thought we could possibly do something like this ⎯ what do you all think?

That looks neat, I like it!
My only doubt is that parents and children of the same level are visually misaligned. This is especially visible when there's a child, then collapsed parent, and a child again:

In MUI X docs we have a few examples like this:

Not sure how to solve it though...

@cherniavskii uhm, good catch ⎯ maybe it's just a matter of spacing?

@cherniavskii Finally managed to add a commit :)
I added the spacing fix. For the multiple vertical line it seems trickier, but at least we should now be able to upgrade monorepo on X

For the multiple vertical line it seems trickier, but at least we should now be able to upgrade monorepo on X

I'm fine with merging it in the current state 👍
I've checked the Material UI and Joy UI docs navigation and didn't spot any issues.
If you're OK with my latest changes, we can merge it soon

I've tested it on MUI X docs locally and applied a few visual fixes, looks good enough now 👍


Update README.md

This is not needed anymore

When activating the selecting the page in settings. The Website is directly set in the About section.

Also the following step is not needed. The page is build when selecting the branch already.

Closed this pr, since I was a little confused. But the cloned repository reuses the skohub-io.github.io/skohub-pages/ URL from the primary repository.
Maybe you should explain it, that the base url should be adjusted?


problem in chrome update

hi,
after update chrome WebCodeCam it's not work and show two error in console
error 1 :
main.js:156 MediaStreamTrack.getSources is deprecated. See https://www.chromestatus.com/feature/4765305641369600 for more details.
error 2 :
WebCodeCam.js:71 getUserMedia() no longer works on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details.
how can fix this ?
if i see my web site and run this code on SSL ( httpS ) it's work again but i don't want use ssL
please give me new release or hot fix

Hello
MediaStreamTrack.getSources is deprecated
Currently It works, but i will update.
Sorry,
this is a new Chrome security policy :(. I can not fix it.
I think on firefox works on http.

soory for open it again,
i don't know why when use this url
http://atandrastoth.co.uk/main/pages/plugins/webcodecamjs/
i can't use webcam and show me error
but
when i use this url
https://andrastoth.github.io/webcodecamjs/
it run correctly and work
why ? What is the difference between these two ؟

Hello,
Your browser does not support getUserMedia via HTTP!\n(see: https://goo.gl/Y0ZkNV)
Sorry, this is a new chrome policy.
Try Firefox it maybe will work.

Hello,
oh yes , i'm sorry
thanks.


Look into Original Data/Code from Previous Papers

Try to find the original datasets and/or code for C12 and C9 (Assertiveness).
Can we replicate these models? Can we use that data for pretraining?

C12: Found it!! I put the link in our master sheet :)
C9: This paper indicated that this dataset is called the Stanford Linguistic Departments SpeedDate Corpus. I googled it but didn't find any resources available. Maybe Emily could use some of your Stanford connections? :)


Fix s5cmd url

Addresses #16 and #17

Sorry as I requested before the gha commits are in the order of the PRs submitted. But I understand your preference and with time, I'm getting more familiar with rebasing and isolating branches, as can be seen in the Cloud Resources repo. I'll update these branches today.
Regarding #17 I did not see where downloadDir is taken as input from the user, so I assumed there is no need for it with the way s5cmd download is setup now. But if this is going to a feature in the future versions, could you eloborate more in the issue?

Regarding https://github.com/ImagingDataCommons/idc-index/issues/17 I did not see where downloadDir is taken as input from the user

I was talking about this function, which takes downloadDir as a parameter:
https://github.com/ImagingDataCommons/idc-index/blob/main/idc_index/index.py#L273

Regarding #17 I did not see where downloadDir is taken as input from the user

I was talking about this function, which takes downloadDir as a parameter:
https://github.com/ImagingDataCommons/idc-index/blob/main/idc_index/index.py#L273

Sorry, I still do not understand. download_from_manifest is simply running the manifest which already contains the downloadDir at https://github.com/ImagingDataCommons/idc-index/blob/main/idc_index/index.py#L260 from download_from_selection  How do you intend download_from_manifest to work?

I was thinking that function should be convenient to use with any manifest - both created inside idc-index, but also the one downloaded from the portal, where user cannot control the destination.
As I was writing about this, I realized the easiest way to address this is to run s5cmd from the destination directory, instead of rewriting the manifest. I will make that fix in the #23 branch.

Sounds good.
I can close this PR as there is PR #23 to tackle the issues mentioned. I noticed that PRs #19 and #20 are already isolated and ready for review.

I can close this PR as there is PR https://github.com/ImagingDataCommons/idc-index/pull/23 to tackle the issues mentioned.

Closing as obsolete.


Added: readme.md file and license

@oleksandr-jr
Hi! Codacy is swearing a lot on the header style here, can you turn that off?


workbench.externalUriOpeners protocol glob patterns don't work

Testing #114962

Have "workbench.externalUriOpeners": { "https:*": "cool-opener" }
Click on a link // https://peet.io
The URL is not opened with that opener

My example was incorrect. The syntax we support is http://*. This is the same syntax supported for trusted domains

My example was incorrect. The syntax we support is http://*. This is the same syntax supported for trusted domains

Cool, that works. Probably worth documenting in the setting -- the description is minimal right now.

Cool, that works. Probably worth documenting in the setting -- the description is minimal right now.

We provide hover intellisense with examples in the json editor:

We will probably add a rich editor for these settings at some point too
I still think supporting https:* makes sense, although I am not sure if there is some reason why trusted domains don't support it

We provide hover intellisense with examples in the json editor:

We will probably add a rich editor for these settings at some point too
I still think supporting https:* makes sense, although I am not sure if there is some reason why trusted domains don't support it

Oh, I see, I was looking on the setting itself rather than the key

Oh, I see, I was looking on the setting itself rather than the key


jenkins-job-trigger: make triggering silent (curl --silent)

switch curl to silent mode, error would still be show but the progress is suppressed

:+1:


Type coverage in modules path

Can I configure something to verify the type coverage of my code inside the modules path?

I was looking at this, too. But I realized - it's a TEST extension, so you have to go into your PHPUnit.xml file and add the path in sources:
    <source>
        <include>
            <directory>app</directory>
            <directory>systems/generators</directory>
        </include>
    </source>

In this case, I needed systems/generators, but that path might be different for you!


commit-103

What does the program do ?
sort an array
In what programming language it is written?
C++

Thank you for participating  in hacktoberfest ❣ if you liked working on this repo you can share it with friends and star this project for helping others


Truncating long text

The OS X status bar isn't the greatest when it comes to having a lot of stuff there. If an element of it is too long to be visible, that and all the subsequent elements will be hidden. Obviously, this isn't the easiest thing in the world to fix, so my suggestion is being able to truncate long text in Statusfy. This would at least limit the impact of the problem if you pretty much always can see at least 40 characters or whatever.

I think this is a good idea, and think I may have seen apps with scrolling text in the status bat, but not sure how to go about it exactly.
If someone were to create a pull request for that, I'd consider merging it.

I think this can be tracked by #29 from now on.


Add these for runecrafting!

add these on the screen please!
add how many charges left on duel rings and binding necklace also add how many actions you made and how much each hour you can make
and add the time to level on the xp orb!

yeah it does but thats on the jewellery i want it to show it on the scree without me going into my inventory or armour slot

Duplicate of multiple issues


github: remove kortschak from FUNDING.yml

Please take a look.

The sponsorship heart remains. Probably we should remove the entire file until it's needed again.


Support for Spree 3.2?

I am trying to setup with spree 3.2 and running into the following error loading the payment page:
Showing /usr/local/rvm/gems/ruby-2.3.3/bundler/gems/spree_braintree_vzero-a860006a9b48/app/views/spree/checkout/payment/braintree_vzero/_payment.html.erb where line #61 raised:

undefined method `to_sym' for {:values=>[:sandbox, :production]}:Hash
Did you mean?  to_s
               to_yaml
               to_set
Extracted source (around line #28):

26
27     def provider
28       Braintree::Configuration.environment = preferred_server.to_sym
29       Braintree::Configuration.merchant_id = preferred_merchant_id
30       Braintree::Configuration.public_key = preferred_public_key
31       Braintree::Configuration.private_key = preferred_private_key

I am using:
$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux]
$ rails -v
Rails 5.0.1
Spree from Gemfile:
gem 'spree', '~> 3.2.0.rc1'
gem 'spree_auth_devise', '~> 3.2.0.beta'
gem 'spree_gateway', '~> 3.2.0.beta'
gem 'spree_static_content', github: 'spree-contrib/spree_static_content'
gem 'spree_braintree_vzero', github: 'spree-contrib/spree_braintree_vzero'

I suspect that my settings are not being saved (or retrieved) properly as the credential fields on the settings page are always blank when viewed.
Should this setup work?  Do I need to select a specific branch of the plugin?

FYI  I have done some investigating.  I don't know why but I can not find any settings (merchant id, public or private key) saved in the database.  I can give access to my cloud 9 test bed if you need it.

I did some debugging and I think that I managed to trace the problem. It seems that when updating a PaymentMethod, the params are not permitted. See here. I tried to permit them and this resolved the problem.

Hi @mzdravkov please submit a PR for https://github.com/spree/spree

@mzdravkov how did you 'fix'?

Ok, I really should have made a PR at the time, because now I don't remember exactly what I did two weeks ago... I tried to run version 3.1 of spree, and this is what I'm currently running, but I investigated the code of the different versions of spree that I have on my machine and I found what the change in payment_methods_controller.rb in version 3.2 of spree is:
I have changed this line to:
update_params = payment_method_params[ActiveModel::Naming.param_key(@payment_method)] || {}
(use payment_method_params instead of params)
You can try this. I'm sorry that I'm not able to help you better.

@damianlegawiec this is still pending? We have this issue with rails 4.2.7 and rails 3.0.0.rc4. How can we solve it?

Update: was unable to fix this or downgrade, and lost a small client

In case someone still has this problem, I managed to fix it by updating Spree. Yeah, updating, apparently I was in 3.2.0.rc2.
I realized that I wasn't able to override some code present on the current stable branch. That was what made me discover the issue. In the end I just did bundle update and poof, problem fixed.
If someone is curious, the problem was in the previous PaymentMethodsController class, it didn't have the current preferences_params method.

And this is why you never use unstable code children! 🦄

I am still facing similar problem on fresh install of Spree. Its happening when I go from delivery to checkout, while BraintreeVzeroPaypalExpress is enabled
NoMethodError in Spree::Checkout#edit

Showing /home/username/workspace/spree_sandbox/spree_braintree_vzero/app/views/spree/checkout/payment/braintree_vzero/_three_d_secure.html.erb where line #7 raised:

undefined method `to_sym' for {:values=>[:sandbox, :production]}:Hash

ruby 2.6.5
rails <IP_ADDRESS>
spree 4.1.2


Documentation request: compat/json_style.ts

Really I'd just like to know what the expected JSON shape for this is, if any. I was thinking about building something like this for Mapbox Studio/Maputnik JSON output files, so those styles could be used in conjunction with protomaps rendering. Is that the direction this is heading?

https://github.com/protomaps/protomaps.js/blob/master/examples/json_style.html is all that exists right now; the first argument is a JSON object that can be also be read by Mapbox GL, MapLibre GL, OpenLayers, etc, although the only key used is the "Layers" key. The result then has a paint_rules and label_rules that can be passed to leafletLayer.
It's not too elegant right now, but yes, the idea is to read the same style specification used by other map renderers. The difficulty here is that the spec surface area as defined by Mapbox or MapLibre is huge; right now only a limited set is implemented. The rendered result will also look difference because the underlying algorithms and rasterization are fundamentally different.
So my plan is not to promise a 1:1 match between other JSON styles and the rendering output of protomaps.js, but have something where you can reasonable write one "style" and use it both in MapLibre GL, protomaps.js, with an editor like Maputnik or Fresco, etc. I've started to explore this universal themes idea here.

I think that's what I'm after as well; although currently using a style output from Mapbox's style editor (I haven't tried Maputnik yet but it's on the docket) results in nothing but water being rendered. I think this could be because the Mapbox v8 tiles I'm using don't conform to the standard they set, though; or it could be as you say, the style standard is huge and most of it is un-implemented. I'm actively working in this area, once I have something to show I'll open a PR, if that's cool? Probably a bit larger than the last one.

If you are using the Mapbox style editor with the Mapbox API, it's likely that the way map features are tagged and organized into layers is disjoint from how they appear in the Protomaps tiles, though they may be built from the same underlying OpenStreetMap data; documentation on how these are organized is online here: https://protomaps.com/docs/map-layers-tags
Though it might be the case certain layers like "water" happen to be similar.

Yeah, that's what I meant. Sorry, I think of file structures/tagging/organization as asynchronous APIs. Thanks for all the info!


Document lumina-pdf application (when ready)

Experimental as of 1.3.0 - will need a full workup when it is ready for full inclusion in Lumina.

Checked Aug 9, still not ready.


Update to react-router@6

Fixes https://github.com/grafana/scenes/issues/608
What changed?
Updating the scenes packages to use react-router v6.
This probably requires a major version bump, as it's going to be a breaking change for plugins that depend on scenes.
Why?
We are in the process of migrating Grafana core and also internal plugins to use react-router v6, however any plugin that is depending on scenes cannot easily do it (or at least it's a complicated task). Scenes still using react-router v5 is a blocker for plugins that would like to update.

Pushed an update to get SceneAppPage and most demos to work
Scene apps needs a big update

add routePath to all SceneAppPage definitions (with * wildcard if they have drilldowns) this needs to be relative not absolute
the url property on SceneAppPage needs to remain and be absolute as it's used to create breadcrumbs and tab links
routePath on all drilldowns needs to be relative and end in wildcard

I have spent sometime trying to green out all the test case, and although I think got somewhere, there are some weird things that might need someone with deeper knowledge of the scenes projects.
The main issue is with the tests under the scenes package: for some reason the inline jest.mock() calls don't seem to go through, while mocking via a __mocks__ directory is still working. Obviously it wouldn't make sense to transition all the tests to use a __mocks__ folder solution, we should instead find the root cause. (There was one issue we discovered with @jackw in the jest config: we also needed to introduce a "setupFiles" and move parts of the setupTestsAfterEnv.ts in there, although that didn't fix this problem.)

I have spent sometime trying to green out all the test case, and although I think got somewhere, there are some weird things that might need someone with deeper knowledge of the scenes projects.
The main issue is with the tests under the scenes package: for some reason the inline jest.mock() calls don't seem to go through, while mocking via a __mocks__ directory is still working. Obviously it wouldn't make sense to transition all the tests to use a __mocks__ folder solution, we should instead find the root cause. (There was one issue we discovered with @jackw in the jest config: we also needed to introduce a "setupFiles" and move parts of the setupTestsAfterEnv.ts in there, although that didn't fix this problem.)
@grafana/dashboards-squad

@leventebalogh I see the tests are passing, did you find the issue?

@leventebalogh I see the tests are passing, did you find the issue?

Yes, thanks @oscarkilhed, we managed to green them out with @jackw 👍

How does this work for apps built with scenes that run in Grafana? Will they continue to work as long as they are built with an older version of scenes, or will they break when Grafana and scenes runs on router@v6?

I am currently testing out these changes with an example plugin, and as soon as I am done with that I'll update the PR description with correct instructions on what steps plugins need to take for updating. (We will probably also have a migration page for this)
At the time being Grafana still supports plugins both using react-router@v5 or react-router@v6. This means, that plugins built with an earlier scenes version will still be supported (at least until core is updated to use react-router@v6 fully - then they will break). As far as I know scenes is bundled (and not externalised), so it shouldn't be a problem that core is depending on a different version (for now). I'll double check this though as well, and update the PR description!
This must be major version bump though, as any plugins updating to this scenes version will also need to update some things in their source code.

@torkelo @dprokop could you please have a look if you think it's legit?

@leventebalogh do we need any additional steps for this to work in grafana/grafana? Did a draft scenes bump PR to launch a drone pipeline and quite a lot of tests are erroring out 🤔


Cleanup CHANGELOG after 0.12.1 release

[ ] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes
In this PR I've just cleaned up and fix the change log after the 0.12.1 release.
Verification
N/A

Done already (:


store url and short_id

fix issue #7
now it shows same short-url whenever the same url is asked by the user until refresh the code.

The thing seems okay. But if the dictionary limit is reached?
And i don't find the shorturl changing on refreshing the page. In the admin panel it lists only one short url even if i short the url in different browsers.

Okay that happens when we restart the server.


为什么按例子测试出错： “ NoMethodError: undefined method `[]' for #<Set: {#<MIME::Type: application/json>}>”

params = {
"redirect": {
"path": "/12345",
"target": "/blogs"
}
}
code, body, header = YhsdApi::PrivateApp.put("redirects", params)
出错： NoMethodError: undefined method `[]' for #<Set: {#<MIME::Type: application/json>}>

Stack Trace:
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:307:in `type_for_extension'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:312:in `type_for_extension'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:278:in `block in stringify_headers'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:272:in `each'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:272:in `inject'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:272:in `stringify_headers'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:92:in `make_headers'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:58:in `initialize'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:33:in `new'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient/request.rb:33:in `execute'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/rest-client-1.6.7/lib/restclient.rb:80:in `put'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/yhsd_api-0.0.3/lib/yhsd_api/http.rb:72:in `put'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/yhsd_api-0.0.3/lib/yhsd_api/private_app.rb:96:in `put'
from (irb):37
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/console.rb:110:in `start'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/console.rb:9:in `start'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:68:in `console'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands.rb:17:in `<top (required)>'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:274:in `require'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:274:in `block in require'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:240:in `load_dependency'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:274:in `require'
from /Users/mango/Documents/glasstic/bin/rails:9:in `<top (required)>'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:268:in `load'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:268:in `block in load'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:240:in `load_dependency'
from /Users/mango/.rvm/gems/ruby-2.2.1/gems/activesupport-4.2.6/lib/active_support/dependencies.rb:268:in `load'
from /Users/mango/.rvm/rubies/ruby-2.2.1/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /Users/mango/.rvm/rubies/ruby-2.2.1/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from -e:1:in `<main>'2.2.1 :038 >


supermariowar: init at 2.0-unstable-2024-06-22

Description of changes
Add the package supermariowar.
A fan-made multiplayer Super Mario Bros. style deathmatch game

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

[ ] 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

[ ] 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.

Is there a reason we're not using https://github.com/mmatyas/supermariowar/tree/v2.0-beta.1.1 or the master branch?

Is there a reason we're not using https://github.com/mmatyas/supermariowar/tree/v2.0-beta.1.1 or the master branch?

I used the commit associated with the continuous tag because I was 100% sure it worked, but in fact we could use a more recent commit, like the latest commit on master, there's also a 2023 tag.

Is there a reason we're not using https://github.com/mmatyas/supermariowar/tree/v2.0-beta.1.1 or the master branch?

I used the commit associated with the continuous tag because I was 100% sure it worked, but in fact we could use a more recent commit, like the latest commit on master, there's also a 2023 tag.

I think we should use either the latest commit that works or the latest stable tag

Is there a reason we're not using https://github.com/mmatyas/supermariowar/tree/v2.0-beta.1.1 or the master branch?

I used the commit associated with the continuous tag because I was 100% sure it worked, but in fact we could use a more recent commit, like the latest commit on master, there's also a 2023 tag.

I think we should use either the latest commit that works or the latest stable tag

Yes, let me try to make work the latest commit (e646679c119a3b6c93c48e505564e8d24441fe4e) and I make a new commit there.

Ok, I added a commit with a more recent rev on the master branch.
I re-tested every binaries and updated the version name.

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

1 package built:

supermariowar

Keep in mind you'll need to squash any extra commits after d50c1902ceae2dad0460cda4cfe1871a6ab580d9 into d50c1902ceae2dad0460cda4cfe1871a6ab580d9
For example squash 104c9232dc5d878378c68a10f9697f11ebf5f4ea into d50c1902ceae2dad0460cda4cfe1871a6ab580d9

Keep in mind you'll need to squash any extra commits after d50c190 into d50c190
For example squash 104c923 into d50c190

Yes no worries, i added a new commit just in case i need to come back to the old one :).

Thanks for the reviews !


Find a way to separate out the JSON bindings from the actual API classes

Maybe we should fully delegate this to the implementation?

Then a toJson() method in the API sounds biased. Wouldn't simply declaring toString() in the interface be better in such case? Leaving it to implementations if they use JSON, XML or something else.

I think we should remove toJson() all together and simply impose the need for a JSON encoded wireformat. But that doesn't need to be reflected in the API at all.


[Feedback] format that is mentioned in this (and other) pages is not correct

After trying for days to make "mentions" work when submitting adaptive card json over graph API, I have discovered that the format that is mentioned in this (and other) pages is not correct.
See: https://poszytek.eu/en/microsoft-en/office-365-en/powerautomate-en/how-to-mention-tags-users-channels-and-teams-using-power-automate/
for a format that works for me.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 001a12ea-30fa-d626-18a9-02a518bfb37f
Version Independent ID: e5f5f69e-66e9-d1b2-e19a-485d0ffcd6fa
Content: Text formatting in cards - Teams
Content Source: msteams-platform/task-modules-and-cards/cards/cards-format.md
Service: msteams
GitHub Login: @surbhigupta
Microsoft Alias: surbhigupta

@v-npaladugu -Thanks for reporting your issue.
We will check this at our end and will get back to you.


API usage questions.

I'm trying to build my own fuzzer using the perf_event_open API for capturing the bitstream as a fun side project.
I've got a lot of questions regarding library usage, partially due to lacking background information. (I've sparsely read the Intel manual on the subject)
Let's start by library basic usage as far as I understand it.
Create decoder -> Run Decoder -> decoder fills bitmap according to the trace data. Where 1 means branch  taken and 0 means not taken.
That much is clear to me. What is considered a branch is (what I presume) left to the capture configuration.
Though the arguments could be clarified a bit more as I needed to check the source what for what they meant.
libxdc_init:

Filter: Are these absolute and/or physical addresses or virtual?

What happens if you capture a guest VM from the host, is the address of the host or the guest?
What if you don't filter by address at record time but just by CR3, do you simply take the whole address range?

page_cache_fetch: The purpose of page_cache_fetch is to fetch data from the fuzzed target. However argument names, purpose of the arguments are left out, so I'm guessing what going on based on the tests.

void* self_ptr, uint64_t page, bool* success

self_ptr: opaque pointer
page: pointer to data it requests? (What is the size? Size of a page of the traced process?)
success: Was the memory fetch successful?
Return value: The address to access the data?

libxdc_decode: Pretty clear.

decoder: libxdc_init context
trace: The recorded intel pt trace bitstream
trace_size: Size of the trace (+ 1 for the 0x55 byte)
Return value: Status code

libxdc_register_bb_callback:  called for each NEW basic block e.g. Function calls?

void* opaque_ptr,
uint64_t start_addr: Source address
uint64_t cofi_addr: Destination address

libxdc_register_edge_callback: Called on each branch e.g. If statements, switch case,?

void* opaque_ptr:
uint64_t src: Source address
uint64_t dst: Destination address

I made a simple test case but I haven't found any success so far
Which might be due to two things, in-proper capture set-up, in-proper library usage, both?
It's relatively small (200 ~LOC), I can post it if you want to take a look. ( Need to clean it up first though )

Here's is the log with DEBUG_TRACES enabled. The bottom is the cache page_cache_fetch requests.
PSB
MODE
MODE
FUP     ffffffff98a76314 (TNT: 0)
VMCS
PSBEND
PGE     ffffffff98a76316 (TNT: 0)
TIP     ffffffff98a16360 (TNT: 0)
TIP     ffffffff98a1662c (TNT: 0)
TIP     ffffffff98a166cd (TNT: 0)
TIP     ffffffff98c15779 (TNT: 0)
TNT a6
TNT 4
TIP     ffffffff98c15970 (TNT: 7)

disasm(ffffffff98c15779,0)      TNT: 7
TNT e
TIP     ffffffff98c17ee5 (TNT: 9)

disasm(ffffffff98c15970,0)      TNT: 9
TNT 14
TIP     ffffffff98c120f0 (TNT: 12)

disasm(ffffffff98c17ee5,0)      TNT: 12
TNT 1a
TIP     ffffffff98c18282 (TNT: 15)

disasm(ffffffff98c120f0,0)      TNT: 15
TNT 96
TNT 2c
TIP     ffffffff98c18683 (TNT: 25)

disasm(ffffffff98c18282,0)      TNT: 25
TNT 4
TIP     ffffffff98c18771 (TNT: 26)

disasm(ffffffff98c18683,0)      TNT: 26
TIP     ffffffff98c18814 (TNT: 26)

disasm(ffffffff98c18771,0)      TNT: 26
TNT 4
TIP     ffffffff98c15970 (TNT: 27)

disasm(ffffffff98c18814,0)      TNT: 27
TNT e
TIP     ffffffff98c18b0e (TNT: 29)

disasm(ffffffff98c15970,0)      TNT: 29
TIP     ffffffff98c19dec (TNT: 29)

disasm(ffffffff98c18b0e,0)      TNT: 29
TNT 4
TIP     ffffffff98c133f3 (TNT: 30)

disasm(ffffffff98c19dec,0)      TNT: 30
TIP     ffffffff98b489ae (TNT: 30)

disasm(ffffffff98c133f3,0)      TNT: 30
TIP     ffffffff98b48abc (TNT: 30)

disasm(ffffffff98b489ae,0)      TNT: 30
TNT c
TIP     ffffffff98c1257d (TNT: 32)

disasm(ffffffff98b48abc,0)      TNT: 32
TNT 8
TIP     ffffffff98c1a84c (TNT: 34)

disasm(ffffffff98c1257d,0)      TNT: 34
TNT 8
TIP     ffffffff98c1aa54 (TNT: 36)

disasm(ffffffff98c1a84c,0)      TNT: 36
TIP     ffffffff98c1228a (TNT: 36)

disasm(ffffffff98c1aa54,0)      TNT: 36
TNT 1e
TIP     ffffffff98c202e8 (TNT: 39)

disasm(ffffffff98c1228a,0)      TNT: 39
TNT 4
TIP     ffffffff98c206c3 (TNT: 40)

disasm(ffffffff98c202e8,0)      TNT: 40
TNT 72
TIP     ffffffff98d057ad (TNT: 45)

disasm(ffffffff98c206c3,0)      TNT: 45
TNT c
TIP     ffffffff98d057fa (TNT: 47)

disasm(ffffffff98d057ad,0)      TNT: 47
TIP     ffffffff99571fe9 (TNT: 47)

disasm(ffffffff98d057fa,0)      TNT: 47
TNT a2
TNT 56
TIP     ffffffff9960008c (TNT: 58)

disasm(ffffffff99571fe9,0)      TNT: 58
TNT 80
TIP     7ffff7b7750b (TNT: 64)

disasm(ffffffff9960008c,0)      TNT: 64
TNT 4
TIP<PHONE_NUMBER>d8 (TNT: 65)

disasm(7ffff7b7750b,0)  TNT: 65

opaque_ptr:     0
page:   0x7ffff7b7750b
success:        1

opaque_ptr:     0
page:   0x7ffff7b7750c
success:        1

opaque_ptr:     0
page:   0x7ffff7b7750f
success:        1

opaque_ptr:     0
page:   0x7ffff7b77511
success:        1

opaque_ptr:     0
page:   0x7ffff7b77515
success:        1

opaque_ptr:     0
page:   0x7ffff7b77517
success:        1

opaque_ptr:     0
page:   0x7ffff7b7751c
success:        1
decoder_page_fault

It seems like you are on the right track in general. The bitmap is actually a byte-map where each byte contains the number of times an edge was taken % 0xff. The filter have to be configured in the same way intel-pt was configured. If the whole address space was traced (e.g. by filtering on CR3) you will have to set the filter to contain the whole range. Your inference on the arguments of page_cache_fetch seem on point. Register BB/Edge callbacks are not needed to fill the bitmap, however they can be useful if you want to print coverage for human consumption.
How does the log differ from what you expect?

Thanks for the quick reply.

The bitmap is actually a byte-map where each byte contains the number of times an edge was taken % 0xff.
I bit confused how to utilize the byte map, how do you reconstruct the ip from the byte map if you have a ip change which cannot be deduced from a binary (Indirect Transfer COFI)?
Also what do you mean with 0xff "was taken % 0xff"?

How does the log differ from what you expect?
Well the return code of libxdc_decode isn't decoder_result_s::decoder_success
but decoder_result_s::decoder_page_fault (as seen in the log) so I presume I'm doing something wrong.

Say you have 4 basic blocks A,B,C,D that are connected in a diamond shape with a loot:
A->B->D->A and A->C->D. The program takes the edges A->B->D->A 5 times and the edges A->C->D once. Then the bitmap will be as follows:
bitmap[A<<1^B] = 5
bitmap[B<<1^C] = 5
bitmap[C<<1^D] = 5
bitmap[D<<1^A] = 5
bitmap[A<<1^C] = 1
bitmap[C<<1^D] = 1

and all other entries are zero. See the afl whitepaper for more details. Notably, if an edge was taken more than 255 times, the corresponding entry overflows. As the index is computed by taking (last_bb_id << 1) xor (curr_bb_id), it's not possible to compute the edges taken from the bitmap itself. If you need access to the edges, you will need to use the callbacks. The bitmap is faster to check for new coverage though. As this is our only concern during fuzzing, is better to use the bitmap for fuzzing purposes. The edge callbacks can be used to display which code was covered during debugging/harness authoring though.
If you are seeing a page_fault, I would assume you page cache is not handling the memory accesses correctly? Usually that would indicate that the decoder is trying to disassemble code that the page cache is unable to provide.  Make sure that your memory dump contains all addresses that you traced (or limit your tracing to the are that you can disassemble).

I vaguely understand how it works, I'll have to get my hands dirty to get a complete understanding and read that white paper I presume you mean https://aflplus.plus/papers/aflpp-woot2020.pdf.
That said, how do you know which edge(BB) connections belongs to which index in the bitmap?

not handling the memory accesses correctly
In my test code the traced function is within the same process so I'd assume that the page is the same and the page_cache_fetch function would look like this:

void *page_cache_fetch(void *opaque_ptr, uint64_t page, bool *success) {
  *success = true;
  return (void *)page;
}

I looked at the last point where it fails and it seems to be
opaque_ptr:     0
page:   0x7ffff7b77517
success:        1

opaque_ptr:     0
page:   0x7ffff7b7751c
success:        1

Debugger:

disassemble -s 0x7ffff7b7751c
libc.so.6`ioctl:
    0x7ffff7b7751c <+28>: fsubs  0x1(%rcx,%rcx,4)
    0x7ffff7b77520 <+32>: orq    $-0x1, %rax
    0x7ffff7b77524 <+36>: retq
    0x7ffff7b77525:       nopw   %cs:(%rax,%rax)
    0x7ffff7b7752f:       nop

I use ioctl (the function above) to enable and disable tracing.
It requests the memory just fine. Which is rather strange.
I presume that the trace was inadequately ended, when I disabled tracing -> kernel call(ioctl) -> end trace.
If I set-up filters, or trace a external process I probably won't have this issue.

I was referring to the original whitepaper (https://lcamtuf.coredump.cx/afl/technical_details.txt). Generally you can't map the bitmap indices to edges. If you care about edges, use the callbacks. Page should probably be PAGESIZE aligned (e.g. 0x1000, like https://github.com/nyx-fuzz/libxdc/blob/master/test/page_cache.c#L168).


[feature request] edit drafts

I did not find a convenient way to edit drafts.
When in a draft folder, you can only open drafts in read-only mode or compose a new empty email. This makes sense for all other folders, but for the draft folder some special behaviour would make sense I believe.
E.g. a mapping to copy the content of the email under the cursor to a new empty email buffer, would suffice.

Duplicate of https://github.com/pimalaya/himalaya/issues/476, the draft management needs definitely a refactor. The editing feature is a must.