cdc: add old_value cache for removing Engine::send_command_txn_extra

What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
What is changed and how it works?
Proposal: xxx
What's Changed:
Related changes

PR to update pingcap/docs/pingcap/docs-cn:
PR to update pingcap/tidb-ansible:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Performance regression

Consumes more CPU
Consumes more MEM

Breaking backward compatibility

Release note

/release

/merge

/run-cherry-picker


Fix errors with new package:meta

Fixes #1586

[ ] I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

See our contributor guide for general expectations for PRs.
Larger or significant changes should be discussed in an issue before creating a PR.
Contributions to our repos should follow the Dart style guide and use dart format.
Most changes should add an entry to the changelog and may need to rev the pubspec package version.
Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

coverage: 91.042%. remained the same
when pulling 4f84c14f0ab450352ab4dfc1c019357c07e2e527 on fixRecordUseAnnotations
into 9d01cfded639ac3de860a1e1c4de1a366251c07f on main.


[BUG]: CoE upgradation issue

Describe the bug
We installed CoE on November at an earlier version. Then two weeks back it was updated to new version. The only thing which we did was import the solution and install it as an update. So we can see the new flows (marked as v3) inside the solution and from history it looks like it's running successfully. On the other hand the old v2 flows which we saved earlier and activated are also running. As per the old documentation and CoE video series (https://www.youtube.com/watch?v=L8gKjeE5GR4&list=PLi9EhCY4z99W5kzaPK1np6sv6AzMQDsXG&index=2) we have saved all the sync template flows and then activated them. Can that be the issue why those v2 flows are still showing up outside the solution?
Can you please suggest what should be done? Should we disable v2 flows and keep v3 flows enabled? Or was there any issue with our upgrade?

Hello. With the creation of the Connection References product feature, you no longer need to create copies of flows to use them. You now instantiate the connections once at solution install instead of at each step as in the painful past. We will be remaking the videos to match.
You should disable and delete the old v2 flows, and you can keep the v3 flows in place now, making installing udpates in the future easier

@JeneferM-MSFT Thanks so much! This clears all of my doubts.

Wonderful. Thanks for using CoE!


SEAB-3792: Fix search self-DOS

Description
This PR implements a fix for [the currently-known variety] of the search "self-DOS" bug.  This is a somewhat hacky fix that feels a bit gross to me, but is probably an ok call from a practical POV.
This self-DOS occurs when the browser back (or forward) button is pressed and there are at least two search URLs at the top of the browser URL stack.  If the current page is a search with a text term and facet selected, and the destination page is also a search, a loop is triggered where the search code appears to repeatedly, rapidly, and endlessly switch between two different search states, triggering a rapid stream of ES queries.
The exact mechanics of the bug were difficult to determine - the search code includes some subtle circular data flows that are susceptible to this type of problem.  And, even if I figured it out, which could take days, I wasn't sure if I could easily fix it, and felt that there was a good chance that I'd introduce other bugs in the process...
So, the solution was to try to avoid the situation which can trigger the issue (two search URLs at the top of the browser url stack) and take evasive action in the cases we could not.
There are two changes:

The search URL rewrite code is modified to replace the entry at the top of the browser stack, rather than add another entry.  This prevents search URLs from piling up, and has the added benefit that when the user presses the back button, they go back to the page they moved to search from, which feels more appropriate (to me) than bumping back one step in the search state.

If we detect a situation where the forward/back button takes us to another search (as can happen after we're on the search page and and we click on a link to the search page [such as in the menu bar]), we force the search component to reinitialize, causing the destination search to run in newly-initialized component, nipping the self-DOS in the bud.

Do note that there may be other undiscovered varieties of the self-DOS lurking...
Issue
SEAB-3792
Please make sure that you've checked the following before submitting your pull request. Thanks!

[x] Check that your code compiles by running npm run build
[x] If this is the first time you're submitting a PR or even if you just need a refresher, consider reviewing our style guide
[x] Do not bypass Angular sanitization (bypassSecurityTrustHtml, etc.), or justify why you need to do so
[x] If displaying markdown, use the markdown-wrapper component, which does extra sanitization
[x] Do not use cookies, although this may change in the future
[x] Run npm audit and ensure you are not introducing new vulnerabilities
[x] Do due diligence on new 3rd party libraries, checking for CVEs
[x] Don't allow user-uploaded images to be served from the Dockstore domain

I find the new back behavior unintuitive; I tried with Amazon as a comparison, and if you select a facet, then click the back button, you go back to the page with the facet unselected. Not a perfect comparison, but still...
But this is exponentially better than self-DOSing ourselves. :) Maybe in the future we can revisit the page; as you said the interactions are complex.

Change #1 (on search facet/text change, replacing the top URL on the browser stack with the new URL rather than adding) is optional, we can remove it if the team deems it objectionable.

Change #1 (on search facet/text change, replacing the top URL on the browser stack with the new URL rather than adding) is optional, we can remove it and keep the previous back behavior if the team deems it objectionable.

I think I agree, I would probably find that unexpected as well.  That said, does it reduce the chance of a self-dos or support change 2 in some way?

Change #1 (on search facet/text change, replacing the top URL on the browser stack with the new URL rather than adding) is optional, we can remove it and keep the previous back behavior if the team deems it objectionable.

I think I agree, I would probably find that unexpected as well. That said, does it reduce the chance of a self-dos or support change 2 in some way?

Change #1 (replacing the url on top of the browser stack on search rewrite) largely prevents the situation that leads to the self-DOS (two search urls on top of the browser stack), but Change #2 seems to work well enough that it can stand on its own.  I will remove Change #1.


[Feature Request] Remove version constraint for pydash

Is your feature request related to a problem? Please describe.
├── pydash [required: >=6.0.0,<7.0.0, installed: 6.0.2]             -- latest version 7.0.6, 7.0 released 2023-04-12
Describe the solution you'd like
relax pydash version to < 8.0.0

related code change merged in #1253


fix(cvs): fix validator verification

Needs tests

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

9 of 9 (100.0%)  changed or added relevant lines in 4 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.008%) to 89.245%

Files with Coverage Reduction
New Missed Lines
%

contracts/libs/ValidatorStorage.sol
1
70.21%

Totals

Change from base Build<PHONE_NUMBER>:
0.008%

Covered Lines:
903

Relevant Lines:
982

💛  - Coveralls


Form field prefix and suffix icons not aligned properly

Bug, feature request, or proposal:
Bug
What is the expected behavior?
Material design guidelines for text field boxes specify icons to have 16px vertical spacing between itself and the input line.
What is the current behavior?
Icons as prefix or suffix are currently raised 14px above input line for both box and non-box text fields. This does not meet material design specifications for either style of text field.
What are the steps to reproduce?
https://stackblitz.com/edit/angular-jzfsl9

What is the use-case or motivation for changing an existing behavior?
Current appearance is not ideal and material guidelines are not being followed. Appearance is especially bad for ordinary text fields without a floating label.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 5.2.6
Angular Material 5.2.1
Is there anything else we should know?
I already know how to override CSS for example to fix problems. I'm reporting this not simply to get you to fix my problems, but so that you can improve your product and so that others can also benefit.

Closing as duplicate of #10089

@josephperrott This not a duplicate - please re-read. This is a follow up. The spec is 16px, implemented is 14px.

I'm not sure if the spec gives an exact pixel amount and I may have misspoke when I said the current was 16px (it depends on what font size you're using). The important part is that its clear from the spec that the icon is vertically centered in the space above the underline. I'm not sure if the appearance="legacy" version is perfectly centered, but the appearance="standard" version that we will encourage people to use post 6.0.0 appears to be correct (background color added to show the box that we want to be centered in):

So this has been fixed in master for 6.0.0

@mmalerba thanks to your image I now understand the intent of positioning icons that high. That being said, the spacing looks pretty awkward when there's no floating placeholder (ie. floatPlaceholder="never").
If we don't consider this a bug, can we at least call it a feature request?

The float never thing was actually something that was added back when the spec didn't differentiate between placeholder and label. It was a way of getting the label to behave more like a traditional placeholder. Now that it's possible to specify the label and placeholder separately, we plan to eventually remove the float never option.
So we probably won't add any official support for it, but you can always add CSS rules to tweak it how you like

@mmalerba how can we style that suffix icon to be lined with text? I tried negative margins, but does nothing

Adding vertical-align: bottom to the <mat-icon> should do it, but it doesn't look great when the label is floating

@sangecz :
.mat-form-field-appearance-legacy {

	.mat-form-field-prefix,
	.mat-form-field-suffix {
		align-self: flex-end;
	}
}

vertical-align: bottom doesn't position the icon low enough IMO - it is not quite centered vertically with the text.


UI Fixes: SearchPage & ProfilePage

Summary of Changes
This PR introduces 2 UI improvements:

Our css for the message that shows up in tabs when there is no data to show was not consistent between ProfilePage and SearchPage. In addition, the text color used on the ProfilePage message did not have enough contrast with the white background to meet design best practices. The markup and css for ProfilePage was updated to be consistent.
ProfilePage (before)

