WIP: Testing Pipeline

Codecov Report

Merging #167 (29ce0c0) into master (0a2c2da) will decrease coverage by 0.14%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #167      +/-   ##
==========================================
- Coverage   43.18%   43.03%   -0.15%
==========================================
  Files          49       51       +2
  Lines        5074     5091      +17
==========================================
  Hits         2191     2191
- Misses       2883     2900      +17

Impacted Files
Coverage Δ

data_processing/common/PipelineBuilder.py
0.00% <0.00%> (ø)

data_processing/transforms.py
0.00% <0.00%> (ø)

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 0a2c2da...29ce0c0. Read the comment docs.


[[Power-Fx]] Localization hand-back [CTAS - RunID=20230424-205846-bw1n6tfk87]

Translation handback check-in (PR Created by automation).

/azp run

superseded by #1508


Windows AWS Credential File Path Template Expectation

I have tried multiple versions of using Windows file paths to point to my AWS Credentials but I am invariably coming up against the following error:
mainThreadExtensionService.ts:65 [[object Object]]Profile c:/Users/gscase/.aws/credentials could not be found or parsed in shared credentials file. $onExtensionRuntimeError @ mainThreadExtensionService.ts:57 _doInvokeHandler @ rpcProtocol.ts:396 _invokeHandler @ rpcProtocol.ts:330 _receiveRequest @ rpcProtocol.ts:269 _receiveOneMessage @ rpcProtocol.ts:208 (anonymous) @ rpcProtocol.ts:90 fire @ event.ts:525 fire @ ipc.net.ts:449 _receiveMessage @ ipc.net.ts:785 (anonymous) @ ipc.net.ts:642 fire @ event.ts:525 acceptChunk @ ipc.net.ts:191 (anonymous) @ ipc.net.ts:191 t @ ipc.net.ts:925 emit @ events.js:223 addChunk @ _stream_readable.js:309 readableAddChunk @ _stream_readable.js:290 Readable.push @ _stream_readable.js:224 onStreamRead @ internal/stream_base_commons.js:181 mainThreadExtensionService.ts:66 Error: Profile c:/Users/gscase/.aws/credentials could not be found or parsed in shared credentials file. 	at resolveProfileData (c:\Users\gscase\.vscode\extensions\iann0036.aws-cloudshell-0.1.6\node_modules\@aws-sdk\credential-provider-ini\dist\cjs\index.js:80:11) 	at c:\Users\gscase\.vscode\extensions\iann0036.aws-cloudshell-0.1.6\node_modules\@aws-sdk\credential-provider-ini\dist\cjs\index.js:29:59 	at async c:\Users\gscase\.vscode\extensions\iann0036.aws-cloudshell-0.1.6\node_modules\@aws-sdk\property-provider\dist\cjs\memoize.js:26:26 	at async c:\Users\gscase\.vscode\extensions\iann0036.aws-cloudshell-0.1.6\out\Utils.js:24:21
I have tried variations with no luck.

c:/Users/gscase/.aws/credentials
file//c:/Users/gscase/.aws/credentials
file://C:/Users/gscase/.aws/credentials
C:\Users\gscase.aws\credentials

Current Setup
session-manager-plugin --version
<IP_ADDRESS>
VSCode Information

Am I missing something?

Do you have your AWS CLI credentials configured? (i.e. can you do an aws sts get-caller-identity) ?


Can't compile / install due to missing ZIP binary on Windows

As the title says... with previous versions of this, I could just comment that line out and it still worked, but now ZIP.exe seems to be a absolute requirement for being able to install. Maybe you could provide a link for Windows users on how to get ZIP.exe?

I don't have much experience with building on Windows, but if you don't have zip you can always just comment out the lines that use it from the buildtools Makefile base.

Well, I know about this issue. I've been researching some more, and stumbled upon this: http://www.willus.com/archive/zip64/
These are compiled binaries of info-zip, which works as a swap-in replacement. Source code is found here:
https://sourceforge.net/projects/infozip/
Commenting out the lines does not do it, you need to change a lot more for install to work again, because as install works now it zips, then unzips.
And, as you said, this is actually an issue with buildtools (on Windows, ofc), which is used by other projects as submodule (I'm looking to include it with CTRXplorer, f.e.), too. So, maybe add a link to the info-zip download to the description?

I had the same issue on my home PC before.
So I tried it again on my office PC yesterday. And it works flawlessly.
Then I tried to find out what's the difference between those two PCs.
Finally I found out that Oracle client 11.2.0 (which includes "zip.exe" and "unzip.exe" in its own bin folder) was installed on my office PC. And fortunately it's already added to Windows Path.
C:\devkitPro\citrus\tools>zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008).


Verify software on new PCB

We should reduce the launch detection requirements and attempt to get data from all 4 phases of flight via telemetry and the SD.

PCB seems to operate as intended, a separate issue has been opened for buzzer issues #74


notify: include context in Stage interface

This adds context.Context to the return arguments of a Stage.
This is necessary to propagate modified contexts.
@brancz
depends on #463

If I understand correctly then the important part here is that the MultiStage receives and forwards the context from one Stage to another. If so LGTM 👍

Test adjusted, PTAL.

LGTM 👍


Improve dump/restore github action

Description
This commit brings the following changes:

Increase rows-per-insert to reduce the github action runtime.
Redirect pg_dump output to file to reduce the size of logs getting printed on console.
Make dump utilities less verbose to get rid of the unnecessary logs.

Signed-off-by: Rishabh Tanwar<EMAIL_ADDRESS>Test Scenarios Covered

Use case based -

Boundary conditions -

Arbitrary inputs -

Negative test cases -

Minor version upgrade tests -

Major version upgrade tests -

Performance tests -

Tooling impact -

Client tests -

Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
41610

Relevant Lines:
57245

💛  - Coveralls


Participate in Hacktoberfest

Hey, I believe the project could benefit a lot from participating in Hacktoberfest through the "hacktoberfest" label and various difficulties (it helps people find repos to contribute in).
For more info read https://hacktoberfest.digitalocean.com/faq
Maybe we could get the label on some issues?

Great idea! Just did this for some issues. Any other issues you think we should add them to?

How about #893, #1642, #557, #1762 and #

Done!


OpenROAD memory crash in antenna repaire in global routing

Description
Memory utilization reaches 100% (67.1 GB) then the OR crashes in antenna repair in global routing. I faced this on 2 different macros since 30/August/2023. Changing some variables such as FP_CORE_UTIL or PL_TARGET_DENSITY gets the flow running but I think this should be investigated.
Attached a screenshot of the memory utilization behavior, the utilization increases linearly since the start of global routing till it reaches 100% utilization.

Expected Behavior
OpenROAD shouldn't need 67GB of RAM to do antenna repair.
Environment report
Kernel: Linux v6.2.0-31-generic
Distribution: ubuntu 23.04
Python: v3.11.4 (OK)
Container Engine: docker v24.0.5 (OK)
OpenLane Git Version: 2264b1240bacca90f8dfd74b8f5d62b7d618038e
pip: INSTALLED
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