ProfilePage (after, consistent with SearchPage)

SearchPage (unchanged)

Added support to change the helper text that is shown on the InfoButton next to search results. The reason is that the previous text "Ordered by the relevance of matches within a resource's metadata, as well as overall usage" is only applicable to table resources because user resources don't have a concept of being ranked by usage. The InfoButton text for user resources will only read "Ordered by the relevance of matches within a resource's metadata"
Table

User

Tests
Component tests have been modified and updated to cover new logic.
Documentation
N/A. This is a UI change to existing features and does not need any documentation.
CheckList
Make sure you have checked all steps below to ensure a timely review.

[x] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[x] PR includes a summary of changes, including screenshots of any UI changes.
[x] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[x] In case of new functionality, my PR adds documentation that describes how to use it.

All the public python functions and the classes in the PR contain docstrings that explain what it does

[x] PR passes all tests documented in the developer guide
[x] I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message"

Codecov Report

Merging #220 into master will increase coverage by 0.13%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #220      +/-   ##
==========================================
+ Coverage   69.96%   70.09%   +0.13%
==========================================
  Files         124      124
  Lines        3203     3217      +14
  Branches      388      390       +2
==========================================
+ Hits         2241     2255      +14
  Misses        931      931
  Partials       31       31

Impacted Files
Coverage Δ

...ication/static/js/components/ProfilePage/index.tsx
98.24% <ø> (ø)
:arrow_up:

...undsen_application/static/js/ducks/search/types.ts
100% <ø> (ø)
:arrow_up:

...lication/static/js/components/SearchPage/index.tsx
100% <100%> (ø)
:arrow_up:

...ation/static/js/components/SearchPage/constants.ts
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

@danwom any further concerns on the PR?


Rethinking error-handling

Currently, the lib throws errors on validating data objects. Given that errors are more backend-useful and might create unexpected frontend scenarios, it might be useful to adopt a universal response that applies to both success and error states.

E.g.,
{
success: true/false,
data: {},
message: 'Only necessary for error messages but could be useful for warnings'
}
Important to consider: given the promise-based interaction, errors should be directed to rejection/error handlers. So, a success parameter might be redundant


optimizations for offline mlperf inference

-Offload detokenization to another thread
-Bulk decode steps

R: @singh-mitali

R: @singh-mitali

LGTM.


root is relative to config file.

it seems paths are relative to mkdocs config file, e.g. mkdocs.yml. Not sure if this is intentional. It is however consistent with other plugins.
I would modify the language in the readme.

But that's exactly what the readme already says


/usr/lib/coreos/kubelet-wrapper does not exist on stable channel

It's a new multi node setup,
DISTRIB_RELEASE=899.15.0
$ journalctl -b
systemd[1408]: kubelet.service: Failed at step EXEC spawning /usr/lib/coreos/kubelet-wrapper: No such

Following below link and manually created the wrapper:
https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html
I understand that this wrapper is not shipped in "stable" channel and prior to 962.0.0 yet, but we should at least have it fixed in stable releases so kublet.service not throwing error. Thanks.

That's not really how the coreos release model works.. You can run the beta channel until stable catches up to 962

@arvinep the hard dependency is rkt version >= 1.0. If you check out https://coreos.com/releases, you'll see that stable actually has rkt 1.0. You should be able to drop the kubelet-wrapper script/ systemd service onto your filesystem and it should work until 962.x.x gets promoted to stable.
\cc @aaronlevy for sanity on this

hey @colhom I did the same and issue gone,
Just wanted to point this out that yet without this wrapper, kubelete.service won't start which means
"kubectl get nodes" throwing following error:
$ kubectl get nodes
The connection to the server <IP_ADDRESS>:443 was refused - did you specify the right host or port

You are correct, if you use the stable release, it will not contain the kubelet-wrapper.
An option here might be to better document this as comments in the vagrant config file:
https://github.com/coreos/coreos-kubernetes/blob/master/multi-node/vagrant/config.rb.sample#L1
https://github.com/coreos/coreos-kubernetes/blob/master/single-node/Vagrantfile#L25

The kubelet-wrapper is now included in the stable channel


V0.2 dev db

Hello @patrickcleeve2! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file fibsem/alignment.py:

Line 75:18: E261 at least two spaces before inline comment

In the file fibsem/config.py:

Line 39:26: E261 at least two spaces before inline comment
Line 39:44: W291 trailing whitespace

In the file fibsem/db/app.py:

Line 16:63: E251 unexpected spaces around keyword / parameter equals
Line 16:65: E251 unexpected spaces around keyword / parameter equals
Line 16:80: E501 line too long (87 > 79 characters)
Line 34:80: E501 line too long (110 > 79 characters)
Line 43:80: E501 line too long (198 > 79 characters)
Line 48:80: E501 line too long (158 > 79 characters)
Line 52:80: E501 line too long (158 > 79 characters)
Line 56:80: E501 line too long (83 > 79 characters)
Line 58:46: W291 trailing whitespace
Line 64:80: E501 line too long (95 > 79 characters)
Line 65:5: E128 continuation line under-indented for visual indent
Line 65:34: W291 trailing whitespace
Line 66:5: E128 continuation line under-indented for visual indent
Line 67:5: E116 unexpected indentation (comment)
Line 72:1: E303 too many blank lines (3)
Line 73:80: E501 line too long (86 > 79 characters)
Line 76:75: W291 trailing whitespace
Line 77:80: E501 line too long (82 > 79 characters)
Line 90:58: E261 at least two spaces before inline comment
Line 90:58: E262 inline comment should start with '# '
Line 96:80: E501 line too long (127 > 79 characters)
Line 100:80: E501 line too long (134 > 79 characters)
Line 105:80: E501 line too long (199 > 79 characters)
Line 109:80: E501 line too long (130 > 79 characters)
Line 114:1: E303 too many blank lines (3)
Line 118:1: E303 too many blank lines (3)
Line 126:80: E501 line too long (192 > 79 characters)
Line 127:1: W293 blank line contains whitespace
Line 128:80: E501 line too long (89 > 79 characters)
Line 133:80: E501 line too long (90 > 79 characters)
Line 135:80: E501 line too long (104 > 79 characters)
Line 148:62: E261 at least two spaces before inline comment
Line 148:62: E262 inline comment should start with '# '
Line 156:80: E501 line too long (145 > 79 characters)
Line 160:80: E501 line too long (129 > 79 characters)
Line 167:80: E501 line too long (110 > 79 characters)
Line 168:80: E501 line too long (126 > 79 characters)
Line 181:62: E261 at least two spaces before inline comment
Line 181:62: E262 inline comment should start with '# '
Line 193:80: E501 line too long (95 > 79 characters)
Line 193:96: W291 trailing whitespace
Line 194:80: E501 line too long (158 > 79 characters)
Line 194:159: W291 trailing whitespace
Line 195:80: E501 line too long (87 > 79 characters)
Line 196:1: W293 blank line contains whitespace
Line 202:80: E501 line too long (192 > 79 characters)
Line 209:80: E501 line too long (93 > 79 characters)
Line 212:5: E303 too many blank lines (2)
Line 223:62: E261 at least two spaces before inline comment
Line 223:62: E262 inline comment should start with '# '
Line 233:80: E501 line too long (98 > 79 characters)
Line 235:80: E501 line too long (91 > 79 characters)
Line 238:80: E501 line too long (118 > 79 characters)
Line 244:80: E501 line too long (92 > 79 characters)
Line 245:80: E501 line too long (97 > 79 characters)
Line 248:9: E303 too many blank lines (2)
Line 259:66: E261 at least two spaces before inline comment
Line 259:66: E262 inline comment should start with '# '
Line 269:80: E501 line too long (102 > 79 characters)
Line 271:80: E501 line too long (126 > 79 characters)
Line 278:80: E501 line too long (167 > 79 characters)
Line 280:34: E222 multiple spaces after operator
Line 280:65: E225 missing whitespace around operator
Line 280:80: E501 line too long (100 > 79 characters)
Line 282:80: E501 line too long (86 > 79 characters)
Line 285:80: E501 line too long (99 > 79 characters)
Line 288:80: E501 line too long (82 > 79 characters)
Line 289:80: E501 line too long (89 > 79 characters)
Line 292:80: E501 line too long (81 > 79 characters)
Line 297:80: E501 line too long (117 > 79 characters)
Line 300:55: E225 missing whitespace around operator
Line 301:54: E225 missing whitespace around operator
Line 304:80: E501 line too long (143 > 79 characters)
Line 307:80: E501 line too long (133 > 79 characters)
Line 314:5: E303 too many blank lines (2)
Line 315:80: E501 line too long (130 > 79 characters)
Line 319:5: E303 too many blank lines (3)
Line 322:5: E303 too many blank lines (2)
Line 326:54: E225 missing whitespace around operator
Line 326:59: W291 trailing whitespace
Line 327:55: E225 missing whitespace around operator
Line 331:80: E501 line too long (91 > 79 characters)
Line 333:80: E501 line too long (84 > 79 characters)
Line 336:5: E303 too many blank lines (2)
Line 337:67: W291 trailing whitespace
Line 338:9: E128 continuation line under-indented for visual indent
Line 344:80: E501 line too long (88 > 79 characters)
Line 346:80: E501 line too long (84 > 79 characters)
Line 350:9: E303 too many blank lines (2)
Line 352:80: E501 line too long (99 > 79 characters)
Line 354:80: E501 line too long (92 > 79 characters)
Line 356:78: W291 trailing whitespace
Line 357:17: E128 continuation line under-indented for visual indent
Line 360:28: W292 no newline at end of file

In the file fibsem/db/util.py:

Line 4:1: E302 expected 2 blank lines, found 1
Line 19:1: E303 too many blank lines (4)
Line 48:1: E302 expected 2 blank lines, found 1
Line 62:1: E302 expected 2 blank lines, found 1
Line 79:1: E303 too many blank lines (4)
Line 87:80: E501 line too long (87 > 79 characters)
Line 96:1: E303 too many blank lines (3)
Line 114:1: E303 too many blank lines (3)
Line 138:1: E302 expected 2 blank lines, found 1
Line 146:40: W291 trailing whitespace
Line 147:9: E128 continuation line under-indented for visual indent
Line 148:30: E128 continuation line under-indented for visual indent
Line 168:1: W391 blank line at end of file

In the file fibsem/detection/detection.py:

Line 96:1: E302 expected 2 blank lines, found 1
Line 100:31: E231 missing whitespace after ','
Line 100:33: E231 missing whitespace after ','
Line 104:69: E231 missing whitespace after ':'
Line 104:75: E252 missing whitespace around parameter equals
Line 104:76: E252 missing whitespace around parameter equals
Line 104:80: E501 line too long (101 > 79 characters)
Line 108:1: E302 expected 2 blank lines, found 1
Line 116:69: E231 missing whitespace after ':'
Line 116:75: E252 missing whitespace around parameter equals
Line 116:76: E252 missing whitespace around parameter equals
Line 116:80: E501 line too long (104 > 79 characters)
Line 235:80: E501 line too long (83 > 79 characters)
Line 254:13: E303 too many blank lines (2)
Line 262:9: E722 do not use bare 'except'
Line 295:5: E303 too many blank lines (2)
Line 300:1: W293 blank line contains whitespace
Line 432:80: E501 line too long (131 > 79 characters)
Line 524:80: E501 line too long (88 > 79 characters)
Line 551:5: E303 too many blank lines (2)
Line 556:1: W293 blank line contains whitespace
Line 563:1: W293 blank line contains whitespace

In the file fibsem/imaging/_tile.py:

Line 113:80: E501 line too long (85 > 79 characters)

In the file fibsem/microscope.py:

Line 130:9: E128 continuation line under-indented for visual indent
Line 136:80: E501 line too long (111 > 79 characters)
Line 323:80: E501 line too long (117 > 79 characters)
Line 475:80: E501 line too long (84 > 79 characters)
Line 476:80: E501 line too long (92 > 79 characters)
Line 739:80: E501 line too long (93 > 79 characters)
Line 993:80: E501 line too long (103 > 79 characters)
Line 1751:16: E225 missing whitespace around operator
Line 1753:38: W291 trailing whitespace
Line 1964:65: E202 whitespace before ')'
Line 1973:1: W293 blank line contains whitespace
Line 2551:80: E501 line too long (119 > 79 characters)
Line 3389:80: E501 line too long (102 > 79 characters)
Line 4897:5: E303 too many blank lines (2)
Line 4897:38: E231 missing whitespace after ':'
Line 4897:72: E231 missing whitespace after ':'
Line 4897:80: E501 line too long (115 > 79 characters)
Line 4897:101: E252 missing whitespace around parameter equals
Line 4897:102: E252 missing whitespace around parameter equals
Line 4903:80: E501 line too long (110 > 79 characters)
Line 4903:89: E231 missing whitespace after ':'
Line 5060:5: E303 too many blank lines (2)
Line 5060:31: E231 missing whitespace after ','
Line 5071:9: E303 too many blank lines (2)

In the file fibsem/segmentation/model.py:

Line 54:13: E303 too many blank lines (2)
Line 60:80: E501 line too long (82 > 79 characters)

In the file fibsem/segmentation/train.py:

Line 68:18: E261 at least two spaces before inline comment

In the file fibsem/ui/FibsemEmbeddedDetectionWidget.py:

Line 74:32: E251 unexpected spaces around keyword / parameter equals
Line 74:34: E251 unexpected spaces around keyword / parameter equals
Line 74:80: E501 line too long (134 > 79 characters)
Line 89:80: E501 line too long (100 > 79 characters)
Line 90:80: E501 line too long (186 > 79 characters)

In the file fibsem/ui/FibsemGISWidget.py:

Line 60:80: E501 line too long (90 > 79 characters)
Line 62:80: E501 line too long (84 > 79 characters)
Line 141:80: E501 line too long (81 > 79 characters)
Line 149:80: E501 line too long (145 > 79 characters)
Line 159:62: E231 missing whitespace after ','
Line 160:1: W293 blank line contains whitespace
Line 171:1: W293 blank line contains whitespace
Line 173:9: E303 too many blank lines (2)
Line 174:31: E225 missing whitespace around operator
Line 175:80: E501 line too long (115 > 79 characters)
Line 177:80: E501 line too long (109 > 79 characters)
Line 178:80: E501 line too long (82 > 79 characters)
Line 192:1: W293 blank line contains whitespace
Line 196:1: E303 too many blank lines (4)
Line 196:12: W291 trailing whitespace

In the file fibsem/ui/FibsemMillingWidget.py:

Line 490:80: E501 line too long (138 > 79 characters)
Line 576:80: E501 line too long (118 > 79 characters)
Line 577:80: E501 line too long (172 > 79 characters)

In the file fibsem/ui/FibsemMinimapWidget.py:

Line 393:27: E231 missing whitespace after ':'
Line 394:31: E261 at least two spaces before inline comment
Line 394:80: E501 line too long (100 > 79 characters)
Line 396:80: E501 line too long (185 > 79 characters)
Line 396:159: E202 whitespace before ')'
Line 397:80: E501 line too long (114 > 79 characters)
Line 398:80: E501 line too long (133 > 79 characters)
Line 399:1: W293 blank line contains whitespace
Line 403:63: W291 trailing whitespace
Line 404:21: E128 continuation line under-indented for visual indent
Line 404:41: W291 trailing whitespace
Line 405:21: E128 continuation line under-indented for visual indent
Line 405:35: W291 trailing whitespace
Line 406:21: E128 continuation line under-indented for visual indent
Line 406:35: E251 unexpected spaces around keyword / parameter equals
Line 406:37: E251 unexpected spaces around keyword / parameter equals

In the file fibsem/ui/FibsemUI.py:

Line 216:1: W293 blank line contains whitespace

In the file fibsem/ui/qtdesigner_files/CurrentAlignmentWidget.py:

Line 59:80: E501 line too long (83 > 79 characters)
Line 60:80: E501 line too long (91 > 79 characters)
Line 61:80: E501 line too long (93 > 79 characters)
Line 62:80: E501 line too long (90 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemDetectionWidget.py:

Line 137:80: E501 line too long (93 > 79 characters)
Line 138:80: E501 line too long (91 > 79 characters)
Line 146:80: E501 line too long (81 > 79 characters)
Line 148:80: E501 line too long (88 > 79 characters)
Line 149:80: E501 line too long (96 > 79 characters)
Line 150:80: E501 line too long (86 > 79 characters)
Line 151:80: E501 line too long (85 > 79 characters)
Line 152:80: E501 line too long (84 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemGISWidget.py:

Line 31:80: E501 line too long (114 > 79 characters)
Line 58:80: E501 line too long (83 > 79 characters)
Line 59:80: E501 line too long (81 > 79 characters)
Line 104:80: E501 line too long (86 > 79 characters)
Line 108:80: E501 line too long (84 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemLabellingUI.py:

Line 113:80: E501 line too long (81 > 79 characters)
Line 114:80: E501 line too long (87 > 79 characters)
Line 115:80: E501 line too long (90 > 79 characters)
Line 116:80: E501 line too long (86 > 79 characters)
Line 117:80: E501 line too long (81 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemManipulatorWidget.py:

Line 104:80: E501 line too long (80 > 79 characters)
Line 111:80: E501 line too long (80 > 79 characters)
Line 112:80: E501 line too long (87 > 79 characters)
Line 113:80: E501 line too long (83 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemMillingWidget.py:

Line 192:80: E501 line too long (88 > 79 characters)
Line 193:80: E501 line too long (97 > 79 characters)
Line 194:80: E501 line too long (89 > 79 characters)
Line 195:80: E501 line too long (84 > 79 characters)
Line 198:80: E501 line too long (84 > 79 characters)
Line 200:80: E501 line too long (80 > 79 characters)
Line 201:80: E501 line too long (81 > 79 characters)
Line 202:80: E501 line too long (80 > 79 characters)
Line 203:80: E501 line too long (85 > 79 characters)
Line 204:80: E501 line too long (82 > 79 characters)
Line 208:80: E501 line too long (82 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemModelTrainingWidget.py:

Line 162:80: E501 line too long (81 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemMovementWidget.py:

Line 29:80: E501 line too long (95 > 79 characters)
Line 30:80: E501 line too long (113 > 79 characters)
Line 31:80: E501 line too long (95 > 79 characters)
Line 36:80: E501 line too long (81 > 79 characters)
Line 38:80: E501 line too long (83 > 79 characters)
Line 40:80: E501 line too long (89 > 79 characters)
Line 41:80: E501 line too long (84 > 79 characters)
Line 51:80: E501 line too long (89 > 79 characters)
Line 55:80: E501 line too long (89 > 79 characters)
Line 56:80: E501 line too long (107 > 79 characters)
Line 57:80: E501 line too long (92 > 79 characters)
Line 64:80: E501 line too long (114 > 79 characters)
Line 79:80: E501 line too long (82 > 79 characters)
Line 88:80: E501 line too long (96 > 79 characters)
Line 91:80: E501 line too long (105 > 79 characters)
Line 92:80: E501 line too long (91 > 79 characters)
Line 93:80: E501 line too long (89 > 79 characters)
Line 97:80: E501 line too long (91 > 79 characters)
Line 98:80: E501 line too long (84 > 79 characters)
Line 105:80: E501 line too long (89 > 79 characters)
Line 109:80: E501 line too long (91 > 79 characters)
Line 110:80: E501 line too long (84 > 79 characters)
Line 116:80: E501 line too long (83 > 79 characters)
Line 183:80: E501 line too long (90 > 79 characters)
Line 184:80: E501 line too long (98 > 79 characters)
Line 185:80: E501 line too long (98 > 79 characters)
Line 186:80: E501 line too long (105 > 79 characters)
Line 187:80: E501 line too long (108 > 79 characters)
Line 188:80: E501 line too long (112 > 79 characters)
Line 189:80: E501 line too long (108 > 79 characters)
Line 190:80: E501 line too long (91 > 79 characters)
Line 192:80: E501 line too long (87 > 79 characters)
Line 193:80: E501 line too long (101 > 79 characters)
Line 194:80: E501 line too long (86 > 79 characters)
Line 198:80: E501 line too long (84 > 79 characters)
Line 199:80: E501 line too long (86 > 79 characters)
Line 200:80: E501 line too long (90 > 79 characters)
Line 201:80: E501 line too long (81 > 79 characters)
Line 209:80: E501 line too long (80 > 79 characters)
Line 210:80: E501 line too long (82 > 79 characters)
Line 211:80: E501 line too long (84 > 79 characters)
Line 212:80: E501 line too long (92 > 79 characters)
Line 213:80: E501 line too long (84 > 79 characters)
Line 214:80: E501 line too long (100 > 79 characters)
Line 217:80: E501 line too long (94 > 79 characters)
Line 220:80: E501 line too long (84 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemSettingUI.py:

Line 233:80: E501 line too long (98 > 79 characters)
Line 234:80: E501 line too long (96 > 79 characters)
Line 235:80: E501 line too long (88 > 79 characters)
Line 236:80: E501 line too long (103 > 79 characters)
Line 237:80: E501 line too long (113 > 79 characters)
Line 238:80: E501 line too long (96 > 79 characters)
Line 239:80: E501 line too long (97 > 79 characters)
Line 240:80: E501 line too long (105 > 79 characters)
Line 241:80: E501 line too long (109 > 79 characters)
Line 242:80: E501 line too long (109 > 79 characters)
Line 243:80: E501 line too long (100 > 79 characters)
Line 244:80: E501 line too long (101 > 79 characters)
Line 245:80: E501 line too long (102 > 79 characters)
Line 246:80: E501 line too long (110 > 79 characters)
Line 247:80: E501 line too long (111 > 79 characters)
Line 248:80: E501 line too long (97 > 79 characters)
Line 249:80: E501 line too long (90 > 79 characters)
Line 250:80: E501 line too long (91 > 79 characters)
Line 251:80: E501 line too long (92 > 79 characters)
Line 252:80: E501 line too long (100 > 79 characters)
Line 253:80: E501 line too long (97 > 79 characters)
Line 254:80: E501 line too long (90 > 79 characters)
Line 255:80: E501 line too long (94 > 79 characters)
Line 256:80: E501 line too long (99 > 79 characters)
Line 257:80: E501 line too long (97 > 79 characters)
Line 258:80: E501 line too long (98 > 79 characters)
Line 259:80: E501 line too long (103 > 79 characters)
Line 260:80: E501 line too long (97 > 79 characters)

In the file fibsem/ui/qtdesigner_files/FibsemSystemSetupWidget.py:

Line 528:80: E501 line too long (80 > 79 characters)
Line 529:80: E501 line too long (85 > 79 characters)
Line 531:80: E501 line too long (82 > 79 characters)
Line 532:80: E501 line too long (91 > 79 characters)
Line 533:80: E501 line too long (87 > 79 characters)
Line 534:80: E501 line too long (83 > 79 characters)
Line 536:80: E501 line too long (90 > 79 characters)
Line 537:80: E501 line too long (87 > 79 characters)
Line 540:80: E501 line too long (86 > 79 characters)
Line 541:80: E501 line too long (83 > 79 characters)
Line 542:80: E501 line too long (80 > 79 characters)
Line 543:80: E501 line too long (80 > 79 characters)
Line 544:80: E501 line too long (85 > 79 characters)
Line 545:80: E501 line too long (82 > 79 characters)
Line 550:80: E501 line too long (82 > 79 characters)
Line 551:80: E501 line too long (82 > 79 characters)
Line 552:80: E501 line too long (81 > 79 characters)
Line 553:80: E501 line too long (88 > 79 characters)
Line 554:80: E501 line too long (90 > 79 characters)
Line 555:80: E501 line too long (82 > 79 characters)
Line 556:80: E501 line too long (80 > 79 characters)
Line 557:80: E501 line too long (85 > 79 characters)
Line 558:80: E501 line too long (86 > 79 characters)
Line 559:80: E501 line too long (88 > 79 characters)
Line 560:80: E501 line too long (86 > 79 characters)
Line 561:80: E501 line too long (91 > 79 characters)
Line 562:80: E501 line too long (97 > 79 characters)
Line 563:80: E501 line too long (89 > 79 characters)
Line 565:80: E501 line too long (88 > 79 characters)
Line 566:80: E501 line too long (99 > 79 characters)
Line 567:80: E501 line too long (84 > 79 characters)
Line 572:80: E501 line too long (91 > 79 characters)
Line 573:80: E501 line too long (83 > 79 characters)

In the file fibsem/ui/qtdesigner_files/ImageSettingsWidget.py:

Line 230:80: E501 line too long (88 > 79 characters)
Line 231:80: E501 line too long (91 > 79 characters)
Line 233:80: E501 line too long (85 > 79 characters)
Line 234:80: E501 line too long (97 > 79 characters)
Line 235:80: E501 line too long (91 > 79 characters)
Line 236:80: E501 line too long (82 > 79 characters)
Line 240:80: E501 line too long (82 > 79 characters)
Line 241:80: E501 line too long (86 > 79 characters)
Line 242:80: E501 line too long (88 > 79 characters)
Line 243:80: E501 line too long (86 > 79 characters)
Line 255:80: E501 line too long (85 > 79 characters)

In the file fibsem/ui/utils.py:

Line 472:80: E501 line too long (147 > 79 characters)
Line 472:106: E261 at least two spaces before inline comment
Line 472:106: E262 inline comment should start with '# '
Line 474:80: E501 line too long (94 > 79 characters)

In the file fibsem/utils.py:

Line 344:1: E302 expected 2 blank lines, found 1
Line 344:52: W291 trailing whitespace
Line 345:1: W293 blank line contains whitespace
Line 355:38: W292 no newline at end of file

@patrickcleeve2 migrate


Expose quinn::EndpointConfig for {Client,Server}Config

This PR exposes the quinn::EndpointConfig via quic_endpoint_config/quic_endpoint_config_mut on ClientConfig/ServerConfig, analogously to how quinn::{Client,Server} are currently exposed.
To give a bit of context to the use case: I'd like to manually manage connection IDs on the application level and would like to set the EndpointConfig::cid_generator for that purpose.
If you have another proposal on how to expose this or don't like to expose it all, let me know. I just figured opening this PR was as quick as opening a discussion on what I'd like to change.

Sure, done. I usually push commits to a feature branch since that makes it easier for reviewers to see what I changed since last time. And then use the "squash and merge" option on GitHub. Anway, squashed these now!


Request path did not match any of the known api paths

Hi, I am struggling with this new problem, I am using this example:
/v1/pets/{petId}:
    get:
      summary: Info for a specific pet
      operationId: showPetById
      tags:
        - pets
      parameters:
        - name: petId
          in: path
          description: The id of the pet to retrieve
          type: string
      responses:
        200:
          description: Expected response to a valid request
          schema:
            $ref: Pets
        default:
          description: unexpected error
          schema:
            $ref: Error

And when I do this:
import requests
from flex.core import load, validate_api_call
schema = load("schema.yaml")
response = requests.get('/v1/pets/dog')
validate_api_call(schema, raw_request=response.request, raw_response=response)

For some reason I am getting this error:
flex.exceptions.ValidationError: 'request':
    - 'path':
        - 'Request path did not match any of the known api paths.'

Is there something specific I should do in the schema to solve this?

Can you drop into a debugger (pdb) statement at this place in the code.
https://github.com/pipermerriam/flex/blob/master/flex/validation/common.py#L459
That LookupError is the source of the validation error.  The LookupError comes from https://github.com/pipermerriam/flex/blob/master/flex/paths.py#L125.  What I'm curious about is whether the exception is coming from line 128 "No paths found" or line 130 "Multiple Paths Found".
Either way, If you can also give me a dump of the paths variable defined at https://github.com/pipermerriam/flex/blob/master/flex/paths.py#L116 that will help.

Also, I think that if you pass your schema through flex.core.validate you're going to get some errors around your parameter definitions.  Specifically, the required field of a parameter is required if the parameter is in the path.
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#fixed-fields-7

Also, what version of flex are you using?

Hi @pipermerriam thanks again for the quick response, I am going to respond your questions:

the exception is coming from line 128 "No paths found" or line 130 "Multiple Paths Found".? The exception is coming from line 128 "No paths found"

My paths are:

{'/v1/pets/{petId}': re.compile('^/v1/pets/\\{petId\\}$'),
'/v1/pets/': re.compile('^/v1/pets/$')}

The required field of a parameter is required if the parameter is in the path. . Yes, I solved that before, adding the required into the swagger.

What version of flex are you using? I am using flex 3.0.0

It looks like the regex for the /v1/pets/{petId} is being compiled without knowledge of the petId parameter.
Can you head back into the match_path_to_api_path function and get the values of both global_parameters and (v or {}).get('parameters', []) for v in path_definitions.items()
What I'm looking for is whether the petId parameter is present in either of those lists.

The global_parameters are {}
And the path_definitions it seems it has all the swagger schema, including the petId parameter:
'/v1/pets/{petId}': {'get':
  {'summary': 'Info for a specific pet', 'operationId': 'showPetById', 'tags': ['pets'],
  'responses': {200: {'description': 'Expected response to a valid request',
  'schema': {'$ref': 'Pets'}}}, 'parameters': [{'required': True, 'in': 'path',
  'description': 'The id of the pet to retrieve', 'name': 'petId', 'type': 'string}

I think I found the problem, in this line:
https://github.com/pipermerriam/flex/blob/master/flex/paths.py#L119
This expression: (v or {}).get('parameters', []) is always returning []
Do you know why this can be happening?

I am going to try to explain what I found:
Our v variable here it something like this:
v = {'get':
{'parameters': [{'required': True, 'name': 'petId', 'description': 'The id of the pet to retrieve', 'in': 'path', 'type': 'string'}],
 'summary': 'Info for a specific pet',
'operationId': 'showPetById',
'responses': {200: {'description': 'Expected response to a valid request', 'schema': {'$ref': 'Pets'}}},
'tags': ['pets']}}

How you can see this (v or {}).get('parameters', []) is always returning [] because v.get('parameters') doesn't exist. What I mean is that if we do v.get('get') we will get this:
{'parameters': [{'required': True, 'name': 'petId', 'description': 'The id of the pet to retrieve', 'in': 'path', 'type': 'string'}],
'summary': 'Info for a specific pet',
'operationId': 'showPetById',
'responses': {200: {'description': 'Expected response to a valid request', 'schema': {'$ref': 'Pets'}}},
'tags': ['pets']}

and if we do v.get('get').get('parameters'), we are going to get the parameters:
[{'required': True, 'type': 'string', 'description': 'The id of the pet to retrieve', 'in': 'path', 'name': 'petId'}]

Ah!
https://github.com/pipermerriam/flex/pull/55
Wasn't looking at the parameters defined at the operation level.  Once this passes, I'll get a 3.1.0 released sometime today.

Great!!! :D
Thanks @pipermerriam!

Really glad to have you using flex and reporting these issues.  Lots of these bugs are present due to my use cases only exposing bugs related to how I use swagger.  Glad to have a broader audience.

You should be able to get 3.1.0 off pypi
https://pypi.python.org/pypi/flex/3.1.0

Awesome! Thanks again!


The stored feed has wrong attributes (Laravel 5.1)

Example scenario:
Quiz model uses GetStream\StreamLaravel\Eloquent\ActivityTrait.
When a new Quiz is created the stored feed has the following attributes:

"actor": "App\User:3"
"foreign_id": "App\Quiz:394"
"id": "*****"
"object": "App\Quiz:394"
"origin": null
"target": null
"time": "2015-09-25T02:42:23.000000"
"to": []
"verb": "app\quiz"

Expected behaviour:
The stored feed has the following attributes:

"actor": "App\User:3"
"foreign_id": "394"
"id": "*****"
"object": "App\Quiz"
"origin": null
"target": null
"time": "2015-09-25T02:42:23.000000"
"to": []
"verb": "created"

The most important attribute is "verb" and I assume it had to be correct for specific actions like create, update, delete.

https://github.com/GetStream/stream-laravel#customize-activity-verb
On Thu, Sep 24, 2015 at 8:55 PM Alex<EMAIL_ADDRESS>wrote:

Example scenario:
Quiz model uses GetStream\StreamLaravel\Eloquent\ActivityTrait.
When a new Quiz is created the stored feed has the following attributes:

"actor": "App\User:3"
"foreign_id": "App\Quiz:394"
"id": "*****"
"object": "App\Quiz:394"
"origin": null
"target": null
"time": "2015-09-25T02:42:23.000000"
"to": []
"verb": "app\quiz"

Expected behaviour:
The stored feed has the following attributes:

"actor": "App\User:3"
"foreign_id": "394"
"id": "*****"
"object": "App\Quiz"
"origin": null
"target": null
"time": "2015-09-25T02:42:23.000000"
"to": []
"verb": "created"

The most important attribute is "verb" and I assume it had to be correct
for specific actions like create, update, delete.
—
Reply to this email directly or view it on GitHub
https://github.com/GetStream/stream-laravel/issues/20.

I know that the verb can be changed manually, the point is to change through the trait.
The foreign_id field is also wrong.


OpenAFS Unusable

After apt-get installing krb5-auth-dialog krb5-user libpam-afs-session libpam-krb5 openafs-client openafs-krb5 openafs-modules-dkms, I (foolishly) expected to be able to run /etc/init.d/openafs-client start successfully.
Of course, the message I receive is:
Starting AFS services:
AFS module /lib/modules/3.4.0+/fs/openafs.ko does not exist.
Not starting AFS.  Please consider building kernel modules using
instructions in /usr/share/doc/openafs-client/README.modules

I understand that there is no Linux kernel and therefore(?) there are no kernel headers to allow the module to be built. I'd like to know if there's any way that such a module could be provided, or if there's an alternative method for connecting to AFS from the Linux userspace (i.e. possibly indirectly through the Windows version, for example).

The difficulty is that the Kernel-mode API of WSL is under heavy development, and has therefore neither been documented nor have headers been developed for compilation of such drivers nor would such headers allow you to just compile those kernel modules.  Moreover, it seems like it would be very hard to maintain given the fact that Linux's kernel-mode ABI is not a stable target and can move at any time.
It may be possible one day if/when MS releases a WSL driver SDK and documentation for WSL (which could be as easy as allowing an NT kernel driver to be exposed as a WSL object in /dev or /proc or /sys or whatever.  However, you will likely not be able to compile such a driver using the Linux code directly.  Likely you would need to port it in the difficult way (or maybe cygwin has developed some kind of way to cross-compile Linux kernel modules and drivers for Windows) in that case.  I guess it will be possible in the future, but right now if you need a kernel-mode module or driver, you are out of luck.

#1893


Provide smart constructors for PreciseDateTime

Nanoseconds is bound to 1s, but DateTime is precise up to the millisecond, so the ns component should never be equal to or greater than 1ms. We should provide smart constructors instead of exposing the representation that account for any inconsistency.

@themattchan is using the constructor but also just proposed using a smart constructor instead.

Something like mkPreciseDateTime :: Date -> Hour -> Minute -> Second -> Nanosecond -> PreciseDateTime?
I'd argue against mkPreciseDateTime :: DateTime -> Nanosecond -> PreciseDateTime as one would expect the following to hold:
toDateTime (mkPreciseDateTime dateTime ns) == dateTime

but in the second version we will have to potentially modify the milliseconds in DateTime to make it agree with the nanoseconds.

Good point.


Began work on tests, service credentials

Added support for service (non-interactive) credentials
Added initial test
Now supports both in-config and JSON-based credentials downloaded from the Google Developer Console
Added some basic documentation

Merged. Thank you for contribution.
I will do some unit tests and add some necessary functionality for myself and after that publish it on Grails portal.


Replace Deprecated API

Replaced ExAllocatePoolWithTag with ExAllocatePool2 to fix a memory initialization security vulnerability.
Removed RtlZeroMemory because memory is zero initialized by ExAllocatePool2.

made additional fix to code using outdated definitions


fix(tests) : updated dockerignore

Note: If there are pending changes to the PR, prefix the PR title with "WIP" and add the label "DO NOT MERGE"
Mandatory

[ ] What does this PR do?

[ ] What issue/task does this PR references?

[ ] Are the tests Included?

Optional

[ ] Is the documentation Included?

[ ] Are the Release Notes included?

[ ] @mention(s) to expected reviewer(s) included

@Raunak1203 Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2715 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2715 and visit http://localhost:5000 to access it.


optparse R library should be included

All the Rscript interfaces to enveomics.R depend upon optparse, so perhaps I should include it with the distributions, together with a non-intrusive way to install it or load it. It only seems to need getopt as pre-requisite, and the packages can be found at getopt and optparse.

The new auto-install function introduced to solve #27 reduces the importance of this issue, I'm pushing it down to v0.3.0.


Use references instead of pointers inside ZienkiewiczZhuEstimator and L2ZienkiewiczZhuEstimator

Use references instead of pointers inside ZienkiewiczZhuEstimator and L2ZienkiewiczZhuEstimator, this also prevents to have to document the ownership.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#2862
@YohannDudouit
@pazner
@pazner + @mlstowell
3/2/22
⌛due 3/16/22
⌛due 3/23/22

@mlstowell, can you take a look when you get the chance?

Merged in next for testing...


Passing own sound data?

Is there a way to pass my own sound data rather than use the presets? blip.create?

Hmm, not sure. You can do that with the OpenAL extension though.

Nowadays it is possible to modify the sound data of an existing sound component. Closing.


Creating a Tolino compatible Quickdic dictionary starting with headwords, inflections and definitions

Hello,
what should I try if I had all the sufficient data (headwords, inflections and definitions) in order to create a Tolino compatible dictionary?
(I hope this question fits here)
Thank you!

This might be related with https://github.com/rdoeffinger/DictionaryPC/issues/8 and maybe some of the commands and examples in that issues are helpful?


Unable to memo_wise Module methods

I have a module namespace that I use for some "FP" style methods.
module CurrentQueries
  prepend MemoWise

  module_function

  memo_wise def current_org(path_key:)
    Organization.fetch_by_path_key(path_key)
  end

I thought this was working, but it is not currently.  I don't know if it stopped working, or never did actually work.
It doesn't matter if I structure it like this:
module CurrentQueries
  prepend MemoWise

  module_function

  def current_org(path_key:)
    Organization.fetch_by_path_key(path_key)
  end
  memo_wise :current_org

If I call the method in both cases I do not get any memoization at all.
CurrentQueries.current_org(:path_key => "blurgh")
CurrentQueries.current_org(:path_key => "blurgh") # not memoized!

I failed to parse the documentation, later figured that out, and failed to close this.  The answer is:
module CurrentQueries
  prepend MemoWise

  module_function

  def current_org(path_key:)
    Organization.fetch_by_path_key(path_key)
  end
  memo_wise self: :current_org
end


Tensorflow model training working slow

I have arond 1500 images  with 7 classes i know its less but i am rookie in machine learning and object detection. Due to technical limitation i am currently training the model  using tensorflow cpu version. the machine is taking 20 second/step. and it took 3 days to reach 11000 steps. i want to reach atleast 40000 steps.  My question is it always take that long time for training the model in tensorflow-cpu or is there some problem? please answer my question as soon as possible
I am using tensorflow-cpu version 1.5 the reason of using this version is that in tensorflow-1.7 i am getting the depracation warning and  was not able to train the model on my laptop
If i am doing something wrong please guide me
thanking you in anticipation

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
TensorFlow installed from
TensorFlow version
Bazel version
CUDA/cuDNN version
GPU model and memory
Exact command to reproduce

Sorry there is a mistake on my end which is I am using tensorflow 1.6 I am really sorry to misguide you earlier, The tensorflow is installed from pypi tensorflow-1.6.0rc1-cp36-cp36m-win_amd64.whl package. windows 8.1  x86 64 bit. CPU model

This question is better asked on StackOverflow since it is not a bug or feature request. There is also a larger community that reads questions there.
If you think we've misinterpreted a bug, please comment again with a clear explanation, as well as all of the information requested in the issue template. Thanks!


Support for overriding credentials

This is useful when the decoded payload has no scopes

Hey @nelsonic, I added some unit tests.
I had to create a new server and separated unit tests, as I wanted to verify scopes control works OK. The only way I found to do that was creating a new server with a different validate Function.

Looks good.
Maintains 100% test coverage.
Merged.
Thanks! :-)

New version published to NPM! thanks for the PR! enjoy!


Issue with Bitbar

I have below errors from bitbar.
Traceback (most recent call last):
  File "/Volumes/Home/rickhan/notion-toolbox/bitbar/get_current_tasks.py", line 17, in <module>
    message = "Working on Nothing | href=%s" % app_url(api.current_day().get_browseable_url())
  File "/Volumes/Home/rickhan/Library/Python/3.7/lib/python/site-packages/cachetools/__init__.py", line 46, in wrapper
    v = func(*args, **kwargs)
  File "/Volumes/Home/rickhan/notion-toolbox/shared/notionscripts/notion_api.py", line 65, in current_day
    day_name = current_date.strftime(self.config.custom_day_format())
TypeError: strftime() argument 1 must be str, not None

@hanj0415 so a recent change was made that allowed the day page formatting to be customizable (#16). The error you are seeing suggests that self.config.custom_day_format() is evaluating to None. I'm curious what you have for your config.json for that option?
https://github.com/kevinjalbert/notion-toolbox/blob/549f763d936c3337e008973d79afafb1fd122ad0/alfred/src/config.py#L52-L53
The above snippet shows that a default value will be used if you don't specify the option (the default is what we had prior to the new change).

config.json is attached which has new change.

@hanj0415 yeah, so the CUSTOM_DAY_FORMAT should be a valid https://strftime.org/ format.
If you don't have any specific needs for a different format, I'd just remove this config from your file and try again.

@kevinjalbert I've removed CUSTOM_DAY_FORMAT from config.json, but I had the same error as below.
❯ /Volumes/Home/rickhan/Dropbox/Bitbar/show_current_tasks.sh
Traceback (most recent call last):
  File "/Volumes/Home/rickhan/notion-toolbox/bitbar/get_current_tasks.py", line 17, in <module>
    message = "Working on Nothing | href=%s" % app_url(api.current_day().get_browseable_url())
  File "/Volumes/Home/rickhan/Library/Python/3.7/lib/python/site-packages/cachetools/__init__.py", line 46, in wrapper
    v = func(*args, **kwargs)
  File "/Volumes/Home/rickhan/notion-toolbox/shared/notionscripts/notion_api.py", line 65, in current_day
    day_name = current_date.strftime(self.config.custom_day_format())
TypeError: strftime() argument 1 must be str, not None

@hanj0415 I was able to reproduce the issue on my end (it is when there was no current task in place).
I've pushed a fix (#21). Update, then close and restart BitBar. It should be working after that.
Reopen the issue if it doesn't work still.


Fix importing multiple accounts from ledger

Select the first wallet from a selection after all wallets are loaded
Closes https://github.com/oasisprotocol/oasis-wallet-web/issues/934

How come this fixed the bug?

Update: I can't reproduce the bug with expectSaga on master. Looks like reducer + saga scheduling in app is different than in expectSaga.
const result = await expectSaga(rootWalletSaga)
.provide(providers)
.withReducer(walletReducer)
.dispatch(
  walletActions.openWalletsFromLedger([
    {
      address: 'oasis1qq2vzcvxn0js5unsch5me2xz4kr43vcasv0d5eq4',
    } as LedgerAccount,
    {
      address: 'oasis1qq5t7f2gecsjsdxmp5zxtwgck6pzpjmkvc657z6l',
    } as LedgerAccount,
    {
      address: 'oasis1qrusst9f8ey6kphgp5d02nuf4kx5qsa80vamtxj8',
    } as LedgerAccount,
    {
      address: 'oasis1qpqs54pdwxstpjefw5t6ucy425nt4yud3c4fgr8p',
    } as LedgerAccount,
    {
      address: 'oasis1qrf54xw003wkznm90w0q05ns8nryla0455tlex38',
    } as LedgerAccount,
  ]),
)
.fork(walletSaga)
.put({ type: walletActions.walletSelected.type, payload: 4 })
.silentRun(50)

expect(result.storeState).toMatchObject({
  selectedWallet: 4,
} as WalletState)

put(selectWallet) in step 8 schedules walletSelected at the end:
1. 'wallet/addWallet', payload: { id: 4, address: 'oasis1qq2vzcvxn0js5unsch5me2xz4kr43vcasv0d5eq4' }
2. 'wallet/addWallet', payload: { id: 5, address: 'oasis1qq5t7f2gecsjsdxmp5zxtwgck6pzpjmkvc657z6l' }
3. 'wallet/addWallet', payload: { id: 6, address: 'oasis1qrusst9f8ey6kphgp5d02nuf4kx5qsa80vamtxj8' }
4. 'wallet/addWallet', payload: { id: 7, address: 'oasis1qpqs54pdwxstpjefw5t6ucy425nt4yud3c4fgr8p' }
5. 'wallet/addWallet', payload: { id: 8, address: 'oasis1qrf54xw003wkznm90w0q05ns8nryla0455tlex38' }

6. 'wallet/walletSelected', payload: undefined
7. 'wallet/walletOpened', payload: { id: 4, address: 'oasis1qq2vzcvxn0js5unsch5me2xz4kr43vcasv0d5eq4' }
8. 'wallet/selectWallet', payload: 4

9. 'wallet/walletSelected', payload: undefined
10. 'wallet/walletOpened', payload: { id: 5, address: 'oasis1qq5t7f2gecsjsdxmp5zxtwgck6pzpjmkvc657z6l' }

11. 'wallet/walletSelected', payload: undefined
12. 'wallet/walletOpened', payload: { id: 6, address: 'oasis1qrusst9f8ey6kphgp5d02nuf4kx5qsa80vamtxj8' }

13. 'wallet/walletSelected', payload: undefined
14. 'wallet/walletOpened', payload: { id: 7, address: 'oasis1qpqs54pdwxstpjefw5t6ucy425nt4yud3c4fgr8p' }

15. 'wallet/walletSelected', payload: undefined
16. 'wallet/walletOpened', payload: { id: 8, address: 'oasis1qrf54xw003wkznm90w0q05ns8nryla0455tlex38' }

17. 'wallet/walletSelected', payload: 4

But it looks like can fix the bug by just removing yield* put(walletActions.walletSelected(initialState.selectedWallet)). There is no reason to select undefined when adding every wallet.

Yeah probably there are many ways to fix it. My preference is to select a wallet when prev actions are done.

I think we should do:

commit: test for re-importing existing accounts (this test is already passing before any changes)
commit: fix the issue by removing yield* put(walletActions.walletSelected(initialState.selectedWallet)) (selecting undefined when adding every wallet makes no sense)
optionally commit: replacing selectImmediately with a select after all wallets are added

(selecting undefined when adding every wallet makes no sense)

fyi @lukaw3d this was actually handling a case when you open an active wallet again

(selecting undefined when adding every wallet makes no sense)

fyi @lukaw3d this was actually handling a case when you open an active wallet again

Ah, I didn't notice when it was added in https://github.com/oasisprotocol/oasis-wallet-web/pull/787/files#diff-f5039a29f4edb72ce140205418b6a20f84c4e5ed87c38bd33c4724aaee5c66fbR130
when changing from
  yield* takeLatest(walletActions.selectWallet, selectWallet)

  export function* selectWallet({ payload: index }: PayloadAction<number>) {
    ...
    yield* put(push(`/account/${newWallet?.address}`))
  }

to
  useEffect(() => {
    if (typeof activeWalletIndex !== 'undefined' && address) {
      history.push(`/account/${address}`)
    }
  }, [activeWalletIndex, address, history])

:/


Add initial client go sdk prototype

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

initial go sdk extension for FPC that hides the FPC transaction flow
from the user
integrate with test-network

Which issue(s) this PR fixes:

Fixes #289
Special notes for your reviewer:
Does this PR introduce a user-facing changes and/or breaks backward compatability?:

Note that eecb1cd relies on a little modification at the go sdk. Opened a PR

PR was already merged!

but most of the issue might be better addressed elsewhere (primary concern is that there are some issues like interface between c and go (issue #412) and encoding/decoding, formats of request/response we seem to make somewhat implicit which i think we should make a bit more explcit/consciously ...).

I agree that these could be better addressed elsewhere, and I would add later after getting the next release out.

I agree that these could be better addressed elsewhere, and I would add later after getting the next release out.

If we don't agree on these encodings, interfaces and types (either explicitly or impliciltly) then there will be no next release?

I agree that these could be better addressed elsewhere, and I would add later after getting the next release out.

If we don't agree on these encodings, interfaces and types (either explicitly or impliciltly) then there will be no next release?

Interfaces and protobufs are already defined, there is no need (at least at this point) for additional details -- hopefully this matches with your definition of "implicit" agreement.
The components being implemented are already part of the next release, and match the design.

Interfaces and protobufs are already defined,

The interfaces i was referring to is regarding #421 which we haven't designed.  Regarding protobufs, we forgot to define message format for (encrypted) fpc chaincode invocations (request and response).  Our spec also omitted the encoding of messages between client and fpc_stub.  We agreed in yesterday's call verbally on that encoding (i.e., base64-encoding of binary-serialization of protobuf objects), my point was only that we might also simply document that (and remove the misleading reference to json-protobuf). Anyway, i can do an AR on myself to create a PR which creates a proposal for the missing protobufs and does the small fix to interfaces.md regarding the encoding.


Cannot verify the published app

At the time of working on this article on the verifiability of your PlayStore app, I failed to verify it. I would much appreciate if you could provide better build instructions so that developers can verify the app easily.

The article mention that we closed the issue
https://github.com/bitpay/copay/issues/9037
Which is incorrect. The author of the ticket closed the issue.
Are you the author of the article? Would you mind please to correct that?
Im pretty sure Android builds of angular application do not offer
deterministic builds. Do you having problems building the app or do issue
is that the resulting binary does not match the one published?
On Fri, Dec 13, 2019, 10:02 PM Leo Wandersleb<EMAIL_ADDRESS>wrote:

At the time of working on this article
https://walletscrutiny.com/posts/2019/11/bitpay/ on the verifiability
of your PlayStore app, I failed to verify it. I would much appreciate if
you could provide better build instructions so that developers can verify
the app easily.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/copay/issues/10425?email_source=notifications&email_token=AAAYEHDOMXJLU42W7JIU4N3QYQWEFA5CNFSM4J2X36LKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IAO2DPQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYEHG4XOQ47R4GFG2TYFTQYQWEFANCNFSM4J2X36LA
.

Our findings are laid out in the article you read.
May I take your comment as confirmation that you do not verify builds? I don't care about bit-wise deterministic builds but about verifiability. If engineer A on his machine that might have a code-swapping virus compiles the app, can engineer B verify the build or not?
How high a bounty do you estimate to be for injecting such a virus on the release manager's machine? Would the release manager watch his family remain hostage before injecting malicious code? Those are the extreme fantasies that made me push for verifiability at Mycelium.

Just FYI, we use the same stack (ionic + cordova) in our project AirGap. We use docker and our builds are deterministic, see the discussion here.

thanks for the information Andreas, we will look into it.
On Mon, Jan 6, 2020 at 12:57 PM AndreasGassmann<EMAIL_ADDRESS>wrote:

Just FYI, we use the same stack (ionic + cordova) in our project AirGap
https://airgap.it. We use docker and our builds are deterministic, see
the discussion here https://github.com/airgap-it/airgap-vault/issues/13.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bitpay/copay/issues/10425?email_source=notifications&email_token=AAAYEHD7CEE5NXJJUBWB2O3Q4NIG7A5CNFSM4J2X36LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIF3ZSY#issuecomment-571194571,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYEHHNV4DQ6PTZTT27OATQ4NIG7ANCNFSM4J2X36LA
.

--
Matías Alejo Garcia
@ematiu
Roads? Where we're going, we don't need roads!

Three months later ... guys, your wallet has more than half a million downloads! It's negligence to not verify the release manager's build! He might have a backdoor on his machine or be put under duress to steal all the funds of all the users. How is the status of this issue?

Hi @Giszmo,
we are on the process of implement a build process based on docker, similar to the one AirGap (thanks again @AndreasGassmann ) is using. We will update this ticket one it is on production.
Thanks for bringing this point to our attention.

It's been a while. How are things going? Time to try rebuilding again??

Currently building the latest version fails: https://github.com/bitpay/wallet/issues/11748#issuecomment-1064483131 thus instructions on how to build latest version in container is the first step, @matiu is there any progress regarding Docker build stack mentioned in https://github.com/bitpay/wallet/issues/10425#issuecomment-605975286 ?


Solstice app not in the expected location

Not sure when it happened, but Mersive change the app name from Solstice Client to Mersive Solstice and that results in the following error in the recipe

The Solstice Client.app wasn't at the expected location.
Failed.
Receipt written to /Users/user/Library/AutoPkg/Cache/local.jss.Solstice/receipts/Solstice-receipt-20210105-171902.plist

Fix is relatively simple, just need to change Solstice Client to Mersive Solstice in the Solstice Processor. I'll make a PR.

Thanks @Chalcahuite.  This may be why I saw an error recently.  But when I ran it again, it seemed to complete without an error, which was confusing.  But I didn't have the time to look into it much at that point.
I have Merged your PR.

Thanks @Chalcahuite.  This may be why I saw an error recently.  But when I ran it again, it seemed to complete without an error, which was confusing.  But I didn't have the time to look into it much at that point.
I have Merged your PR.


KAFKA-8453: AdminClient describeTopic should handle partition level errors

Here is the draft fix. The approach is simple:

Add a new method, MetadataResponse#partitionErrors, which returns a map from topic to the set of its partition errors. (It follows how MetadataResponse#topicMetadata does.)
Call#handleResponse in KafkaAdminClient#describeTopics now uses both of topic level error map and partition level error map; if there is ListenerNotFound error in partition level error map, it calls KafkaFuture#completeExceptionally.

However, since it now throws a new Exception, it brokes following tests which are related to the leader election.

kafka.server.DynamicBrokerReconfigurationTest.testUncleanLeaderElectionEnable
kafka.api.AdminClientIntegrationTest.testElectUncleanLeadersAndNoop
kafka.api.AdminClientIntegrationTest.testElectUncleanLeadersForManyPartitions
kafka.api.AdminClientIntegrationTest.testElectUncleanLeadersForAllPartitions
kafka.api.AdminClientIntegrationTest.testElectUncleanLeadersForOnePartition
kafka.api.AdminClientIntegrationTest.testElectUncleanLeadersWhenNoLiveBrokers
kafka.api.SaslSslAdminClientIntegrationTest.testElectUncleanLeadersAndNoop
kafka.api.SaslSslAdminClientIntegrationTest.testElectUncleanLeadersForManyPartitions
kafka.api.SaslSslAdminClientIntegrationTest.testElectUncleanLeadersForAllPartitions
kafka.api.SaslSslAdminClientIntegrationTest.testElectUncleanLeadersForOnePartition
kafka.api.SaslSslAdminClientIntegrationTest.testElectUncleanLeadersWhenNoLiveBrokers
kafka.admin.TopicCommandWithAdminClientTest.testDescribeUnavailablePartitions
kafka.admin.TopicCommandWithAdminClientTest.testDescribeUnderMinIsrPartitionsMixed

Which approach would be appropriate to fix the problem above? Do you have something in mind?
cc/ @hachikuji
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@dongjinleekr Thanks for picking this up. I was looking into the usage of LISTENER_NOT_FOUND. In MetadataCache, we have the following logic:
        maybeLeader match {
          case None =>
            val error = if (!snapshot.aliveBrokers.contains(brokerId)) { // we are already holding the read lock
              debug(s"Error while fetching metadata for $topicPartition: leader not available")
              Errors.LEADER_NOT_AVAILABLE
            } else {
              debug(s"Error while fetching metadata for $topicPartition: listener $listenerName not found on leader $leaderBrokerId")
              if (errorUnavailableListeners) Errors.LISTENER_NOT_FOUND else Errors.LEADER_NOT_AVAILABLE
            }
            new MetadataResponse.PartitionMetadata(error, partitionId.toInt, Node.noNode(),
              Optional.empty(), replicaInfo.asJava, java.util.Collections.emptyList(),
              offlineReplicaInfo.asJava)

Basically if we could not locate the endpoint for the current leader, then it's either because the leader does not support the right listener or it's just not online. Either way, the information reported by Metadata will not be accurate. @huxihx is working on fixing this problem in #6836.
From an admin client perspective, It's a bit annoying that we lose leader/ISR visibility when the leader is offline. The ideal would be to ensure the metadata is accurate and to let the admin client ignore the error. However, we have to deal with the inaccuracy for older versions of the broker even if we fix this going forward.
So I'm not 100% sure how the admin client should handle this. Maybe it can observe the error code and check if the leader is undefined? If so, we raise an error; otherwise we ignore the error. Alternatively, we could continue to ignore these errors in all cases. Any thoughts?

@hachikuji I have no strong opinion on how the admin client should handle this error. I will follow the decision of you and other experienced contributors. Anytime you decide it, please leave a comment here.
+1. Meanwhile, I have another issue about the command line tools; Please have a look at KAFKA-8507 when you are free.


List isn't added to the document

I've clicked the "update lists" but they are not being added to the document.

Did you manage to resolve this on your own?

Did you manage to resolve this on your own?


Publish ltsc2022 tags for Windows

Context
We are looking to shift our internal CI to GameCI, but our current stack relies on Windows Server 2022 which means we can’t use the pre-built GameCI images for Windows since they are based on ltsc2019 (and we don’t particularly want to use hyper-v isolation).
Suggested solution
Would it be possible to have ltsc2022 images published as well as ltsc2019?
Considered alternatives
Considered Hyper-v isolation, but might be prohibitively slow for large projects.

Right now we're only supporting officially supported operating systems. Since our uploads are sizeable we're not looking to add another version of the same base OS at this time.
However, please feel free to discuss your approach and bumps in the road on our discord and feel to contribute an example docker image to this repository, or instructions for it to our documentation website. That way the community can still help out.

@webbertakken thanks for the prompt response! I totally understand your position on this, and I figured this might be the answer I'd get. We will look for alternative solutions in the meantime. 👍


Add shuffled names feature

Uses Foswig lib

Should probably add foswig to README.md dependencies

forgot to mention the issue #30


Regression in v10.1.0

@metamask/eth-block-tracker v10.1.0 is causing a regression noticed in CI for @metamask/eth-json-rpc-filters: https://github.com/MetaMask/eth-json-rpc-filters/pull/176#issuecomment-2240913555
Error: PollingBlockTracker - encountered an error while attempting to update latest block:
TypeError: this._provider.request is not a function
    at PollingBlockTracker._fetchLatestBlock (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:275:43)
    at PollingBlockTracker._updateLatestBlock (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:258:36)
    at PollingBlockTracker._updateAndQueue (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:292:18)
    at PollingBlockTracker._start (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:249:10)
    at PollingBlockTracker._maybeStart (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:166:10)
    at PollingBlockTracker._onNewListener (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:146:12)
    at safeApply (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/safe-event-emitter/index.ts:10:13)
    at PollingBlockTracker.emit (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/safe-event-emitter/index.ts:63:7)
    at _addListener (node:events:560:14)
    at PollingBlockTracker.addListener (node:events:609:10)
    at PollingBlockTracker.once (node:events:653:8)
    at /home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/test/util.js:50:50
    at new Promise (<anonymous>)
    at Object.trackNextBlock (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/test/util.js:50:12)
    at deployLogEchoContract (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/test/util.js:149:15)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at PollingBlockTracker._updateAndQueue (/home/runner/work/eth-json-rpc-filters/eth-json-rpc-filters/node_modules/@metamask/eth-block-tracker/src/PollingBlockTracker.ts:294:22)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
Error: PollingBlockTracker - encountered an error while attempting to upda

@kanthesha and I have deprecated 10.1.0, marked the change in #252 as a breaking change, and re-released it as 11.0.0.


Mergify: Make backports automatically assign PR author

This change has been made by @ValarDragon from https://mergify.com config editor.

Going to backport this just to sanity check it works, even though mergify says the config is valid


Replace deprecated dash-functional dependency

Dash 2.18.0 now subsumes dash-functional.
See https://github.com/magnars/dash.el/blob/master/NEWS.md#from-217-to-218

nice, thanks!


Can't npm install a branch

Is your feature request related to a problem? Please describe.
Yes. I can only npm i versions that have been released to npmjs.com.  For example, 7.1.1 has a github release, but has not been uploaded to npmjs.com
Because the module is in the nativescript-angular subdir, the standarized way to install from a branch does not work. IE:
npm i NativeScript/nativescript-angular@master

Describe the solution you'd like
Move package.json to root.
Describe alternatives you've considered
move the nativescript-angular npm module to its own repo.
Additional context
AFAIK npm and yarn do not support installing from git when package.json is in a subdir.

Hi @rynop,
Thank you for the provided feedback.
I would suggest checking out the described workflow in the repository - developer-workflow. As it is mentioned the repository contains several test apps that are used for testing the nativescript -angular and provides a straightforward workflow for the devs.
If you need to use the upcoming version of this page you can use @next npm version of the nativescript-angular, which corresponds to the master branch. If you still need to use directly the master branch, you can follow the below-described steps.

git clone https://github.com/NativeScript/nativescript-angular
cd nativescript-angular/nativescript-angular
npm i
tsc
link the package in your project.

Thanks @tsonevn.  I tried @next but it did not correspond to master (was still 7.1.0-x).
It's unfortunate that the file structure of the repo is preventing a slew of easy-to-use npm/yarn function on install/update (ex: tag,version,url,tar).
Any idea when 7.1.1 is going to be released to npmjs.com?  I think my use case/concern goes away with just some education on my part.
When a patch version is released to github, what is the timeline for it to be released to npmjs.org? 7.1.1 contains a fix for a regression bug that broke navigation functionality.


chore: Migrate trace synth.py to bazel

The changes in grpc stubs are caused by the gRPC upgrade from 1.10 (more than a year old) to 1.27 (same version which is used as runtime dependency)

@chingor13 PTAL


Add origin param to proposeTransaction method in safe-service-client

Check https://ethereum.stackexchange.com/questions/120143/origin-field-not-exist-in-safetransactiondata/120173#120173

amazing thank you

To be released early next week

@terryli0095  Hi, a new release of the SDK was published adding this feature