2264b124 2023-09-03T13:16:28+00:00 bump open_pdks version (#1969) - Kareem Farid -  (HEAD -> master, origin/master, origin/HEAD)
6a293792 2023-09-03T14:02:52+03:00 Add Banner for OpenLane 2 (#1966) - Mohamed Gaber -  ()
698c0fac 2023-09-03T14:02:00+03:00 Partially Revert "Illegal Overlap Check Fix" (#1967) - Mohamed Gaber -  ()
---
Git Remotes

origin	git@github.com:The-OpenROAD-Project/OpenLane.git (fetch)
origin	git@github.com:The-OpenROAD-Project/OpenLane.git (push)

Reproduction material
issue_reproducible.zip
Relevant log output
[ERROR]: during executing openroad script /openlane/scripts/openroad/groute.tcl
[ERROR]: Log: ../home/hosni/ML-SOC/caravel-ML-SoC/openlane/SW_SHA256_AHBL/runs/23_09_03_17_57/logs/routing/23-global.log
[ERROR]: Last 10 lines:
met3             53990         13712           25.40%             0 /  0 /  0
met4             29572          5140           17.38%             0 /  0 /  0
---------------------------------------------------------------------------------------
Total           236746         91689           38.73%             0 /  0 /  0

[INFO GRT-0018] Total wirelength: 906839 um
[INFO GRT-0014] Routed nets: 13280
[INFO GRT-0006] Repairing antennas, iteration 1.
[INFO GRT-0043] No OR_DEFAULT vias defined.
child killed: kill signal

We're working on getting OR updated.

OR should be updated now..?

Still facing the same issue using OpenROAD 6dacde2b1f4ddc58ea64e6d889bc8665762da095

No longer facing a crash or high memory consumption with OpenLane 66e938bcb87d7f5b9a0487c018e6a0083b289d5d


⚠ Guya.moe Proxied has degraded performance

In d30eb0a, Guya.moe Proxied (https://ice.guya.moe/) experienced degraded performance:

HTTP code: 200
Response time: 11874 ms

Resolved: Guya.moe Proxied performance has improved in 9d78df6 after 1 hour, 36 minutes.


[OTHER] Why do versions >1.1.1 require python 3.9+?

Hello, we were originally intending to piecemeal upgrade our camera stack first on Buster, then slowly move to Bullseye over time. Unfortunately this plan has been thwarted by the fact that recent version of picamera2 seem to requires Python 3.9+, which Buster does not have access to. As any good scientist knows, don't change two variables at once! We are trying to avoid combining problems from shifting camera stack and OS at the same time.
Please let me know if this can be changed, but if not we understand.
If this will not be changed, the documentation should probably be updated since the libcamera stack can be installed and used on Buster otherwise.
Thanks!

We generally have such headaches with libcamera changes, different kernel versions, different kernel drivers and so on, that I'm probably a bit paranoid and want to limit everything to Bullseye. Which doesn't mean you can't make it work - I would try checking Picamera2 out from the repository, point your PYTHONPATH environment variable at it, and see what happens.

I'll give it a try and update this issue with results

@mikkelam I had issues with libcamera being out of date and the colorspaces not matching. I suspect picamera2 0.3.2 would've worked. We've since decided to fully switch to bullseye instead of trying to do this the "wrong" way.

I'm closing this issue, since I do not intend to move further with it.


Cannot start VR programmatically even though full screen is already started

I'm trying to implement a flow similar to this demo:
https://petravr.withgoogle.com/
The flow is basically:

Let the user choose the type of experience. Prevent sleep and on launch fullscreen mode (on Android) from the button press.
Ask the user to rotate the screen
When the screen has been rotated to landscape mode, start the stereoscopic rendering

On iOS this works fine, because iOS Safari has no fullscreen API.
Unfortunately on Android webvr-polyfill does a failing requestFullscreen-call (because the request doesn't come from a user event), which seems to prevent the scene from starting stereoscopic rendering.
Here's the specific line:
https://github.com/googlevr/webvr-polyfill/blob/master/src/base.js#L282
My problem is somewhat related to this:
https://github.com/aframevr/aframe/issues/1933
I wish I could take control of whether or not webvr-polyfill tries to launch full screen mode.

Thanks for filing! According to the 1.1 spec, requestPresent must be called within a user gesture. This is failing on Android for you due to fullscreen API having the same limitation -- this will also fail on a VR device (Vive, oculus, daydream, gear vr), so I don't think a workaround for the Android fullscreen is appropriate. Could you trigger the requestPresent from the user selection? The cardboard implementation inside the polyfill will trigger a rotation display and prompt the user to rotate as well similar to your step 2.

If I use requestPresent directly from the user gesture, the onFullscreenChange callback will automatically rotate the screen (if possible) preventing me from showing an instructions screen.
I don't see how I can then create an experience similar to the petra vr demo without patching VRDisplay.prototype.requestPresent to not automatically rotating my screen.

I've made the flow work by patching requestPresent to always request fullscreen on the document body, and to not rotate and lock the screen.
In case anyone needs a similar flow, here are the changes:
To use document.body as fullscreen element, and to not wrap it, replace this line:
var fullscreenElement = self.wrapForFullscreen(self.layer_.source);
with:
var fullscreenElement = document.body
Since the object is no longer wrapped, all occurences of self.removeFullscreenWrapper() can be removed.
To prevent the screen from getting rotated, comment out the following lines:
if (screen.orientation && screen.orientation.lock) {
  screen.orientation.lock('landscape-primary').catch(function(error){
          console.error('screen.orientation.lock() failed due to', error.message)
  });
}

@jeppester do you have a demo URL or video of this flow? I think I understand what you're trying to do.

I figured this isn't entirely the same issues you're trying to solve, but I figured I'd bring it up here because it may help you…
A-Frame uses the WebVR Polyfill, primarily for handling Google Cardboard on iPhone.
the WebVR Polyfill's "faux-fullscreen" is actually helpful (though limited in capability). a user can click on an "Enter VR" button and rotating the phone's orientation to landscape "just works."
I like that flow personally, but there are a few issues because portrait locks prevents the events from knowing the phone changed orientation:

https://github.com/aframevr/aframe/issues/1239
https://github.com/aframevr/aframe/issues/2992
https://github.com/aframevr/aframe/issues/2577

when the Fullscreen API is available (i.e., Chrome/Firefox for Android), obviously, that ought to be used.


Garden duplication with high tech cost multipliers

Move garden duplication recipes to Alien farming
Remove environment tech's prerequisite on Alien farming

KiwiHawk/SeaBlock@c7056b3

KiwiHawk/SeaBlock@c7056b3


Proposed solution to issue #224, getting the expected request_path when ...

...creating a nested resource
This solution follows along the lines of what you do with the parent id and includes the parent request path when building the resource.
Please give some feedback on this, if it's a fair solution, if something is missing. I would like your thought on this.

I'm not sure that this is such a good idea. Having an association doesn't necessarily mean that the parent path should be prepended like this. It really depends on the API. You can work around it by explicitly defining the collection_path but you may have noticed that this doesn't work for nested associations. I have fixed this in #318.
On the other hand, if you need to access a model directly as well as through an association then setting collection_path won't help. This is a tricky one. Maybe we need to be able to explicitly state the path that is used for direct access, if there is one, as well as the path used for each association. These paths could all be the same in some cases or they could all differ.

@edtjones, if you're looking at this one, I'd really appreciate having a chat with you about it.


wa - duplicate results in file

User is having issues with results duplicating on a file
User cannot update the feed
When user opens file it shows the duplicated results
should have no duplicates

Here's the text from the image above:
MSH10 10618cab-30ec-42eb-a48c-9c2f8d40e733 repeated twice
MSH 10 76385bf0-1870-4af9-b467-f3f4f8952145 repeated twice
MSH 10 2f8406d-2f0d-433c-bc14-964ccd3863fc repeated twice
MSH 10 a655db61-57de-4f3b-a956-5e2460c873f9 repeated twice

I've reached out to SimpleReport @zdeveloper for an answer on this. Waiting to hear back.
@Adrian-Brewster can you reach out to Washington to see if there's any actions they want us to take?

@Adrian-Brewster Per the user<EMAIL_ADDRESS>Thank you for letting us know.  We would like for duplicate results to be suppressed in the future and it sounds like you have a fix that can be applied, so this ticket may be closed.


feaLib: without glyphNames, warn but don't parse hyphens as ranges

Fixes https://github.com/fonttools/fonttools/issues/1768
cc @lianghai

If Parser is initialized without a glyphNames parameter (or with empty one), since it cannot distinguish between a glyph name containing an hyphen, or a range of glyph names, it will now interpret them as literal glyph names, while also outputting a logging warning to alert user about the ambiguity.
To silence the warning, one should either provide an explicit glyphNames to the Parser, or wrap the range-denoting hyphen with spaces, so that it cannot be confused with a single glyph name.

What do we want to do here? I think it's perfectly reasonable to expect that, when the parser is not given a context to distinguish glyph names containing hyphens from range of glyph names (e.g. when the content of the glyph set is not known in advance, and the purpose of such parsing is not building binary tables but extract/manipulate the data in the FEA), that the parser treats any token that resembles a glyph name as a glyph name while warning that it may resemble a glyph range. The warning gives the user the possibility to modify the text so that the ambiguity is resolved (by inserting spaces around the range-denoting hyphens) or by providing an explicit glyphSet when initializing the Parser.
This will not change the way feaLib builds the OTL tables since we always require that the glyphSet is given when the Builder instantiate its Parser, thus it is not an incompatible change.
I am inclined to merge this, but I want to hear from others first.


Consolidate and clean up tests / make them more uniform

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
As @jorgecarleitao  pointed out many moons ago, in https://github.com/apache/arrow/pull/9936#pullrequestreview-632020250 , the tests in datafusion/src/context.rs are not really unit tests. They are more like SQL integration tests.
There is also a small and languishing set of sql tests in rust/datafusion/tests/sql.rs that use a string comparison style that I personally find quite hard to upgrade.
Among other things, this split makes it hard to understand the state of DataFusion's test coverage.
Since these tests are critical for DataFusion's quality, I propose a small reorganization so it is easier to find existing test coverage and write new ones:
Describe the solution you'd like
Specifically I propose:

[x] #745
[ ] Update the style of all sql.rs tests to be inline with that in context.rs (using assert_batches_eq!)
[ ] Move tests that are not specific to ExecutionContext out of context.rs and into sql.rs
[ ] (maybe) move rust/datafusion/src/test to its own module rust/test_helpers (so that it can be shared with sql.rs)

Then over time I imagine being able to organize the tests within sql.rs better (split into multiple modules, for example)
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
None
Additional context
Original mailing list thread: https://lists.apache.org/thread.html/r77cb6f55952803debdbe10bb615d00ec097942fb88c1a88496b3d69a%40<dev.arrow.apache.org>

@alamb i believe we can mark task 2 completed now. If you agree then I can start looking at 3


feat: sequential getFoxyOpportunities

Description

Notice

[ ] Have you followed the guidelines in our Contributing guide?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

Risk

Testing

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #2512

PR #2523
PR #2532   👈

This comment was auto-generated by Graphite.

plz rename PR to parallel getFoxyOpportunities


Considering using rfc2629.xslt for testing v2/v3 equivalence

Julian Reschke suggested that we can try out his rfc2629.xslt. I'm thinking that we can use it for testing our backend v2/v3 equivalence. Thoughts @opoudjis ?
Link: https://www.greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#v3

If you find defects in rfc2629.xslt, feel free to raise issues at https://github.com/reschke/xml2rfc

arched eyebrow As in, RFC2629.xslt processes both RFC XML v2 and RFC XML v3, and I diff the resulting HTML? I could, though I hesitate because of the note that RFC2629.xslt support of v3 is incomplete, and of course a lot of the v3 features are additions to v2 to begin with. I'll see what I get out of it.

I think it would be more interesting to see whether rfc2629.xslt does something meaningful with the V3 output...

That's true. Instead of diff-ing, at least we can ensure that our v3 output works with rfc2629.xslt (and xml2rfc).

In fact, rfc2629.xslt can be a good nits-picker:
$ saxon draft-ribose-openpgp-oscca-01.xml rfc2629.xslt  > a.html

INFO: The /rfc/front/workgroup should only be used for Working/Research Group drafts
INFO: No need to include 'Working Group' or 'Research Group' postfix in /rfc/front/workgroup value 'Network Working Group'
WARNING: Unknown IETF area: "internet" - should be one of: "Applications and Real-Time", "art", "General", "gen", "Internet", "int", "Operations and Management", "ops", "Routing", "rtg", "Security", "sec", "Transport", "tsv" (as of the publication date of 201711)
WARNING: title/@abbrev was specified despite the title being short enough (28) - Title: 'OSCCA Extensions For OpenPGP', abbreviated title='OSCCA Extensions for OpenPGP'
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc2119 in link calculation
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc4880 in link calculation
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc6637 in link calculation
WARNING: @initials 'A': did you mean 'A.'?
WARNING: @initials 'S': did you mean 'S.'?
WARNING: @initials 'X': did you mean 'X.'?
WARNING: @initials 'R': did you mean 'R.'?
WARNING: @initials 'W': did you mean 'W.'?
WARNING: @initials 'P': did you mean 'P.'?
WARNING: @initials 'R': did you mean 'R.'?
WARNING: @initials 'W': did you mean 'W.'?
WARNING: @initials 'S': did you mean 'S.'?
WARNING: @initials 'S': did you mean 'S.'?
WARNING: @initials 'X': did you mean 'X.'?
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc6150 in link calculation
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc6234 in link calculation
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc7253 in link calculation
INFO: Ignoring @target https://www.rfc-editor.org/info/rfc8126 in link calculation
WARNING: unused reference 'SM2-1'
WARNING: missing text in street


onEvent(callback) API doesn't work

Description
If we use the onEnter() API from Usage example callbacks will not be fired in browsers where IntersectionObserver is not supported (e.g. IE):
const { onEnter } = this.inViewport.watchElement(element);
onEnter(this.didEnterViewport.bind(this));

Appearance of element in viewport leads to idle calling of noop() here
Workaround
Use modifier or pass callback to watchElement:
this.inViewport.watchElement(element, {}, this.didEnterViewport.bind(this));

@MaxKrai 👋 Thx for the issue.  I converted some of our dummy app examples to use this and the tests/ember serve seem to work correctly.  Possible to identify what is different than our examples?


You must depend on an EXACT version of electron not a range (^3.0.0-beta.1)

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Why this? I setup a simple project with electron-webpack & it didn't give me an error which by the way can be found here. I don't why this error is thrown :(

We currently reccomend you pin your electron dependency so that you don't run in to side effects when new versions of Electron get released.  This is historically because Electron < 2.0 didn't follow semver, there is a proposal to change how we handle this in a > 2.0 world


Remove from network

I recently merged some PRs onto master, which should help with the failling test suite.

I rebased it from master. it is now running checking on travis-ci.


Problem deploying this app on local tomcat

Hello @DanWahlin ,
I am trying to deploy this app on my local tomcat by copying the contents of the dist folder upon running ng build --prod into another myApp folder in webapps of my tomcat folder. I keep running into this issue with the internal api calls. Appreciate if you could help me get through this issue.
Request URL: http://localhost:8080/api/customers/page/0/10
Request Method: GET
Status Code: 404
Remote Address: [::1]:8080
Referrer Policy: no-referrer-when-downgrade
Content-Language: en
Content-Length: 1113
Content-Type: text/html;charset=utf-8
Date: Thu, 21 Feb 2019 17:51:57 GMT
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: 49a5kdkv409fd39
Cache-Control: no-cache
Connection: keep-alive
Host: localhost:8080
Origin: http://evil.com/
Pragma: no-cache
Referer: http://localhost:8080/myApp/customers
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Thanks..

This app has a RESTful service it calls that is written in Node (that's why npm start is called rather than ng serve to launch it locally). You'd have to deploy the Node service as well (and enable CORS since it'd be running on a different port doing it that way) or convert the service (code is in server.js) to Java. I'm not going to be able to help with that part of it since it's outside the scope of this project, but hopefully that gets you started.


Modal with fixed footer broken in IE11

The current version of the modal footer is displayed as shown in the screenshot below:

The white rectangle at the bottom of the window is the actual modal-footer div.

Just wanted to confirm that this issue is still present in v0.95.2 and can be tested in the http://materializecss.com/modals.html page with the same results as the screenshot.

Hmm we will have to look into fixes for this. It may not be possible to do this in IE


afterSwitchCommand doesn't appear in current version

Hello,
Currently trying to use the repo but am getting an issue here:

Hoping to use this case for when we remove node modules in the pr that are being used in some tests
As a workaround I am installing before and after but that is quite slow :(
Thanks for the awesome project :)

Thank you so much for updated! works perfectly :)


Code quality, style, and formatting (Request for Comments)

Summary
I took some time this weekend reading through the codebase at large and decided to try and cleanup inconsistencies in code style, restructuring code for readability, and applying some best practices for Unity at large. I've also updated the readme to include a style guide section here that covers this style for contributors.
Changes
Cleaned up code readability, naming style to be consistent

Add abstract modifier to all generic classes meant not to be instantiated directly as the intent is to specify a pattern for a closed type that can be serialized.
Added sealed keyword to all closed types. This is an incidental performance improvement for mobile and desktop platforms utilizing il2cpp due to the way unsealed vs sealed virtual methods are handled in generated C++ code.
Also sealed all inspectors to mark them as closed types.
Dropped all where constraints to the next line as most of these class declarations break 120-130 characters. This should help improve readability and make this style consistent as it has been in use for the most-complex generic types already, but not for others.
Dropped all generic type parameters (generally) numbering three or more to the next line to improve readability.
Where found, added empty lines between property/field declarations in classes to improve readability.
Extracted several 2x event classes into their own files to match convention established by other event classes.
Removed unecessary meta files for C# solution.
Added compiler options file (csc.rsp) file for the Unity project and added global warning ignore for 0649 (Field 'field' is never assigned to, and will always have its default value 'value'). This is necessary since 2018.3 switched the compiler to Roslyn and by design they have decided to not suppress this warning for monobehavior fields that are private, but serialized. This is very widely contested as most developers will not make every field needed to be assigned in the Editor as public (breaks encapsulation, opens surface area for bugs) and this can in some cases generate hundreds if not thousands of warnings. Adding the compiler options file suppresses this warning which also may hide legitimate warnings, but is far the lesser of two evils.
Moved example scripts not in a namespace to UnityAtoms.Examples.
Reordered public/private fields and properties to be consistent. Order is as follows; public and private properties followed by public/private fields.
Renamed private fields to use '_' prefix and marked public fields as private where only used internally. Marked these fields with FormerlySerializedAs attribute to preserve older serialized values already in use.
Removed redundant initialization of null to reference types as this is their default value.
Marked implicitly private methods and members without an access modifier as explicitly private.
Updated unit tests to use new private name field when getting private member field info.

Testing
There are few functional changes associated with this PR (internal changes for loop control in AtomicTags), but in general running unit-tests and playing the sample content would be good. I would also make sure to read the style guide here .

this seems to be a duplicate of #30
✔Add abstract modifier to all generic classes...
✔ Added sealed keyword to all closed types....
❌ Dropped all where constraints to the next line as most of these class declarations break 120-130 characters.
❌ Dropped all generic type parameters
I personally think a strictly forced line width does more harm than use.
e.g:

public abstract class ScriptableObjectList<T, E> : ScriptableObject where E : GameEvent<T>
vs
public abstract class ScriptableObjectList<T, E> : ScriptableObject
    where E : GameEvent<T>

or:

public class BoolReference : ScriptableObjectReference<bool, BoolVariable, BoolEvent, BoolBoolEvent> { }
vs
public sealed class BoolReference : ScriptableObjectReference<
    bool,
    BoolVariable,
    BoolEvent,
    BoolBoolEvent> { }

🆗 added empty lines between property/field declarations in classes to improve readability
🆗 Extracted several 2x event classes into their own files to match convention established by other event classes
I personally thought the complete oposite: since most of those classes are empty, they could share the same file. Their only use is to define the generic types.

✔ Removed unecessary meta files for C# solution
🆗 Added compiler options file (csc.rsp) file for the Unity project and added global warning ignore for 0649
but this will not solve the problem for people using UnityAtoms. (correct me if I'm wrong)

✔ Moved example scripts in a namespace to UnityAtoms.Examples.
🆗 Reordered public/private fields and properties to be consistent. Order is as follows; public and private properties followed by public/private fields.
❌ Renamed private fields to use '_' prefix and
see my comment in #30 https://gist.github.com/soraphis/7651bc5a8bb8e26fd5aa81b239aee835
especially the "private static" -> PascalCase does not make sense to me. Imho it should follow the other "private fields"
✔ marked public fields as private where only used internally.
✔ Marked these fields with FormerlySerializedAs attribute to preserve older serialized values already in use.
✔ Removed redundant initialization of null to reference types as this is their default value.
✔ Marked implicitly private methods and members without an access modifier as explicitly private.
✔ Updated unit tests to use new private name field when getting private member field info.

internal changes for loop control in AtomicTags

why? this should not make any difference in this case, because the ReadonlyList is just returning the Enumerator of the List it references, and iterating over List should not allocate memory - at least not since Unity 5.6


Use @material-ui/core v1.0.0

Updating the package dependencies to use @material-ui/core, the conversion is fairly straight-forward.
I also updated the /example/ package import statements, but struggled a little bit when testing the changes.  I ended up needing to use yarn on my local environment to test the devServer hosted sample page, but it seems to operate as expected.

I am having some struggles with updating the /example/package-lock.json.  My locally linked module  works fine through yarn, but it seems to fail when I try using npm install.
Also, the /example/ page still needs some attention to fix the form input fields, there is some strangeness not showing things like labels and stuff, that I am sure I have just overlooked the changes in the new release candidate of the @material-ui/core components.

I am getting strange errors like:
./node_modules/redux-form-material-ui/lib/Checkbox.js
Module not found: Can't resolve 'material-ui/Checkbox' in '/Users/nils/dev/mvp/webui/node_modules/redux-form-material-ui/lib'

I guess this pr would fix that, no ? .

Cheers @travomic!

Hi @travomic ,
I see there are two PR for the same change, I have consolidated with @andreapier PR.
Closing this in favor of #251

I have published new version on next, if no issues found will move this changes to master.


triggering workflow

What was wrong?
Closes #
How was it fixed?
@gnosis/safe-services

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
6288

Relevant Lines:
7174

💛  - Coveralls


Collection concat modifies integer index of second array

Laravel Version: 5.7.24
PHP Version: 7.2
Database Driver & Version: doesn't apply

Description:
concat method in Illuminate\Support\Collection does not respect index keys of second array when they are integers
Steps To Reproduce:
$a = collect([2 => 'a', 4 => 'b']);
$b = collect([10 => 'c', 12 => 'd']);

$result = $a->concat($b);

Expected
[
    2 => "a",
    4 => "b",
    10 => "c",
    12 => "d",
]

Actual Output
[
    2 => "a",
    4 => "b",
    5 => "c",
    6 => "d",
]

Using $a->toArray() + $b->toArray(); does show the expected and desired output.

Ok, I understand. Thank you and thank you for referencing the union method


Option to revert back a few "enhancements" + more

Is your feature request related to a problem? Please describe.
I love using goplay.tools for on-the-fly Go validation and recommended it to most everyone who used Go over the go.dev playground.  However, recent iterations of the platform have make it overly complicated or silly to use.
Notable gripes and suggestions:

Upload a file: Why?  People cannot copy-and-paste their code?
Local storage: I think whatever we worked on last time reappears when we go back to goplay.tools vs. having a clean canvas.  I try to not have any browser restrictions (eg - uBlock, Tracking Blockers) on the website because it is useful and if you can make a few bucks from user data to keep it running, then that's great. But, will have to enable those if it means less local storage and a new canvas with each subsequent visit to the website.
Font: We can increase the terminal font size, but not the editor font size, correct?  I would think the opposite would be ideal.
Suggestions: Seem too quick. It would be great to add some lag to these.
Errors: Nothing is really highlighted for errors, which keeps in line with a lightweight platform for porottyping, but I'd rather see error highlighting vs. file uploading.

Describe the solution you'd like
Stop "enhancing" things.  Or, provide an option for a lightweight version of the tool.
Describe alternatives you've considered
n/a
Additional context
n/a

You actually can increase editor font side in the same way as in VSCode - by holding Ctrl/Meta and mouse wheel scroll

Upload a file: Why? People cannot copy-and-paste their code?

They can, this is just a convenience option since the first option. Also copy-pasting code on mobile devices might be problematic without app to edit code.

Local storage: I think whatever we worked on last time reappears when we go back to goplay.tools vs. having a clean canvas

Auto-save will be an optional feature in next version, but local storage can't be fully removed as it used to persist settings.

Suggestions: Seem too quick. It would be great to add some lag to these.

I can't control that as monaco editor library responsible for that.

Errors: Nothing is really highlighted for errors

What are you talking about? Simple syntax errors are highlighted.

Any more advanced errors (type check, imports, etc) will require integration of a full LSP server but as you said yourself, it's better to keep playground "a lightweight platform for prototyping".


KNOX-1756 - Knox Gateway TLS Keystore and Alias Should be Configurable

What changes were proposed in this pull request?
Problem
The location of the keystore housing the Knox Gateway TLS certificate is hardcoded to <calculated from configs>/keystores/gateway.jks and the certificate alias is hardcoded to “gateway-identity”. This limits the ability for external management facilities to setup a custom TLS key and certificate for the Knox Gateway. For example, a host-wide, CA-signed, TLS certificate.
Knox has configuration hooks for the following (optional) properties

Home Directory - GatewayConfig.getGatewayHomeDir()

Gateway-site property: GATEWAY_HOME
System property: GATEWAY_HOME
Environment variable: GATEWAY_HOME

Data Directory - GatewayConfig.getGatewayDataDir()

System property: GATEWAY_DATA_HOME
Environment variable: GATEWAY_DATA_HOME
Gateway-site property: gateway.data.dir
Calculated: [Home Directory] + [Path Separator] + “data”

Security Directory - GatewayConfig.getGatewaySecurityDir()

Gateway-site property: gateway.security.dir
Calculated: [Data Directory] + [Path Separator] + “security”

Note: the calculation for the home directory is inconsistent with the other directory calculations. This inconsistency may be confusing to users and thus should be fixed to be

System property: GATEWAY_HOME
Environment variable: GATEWAY_HOME
Gateway-site property: gateway.home.dir

The path to the Knox Gateway TLS keystore is calculated as
[Security Directory] + [Path Separator] + “keystores” + [Path Separator] + “gateway.jks”

Solution
To make it easier to use an externally provided TLS key and certificate, the Knox Gateway should allow the TLS keystore file and alias name to be configurable. The following properties should be made available:

TLS Keystore File Path - GatewayConfig.getIdentityKeystorePath()

Gateway-site property: gateway.tls.keystore.path
Calculated: [Security Directory] + [Path Separator] + "keystores"  +[Path Separator]+  "gateway.jks"

TLS Keystore Password Alias (value to be stored in the Knox Gateway credential store) - GatewayConfig.getIdentityKeystorePasswordAlias()

Gateway-site property: gateway.tls.keystore.password.alias
Calculated: "gateway-identity-keystore-password"

TLS Keystore Type - GatewayConfig.getIdentityKeystoreType()

Gateway-site property: gateway.tls.keystore.type
Calculated: :”jks”

TLS Key Alias - GatewayConfig.getIdentityKeyAlias()

Gateway-site property: gateway.tls.key.alias
Calculated: “gateway-identity”

TLS Key Passphrase Alias - GatewayConfig.getIdentityKeyPassphraseAlias()

Gateway-site property: gateway.tls.key.passphrase.alias
Calculated: "gateway-identity-passphrase"

Additional methods for GatewayConfig should be added to improve consistency and prepare for potential changes to signing key related configurations

Keystore Directory - GatewayConfig.getKeystoreDir()

Calculated: [Security Directory] + [Path Separator] + “keystores”

Signing Keystore File Path - GatewayConfig.getSigningKeystorePath()

Calculated: If gateway.signing.keystore.name is set, [Keystore Directory] + [Path Separator] + [Signing Keystore Name]; else [TLS Keystore File Path]

Signing Keystore File Type - GatewayConfig.getSigningKeystoreType()

Calculated: If gateway.signing.keystore.name is set, value of gateway.signing.keystore.type (default: "jks"); else [TLS Keystore File Type]

Signing Keystore Password Alias - GatewayConfig.getSigningKeystorePasswordAlias()

Calculated: If gateway.signing.keystore.name is set, value of gateway.signing.keystore.password.alias (default: "signing.keystore.password"); else [TLS Keystore Password Alias]

Signing Key Alias - GatewayConfig.getSigningKeyAlias()

Calculated: If gateway.signing.keystore.name is set, value of gateway.signing.key.alias (default: "gateway-identity"); else [TLS Key Alias]

Signing Key Passphrase Alias - GatewayConfig.getSigningKeyPassphraseAlias()

Calculated: If gateway.signing.keystore.name is set, value of gateway.signing.key.passphrase.alias (default: "signing.key.passphrase"); else [TLS Key Passphrase Alias]

Note: the calculated values are set so they are backwards compatible with older versions of Knox to ease the upgrading process.
Hardcoded values related to the identity and signing keystore location and relevant alias names should be removed, using the GatewayConfig methods to provide configured or calculated values.  Assumptions that the keystore and key passwords are the master secret should be removed; however, if a password cannot be found via the AliasService, the fallback value should the master secret.
How was this patch tested?
Updated unit tests
Manually tested using

default keystore for identity and signing
custom keystore for identity, default keystore for signing (falls to custom keystore for identitiy)
custom keystore for identity, custom keystore for signing

Please review Knox Contributing Process before opening a pull request.

Changes look reasonable but getting test failures with mvn -T.5C verify -Prelease,package
[ERROR] Errors:
[ERROR] org.apache.knox.gateway.GatewayDeployFuncTest.testDeployRedeployUndeploy(org.apache.knox.gateway.GatewayDeployFuncTest)
[ERROR]   Run 1: GatewayDeployFuncTest.setupGateway:110 » NullPointer
[ERROR]   Run 2: GatewayDeployFuncTest.cleanupGateway:121 NullPointer
[INFO]
[ERROR] org.apache.knox.gateway.GatewayMultiFuncTest.org.apache.knox.gateway.GatewayMultiFuncTest
[ERROR]   Run 1: GatewayMultiFuncTest.setUpBeforeClass:87->setupGateway:124->startGatewayServer:139 » NullPointer
[ERROR]   Run 2: GatewayMultiFuncTest.tearDownAfterClass:94 NullPointer
[INFO]
[ERROR] org.apache.knox.gateway.GatewaySslFuncTest.org.apache.knox.gateway.GatewaySslFuncTest
[ERROR]   Run 1: GatewaySslFuncTest.setUpBeforeClass:100->setupGateway:141->startGatewayServer:170 » NullPointer
[ERROR]   Run 2: GatewaySslFuncTest.tearDownAfterClass:107 NullPointer
[INFO]
[INFO]
[ERROR] Tests run: 62, Failures: 0, Errors: 3, Skipped: 3

The three tests above I checked in an IDE and they all broke at DefaultKeystoreService line 172 checking if the configured keystore exists or not.

All tests passed locally now. Performing some sanity checks to make sure this works as designed.

@rlevas while testing I noticed the following:

There are strings like the following still present when there are errors loading the certificate "provided (or persisted) master secret"
./bin/knoxcli.sh create-cert seemed to overwrite my existing certificate. Checking into this more to see what happened here.

For the ./bin/knoxcli.sh create-cert, I was using a self signed certificate for testing and create-cert overwrites the existing certificate if it is self signed. Based on rereading the PR this is expected behavior.
I guess I was expecting to have to force to overwrite the existing certificate since it was a certificate that I had created.

Found an interesting edge case when configuring Knox.
If you configured a custom signing certificate in gateway-site.xml and then go to create the aliases with ./bin/knoxcli.sh create-alias ... you will run into the following error:
2019-02-22 14:25:36,775 ERROR knox.gateway (BaseKeystoreService.java:getKeystore(113)) - Failed to load keystore [filename=keystore-signing.jks, type=JKS]: java.io.IOException: Keystore was tampered with, or password was incorrect

DefaultKeystoreService.init(...) is doing checks to see if the signing certificate is setup correctly. This was not added in this PR but breaks the ability to add aliases if there is a custom signing certificate not fully setup. The check in DefaultKeystoreService should be removed because it doesn't belong in the KeystoreService. The KeystoreService impl should be generic to what is stored in the keystore. Currently the signing certificate check breaks that design.

For the ./bin/knoxcli.sh create-cert, I was using a self signed certificate for testing and create-cert overwrites the existing certificate if it is self signed. Based on rereading the PR this is expected behavior.
I guess I was expecting to have to force to overwrite the existing certificate since it was a certificate that I had created.

Would you like this behavior changed to require --force if the entry exists in the keystore?  However I think overwriting was the behavior before the changes in this patch.

Would you like this behavior changed to require --force if the entry exists in the keystore? However I think overwriting was the behavior before the changes in this patch.
I think the existing behavior made sense when it was in data/security/keystores/gateway.jks. This was a path that was fully owned by Knox. Since we are now following the path to the custom keystore, we should be more careful about what we overwrite. Not sure how easy it would be to check if the identity path is the default vs a configured one?

The check in DefaultKeystoreService should be removed because it doesn't belong in the KeystoreService. The KeystoreService impl should be generic to what is stored in the keystore. Currently the signing certificate check breaks that design.

Would you like this changed in this patch.  It seems like maybe it would fall under a different issue, but I will fix it here is desired.

I think the existing behavior made sense when it was in data/security/keystores/gateway.jks. This was a path that was fully owned by Knox. Since we are now following the path to the custom keystore, we should be more careful about what we overwrite. Not sure how easy it would be to check if the identity path is the default vs a configured one?

I guess we can see if the path is the expected default and maybe also see if the cert is self-signed and has the DN of the Gateway-created one. If so, we blindly overwrite, else we require a --force. This seems like it may fall under a different issue, but I can fix it in this patch if desired.

Would you like this changed in this patch. It seems like maybe it would fall under a different issue, but I will fix it here is desired.

@rlevas can you file a separate JIRA to fix this? They are definitely related but can be fixed independent of this PR.
There is an easy work around, define the aliases upfront before configuring gateway-site.xml. This wouldn't work in a Docker scenario potentially but something that would be possible in a lot of cases.

I guess we can see if the path is the expected default and maybe also see if the cert is self-signed and has the DN of the Gateway-created one. If so, we blindly overwrite, else we require a --force. This seems like it may fall under a different issue, but I can fix it in this patch if desired.

I think it should be fixed here since the check for self-signed was introduced in this patch. I worry that someone will have their own self signed certificate overridden by mistake if we introduce this patch.

Create a JIRA to address the DefaultKeystoreService check issue

Created https://issues.apache.org/jira/browse/KNOX-1793.

@risdenk tasks completed with latest push...

[x] Fix the logging messages to be consistent - remove remaining references to "provided (or persisted) master secret"
[x] Address the ./bin/knoxcli.sh create-cert check for selfsigned to check if it is the default path

Manual tests all look good as well. Ran the following tests:

Checked that with no configuration Knox still works
Checked that TLS and signed certificate configurations work independently
Misconfiguring on purpose TLS/signed configuration properties
Checked that error messages are reasonable
Checked both self signed and CA signed certificates work correctly
Ensure that JKS and PKCS12 certificates work


[PRO-2779][v1] - Pre-commit hooks

Similar to https://github.com/kiva/protocol-sdk-verifier/pull/14, this doesn't solve all our problems, but it's a start

For the record I don't see a postinstall script as any more invasive than asking people to install our NPM project, but I don't want to make anyone unnecessarily uncomfortable.
Also, people may have their own hooks set up. Overwriting those hook scripts with ours would definitely be a Bad Thing.


⚠ Bofrost.es has degraded performance

In 80a3d0a, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1486 ms

Resolved: Bofrost.es performance has improved in 40efa64 after 310 days, 16 hours, 45 minutes.


Bubble chart from demo loads too long (or not at all) with 4 more bubbles

I want to use your chart and I decided to start with demo. I need a lot of bubbles, so I started with adding 4 more to your demo and it stopped working.  Firefox (34.0.5) behaves similar.
I tried to debug it, but I went as far as running profile in Chrome developer tools. I noticed that function randomCirclesPositions took the most of the execution time. I suspect that $.each could be the culprit.

Thanks @hahiserw,
The purpose of randomCirclesPositions is to make sure no bubble can not be intersect on others, therefore output of this function is an array of containing positions of bubbles without overlay others.
There are 2 options to due with the issue (see the example)
intersectDelta: Intersection between circles, in pixel
intersectInc: Increment of intersectDelta, in pixel, the randomCirclesPositions will auto-add intersectInc if it can not find a position for a bubble
In case you add 4 more on my demo, the function is infinity loop because it not find suitable positions for all of them. Therefore, I close this issue.
Hope this help


LinkedIn Scope issue "InternalOAuthError: failed to fetch user profile"

We have been getting InternalOAuthErrors for linkedIn recently on PRODUCTION.
Also reported by @IsaacAbrahamson in https://github.com/freeCodeCamp/freeCodeCamp/issues/14652#issuecomment-359528285
We need to update our config as per the suggested fix for the correct scope:
https://github.com/auth0/passport-linkedin-oauth2/issues/24#issuecomment-358279513
Just to note, this still links the profile, correctly, only thing is this exception needs to be handled, by correcting the scopes.

Reading through https://github.com/auth0/passport-linkedin-oauth2/issues/24 and looking at the config used in your code the scope looks fine, but the profileFields need being set -unless you prefer catch the exception and shrug.
I'm not familiar with this code base, but based on @raisedadead's suggestion to just catch the exception it sounds like we don't really care what is returned at all.
A blunt fix would be to just add the suggestion in https://github.com/auth0/passport-linkedin-oauth2/issues/24 and specify the profileFields:
{
   // specify which profile fields to fetch, instead of the default to return all the things
    profileFields: [
                "formatted-name",
                "headline",
                "id",
                "public-profile-url",
                "email-address",
                "location",
            ],
    scope: ["r_basicprofile", "r_emailaddress"], // as in place at the moment
}

I noticed you have three places where you configure linkedin, as linkedin in /config/secrets.js and as linkedin-login and linkedin-link in /server/passport-providers.js

@raisedadead @QuincyLarson just got back from lunch, have created and linked a PR to this issue.

@raisedadead case closed?

Thanks @ojongerius


chore: Run yarn install with 'ignore engine' flag in ci

Not all dependencies specify yet that they run on node 18.
This change should allow us to merge this dependabot pr: https://github.com/SAP/cloud-sdk-js/actions/runs/3934981468/jobs/6730242461

We had this in the past, but removed it to make sure we are aware if problems like this exist. Should we have an additional check (that is optional in the PR checks) to validate that our dependencies correctly specify their engine support?


visual tweaks

Just making the text be centred and the background image fit full screen.  The text centre is only really noticeable when there is less text.
Before...

After...

@AndyGaskell Thank you


Content Planning - What is a guideline and what guidelines we are going to create for 2020

As an IBM.com Library website content creator,

I need a way to help adopters understand what is a guideline and provide guidelines specificity to their day to day work

so they can work on their day to day tasks without confusion.

Additional information
We need to find answers on the following two areas:

What is a guideline?
What guidelines are needed specifically for IBM.com adopters?

Acceptance criteria

[x]  Have an agreed definition of what a guideline is from the team.
[ ]  Have a list of the guidelines we can update the website sitemap with and make plans for content creation.

@wonilsuhibm @larahanlon2 @oliviaflory FYI on this task issue created based on our conversation today.

We will work on the next step via #304.


Why using redux when apollo client manages its own store?

The initial look at the project seems very promising. However, I am wondering why are you using redux for state/store management when apollo-client uses its own internal store.
Or you just provide redux integration in case someone wants to utilize it, but redux is not necessary in order to build the client side.

Good question, @mairh - I'm sure other devs might be wondering the same.
The reason is touched on very briefly [in this code comment)(https://github.com/reactql/kit/blob/master/kit/lib/redux.js#L15-L16).
It's very common you'll run into the need for application state outside of Apollo/GraphQL.
Say, clicking a button that fires an AJAX request to a non-GraphQL endpoint and needs to do something with the data... or connecting to a Websocket and responding to server events... or even something much more trivial, such as clicking a button and changing a user setting.
There are plenty of times when the data returned from your GraphQL server will only form part of the full picture. Flux is a useful pattern for the rest of the app, too. By setting Redux explicitly (vs. Apollo's implicit use of it), we can easily add our own 'reducers' that are useful to the non-GraphQL parts of our app.
Let me know if you have any other Qs.

Also worth mentioning are these lines from the same Redux lib.
By going 'explicit', we can fine-tune the kit to enable Redux tools by default, and rehydrate application state across the full store dump - not just Apollo.

Excellent answer @leebenson Could you please tell me if everything from apollo store is mapped automatically to the redux store by default?
However, we have the option to create own redux modules (if case we want to).
For e.g (Apolo store)

vs Redux store

@mairh - correct. Redux uses a single store for the entire application, and the Apollo data appears as an apollo key on that one store:

So, you can add additional reducers to Redux that listen to events other than APOLLO_QUERY_INIT, etc, and update the store data as needed.

In order to handle external data requests etc, we leverage apollo's client side resolvers to handle non graphql accessible data sources.
I'd like to understand if there are other reasons for using an additional layer like redux if using the approach above.
Link to apollo client side resolvers:
https://www.apollographql.com/docs/link/links/state.html#resolver

@ntziolis - there shouldn't be, no. Per your link:
4. Query resolvers are only called on a cache miss. Since the first time you call the query will be a cache miss, you should return any default state from your resolver function.

If you're using Apollo to retrieve data from, say, a REST endpoint, then it should be stored in the Apollo cache on initial retrieval. If you have a <Query> object that uses that same data later on, it will pull it from cache, rather than re-request it remotely.
If you have more complex needs, you can even create a mutation in src/graphql/state.ts that takes the piece of data you care about, and wrap the block in a <Mutation> that triggers the mutation query (i.e. putting the data into the local store), which subsequent <Query> blocks can pull from using standard GraphQL syntax.
The point being, the local Apollo store is intended to entirely replace Redux, and give you access to it using regular GraphQL.

Wow. Thank you for this blazing fast and thorough answer. For us its really exiting to see graphql not just being able to unify "to/from" server, but also internal application communication.

My pleasure!


changed from hardening-io to dev-sec in README.md and added ubuntu and centos version to ssh_crypto.rb

Awesome @atomic111


How to clear barcodes that already had value in useScanBarcodes?

any idea?

Same issue here, the hook doesn't expose the setter. A workaround is to hold your own state, you can update the state in an useEffect whenever the property barcodes changes. Now you can control your own state and base your UI on that instead of the one that the hook gives you.

@zxccvvv
I decided to do it in the next way if it is actual, not sure if it the best solution, but lib doesn't provide anything from inside
let [frameProcessor, barCodes] = useScanBarcodes
once you did what you need with barcodes  just:
barCoder = []


Feature Request - Client side form validation

Type: New feature / ~Migration from Vanilla JS~
Description: When input is changed, validate the input & show error message immediately below the input
Example Links:
1)
2)
3)

Requested feature in the udemy course:
Stimulus Sortable, with acts as list and ajax to save the position, if possible.


code issues

Hi
I want to ask if there is an issue with this line of code? Why are we using sigmoid function after obtaining the atomic mass features?
https://github.com/molML/MoleculeACE/blob/27f26ebae652e5f4101218ac7a27b25558d2db33/MoleculeACE/benchmark/featurization.py#L280

Interesting point! I want to know why as well.


[WIP] Improve display of 404 pages

With this change, the EntriesController will now raise
ActiveRecord::RecordNotFound for all unknown formats.
This bubbles up to the ApplicationController where it is currently
dealth with in a rescue_from block. This has been changed to simply
render a 404 head response.
This frees us from trying to come up with appropriate response formats
while still giving the correct HTTP header.
I would strongly prefer to entirely ditch the rescuing from
ActiveRecord::RecordNotFound and let the host application deal with this
problem. It seems something that is very specific to the host, and not
up to Pageflow.
fixes #40

@tf this is just an idea I had that will deal with this error gracefully, in my opinion. By raising this error we can let other layers deal with this problem. In this case that will be the application controller, but I would actually suggest to not rescue that and let the host application deal with it.
For example, I know that the regular 404 had hard-coded German in it, which is not something easily useful for English apps. I would say that raising is the most appropriate thing to do, even if we're not strictly trying to find a non-existing ActiveRecord.
Your ideas?
When pursued the public folder and associated stylesheets should be cleaned up too.
I never could find a reference to the 500.html, it seems to be an orphan.

Coverage decreased (-0.03%) to 97.597% when pulling b804ad397238535cf1eae6f5bd274b6a217f450d on scrollytelling:404-improvements into 9bdf06ffcb8df3f2f7bff44b7be5f88f5eb11895 on codevise:master.

You make some compelling points and, as #40 states, things are currently a bit broken in this area.
First, I'd suggest removing the format.any from EntriesController completely since we already are rescuing UnknownFormat in the ApplicationController. We should probably improve our response there instead of rendering the text "Not found".
Regarding removing all rescuing logic I'm skeptical. Even if Pageflow::ApplicationController inherited from ApplicationController, forcing the host application to handle all cases there seems like leaking to much implementation detail to me. But what do you think about having the install generator create public/pageflow/404.html and rendering that? That way the host application has full control of what is rendered, but does not have to care about when this happens.
Keeping files in public also makes it easy to reuse files in the Nginx config. That's where the stray 500.html comes from.
For more complex integration, I'd otherwise suggest doing this via new config options, i.e. allowing to register a lambda that handles the case where an entry is not found. That could then deal with specific needs like displaying a localized error page etc.
Thoughts?

Tweaking the generator is an excellent idea! This is the least surprising alternative and quite flexible too.
I might be able to start work on this next week.

Coverage decreased (-0.01%) to 97.731% when pulling c258942d8148444adf2f1ed145e64b647ac33081 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

@tf I pushed some new commits.
Once people upgrade to 0.11/0.12 we would have to urge them to re-run the generator.

Coverage decreased (-55.8%) to 41.981% when pulling ffbf3f885facc20414985bc6c8f89fb4d5c5421c on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Coverage decreased (-0.07%) to 97.678% when pulling ffbf3f885facc20414985bc6c8f89fb4d5c5421c on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Coverage decreased (-55.8%) to 41.981% when pulling 28b2d878b917875a21fbebb4d6f09d8a706df3da on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Coverage increased (+0.05%) to 97.791% when pulling bac037807c1bbb572bbfead24738ec35662ef0f5 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Coverage decreased (-0.05%) to 97.688% when pulling 88bb088e430011487a8415ef6a2f371f563aa624 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Looks really good already! And for the upgrade step running the pageflow:error_pages generator should be enough, right?

And for the upgrade step running the pageflow:error_pages generator should be enough, right?

Yes.
Just pushed up the new commit to move error pages into its own directory. Final review?

Coverage decreased (-0.07%) to 97.673% when pulling c556423f0a66d4b680c179ceb7fe45ec3d27d342 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Coverage decreased (-0.009%) to 97.734% when pulling efa67ba0da6fa5b2400551915e50329baf1720a9 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Added two more notes. Not sure about the test issue. Please again squash to one descriptive commit when you're done.

Coverage decreased (-0.01%) to 97.728% when pulling 4827847ddedfe96095b7f01986848cf6c4b17ac9 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

Coverage decreased (-0.01%) to 97.728% when pulling 4827847ddedfe96095b7f01986848cf6c4b17ac9 on scrollytelling:404-improvements into 2249619f73449f13014b57149919881e5fdeae89 on codevise:master.

The test does not seem to work. I got suspicious when I saw that the rescue clause still has no test coverage. Running the test locally a few times reveals that rails caches rendered files. So if a spec before already rendered the 404.html, renaming it does not hurt. I'm not sure what to do. Stubbing render also feels dirty. We could take this as an excuse to make the path to the error page configurable. That way, if the host app already has a public/404.html, Pageflow could be configured to reuse that. In our test though, we could point the config option to a non-existing path and check for the head response. What do you think?
Regarding testing the response body: The current test does not really ensure the template is used. For all we know this could also be the head response. Maybe we can at least test that the response is not empty or looks like an html page.
Finally, I'm not so fond of using rand in tests. If the id really does not matter, we can just as well choose one or use a string like "not_there".

@tf I took out the test and left it at that for the moment.
Adding the config feels a little scope-creepy to me, but not a bad idea in principle. If we're doing that only to satisfy the test case, that's probably not the right reason though.
I will be on vacation for three weeks, with little access to GitHub.

Agreed. Have a nice vacation.


Implementation Query - Example 14 (Actuator and Sensor Interface)?

Hello,
I have been working with Ros2 control for a very long time and it is wonderful. Now, I am trying to implement a z axis with stepper control. So I just need a trigger signal that sends true (int 1) to my arduino based on my system state from ros ecosystem and after the task is done my Microcontroller would send back true in another variable through serial. I have a custom serial interface already implemented so all I need to do is call two different functions from my comms file which is void sendRequest(triggersignal) and void readState(zaxisstate) and I update another feedback topic based (provided by ros2 control) on the information I get. I thought I could use actuator interface although read function wasn't there in the example, I tried adding it. It doesn't really work. Also when my stepper does the task it gets stuck in a while loop as the steps are passed to the driver. Does it block my serial interface? In this case, which example I should be looking for and what is the best method to implement this?
Thank you.

You can see the difference of system_interface, actuator_interface, and sensor_interface here.
You could try to implement both inside a system_interface like in example_4 or separate it into sensor and actuator as done in example_14.

Closing due to inactivity.


Multiple aggregate groups per check

I was thinking Aggregates 2.0 was going to allow for this, but looking at the documentation "aggregate" only accepts a string. Is there a way to have the same check show up in multiple aggregates? If not any plans on supporting this?

@RyanJarv "Aggregates 2.0" made it possible to add multiple checks to an aggregate. We could potentially introduce "aggregates": [] as a check definition attribute, allowing a check to be added to multiple aggregates.

This is a cool idea!

My main use for this would be to avoid spam during major issues. Things could be grouped per cluster, zone, datacenter and if any one is say over 50% down it would trigger a single check that would silence everything that is a member of it, so everything in that group would be a dependent on that aggregate check. I think this would work anyways.. might need to think it over again just because this was my plan a while ago but put it on hold.

We can do something like https://github.com/sensu/sensu/blob/master/lib/sensu/server/process.rb#L249

Implemented by #1379, to be released in Sensu 0.26.


Prompt to uninstall outdated Dokan in the GUI

Note that this replaces https://github.com/keybase/client/pull/13648 , which was inferior because it tried to do the registry operations separately on the GUI side instead of having the service do it as part of the fuse status info. The uninstaller still has to be invoked from js though.

I tried to not use a generator by various combinations of actionToPromise, actionToAction, using chiled_process.exec instead of execSync, etc., and none of it worked so I put it back this way. Again, all it needs to do is get a string from the store, invoke it as an external process, then do an action when finished.
@chrisnojima


ONNX export: Square and ReduceSum operators

Description
Enabling export of Square operator and Sum operator
v2: Added reduce_sum tests based on @anirudhacharya's review
v3: Addressed @Roshrini's and @zhreshold's review comments
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

Export mx.sym.Square using Power operator in ONNX
Export mx.sym.Sum using ReduceSum operator in ONNX
Added tests for ReduceSum

Comments

Tested onnx_backend_test.py

@mxnet-label-bot[pr-awaiting-review]

Rebased on top of #12633.
Added tests for ReduceSum.
Test for square is taken care by the existing tests for Pow operator.
@anirudhacharya @Roshrini @zhreshold This PR is ready for review again.

LGTM

@anirudhacharya @zhreshold ping for review

@zhreshold @Roshrini @anirudhacharya review comments addressed. is this PR good to go?

Since this PR uses changes in https://github.com/apache/incubator-mxnet/pull/12646, combining the 2 PRs. This will be closed in favor of https://github.com/apache/incubator-mxnet/pull/12646 once the changes are pushed.


is_numerical argument GrootTreeClassifier

Running the example code on the make moons data in the README I get:
Traceback (most recent call last):
  File "/home/.../groot_test.py", line 11, in <module>
    tree = GrootTreeClassifier(attack_model=attack_model, is_numerical=is_numerical, random_state=0)
TypeError: __init__() got an unexpected keyword argument 'is_numerical'

Leaving out the argument and having this line instead:
tree = GrootTreeClassifier(attack_model=attack_model, random_state=0)
results in this error:
Traceback (most recent call last):
  File "/home/.../groot_test.py", line 15, in <module>
    adversarial_accuracy = DecisionTreeAdversary(tree, "groot").adversarial_accuracy(X_test, y_test)
  File "/home/.../venv/lib/python3.9/site-packages/groot/adversary.py", line 259, in __init__
    self.is_numeric = self.decision_tree.is_numerical
AttributeError: 'GrootTreeClassifier' object has no attribute 'is_numerical'

I'm guessing the code got an update, but the readme didn't.

Sorry for missing this issue, somehow I had my notification turned off! The problem is indeed my mistake of forgetting to update the README.md. I now replaced the example inside of the README.md with the example from the docs and this should work. Could you test that? Let me know if there are any remaining problems!
The new example should be:
from groot.model import GrootTreeClassifier
from groot.toolbox import Model

from sklearn.datasets import make_moons

# Load the dataset
X, y = make_moons(noise=0.3, random_state=0)
X_test, y_test = make_moons(noise=0.3, random_state=1)

# Define the attacker's capabilities (L-inf norm radius 0.3)
epsilon = 0.3
attack_model = [epsilon, epsilon]

# Create and fit a GROOT tree
tree = GrootTreeClassifier(
    attack_model=attack_model,
    random_state=0
)
tree.fit(X, y)

# Determine the accuracy and accuracy against attackers
accuracy = tree.score(X_test, y_test)
model = Model.from_groot(tree)
adversarial_accuracy = model.adversarial_accuracy(X_test, y_test, attack="tree", epsilon=0.3)

print("Accuracy:", accuracy)
print("Adversarial Accuracy:", adversarial_accuracy)


wsl set default version

okay so i've tried to get wsl on windows insider at start but didnt seemed to work so i did manual thing and I got thing when i execute the "wsl --set-default-version 2"
here's the error log (french):
PS C:\WINDOWS\system32> wsl --set-default-version 2
Pour plus d’informations sur les différences de clés avec WSL 2, visitez https://aka.ms/wsl2
i dont know if that mean version is set to 2, i've also tryed enable VT on my bios, i've check marked it and saved things but when i execute "(GWMI Win32_Processor).VirtualizationFirmwareEnabled" in PS it says "False"
i use a HP pro book

Have you already read this post?

Have you already read this post?


Twilight 2000 4th Edition | Fix medical aid roll bug

Changes / Comments
Necessary fix to Medical Aid resolving a typo on the attribute.
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[x] Is this a bug fix?
This fixes an issue with a typo in the Medical Aid attribute so that the roller works as expected
[x] Does this add functional enhancements (new features or extending existing features) ?
This does not add new or enhanced features
[x] Does this add or change functional aesthetics (such as layout or color scheme) ?
This change does not
[x] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
Will not preserve data as the previous medical aid attribute had a typo in it
[x] If this is a new sheet, did you follow [Building Character Sheets standards]
This is not a new sheet
(https://wiki.roll20.net/Building_Character_Sheets#Roll20_Character_Sheets_Repository) ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


Vue 3 Composition API

[ ] Implement Composition API as plugin for Vue 2
[x] create example component

very basic example can be tested in PR #997


Improve MLKDNN LayerNormLastDim() performance

Description
imporve MKLDNN LayerNormLastDim() performance, it will benefit the gluonnlp/bert and maybe other nlp task.
test the performance with both MXNet master and this pr at skx8180-1s with the performance test script  , get speedup 1.27X~2.31X.
master branch:
shape: [1, 128, 768],   time: 0.148154 ms
shape: [8, 128, 768],   time: 0.296437 ms
shape: [32, 128, 768],  time: 0.790932 ms
shape: [1, 128, 1024],  time: 0.237234 ms
shape: [8, 128, 1024],  time: 0.553549 ms
shape: [32, 128, 1024],         time: 1.765041 ms

opt_layernorm branch:
shape: [1, 128, 768],   time: 0.064805 ms
shape: [8, 128, 768],   time: 0.198420 ms
shape: [32, 128, 768],  time: 0.439751 ms
shape: [1, 128, 1024],  time: 0.121733 ms
shape: [8, 128, 1024],  time: 0.430842 ms
shape: [32, 128, 1024],         time: 1.359872 ms

Through the profiling of gluonnlp/bert/finetune_classifiy.py, get speedup 1.8X~3.37X on LayerNorm op.
@TaoLv @juliusshufan @PatricZhao @eric-haibin-lin
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

Thanks for the improvements. Is there a test case to cover this OP?

@pengxin99 Thank you for the contribution. Could you change the title and description? I think this PR and the LayerNorm operator is not related to MKL-DNN. Better to call it "Performance optimization of LayerNorm on CPU".
@pengzhao-intel Test should be covered by https://github.com/apache/incubator-mxnet/blob/master/tests/python/unittest/test_operator.py#L3594 and https://github.com/apache/incubator-mxnet/blob/master/tests/python/unittest/test_gluon.py#L741.


[mesheryctl] Unnecessary usage offered on failure to deploy Meshery to Kubernetes

Refer the mesheryctl Command Tracker for current status of mesheryctl.
Current Behavior
When the configured Kubernetes environment is not available, users error messages AND usage / help. Printing out help is unnecessary and not helpful in this circumstance.
$ mesheryctl system start
Kubernetes unreachable.
Error: Kubernetes is not available. Verify Kubernetes is up, reachable, and a valid cert / token is available.%!(EXTRA string=start): Get "https://kubernetes.docker.internal:6443/api/v1/pods": dial tcp <IP_ADDRESS>:6443: connect: connection refused
Usage:
  mesheryctl system start [flags]

Flags:
  -h, --help          help for start
      --reset         (optional) reset Meshery's configuration file to default settings.
      --skip-update   (optional) skip checking for new Meshery's container images.

Global Flags:
      --config string    config file (default location is: /Users/lee/.meshery/config.yaml)
  -c, --context string   (optional) temporarily change the current context.
  -v, --verbose          verbose output
  -y, --yes              (optional) assume yes for user interactive prompts.

#### Desired Behavior
Do not display help on failure to connect to Kubernetes.

#### Contributor Resources

- [mesheryctl Contributing Guide](https://github.com/layer5io/meshery/blob/master/mesheryctl/README.md)
- [Beginner's guide to contributing to Meshery and mesheryctl](https://youtu.be/hh_kFLZx3G4)
- [mesheryctl Command Tracker](https://docs.google.com/spreadsheets/d/1q63sIGAuCnIeDs8PeM-0BAkNj8BBgPUXhLbe1Y-318o/edit#gid=0)
- [Meshery CLI Commands and Documentation](https://docs.google.com/document/d/1xRlFpElRmybJ3WacgPKXgCSiQ2poJl3iCCV1dAalf0k/edit#heading=h.5fucij4hc5wt)

@leecalcote
Thanks for assigning this issue!
Just to clarify, is this the expected output:

Wanted to clarify before moving ahead.
Thanks!


Aggregate finders

Currently there is no way to specify pairs of paths and names as a search criteria (ie. all names are looked up in all paths which may not be desirable).
One potential solution is eliminating the difference between paths and names.
Another solution is creating a separate finder implementation that aggregates different finders (maybe running them in parallel).
This may not result in the best performance, but the primary purpose of this library is to support configuration loading use cases where performance is rarely a concern.
Introducing alternate implementations comes with a new challenge though: we need a finder interface in this library. The name Finder is already taken though.

I decided to tackle this in spf13/viper#1849 instead.


tippy: Remove the focus trigger from the compose-control-buttons.

By default, tippyjs uses a trigger value of 'mouseenter focus', which means that the tooltips can appear either when the element is hovered over or when it receives focus (e.g., by being clicked). Because of this, if you click on the button to open the popover, the tooltip also appears. To prevent this behavior, we need to remove the 'focus' trigger from the buttons so that the tooltips don't appear when the buttons are clicked.

Fixes: #25277
CZO: Thread

Screenshots and screen captures:

Before:

After:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@shameondev , could you please review the PR, thanks :)

And I just wanted to point out that the message actions tooltip and popover are working smoothly. Maybe we could take a closer look and see what they're doing right that we could apply here? What do you think?

I just wanted to point out that the message actions tooltip and popover are working smoothly. Maybe we could take a closer look and see what they're doing right that we could apply here? What do you think?

Sure, will look into this and will push the latest changes by tomorrow morning.

While I think we may need to do something for accessibility to make sure it's possible to get these tooltips from the keyboard, I've merged this just to replace the highly visible bug with a less highly visible bug while we investigate the best path forward here.


Activation failed with version 1.6.2

OP.
Dev log saids
Activating extension `streetsidesoftware.code-spell-checker` failed:  Cannot find module 'fs-extra'.

Re-install the extension solved the problem. Though I have no idea what caused the previous problem.

Strange. Thank you for reporting.


boards: Add particle-xenon (for full-image and riotboot)

This adds yet another board, but this time it's tricky because that board doesn't have an on-board debugger. It is commonly used in either of three modes:

with the upstream bootloader (which uses dfu-util and an elaborate startup sequence)
with riotboot-dfu (which uses 16KiB bootloader followed by two slots, which is a weird default for a USB based bootloader, but convenient when you also want to do OTA)
with an external programmer (using a 2x5 pin ~50mil IDC connector)

On the long run I hope we can support the upstream bootloader, but riotboot is a) easier (no checksumming outside the header, and I can flash it and debug step through the loading process), and b) more widely spread in our ecosystem. This PR includes riotboot support.
Riotboot support is implemented using cargo flags that tell a build.rs which partitioning is used. On the long run, that code will need to be more universal; right now it's sitting in nrf52/build.rs for further experimentation.
I've successfully used this to flash a board through riotboot-dfu, but so far that's a manual process, because it involves:
$ laze -C examples/embassy-net-udp build --verbose -b particle-xenon-riotboot-dfu-slot0 -s probe-rs-run
$ objcopy build/bin/particle-xenon-riotboot-dfu-slot0/embassy-net-udp/embassy-net-udp.elf -Obinary out.bin
$ ${RIOT}/dist/tools/riotboot_gen_hdr/bin/genhdr generate out.bin 1 16640 256 header.bin
$ cat header.bin out.bin > total.bin
$ dfu-util -a 0 -D total.bin

I'm confident that either laze or probe-rs (or whatever the Rust ecosystem uses for flashing when no probe is attached) will be helpful in automating this, but first steps first and I'd appreciate a rough yes/no on the direction before continuing.

@kaspar Can we feed build.rs effects back into laze, or would that be doing things bent over backwards?
I'd guess not, then we have two paths for building riotboot images:

Do it outside of cargo. Then all the pre-calculation ((firmware size - bootloader) / slots)) needs to happen in laze, laze will need to set those numbers to be available to build.rs, and that has the simple task of just creating a linker script of that. The header building then runs using the existing riotboot-genhdr tool, which receives the values from laze.
Do it in cargo. laze will not do much except pass on the board selection (as I'm doing it now), and build.rs will get the extra task of also creating some binary that represents the boot loader header, and includes it through the linker setup.

I'd prefer the latter, because it stands chances of being usable also for other Rust based systems, but I'll still need to verify whether some deep-down crate can still do things to the final product (because for bootloaders such as the particle-xenon native one, we'll need to include some check sum of the application).

The plan I think I'd prefer is this:

Do all the relevant calculations in the build.rs (passing on information to the compiler as needed), to ensure that the ELF file contains all information later image builders need.
Then we can use laze to do either of two things:

Use a runner that makes use of all the information there (but gets little else from laze) to build an image and flash it.
Have some target (note to self: learn laze) to build the image for later flashing.

Nice! I think some of the bootloader logic is already covered by ld-memory.

I'd guess not, then we have two paths for building riotboot images:
guessed right. :)

* Do it outside of cargo. Then all the pre-calculation ((firmware size - bootloader) / slots)) needs to happen in laze, laze will need to set those numbers to be available to build.rs, and that has the simple task of just creating a linker script of that. The header building then runs using the existing riotboot-genhdr tool, which receives the values from laze.

* Do it in cargo. laze will not do much except pass on the board selection (as I'm doing it now), and build.rs will get the extra task of also creating some binary that represents the boot loader header, and includes it through the linker setup.

I'd prefer the latter, because it stands chances of being usable also for other Rust based systems, but I'll still need to verify whether some deep-down crate can still do things to the final product (because for bootloaders such as the particle-xenon native one, we'll need to include some check sum of the application).

I'm generally in favor or using cargo for everything that it actually can do without getting too hacky.
In this case, bending cargo to do more than building a .elf is getting too hacky. We could wrap the linker, or the runner, to build a binary including e.g., the boot loader header or checksum. But IMO that's just a step after cargo built the .elf.
Laze should have all the info (whether the bootloader should be used, which slot to build, ...), so it can pass it down to cargo and still use it later for flashing or running.
That said, laze is a bit clumsy here. For starters, there needs to be some way to add post processing recipes. Currently, the simplest way to create some binary that includes the bootloader would be a flashing task (script), but that is re-run on every invocation.
And tasks can only be disabled by making them depend on a variable. It should maybe possible to define them in modules (vs. only in contexts), so they go through the usual dependency&conflicts machinery.

here is how the existing ldmemory infra can be used to do the slotting.

Yes, thanks! I've had to do do some adjustments here and there (eg. calculate NRF52_FLASH_OFFSET from FLASH_SLOT_OFFSET and FLASH_OFFSET b/c SLOT_OFFSET is not known to ld-memory ... guess where https://github.com/kaspar030/ld-memory/pull/1 came from ;-) ), but I've just successfully run laze -C examples/embassy-net-udp build -vv -b particle-xenon-riotboot-dfu-slot0 run and the embassy network interface came up.

Now updated to a working version, which squashes the back-and-forth between my original version and your commit which you referenced.
I've been using it like this:
$ PATH=~/git/RIOT/dist/tools/riotboot_gen_hdr/bin:$PATH laze -C examples/embassy-net-udp build -vv -b particle-xenon-riotboot-dfu-slot0 run

Open FIXMEs (which we may address now or merge it and leave them for later):

Can we get any better story for how to find riotboot's genhdr than asking the user to put it in the PATH?
To do the address calculations, genhdr needs the full memory story, which was missing the total flash size (so that "shift by OFFSET, divide the rest by NUM_SLOTS, shift into the right slot and then add SLOT_OFFSET" can be calculated). Right now this is passed in as FLASH_SIZE_TOTAL, but it's duplication against the 1024 in nrf52's build.rs script; we may manage to do better.
I'm rather naive in what can be done in laze, so I did the easiest thing and passed a few variables to the CARGO_RUNNER with a healthy serving of trial-and-error escaping. (There is way too much "we define this here and later text-paste it there, where it gets evaluated by the shell into a variable, which is better used with quotes because it still contains whitespace" in all of this for my taste). There may well be a clean way of prep'ing all the data in laze. Such a path would likely not go through cargo run any more, and I don't have an opinion yet on whether that'd be good or bad. (As long as we go through cargo run, we do need one script/executable that gets us all the way from "here's the elf file" to "and it's running". Given we flash and don't run, and in particular don't capture the stdout, maybe run is not the right term).

Concrete plan now that I need this working to work on other parts:

I'm rebasing this onto master (without any testing).
I'm squashing things into a separate branch that will be a new PR for programmer-only particle-xenon
We can figure out how to do bootloader stuff best later, and apply it to more chips than just this one.

This is now based on https://github.com/future-proof-iot/RIOT-rs/pull/224

this PR is relatively "old" for this repo ;) Is closure still planned?

@chrysn is this PR still relevant at this stage?


Support for Wild World, City Folk, and New Leaf

As the end of work on the GameCube title comes to a close, I want to add the rest of the games to the editor. I want this editor to be similar to PKHeX, where it supports all "generations" of Animal Crossing.

Support is finished for Wild World, City Folk, and New Leaf. Only Welcome Amiibo support needs to be added for complete series support. A few features need to be completed as well, such as the Villager & House editor portions.

Welcome Amiibo support is finished. I only have to finish up a few miscellaneous features, and I will then release it.

Overhauled ACSE can be found here: https://github.com/Cuyler36/ACSE


ValueError: Shape must be rank 4 but is rank 3 for 'simple_nms/MaxPoolV2'

hi
After following the instruction, I installed it in a Python 3 workspace
however when I run rosrun feature_extraction feature_extraction_node.py
I get the following error:
2021-09-02 15:58:06.602657: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
Traceback (most recent call last):
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/framework/ops.py", line 1628, in _create_c_op
    c_op = c_api.TF_FinishOperation(op_desc)
tensorflow.python.framework.errors_impl.InvalidArgumentError: Shape must be rank 4 but is rank 3 for 'simple_nms/MaxPoolV2' (op: 'MaxPoolV2') with input shapes: [1,?,1], [4], [4].

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mobiiin/catkin_ws/src/deep_features/feature_extraction/feature_extraction_node.py", line 200, in <module>
    main()
  File "/home/mobiiin/catkin_ws/src/deep_features/feature_extraction/feature_extraction_node.py", line 42, in main
    net = FeatureNet()
  File "/home/mobiiin/git/deep_features/feature_extraction/hfnet_tf.py", line 38, in __init__
    config['nms_iterations'], config['nms_radius'])
  File "/home/mobiiin/git/deep_features/feature_extraction/hfnet_tf.py", line 80, in select_keypoints
    scores = self.simple_nms(scores, nms_iterations, nms_radius)
  File "/home/mobiiin/git/deep_features/feature_extraction/hfnet_tf.py", line 69, in simple_nms
    max_mask = tf.equal(scores, max_pool(scores))
  File "/home/mobiiin/git/deep_features/feature_extraction/hfnet_tf.py", line 67, in <lambda>
    strides=[1, 1, 1, 1], padding='SAME')[..., 0]
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/ops/gen_nn_ops.py", line 5666, in max_pool_v2
    padding=padding, data_format=data_format, name=name)
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/framework/op_def_library.py", line 787, in _apply_op_helper
    op_def=op_def)
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/util/deprecation.py", line 488, in new_func
    return func(*args, **kwargs)
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/framework/ops.py", line 3274, in create_op
    op_def=op_def)
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/framework/ops.py", line 1792, in __init__
    control_input_ops)
  File "/home/mobiiin/.local/lib/python3.6/site-packages/tensorflow/python/framework/ops.py", line 1631, in _create_c_op
    raise ValueError(str(e))
ValueError: Shape must be rank 4 but is rank 3 for 'simple_nms/MaxPoolV2' (op: 'MaxPoolV2') with input shapes: [1,?,1], [4], [4].

ros melodic
ubuntu 18
tensorflow cpu 1.12.0
ps:
I also tried tensorflow 1.13.1 and 1.14 and 1.15
all led to the previous error
also not a numpy issue

Hi @mobiiin , sorry I do not have any hints about your issues. tf 1.14 should work, see environment.yml. And the code of simple_nms was copied from
hfnet, which specifies tf 1.12, so 1.12 should also work in theory.

Hello, I have also encountered the same problem. Have you resolved it！


PIR/SIG architecture

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

waiting for swagger to merge https://github.com/Azure/azure-rest-api-specs/pull/17853


Change MessageDispatcher to not synchronize on the global queue.

This is no longer necessary, as it is owned by this class.  It also prevents every ack, nack and batch receipt from happening only one at a time.

Can you please break this up into straightforward refactoring(s) and then the crux of the change?