Automatic view compilation isn't happening in asp.net core 2.1.2

When I upgraded my project to asp.net core 2.1.2 and the ViewCompilation package to 2.1.1 the automatic view compilation doesn't appear to be working when I publish
To test I created two new projects from the asp.net core templates targeting .net framework 4.6.2. In one of them I upgrade it to asp.net core 2.1.2 and the other is default asp.net core 2.0.4 with ViewCompilation 2.0.4.
The resulting output is below
ViewCompilation 2.0.4

ViewCompilation 2.1.1

csProj for 2.0.4
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.4" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.4" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.4" PrivateAssets="All" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.3" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.3" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.4" />
  </ItemGroup>
</Project>

csProj for 2.1.2
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.1.1" PrivateAssets="All" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.1.1" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.1.1" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.4" />
  </ItemGroup>
</Project>

Thanks for contacting us, @shoe788.
@pranavkm, can you please look into this? Thanks!

I am on Visual Studio 15.7.5

Here are the build logs.
vslog_1.txt
vslog_2.txt
vslog_3.txt
vslog_4.txt

It looks like your app's using the 2.0 SDK (the SDK versioned 2.1.2x is for the 2.0 runtime \ release). It's strange that VS did not install the 2.1.3.x SDK that shipped with the 2.1 runtime. You may download the Sdk from here - https://www.microsoft.com/net/download/dotnet-core/2.1 if you don't already have it installed. If you do have it installed, perhaps you have a global.json that's pinning the sdk?

Yep, the VS update didn't install the sdk. Thank you very much!
You said that the ViewCompilation package is deprecated so does it work to uninstall that package and just have Microsoft.AspnetCore.Mvc?

You said that the ViewCompilation package is deprecated so does it work to uninstall that package and just have Microsoft.AspnetCore.Mvc?

Yup. Removing that package reference would be the way to go.

I had the same problem. Thanks you!


Broken asset links when using cleanUrl setting

🐛 Bug Report
When using the cleanUrl: true setting, docusaurus generates new sub folders for each site. For example, if you want clean url /docs/Connectivity, what docusaurus generates is a sub folder called Connectivity with an index.html file in it instead of the original Connectivity.html.
I really like the idea of this, but when the index.html within a cleanUrl subfolder references an image from the docs/assets folder, the link is broken because it's still relative to the original docs/ folder.
To Reproduce

Set cleanUrl to true in siteConfig.js
Reference an image from the assets folder within your markdown file
Browse to the clean url, e.g. docs/Contributing, instead of docs/Contributing.html
Image in clean URL is broken, in .html document image will work.

Expected behavior
When setting cleanUrl to true, docusaurus generates correct asset links to parent directory, where asset directory is located.
Actual Behavior
Image is broken due to link still being relative to parent directory instead of being relative to the directory created for clean url

1.We actually produce connectivity.html and connectivity/index.html when cleanUrl is true.

How did you reference the image ?

Example:
![test](/docs/assets/activeMachine.png)

Our documentation recommend on using absolute url path instead of relative path.

@endiliey thanks for your fast reply!
you're right, we're actually not using absolute paths. I'll figure out if we can change this in our existing documentation.
Do you see this as an issue for larger projects? I'm thinking about big projects with existing markdown structures using relative paths, trying to use Docusaurus.

@eimerreis
Actually this relative path case will happen on i18n and/or versioned website as well.

i18n website has urls like /docs/en/, /docs/ja.
versioned website has urls like /docs/next/.
i18n & versioned website has urls like /docs/en/next

There are many ways to solve this either on Docusaurus side or user side, but I think it is really really straightforward for user to use absolute url instead of Docusaurus having to transform all those links again (+ build times, + more codes = more bug).

Have any workarounds been found for this issue? I started using absolute URLs so my images render on the published website, but they don't show up for local builds as expected.

Marking this as wontfix in v1. The recommended way is to use absolute URL.
This should be out of the box in v2 (I think)

Have any workarounds been found for this issue? I started using absolute URLs so my images render on the published website, but they don't show up for local builds as expected.

I am using this as a workaround:

Use relative paths in your markdown so images show up in your local markdown editor without setting something like an image root path
Disable cleanUrl so the relative paths will break after markdown files are converted to html

Absolute paths are great if the markdown files are for websites only. But unfortunately, I am also running the same markdown files through DITA Open Toolkit to generate PDFs, and DITA OT won't recognize the absolute paths.


Fix the error 'TypeError: Cannot read property 'search' of undefined'

To resolve this error, the xml-encryption has to update to 0.9.0. I am not sure why I am the only one in the world having this problem. I am using:
Node.js: 0.4.3
React
/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/util.js:1320
          _queryVariables = parse(window.location.search.substring(1));
                                                 ^

TypeError: Cannot read property 'search' of undefined
    at Object.util.getQueryVariables (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/util.js:1320:50)
    at Array.initModule (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/log.js:306:26)
    at Array.module.exports (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/log.js:359:14)
    at Module.module.exports (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:42:14)
    at defineFunc (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:48:10)
    at /Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:86:14
    at define (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:15:7)
    at define (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:55:22)
    at /Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:60:1
    at Object.<anonymous> (/Users/ericso/az/kancho/web/rubix-3.0/node_modules/passport-saml/node_modules/node-forge/js/forge.js:88:3)

Please help me to merge it sooner because it is currently blocking our development.

oops.. not sure if the CI test fail is related to my change.

I just tried to rollback the xml-encryption to ~0.7 that I am seeing the same error.
SAML.js
getAuthorizeUrl
✓ calls callback with right host
✓ calls callback with right protocol
✓ calls callback with right path
✓ calls callback with original query string
✓ calls callback with saml request object
passport-saml /
captured saml responses /
✓ Okta -- valid config should succeed (154ms)
✓ Okta -- valid config should succeed passReqToCallback (59ms)
✓ Onelogin -- invalid cert (from Okta case) should fail
✓ Onelogin -- invalid cert (from Okta case) should fail passReqToCallback
✓ Onelogin -- valid config should succeed
✓ Onelogin -- valid config should succeed passReqToCallback
✓ Testshib -- valid encrypted response should succeed (350ms)
✓ Testshib -- valid encrypted response should succeed passReqToCallback (305ms)
captured SAML requests /
✓ Empty Config
✓ Empty Config w/ HTTP-POST binding
✓ Config #2
✓ Uncompressed config #2
✓ Config #3
✓ Config with AuthnContext
saml.js /
✓ generateLogoutRequest
✓ generateLogoutRequest adds the NameQualifier and SPNameQualifier to the saml request
✓ generateLogoutResponse
✓ generateLogoutRequest
✓ generateServiceProviderMetadata contains logout callback url
✓ #certToPEM should generate valid certificate
✓ response with error status message should generate appropriate error
✓ response with error status code should generate appropriate error
generateServiceProviderMetadata tests /
✓ config with callbackUrl and decryptionPvk should pass
✓ config with callbackUrl should pass
✓ config with protocol, path, host, and decryptionPvk should pass
✓ config with protocol, path, and host should pass
my test
✓ accept response with an attributeStatement element without attributeValue
request signature checks /
✓ acme_tools request signed with sha256
✓ acme_tools request signed with sha1
xml signature checks /
✓ valid onelogin xml document should validate
✓ onelogin xml document with altered assertion should fail
✓ onelogin xml document with duplicate altered assertion should fail
✓ onelogin xml document with extra unsigned & altered assertion should fail
✓ onelogin xml document with extra nexted assertion should fail
getAdditionalParams checks /
✓ should not pass any additional params by default
✓ should not pass any additional params by default apart from the RelayState in request query
✓ should not pass any additional params by default apart from the RelayState in request body
✓ should pass additional params with all operations if set in additionalParams
✓ should pass additional params with "authorize" operations if set in additionalAuthorizeParams
✓ should pass additional params with "logout" operations if set in additionalLogoutParams
✓ should merge additionalLogoutParams and additionalAuthorizeParams with additionalParams
✓ should prioritize additionalLogoutParams and additionalAuthorizeParams over additionalParams
InResponseTo validation checks /
✓ onelogin xml document with InResponseTo from request should validate
✓ onelogin xml document without InResponseTo from request should fail
✓ xml document with SubjectConfirmation InResponseTo from request should be valid
✓ xml document with multiple AttributeStatements should have all attributes present on profile
InResponseTo server cache expiration tests /
✓ should expire a cached request id after the time (302ms)
✓ should expire many cached request ids after the time (606ms)
assertion condition checks /
✓ onelogin xml document with current time after NotBefore time should validate
✓ onelogin xml document with current time equal to NotBefore (plus default clock skew)  time should validate
✓ onelogin xml document with current time before NotBefore time should fail
✓ onelogin xml document with current time equal to NotOnOrAfter (minus default clock skew) time should fail
✓ onelogin xml document with current time after NotOnOrAfter time (minus default clock skew) should fail
✓ onelogin xml document with current time after NotOnOrAfter time with accepted clock skew equal to -1 should pass
validatePostRequest()
✓ errors if bad xml
✓ errors if bad signature
✓ returns profile for valid signature
✓ returns profile for valid signature including session index
63 passing (2s)
works in my

To avoid other CI test failed due to the new node stable version, please consider to merge this pull-request. Thanks.

Hi, is updating dependencies what you are looking to do? If so I am in progress of doing just that, and will close this PR unless there's something else here

You need to update the dependency in package.json. I don't remember if I have a pull request for you.

Ops.. this is the pull request, can you merge this pull request?

This PR expired. The module in question was updated elsewhere, and Node compatibilty was fixed elsewhere as well.


Collection of TODOs

More complex TODOs should become own issues or PRs, but for now, I will just add a list of TODOs here to keep things documented

[ ] #6
[ ] Make RAINLINK runable
[x] Make some other R code runable (done with PWS code and data in #9)
[x] Add example notebooks in root dir or add an index notebook there that links to relevant content
[x] #3
[x] #5
[x] #10
[ ] move data downloader and transformation code to own repo and simple python package
[ ] set up CI (ideally trigger all tests of included packages, if they have any, but also test example notebooks that are only in this repo, e.g. using https://pytest-notebook.readthedocs.io/en/latest/)

[ ] Add pws-pyqc
[ ] Develop social media outreach strategy
[ ] Add index notebook for all notebooks and improve readme.md
[ ] Create a new example notebook for PWSQC which uses source() to load the packages functionalities and clean/remove the old notebook/Rmd/html files
[ ] Reduce mybinder startup time
[ ] Add more CML and PWS data


Fix forms to avoid multiples submissions

In order to improve the GUI interface quality and to avoid making unecessary requests to the backend:

Disable buttons after submission until the transaction is completed (login/check update/change username/change password)
Add submission by pressing "Enter" key on login page

Done in commit fix (frontend): avoid multiple clicks/submissions on buttons (91b7161)


Different number of examples in csv files?

my csv counter script has counted different number of examples so I corrected it :)

this is the csv counter script I used:
import csv

def count_lines_in_csv(file_path):
    try:
        with open(file_path, 'r') as csvfile:
            # Use csv.reader to iterate over the lines in the CSV file
            csv_reader = csv.reader(csvfile)
            # Use a counter to count the number of lines
            line_count = sum(1 for row in csv_reader)
        return line_count
    except FileNotFoundError:
        print("File not found.")
        return None
    except Exception as e:
        print("An error occurred:", e)
        return None

# Example usage:
file_path = 'val.csv'  # Replace 'example.csv' with the path to your CSV file
line_count = count_lines_in_csv(file_path)
if line_count is not None:
    print("Number of lines in the CSV file:", line_count)


Hover Effect Missing on "View 2023 Idea list" Button

Description:
The "View 2023 Idea list" button on the Projects page does not show any visual effect when hovered over. A hover effect would improve user experience by providing visual feedback.
Steps to Reproduce:
Navigate to the Ideas page.
Hover the mouse pointer over the "View 2023 Idea list" button.
Expected Behavior:
The button should display a visual effect (e.g., change in color, shadow, etc.) to indicate it is being hovered over.
Actual Behavior:
No visual effect is observed when the button is hovered over.
Screenshot -

Please assign this to me!

@sachan13harshit can you please assign this issue to me ?

can i be assigned to this issue?

@sachan13harshit pls assign it too me

Hi @sachan13harshit could you assign this issue to me ,I have done it.

@sachan13harshit can I work on it?

can i work on this issue @sachan13harshit


x/pkgsite: request for documentation for non-std modules responds with an error

What is the URL of the page with the issue?
Any module that does not have a dot in its name and is not part of the standard library.
What is your user agent?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36

What did you do?

Run a local pkgsite instance to serve documentation for a module that is only available internally and which does not have a . in its name.
Request the godoc for module's packages.

What did you expect to see?
The godoc for the page.
What did you see instead?
An error page.
The issue is caused by "github.com/golang/pkgsite/internal/frontend".serveDetails, which calls "github.com/golang/pkgsite/internal/frontend".extractURLPathInfo which in turn relies on "github.com/golang/pkgsite/internal/stdlib".Contains.
While I can understand the standard library taking precedence, it would be nice if serveDetails would fallback to checking the other modules so that modules which are internal to a company and not expected to be available publicly could have documentation served by pkgsite as well.
Unfortunately, updating the module name is a disruption that is not yet worth the trouble.

I understand the use case but I'm not sure this is something we would move forward with. Package names should always be globally unique and this namespace is reserved for the stdlib. Others might disagree. /cc @jba @julieqiu
Would the replace directive be useful here in avoiding major disruption from a module name change?

I agree with Jamal.
If you don't want to change your package names, I'd suggest patching our code for your local deployment.

is this documented some place

That would be #32819
Closing as this isn't going to be supported

@seankhliao The reasons for not lifting the ristrictions here is fair enough, but the error message returned should be revised.
The HTTP 424 Failed Dependency along with the message "This page is not supported by this datasource." is exceptionally vague to use as a search engine keyword, and is actually misleading in this case.
As @julieqiu mentioned in #40371, pkgsite (run locally as a light-weight go doc visualizer for private repositories) can be used as an alternative to the godoc cmd which also serves http requests, so running into this problem isn't that rare.
After hours of digging into the source code of pkgsite, I was finally confirmed that the error page has nothing to do with the datasource choice (of not using postgresql). The error handling logic redirect every 404 not found to this 424 failed dependency if the datasource is not postgresql, which is actually counterintuitive as 404s are most certainly 404s.
To better explain: error handler tried to tell user that a 404 not found is due to local filesystem as datasource, mistaking the fact for the actual cause when 404 occured. This logic is flawed for queries that normally return 404s from a postgresql backed instance of pkgsite.
If someone made his first attempt to run pkgsite locally with a single-word named module, and ends up with the program producing "not supported by datasource" page for every url he could come up with, while developer mentioned only

Search and other tabs on the package page are not supported in direct proxy mode.

he would expect the problem to be improper deployment, and head to the wrong direction. (I wasted hours ruling out the possibilities of "needing a postgresql server to fix", "undocumented dependency on linux environment while I run windows", "unknown problem connecting to database", "go for windows not recognizing user-scoped environment variables", definitely don't want to be repeated)
Limiting the "not supported by datasource" error page to search queries should help. And it would be nice to have a link guiding newcomers to the documentation about #32819


Update ReflectionLoader.php

use getNumberOfParameters instead of getNumberOfRequiredParameters, to allow nullable relation.
https://github.com/dunglas/DunglasApiBundle/issues/217

Please close, I just wanted a quick check to see if it passes travis


Tracking: some upstream test fixtures fail when updating to v7.0.0-beta.1

This issue is to track findings on why upstream fixtures fail in PR #1852, so I don't trash the PR discussion.
Working in update-fixtures-to-v7.0.0-beta.1 branch of mine, rolling off the one in PR #1852.

There are 6 failures for --fork Istanbul, all in fixtures/BlockchainTests/GeneralStateTests/stRevertTest:
RevertPrecompiledTouch.json:RevertPrecompiledTouch_d0g0v0_Istanbul
RevertPrecompiledTouch.json:RevertPrecompiledTouch_d3g0v0_Istanbul
RevertPrecompiledTouch_storage.json:RevertPrecompiledTouch_storage_d0g0v0_Istanbul
RevertPrecompiledTouch_storage.json:RevertPrecompiledTouch_storage_d3g0v0_Istanbul
RevertPrecompiledTouchExactOOG.json:RevertPrecompiledTouchExactOOG_d7g2v0_Istanbul
RevertPrecompiledTouchExactOOG.json:RevertPrecompiledTouchExactOOG_d31g2v0_Istanbul

These were added in https://github.com/ethereum/tests/pull/580, then updated/refilled in https://github.com/ethereum/tests/pull/609 and https://github.com/ethereum/tests/pull/610.
For the first four, data indices 0 and 3 produce the same result upstream, so it's no surprise that 0 and 3 fail while 1 and 2 do not.
The last two are also grouped upstream.

RevertPrecompiledTouch.json has program of the following form:
{
 (CALL 50000 1 0 0 0 0 0)
 (CALL 50000 2 0 0 0 0 0)
 (CALL 50000 3 0 0 0 0 0)
 (CALL 50000 4 0 0 0 0 0)
 (CALL 50000 5 0 0 0 0 0)
 (CALL 50000 6 0 0 0 0 0)
 (CALL 50000 7 0 0 0 0 0)
 (CALL 50000 8 0 0 0 0 0)
 [[1]] (GAS)
 [[2]] (GAS)
 [[3]] (GAS)}

That is, sequentially call precompiles 1 through 8, then store remaining gas 3 times in this contract's storage.
The comment shows that it's expected to OOG-fail.

Guess: the difference between py-evm and geth (which filled the tests) is due to different gas use.
Trace shows tx fee of 98780; haven't found number for geth yet.

Guess: very telling is the fact that variants 0 and 3 of the test say that precompile 3 (RIPEMD160) should get its nonce cleared. RIPEMD160 is a special cookie...

Relating to candidate 2: ethereum/EIPs issue https://github.com/ethereum/EIPs/issues/716 ("Clarification about when touchedness is reverted during state clearance").

So, in short:
In collect_touched_accounts(), we now have to also check when a computation touches RIPEMD160, succeeds itself, but the parent (or someone along the call ladder) fails, and the failee is not necessarily the origin computation.
I can't figure out how to do this without a double-pass through the nested computations, or ugly hacks - not today, at least, and got to run anyway.

RevertPrecompiledTouchExactOOG still fail - investigating.

The test cases
RevertPrecompiledTouchExactOOG.json:RevertPrecompiledTouchExactOOG_d7g2v0_Istanbul
RevertPrecompiledTouchExactOOG.json:RevertPrecompiledTouchExactOOG_d31g2v0_Istanbul

get insufficient (69K) gas is provided, and should OOG-fail according to upstream.
The precompile called, 0x08, should remain as-is, whereas if 120K gas is provided, its storage should be cleared (highlighted in same link).
This seems consistent to me.
The call that OOG-fails is nested, as shown in the trace from py-evm. On exit from that, remaining gas is enough to finish the parent and grand-parent computations.
py-evm then proceeds to clear 0x08's, which seems incorrect.

Slowest tests: https://gist.github.com/veox/02336c518f049cb749608657622d127f

Closing since PR #1858 was superseded by PR #1871 and addressed this; the issue was left hanging.

JIC, I was reminded of this because a discussion arose recently on gitter of geth (!) failing to produce an expected result for @adria0, for case RevertPrecompiledTouchExactOOG_d30g2v0_Istanbul in particular.
That said, I don't remember if py-evm had issues with the d30g2v0 variant... The sherlocking is now split across several issues/PRs pertaining to different network upgrades, and tests filled by two different implementations.
So, just dropping this here for future archeologists.
Pinging @holiman, too, as participant in gitter discussion.

@veox, finally I found the way to fix it https://github.com/openethereum/openethereum/pull/11597/commits/74eabccda5b286bfc68138dc65b5b4dcd5c2ce3e.
In short, this test has a preexistent 0000...0008 in the account trie with zero gas. The test makes a  call/staticcall to this address, so since this empty account is touched, the account should be removed from the trie. But, the call does not have enough gas to call the precompile, so it reverts, and as EIP161 says that empty account deletions are reverted when the state is reverted.
OE was not "reverting the deletions", so there was a problem in the state trie root.
Take care, with the current gas parameters defined in the RevertPrecompiledTouchExactOOG.json, some of the tests do not OOG (needs to be fixed) and this cause some confusion when debugging the test cases.

But, the call does not have enough gas to call the precompile, so it reverts, and as EIP161 says that empty account deletions are reverted when the state is reverted.

... Except if it's pre-compile number 3, in which case the deletion should be left as-is, including in cases when the parent computation eventually fails anyway, whether it's the origin computation or not; unless the test-filling implementation changes, as this github issue has shown, then do as Simon says, and don't be the last one to find a chair...
Toodly-doo!.. :saxophone:
In all seriousness: always mention the exception.

This is all OT to the issue(s) you've found; still!
<rant>
A "proper" way to address the above would be† to have an irregular state transition (IST) to "right" this previous "accidental" IST that we let slip through, because it was a secondary failure in an already debilitating net-wide consensus failure.
The common reasoning against such "right the wrong" ISTs is "the tech debt only increases with that"; to which I can only reply that the cognitive debt keeps piling on, with each new node implementation, with each new developer who is about to find out the hard way. :exploding_head:
Doesn't matter if you start from a snapshot, doesn't matter if you're running a testnet. I swear, we'll take this RIPEMD160 ghost to Eth 2.0 with us, as an annoying weird uncle to Casper. :smile:
Perhaps I should write an EIP for that, if only for it to be filed as a formal complaint. Maybe next March 32nd, instead of dealing with integer overflows...
† Or "would have been", I gather, considering this is years-old.
</rant>

... Except if it's pre-compile number 0x3, in which case the deletion should be left as-is, including in cases when the parent computation eventually fails anyway, whether it's the origin computation or not; unless the test-filling implementation changes, as this github issue has shown, then do as Simon says, and don't be the last to find a chair, because it's not there!..

Haha, it has been an interesting issue to fix, to be the first one :sweat_smile:
I agree with you that this TriePrunning/0x3 specific issue maybe is one of the cases that deserve an IST, because it happens that the embedded logic to fix this irregular stuff is also deployed to other blockchains, not only mainnet. I put on the agenda to ping you on next March 32 (with integer overflows :stuck_out_tongue_winking_eye:), hehe.


Introduce separate source files for SSL messaging layer and TLS 1.2 handshake logic

Summary: The goal of this PR is to modify the file structure of the SSL/TLS module in preparation for future changes in both the messaging layer (MPS) and the handshake logic ([D]TLS 1.3):

A new file ssl_msg.c is introduced which contains the current messaging layer implementation (that is, the record layer and retransmission state machine). This implementation was previously part of ssl_tls.c, alongside the implementation of the public SSL API and shared client/server handshake logic functionality.
Three files ssl_12_gen.c, ssl_12_cli.c and ssl_12_srv.c are introduced which hold handshake reading/writing functions specific to TLS versions <= 1.2 (which is in fact all - for now).

It is the intention of this PR to solely move code but not modify it (except from linkage and private vs [internal] public namespace changes). The hope is that this way it can be integrated quickly, thereby providing a base for future integration of ongoing work on the new messaging layer and the TLS 1.3 prototype. In a nutshell, the new messaging layer should mostly replace ssl_msg.c, while the TLS 1.3 prototype will be introduced as ssl_13_{gen|cli|srv}.c.
Currently, not every function can be clearly attributed to either the messaging or the logic layer, and code adaptation might be needed to improve this. However, this is left for future PRs in order to keep the changes in this PR non-functional.
Note: It is strongly recommended to review the commits performing the code shuffling through git diff --color-moved=dimmed-zebra which will auto-detect and dim lines that have been moved.
CC @hannestschofenig

@gilles-peskine-arm Thanks for your review, I believe to have addressed your comments.
As for the reviewing, please consider reviewing the cumulative effect of commits 1-3 (from development to 2259887) and 5-7 (from bef2d91 to b769db8) through git diff --color-moved. Except from a few place where git doesn't detect the moving, this will either make it apparent that code has solely been moved or whether I have slipped somewhere.

One DTLS test case (https://jenkins-internal.mbed.com/job/mbedtls-pr-multibranch/job/PR-3010-head/8/execution/node/2593/log/) failed on HEAD but passed on MERGE, passed on other configurations and passes locally. This looks like an intermittent DTLS failure (probably (internal link) https://confluence.arm.com/display/IoTBU/Mbed+TLS+tests#MbedTLStests-DLTStestsconnectionoverbleed), unrelated to this PR.

@mpg @gilles-peskine-arm @yanesca
The following diff commands seems useful for review:

git diff --histogram --color-moved=dimmed-zebra 36ce88be1edcc9b561bab72b0fd69f6f09b92a1e<PHONE_NUMBER>8b0534cf3ddf89ff57d094affb15b0 (first bunch of commits splitting ssl_tls.c into ssl_tls.c and ssl_msg.c)
git diff --histogram --color-moved=dimmed-zebra bef2d91478ff1103014f632e2c7d80ec9e17b2e2 b769db8c6628ece4feb6fe5b8b1edffa2b178e5b (second bunch of commits splitting ssl_{tls|cli|srv}.c into ssl_12_{gen|sr|cli}.c and ssl_{tls|cli|srv}.c.

@gilles-peskine-arm Regarding your plan to ensure that each commit builds, which I like (both the goal and the general plan), it seems to me that steps 5 and 6 need to happen in the same commit. Do you agree? (Btw, steps 3 and 4 could also happen in the same commit without impacting reviewability or buildability I think.)

Steps 3 and 4 can happen together, but they're independent so I think they belong in separate commits. Step 5 can be multiple commits. Step 6 can be dissolved into step 5 if it makes more sense.

@gilles-peskine-arm @mpg I have rebased the PR and applied the commit structure that @gilles-peskine-arm recommended. However, I restricted it to the splitting of ssl_tls.c into ssl_tls.c and ssl_msg.c, because I stumbled over points in the further splits about which I wasn't sure on second thought. I'd therefore prefer to prepare the splitting of the remaining ssl_tls.c into TLS-<=1.2-specific functions and generic functions (init/free, save/load, config, ...) in a separate PR.

The CI found a build failure when SSLv3 is enabled (but is otherwise happy):
/var/lib/build/library/ssl_msg.c: In function 'mbedtls_ssl_encrypt_buf':
/var/lib/build/library/ssl_msg.c:576:31: error: 'SSL_MAC_MAX_BYTES' undeclared (first use in this function)
             unsigned char mac[SSL_MAC_MAX_BYTES];
                               ^
/var/lib/build/library/ssl_msg.c:576:31: note: each undeclared identifier is reported only once for each function it appears in
/var/lib/build/library/ssl_msg.c:577:13: error: implicit declaration of function 'ssl_mac' [-Werror=implicit-function-declaration]
             ssl_mac( &transform->md_ctx_enc, transform->mac_enc,
             ^
/var/lib/build/library/ssl_msg.c:576:27: error: unused variable 'mac' [-Werror=unused-variable]
             unsigned char mac[SSL_MAC_MAX_BYTES];
                           ^
/var/lib/build/library/ssl_tls.c:1951:13: error: 'ssl_mac' defined but not used [-Werror=unused-function]
 static void ssl_mac( mbedtls_md_context_t *md_ctx,
             ^

The fact that ssl_mac is seen both as used but not declared and defined but not used probably means it's not defined in the right place. Then it's unclear to me if the issues with SSL_MAC_MAX_BYTES and mac unused are related or not.

@gilles-peskine-arm Do you mind addressing the dependencies in subsequent work? After all, one reason why we're reworking the messaging layer is precisely because there are two many interrelations between what should be logically separate.

The dependencies are not a blocker, but I'd like to know why you split in a way that has mutual dependencies.
Splits are somewhat disruptive. If we break up the TLS code iteratively, I'd prefer to isolate a few functions that belong together, create a file for them, and then not move them again: subsequent split should address other functions. I'd prefer that to creating a categories, then subdividing each category again and so on.

@gilles-peskine-arm I suspect completely removing cyclic dependencies may require non-trivial work, in any case work that goes beyond moving functions around to new files. That's because the protocol itself is not quite as cleanly layered as we'd like.
Take for example support for DTLS clients reconnecting from the same port: at least information needs to be passed both ways between upper (handshake logic) and lower (message handling) layers, since the lower layer needs to ask the upper layer whether this looks like a valid ClientHello with a valid cookie, and to send a HelloVerifyRequest if it's a ClientHello without a valid cookie (and quite obviously the upper layer depends on the lower layer to do that).
Currently this dialog happens by directly calling function of the upper layer from the lower layer, creating a circular dependency. It's probably possible to do it another way (eg the lower layer could return a special error code meaning "can you check this for me, send a HVR if necessary, and call me back when you're done?") but that would be a non-trivial change to a not-entirely trivial feature that's easy to get wrong and hard to fully test (actually I believe the current implementation might have bugs not quite caught by our tests).
So I think I'd also prefer leaving the dependencies for later.

Ok for keeping mutual references this time. Please take this into consideration in further splits.
I'll approve if you fix the preprocessor guards in ssl_internal.h.

@gilles-peskine-arm Done.
@gilles-peskine-arm @mpg Could you please re-review?


Hello I am unable to provide customInput MUI TextField

I am trying to render customInput, What I have so far is:
type IProps = {
  name: string;
  rules?: RegisterOptions;
  defaultValue?: string;
};

type Props = IProps & TextFieldProps;

export default function RHFCurrencyField({ name, rules, defaultValue, ...other }: Props) {
  const { control } = useFormContext();

  return (
    <Controller
      name={name}
      rules={rules}
      control={control}
      render={({ field, fieldState: { error } }) => (
        <CurrencyInput
          name={name}
          groupSeparator=" "
          defaultValue={defaultValue}
          decimalsLimit={2}
          onValueChange={(value, name) => {
            field.onChange(value);
          }}
          customInput={() => <CurrencyTextField {...other} {...field } />}
        />
      )}
    />
  );
}

export const CurrencyTextField = React.forwardRef((props: Props, ref: any) => {
  return <TextField {...props} ref={ref} />;
});

And I am getting a warning, and input i
react-dom.development.js:67 Warning: Function components cannot be given refs. Attempts to access this ref will fail. Did you mean to use React.forwardRef()?
Check the render method of CurrencyInput.

can you solve this? I have the same problem.

@WingsDevelopment @italosantana Howdy, I was having a similar issue with the same fix you had:
const CustomInput = React.forwardRef((props, ref: React.Ref<HTMLInputElement>) => <EuiFieldText {...props} inputRef={ref} />)
but I just passed it into customInput I didn't wrap it around another function and that warning goes away


Merge pull request #1444 from bgoonz/preview

Skip to content
Search or jump to…
Pull requests
Issues
Marketplace
Explore
@bgoonz
bgoonz
/
BGOONZ_BLOG_2.0
Code
Issues
6
Pull requests
1
Discussions
Actions
Projects
1
Wiki
64
Settings
Releases
2
More
Merge pull request #1444 from bgoonz/preview #1445
Open
preview  master
+0 −0
Conversation 0
Commits 1
Checks 26
Files changed 0
Conversation
@bgoonz
Owner
bgoonz now
No description provided.
@bgoonz
Merge pull request #1444 from bgoonz/preview
ba7e16e
Merge state
Add more commits by pushing to the master branch on bgoonz/BGOONZ_BLOG_2.0.
This branch is being deployed
1 in progress deployment
github-pages
— ba7e16e9 Deployed 12 seconds ago by github-pages[bot] via deploy #138
2 in progress, 23 successful, 2 failing, 1 pending, and 1 neutral checks
@github-actions
Tests: release process / release (push) In progress — This check has started...
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (11) (push) Successful in 24s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (10) (push) Successful in 46s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (9) (push) Successful in 19s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (9.2) (push) Successful in 23s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (9.1) (push) Successful in 24s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (9.0) (push) Successful in 18s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (8) (push) Successful in 19s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (7) (push) Successful in 19s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (6) (push) Successful in 18s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (6.1) (push) Successful in 19s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (5) (push) Successful in 21s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (5.9) (push) Successful in 28s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (4) (push) Successful in 28s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (4.6) (push) Successful in 23s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (4.5) (push) Successful in 27s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (4.4) (push) Successful in 23s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (3) (push) Successful in 25s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (2) (push) Successful in 24s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (1) (push) Successful in 25s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (0.12) (push) Successful in 28s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (0.10) (push) Successful in 25s
Details
@github-actions
Tests: nvm install-latest-npm / nvm install-latest-npm (push) Successful in 1s
Details
@google-cloud-build
Build<PHONE_NUMBER>98) — Summary
Details
@deadpendency
Deadpendency Check Failing after 8s — Deadpendency Check Result
Details
@lgtm-com
LGTM analysis: JavaScript In progress — Starting up
Details
docs/readthedocs.org:bgoonzblog2 Pending — Read the Docs build is in progress!
Details
@github-code-scanning
Code scanning results / CodeQL — No analyses found
Details
@commitcheck-app
CommitCheck — All commit messages are valid!
Details
This branch has no conflicts with the base branch
or view .
@bgoonz
Leave a comment
Remember, contributions to this repository should follow its contributing guidelines and code of conduct.
ProTip! Add comments to specific lines under Files changed.
Reviewers –
Still in progress?
Assignees –
Labels
Projects
Milestone
Linked issues
Notifications
Customize
You’re receiving notifications because you’re watching this repository.
1 participant
@bgoonz
© 2022 GitHub, Inc.
Terms
Privacy
Security
Status
Docs
Contact GitHub
Pricing
API
Training
Blog
About


Documentation: Question about expected return

Hi,
going through the RL Intro I stumbled something that is not yet clear to me. On https://spinningup.openai.com/en/latest/spinningup/rl_intro.html#the-rl-problem
for the expected return it says
.. math:: J(\pi) = \int_{\tau} P(\tau|\pi) R(\tau) = \underE{\tau\sim \pi}{R(\tau)}
where I would have expected
.. math:: J(\pi) = \int_{\tau} P(\tau|\pi) R(\tau) = \underE{\tau\sim P}{R(\tau)}
My understanding is that \tau is a RV distributed with respect to P, and only the actions are taken from \pi, as later clearly differentiated on https://spinningup.openai.com/en/latest/spinningup/rl_intro.html#bellman-equations
Please, can someone explain me why it says \tau\sim \pi?
Thank you very much in advance!

Hi, @aflgit. I'll try to explain how I understand this:

P does determine the next state of the environment (based on previous state and the action taken), therefore you have P(s_t+1 | s_t, a_t).
However, the expression you highlight reflects the expected outcome of a trajectory by an agent that follows a given policy pi, i.e. sampling from it. The fact that the trajectory is indeed affected by other factors like P is simply implicit in the expression.

Hope it helps.
Alberto


allocateDASD recommended value 0

The recommended value for check <IP_ADDRESS> is "Administrators" which is 0 not 2

Windows Server only recommends only Adminitrators

Oops, sorry my bad - you're right


InjectionResults returning ValueKind instead of Content Script return value

Thank you so much for providing this package -- it is really very helpful!
I am trying to get the results from a query of the DOM using a Content Script and I am only getting the following back in my Injection Results:
{
    "ValueKind": 1
}

I have created a simple test to narrow down the issue so that I can resolve it and the JS Content Script I am using below just logs a simple object to the Target and return the object:
(async () => {
    const obj = { text: "TEST" };
    console.debug(obj);
    return obj;
})();

The C# Injection is below and I am expecting to get the JSON object above, but all I get is { "ValueKind": 1 } as a result:
ScriptInjection injection = new ScriptInjection();
var target = new InjectionTarget();
IEnumerable<string> files = new List<string>();

files = files.Concat(new[] { "js/info/get-info.js" });
target.TabId = _tabId;

injection.Files = files;
injection.Target = target;

var injectionResults = await WebExtensions.Scripting.ExecuteScript(injection);
Log.Debug("injectionResults: {@injectionResults}", injectionResults);
var first = injectionResults.FirstOrDefault();
Log.Debug("first: {@first}", first);
var result = first?.Result;
Log.Debug("result: {@result}", result);

Below is screenshot of the browser console on the Extension that is logging the results of the injection:

And also below is a screenshot of the Target browser tab that the Content Script is being run on:

From the above it seems like the Content Script is running successfully, but the Injection Result is not being deserialized properly when it is received.
Is there something additional required to get the return result of the Content Script?

What you get back in return is most likely a JsonElement, which you can use to access the properties of dynamic objects with the indexer or you can deserialize it into a proper class that matches the data of the object returned.

@mingyaulee thank you, I was able to get the return result of the Content Script using the following code:
// deserialize result json to array of string

var resultStringArray = JsonConvert.DeserializeObject<string[]>(result.ToString())!;

Log.Debug("resultStringArray: {@resultStringArray}", resultStringArray);


9.2.1 release

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

Update of 9.2.0 with autoconf fixes so we do not need fortran compiler.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I can't see where we add a dependency on libyaml.


Documentation: RedisOpsRequest

In the upgrading documentation, the Before you begin section tells you need to be familiar with the RedisOpsRequest. A link is provided.
Behavior
Expected behavior
Clicking on RedisOpsRequest redirects to an explanation of the RedisOpsRequest concept.
Actual behavior
Clicking on RedisOpsRequest redirects to an empty documentation.
The empty documentations has the following header:

You are looking at the documentation of a prior release. To read the documentation of the latest release, please visit here.

But clicking on here redirects to the exact same page.
Questions

Is RedisOpsRequest still needed (or does it still exist)? The Concepts section of the documentation does not mention it.
Is the upgrading documentation up to date?

Hi @sambonbonne,
Yes, RedisOpsRequest is still needed for upgrading to another version. The documentation of the concepts is not updated. We'll try to update it soon.
For now, you can follow the Standalone or Cluster upgrading guides, those are up to date. Those guides have all the information necessary for upgrading.
ref:
https://kubedb.com/docs/v2021.06.23/guides/redis/upgrading/standalone/
https://kubedb.com/docs/v2021.06.23/guides/redis/upgrading/cluster/
Let me know if you need any more information.
Thank you!

Thanks for this answer.
Both links are telling:

This is an Enterprise-only feature. Please install KubeDB Enterprise Edition to try this feature.

Is this the same upgrade path for community edition?

1+ year later and this documentation page still doesn't exist. It is also referred from the Horizontal Scaling and Vertical Scaling pages. It is not possible to comprehend how to do scaling without a proper reference for RedisOpsRequest.

Redis ops request is an area under active development / improvement. For now, you can see the available fields
https://github.com/kubedb/apimachinery/blob/master/apis/ops/v1alpha1/redis_ops_types.go#L104
I understand that Go type definition is not a replacement for proper docs. Docs will be worked on soon.


Go get doesn't work

What version of Go are you using (go version)?

$ go version
go version go1.16 linux/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build472802718=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.16 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.16
uname -sr: Linux 5.11.1-artix1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.33.
gdb --version: GNU gdb (GDB) 10.1

What did you do?
i imported mongodb drivers with:
import (
	"context"
	"log"
	"time"
	"go.mongodb.org/mongo-driver/bson"
	"go.mongodb.org/mongo-driver/mongo"
	"go.mongodb.org/mongo-driver/mongo/options"
	"go.mongodb.org/mongo-driver/mongo/readpref"

	"../models"
)

and go get -u go.mongodb.org/mongo-driver/mongo

What did you expect to see?
Working code and go.mongodb.org directory in $GO_PATH/src/
What did you see instead?
database/database.go:8:2: cannot find package
database/database.go:9:2: cannot find package
database/database.go:10:2: cannot find package
database/database.go:11:2: cannot find package

and only 2 folders in $GO_PATH (i did reinstall)

please refer to the release notes: https://golang.org/doc/go1.16#go-command


Support for documentation reference

The json schema support to provide a documentation reference using documentationRef. It would be great if we could add this to the existing Template annotation.
If possible I would like to contribute on this.
Kind regards
Alexander Skrock

Can you give an example how this "documentationRef" should be used in detail in context of an element template?

According to the documentation it can be any url (see Defining Templates). At my company we use this field to have a shortcut in the Camunda Modeler to jump to our confluence page.
Kind regards
Alexander Skrock


Update users.rst

Add hollerith, for #47

It's nice that support Python 3.8 is as a simple as copy pythoncapi_compat.h and add 1 line of code:
#include "pythoncapi_compat.h"

Merged. I'm glad that more projects are using it :-)


refactor rust library logging

currently all logs in the rust library are performed at the info level.
several logs could be too verbose so we should use different logging levels.
I propose to use debug logs to show the received requests in their entirety and to use info to just show that a request has been received (without printing the request params).

Approach I use in RGB Node and LNP Node:

All large objects can be print only with trace! and never with debug/info!
There must be only a single info per operation'; today it is done already in methods inside RGB Node (for things like consignment acceptance etc)
All the rest is debug!


Remove redundant commands from travis file

In an effort to speed up the travis ci build:

installation of node/npm is done based on node_js
npm ci is the default npm installation command
truffle compilation is done automatically

Roughly 30 seconds faster 😐


Use uv for project management

We should probably upgrade from setup.py to pyproject.toml.
I've been using uv to manage all my Python projects recently and I like it much more than poetry.
I will put together a PR to migrate to using uv, including refactoring some folders and CI scripts.

Same, just note that uv resolves differently than pip, which might sometimes be a problem (see ).


regenerate apis

Sorry, just got around to regenerating them. We need an automated way to do this :)


[SymbolGraphGen] don't use Clang modules in the "only re-export public symbols" check

Resolves rdar://110399757
When symbols are checked for being "effectively private", there is a check to ensure that only public symbols from @_exported import modules are re-exported (to prevent internal symbols from the other module from appearing in the host module's symbol graph). However, this can mess up the "minimum access level" calculation when an underlying Clang module is present: Because there is an implicit @_exported import for the underlying Clang module, internal symbols in the Swift module are considered to be "re-exported" for the purposes of this check. This voids the previous "minimum access level" check, because in this case an internal symbol was meant to be considered for inclusion in the symbol graph!
This PR updates the "is this module export-imported" calculation by optionally forcing modules to be emitted from the same compiler, and then using this option in the above-mentioned calculation. This allows [-symbol-graph]-minimum-access-level to be used when there is also Clang code being built alongside the Swift module.

@swift-ci Please smoke test


Undefined symbols for architecture x86_64 with ImmutableMappable struct

Your model:
struct FeedItemEnvelope: ImmutableMappable {
  let title: String
  let headline: String?

    public init(map: Map) throws {
        title = try map.value("title")
        headline = try? map.value("headline")
    }

    public mutating func mapping(map: Map) {
        // TODO
    }
}

What you did:
class FeedItemEnvelopeSpec: QuickSpec {
    override func spec() {
        describe("mapping from JSON") {
            it ("works fine") {
                let myJSON: [String: Any] = [
                    "title": "My Title",
                    "headline": "My Headline"
                ]

                do {
                    let feedItemEnvelope = try FeedItemEnvelope(JSON: myJSON)
                    expect(feedItemEnvelope).notTo(beNil())
                } catch {
                    fail("Conversion from JSON to object failed.")
                }
            }
        }
    }
}

(using version 2.2.7)
What you got:
Undefined symbols for architecture x86_64:
  "__TIFE12ObjectMapperPS_17ImmutableMappablecFzT4JSONGVs10DictionarySSP__7contextGSqPS_10MapContext___xA0_", referenced from:
      __TFFFC12TripperTests20FeedItemEnvelopeSpec4specFT_T_U_FT_T_U_FT_T_ in FeedItemEnvelopeSpec.o
  "__TFE12ObjectMapperPS_17ImmutableMappableCfzT4JSONGVs10DictionarySSP__7contextGSqPS_10MapContext___x", referenced from:
      __TFFFC12TripperTests20FeedItemEnvelopeSpec4specFT_T_U_FT_T_U_FT_T_ in FeedItemEnvelopeSpec.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I just updated my model to make it Mappable instead of ImmutableMappable and I get a similar error:
Undefined symbols for architecture x86_64:
  "__TIFE12ObjectMapperPS_12BaseMappablecFT4JSONGVs10DictionarySSP__7contextGSqPS_10MapContext___GSqx_A0_", referenced from:
      __TFFFC12TripperTests20FeedItemEnvelopeSpec4specFT_T_U_FT_T_U_FT_T_ in FeedItemEnvelopeSpec.o
  "__TFE12ObjectMapperPS_12BaseMappableCfT4JSONGVs10DictionarySSP__7contextGSqPS_10MapContext___GSqx_", referenced from:
      __TFFFC12TripperTests20FeedItemEnvelopeSpec4specFT_T_U_FT_T_U_FT_T_ in FeedItemEnvelopeSpec.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

How did you install ObjectMapper?

Via Cocoapods.

I got same error:
Undefined symbols for architecture x86_64:
"__TIFE12ObjectMapperPS_12BaseMappablecFT4JSONGVs10DictionarySSP__7contextGSqPS_10MapContext___GSqx_A0_", referenced from:
    __TFC18CampeonatoBrzTests11ServiceMock8getGamesfT3urlSS9completedFGSaC13CampeonatoBrz9GameModel_T__T_ in CampeonatoBrzPresenterTest.o
    __TFC18CampeonatoBrzTests11ServiceMock8getTeamsfT3urlSS9completedFGSaC13CampeonatoBrz9TeamModel_T__T_ in CampeonatoBrzPresenterTest.o
"__TFE12ObjectMapperPS_12BaseMappableCfT4JSONGVs10DictionarySSP__7contextGSqPS_10MapContext___GSqx_", referenced from:
    __TFC18CampeonatoBrzTests11ServiceMock8getGamesfT3urlSS9completedFGSaC13CampeonatoBrz9GameModel_T__T_ in CampeonatoBrzPresenterTest.o
    __TFC18CampeonatoBrzTests11ServiceMock8getTeamsfT3urlSS9completedFGSaC13CampeonatoBrz9TeamModel_T__T_ in CampeonatoBrzPresenterTest.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@dirtyhenry  Hi,  I got the same issue,  have you solved it ?

@tomtcl Unfortunately this was more than a year ago and I don't have the code base at my disposal anymore. Sorry.


🐞[bug]:  hover color change due to  user visibility ,

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
when we hover  arrow up icons . the icons not look for user

on hover the element is hide

Expected behavior
i want when user hover these arrow element we feels like we get some response from it
Add ScreenShots
No response
What browsers are you seeing the problem on?
No response
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24EXTD contributor
[X] I have starred the repository

It is not needed currently.

Hi [@Anjaliavv51 ],
Thank you for your feedback. I understand that the hover color change is not needed at the moment.
If there's any future work or updates required, please feel free to assign them to me. I'd be happy to assist!
Best regards,
Anish


End-to-end automation test for reindexing

We released 4.5.0 without catching a reindex bug that prevented the correct migration of data:  https://github.com/IBM/FHIR/issues/1742
To prevent that from happening again, we should include a test in our CI pipeline which does the following:

writes a resource / some set of resources (maybe the Basic ones used in our persistence search tests?)
changes the configured set of search parameters (maybe add the corresponding extension-search-parameters for the search tests?)
invoke reindex (as needed until everything is refreshed)
performs a search / set of searches to verify the data is returned as expected

For even greater assurance, we could extend the existing db migration test to do the following:

deploy an older version of the schema
write a resource / some set of resources (maybe the Basic ones used in our persistence search tests?)
apply the schema migration
(optional) adjust the search parameters slightly
invoke reindex
perform a search to verify the expected resources are still returned

UPDATE:  we probably don't need to tie the re-index test to the migration test.  Having them as two separate tests should be sufficient.

Does https://github.com/IBM/FHIR/pull/2107/files sufficiently cover this one?

Does https://github.com/IBM/FHIR/pull/2107/files sufficiently cover this one?

Currently, it's just a sniff test.  Does it work with one resource.
If you are OK, we can rock with one sniff test (across derby, postgres, db2) or we can add a small loop of say one hundred.
Also, to be a true test, we would create a set of search parameter, search find the resource by search parameters related to the types, and then change the search parameters (not type) to a new FHIR Path, and show they are not retrievable by the search parameter.

OK, thanks Paul.  Lets leave this one open then for the testing improvements you mention.

Tests are part of the integration tests that run as part of the build now. closing issue


[2pt] PR: docker file for OWP, non root user

For security reasons, we needed to create a docker image that does not use the root user in anyway. This can only be used on OWP servers at this time.
Additions

owp.Dockerfile: as described

Testing

see Rob for details on how to test.

Deployment Plan (For developer use)
How does the changes affect the product?

[ ] Code only?
[x] If applicable, has a deployment plan be created with the deployment person/team?
[ ] Require new or adjusted data inputs? Does it have start, end and duration code (in UTC)?
[ ] If new or updated data sets, has the FIM code been updated and tested with the new/adjusted data (subset is fine, but must be a subset of the new data)?
[ ] Require new pre-clip set?
[x] - sort off. new dockerfile.  Has new or updated python packages?

Issuer Checklist (For developer use)
You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.

[ ] Informative and human-readable title, using the format: [_pt] PR: <description>
[ ] Links are provided if this PR resolves an issue, or depends on another other PR
[ ] If submitting a PR to the dev branch (the default branch), you have a descriptive Feature Branch name using the format: dev-<description-of-change> (e.g. dev-revise-levee-masking)
[ ] Changes are limited to a single goal (no scope creep)
[ ] The feature branch you're submitting as a PR is up to date (merged) with the latest dev branch
[ ] pre-commit hooks were run locally
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged / future todos are captured in comments
[ ] CHANGELOG updated with template version number, e.g. 4.x.x.x
[ ] Add yourself as an assignee in the PR  as well as the FIM Technical Lead

Merge Checklist (For Technical Lead use only)

[ ] Update CHANGELOG with latest version number and merge date
[ ] Update the Citation.cff file to reflect the latest version number in the CHANGELOG
[ ] If applicable, update README with major alterations

I got an error running fim_pipeline.sh. Merging with dev (v<IP_ADDRESS>) should fix this error.
Create list file of branch ids for 03100204
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexes/base.py", line 3652, in get_loc
    return self._engine.get_loc(casted_key)
  File "pandas/_libs/index.pyx", line 147, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 176, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7080, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7088, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'levpa_id'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/foss_fim/src/generate_branch_list.py", line 51, in <module>
    generate_branch_list(**args)
  File "/foss_fim/src/generate_branch_list.py", line 32, in generate_branch_list
    stream_network_dissolved = stream_network_dissolved.loc[:, branch_id_attribute]
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexing.py", line 1097, in __getitem__
    return self._getitem_tuple(key)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexing.py", line 1280, in _getitem_tuple
    return self._getitem_lowerdim(tup)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexing.py", line 1000, in _getitem_lowerdim
    section = self._getitem_axis(key, axis=i)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexing.py", line 1343, in _getitem_axis
    return self._get_label(key, axis=axis)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexing.py", line 1293, in _get_label
    return self.obj.xs(label, axis=axis)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/generic.py", line 4082, in xs
    return self[key]
  File "/usr/local/lib/python3.10/dist-packages/geopandas/geodataframe.py", line 1750, in __getitem__
    result = super().__getitem__(key)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/frame.py", line 3761, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/usr/local/lib/python3.10/dist-packages/pandas/core/indexes/base.py", line 3654, in get_loc
    raise KeyError(key) from err
KeyError: 'levpa_id'
Command exited with non-zero status 1
	Command being timed: "/foss_fim/src/run_unit_wb.sh"
	User time (seconds): 11.25
	System time (seconds): 5.85
	Percent of CPU this job got: 247%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:06.90
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 272148
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 107405
	Voluntary context switches: 929
	Involuntary context switches: 15738
	Swaps: 0
	File system inputs: 127496
	File system outputs: 133096
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 1

***** An error has occured  *****


Test WAL encryption with different options

We have to test WAL handling and replication with encrypted WAAL and different WAL settings if changing the parameters doesn't cause some issues. For example changing wal_buffers GUC, --wal-segsize initdb option and --with-wal-blocksize configure option (see https://www.postgresql.org/docs/current/wal-internals.html)

Will be tracked here https://perconadev.atlassian.net/browse/PG-840


hasp_Display_Text.yaml fails on import

Discussed in https://github.com/HASwitchPlate/HASPone/discussions/186

Originally posted by robellis-zz May  5, 2022
When i try to import the hasp_Display_Text.yaml blueprint i get an 'unknown error' is there a different way to import or can i copy and paste it into HA?

The scope of this is much wider than this one blueprint, issue seems to have cropped up in 2022.05 and impacts anything using a slider-type number select.

@robellis-zz Question for you - what version of Home Assistant are you currently running where you are seeing this import error?  2022.05 or some older version?

Apparently this is a bug in 2022.05: https://github.com/home-assistant/core/issues/71396

Makes sense. I am running 2022.5.1 right now

Looks like a fix has been merged, so we should see resolution in the .2 point release.

Allright, the 2022.5.2 release has fixed the issue reported above.  However, there are reports of other problems that are related.  I don't think the remaining issues should impact anything we're doing with the HASPone blueprints, but I'm going to leave this open until I see that those additional problems have been patched just to make sure.

Looks like we should be all set, the release version of  HA (2022.05.2) fixes all HASPone related issues and a patch is on the way for the rest of the issues (which don't impact HASPone).  Closing this issue, I think we should be set!
Thanks again to @robellis-zz for the report and helping troubleshoot.


No training data provided

I found the link to download the test data. But training data is not provided. Does that mean I should download the Imagenet dataset and use the 'symlink_to_data.py' to create the training data?
Thanks.

Yes.

Here is the training set
https://drive.google.com/file/d/1B5c39Fc3haOPzlehzmpTLz6xLtGyKEy4/view?usp=sharing


Update cluster storage modal

https://issues.redhat.com/browse/RHOAIENG-1098
Description
Refer the mock the design
https://github.com/user-attachments/assets/9ea3acfa-225d-43aa-9e18-e6b6fb982024

How Has This Been Tested?
Refer mocks to cover all the checks

Create a cluster storage and attach the existing workbench
Check for default mount path
Verify the validation path ( We are now allowing numbers)
create the cluster storage and check if the mountpath is correctly updated to workbench
Edit  the existing cluster and check and change the workbench

Test Impact
Added cypress test

Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

cc @xianli123 , I have updated the description with required screenshot
when custom path is empty, Currently I have displayed this error, let me know your thoughts around here

There is an edge case where the newly added mount path will be reset to default. Here is the step to reproduce:

Edit storage A which already has a workbench connection
Add workbench connection and edit the mount path
Click minus icon to remove the existing connection
See the newly added connection mount path is set to default, user will lose the edited value in this case

Thanks @pnaik1.
I want to confirm how to trigger the popover as you shared (I attached it below). Does the 'View connection paths' trigger the popover?
A small enhancement: The bottom border of the row is missing. It will LGTM, once the border is added.

@xianli123 Thanks for the review, the popover will trigger when clicked on View connected paths , I have added the border in the latest changes
https://github.com/user-attachments/assets/1d905418-68c3-4a9e-9f66-28d08cf871b5

@pnaik1 Thanks for doing it! LGTM!

wide screens have dropdown show over the modal

there should be a slash in front of the custom ones

root standard storage path doesn't get a checkmark

Updated the PR accordingly

This all looks good. just need to still fix the modal overflow issue: https://github.com/opendatahub-io/odh-dashboard/pull/3529#issuecomment-2515714000

@pnaik1 Can you rebase the PR please? Want to see how it looks like on PF6

Left some comments based on my testing. I am not a fan of the way to save id in the table column and hide it just in order to auto-generate the name, there should be a better way to save and use this information. 🤔 WDYT? @Gkrumbach07

we should be autogenerating the name when we create it and not in the row

@DaoDaoNoCode @Gkrumbach07 Thanks I have updated the pr accordingly
I have a question around this,
Since the rows are dynamic and are editable, there is a required for unique stable column, removing this it aligns the row based on name  which disturbs the flow
I see same think done here: https://github.com/opendatahub-io/odh-dashboard/blob/main/frontend/src/pages/projects/screens/spawner/storage/constants.ts#L6-L11

Left some comments based on my testing. I am not a fan of the way to save id in the table column and hide it just in order to auto-generate the name, there should be a better way to save and use this information. 🤔 WDYT? @Gkrumbach07

we should be autogenerating the name when we create it and not in the row

@DaoDaoNoCode , I have updated the SpawnPage cluster storage table

There seems to be a rendering issue. you have some infinite render loop when you add a new row to the table


2019 standards update

Pull requests into cqm-execution require the following. Submitter and reviewer should :white_check_mark: when done. For items that are not-applicable, note it's not-applicable ("N/A") and :white_check_mark:.
Submitter:

[ ] This pull request describes why these changes were made.
[ ] Internal ticket for this PR:
[ ] Internal ticket links to this PR
[ ] Code diff has been done and been reviewed
[ ] Tests are included and test edge cases
[ ] Tests have been run locally and pass

Reviewer 1:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Codecov Report

Merging #71 into master will decrease coverage by 0.54%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
- Coverage   87.65%   87.11%   -0.55%
==========================================
  Files           6        6
  Lines         705      706       +1
  Branches      212      212
==========================================
- Hits          618      615       -3
- Misses         87       91       +4

Impacted Files
Coverage Δ

lib/models/calculator.js
94.56% <100%> (+0.05%)
:arrow_up:

lib/helpers/calculator_helpers.js
85.32% <100%> (-1.09%)
:arrow_down:

lib/helpers/results_helpers.js
96.52% <0%> (-0.7%)
:arrow_down:

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 e3a3a4b...546b40f. Read the comment docs.


Why training autoencoder architecture different from inference?

Hi, during training using the ipynb file we have a autoencoder architecture which differs from what we have imported as torch_models during the inference part. Why is it so?

Can you check the torch_infer.py file it used the same model in training.


Update almalinux 9 sample to 9.4

Updated images are available

Thanks, would you want to update rocky and oraclelinux too?

ping @fwilhe2

Out of curiously: Is there an api to automate this process?

Not yet.

https://github.com/lima-vm/lima/issues/1347

It is not super important, since once you update the image the result will be the same (and it can be done at boot).
But it saves bandwidth, not having to download an outdated image with outdated packages only to update it...


[fuchsia_ctl] unit tests failed on windows platform

failed instance
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8814226430734410449/+/u/Run_package_tests/custom_package_tests/stdout
00:00 +8 -1: test\emulator_test.dart: Emulator prepare environment runs as expected [E]
  Expected: true
    Actual: <false>

  package:test_api              expect
  test\emulator_test.dart 56:7  main.<fn>.<fn>

00:00 +9 -1: test\image_paver_test.dart: Tar fails

Fuchsia_ctl is currently skipped, we should figure out whether this can be fix or not

This package was removed.


fix: no smartdeploy on first update

fix #22
This function is not needed because the three-way merge in apply phase never removes annotations of on-cluster resources

Codecov Report

Merging #24 (bbe5226) into main (fc9669d) will increase coverage by 0.18%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   68.20%   68.39%   +0.18%
==========================================
  Files           9        9
  Lines        1211     1215       +4
==========================================
+ Hits          826      831       +5
+ Misses        309      307       -2
- Partials       76       77       +1

Impacted Files
Coverage Δ

pkg/deploy/deploy.go
66.52% <100.00%> (+0.49%)
: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 fc9669d...bbe5226. Read the comment docs.

we found out that removing entirely the function was not the right solution.
This change adds an integration test that will:

smart_deploy 4 times the same object : expect no pod restart
deploy_all: expect a pod restart
smart_deploy: expect no pod restart

Without this PR the second smart_deploy of the first bullet point fails

Remove the function does not work because the annotation is not present the first time, and set at the second? If this is the case, is not possible to add if empty, and do nothing otherwise?

This function is needed because after a deploy_all that annotation should be preserved, otherwise the following smart-deploy will trigger a restart removing the annotation that is not present in the applying deployment.
With this PR the function do nothing if the annotation is not found, but preserve it if is present ( even if is empty string ) before this PR it created an empty annotation causing a restart.


Redfish json validator and Service Root class

This adds RedfishJsonValidator class and ServiceRoot class, respective tests and docs.
Also app.py was moved from api directory to module root (oneview_redfish_toolkit)
Run.py and tests where updated accordingly.
Closes #17
Closes #18

This change is

Reviewed 19 of 250 files at r1.
Review status: 18 of 249 files reviewed at latest revision, 18 unresolved discussions.

oneview_redfish_toolkit/app.py, line 23 at r1 (raw file):

from oneview_redfish_toolkit import util

cfg = util.load_config('oneview_redfish_toolkit/redfish.ini')

as i expected load_config returns false (should be None) but we are not testing it here before using it...
the whole application should fail gracefully when this happens, right?

oneview_redfish_toolkit/app.py, line 26 at r1 (raw file):

schemas = dict(cfg.items('schemas'))
schemas_dict = util.load_schemas(cfg['directories']['schema_dir'], schemas)

same as above...

oneview_redfish_toolkit/api/redfish_json_validator.py, line 51 at r1 (raw file):

        self.redfish = collections.OrderedDict()

    def _Validate(self):

_validate

oneview_redfish_toolkit/api/redfish_json_validator.py, line 70 at r1 (raw file):

            raise(e.message)

    def Serialize(self, pretty=False):

serialize

oneview_redfish_toolkit/api/redfish_json_validator.py, line 84 at r1 (raw file):

        '''

        self._Validate()

self._validate()

oneview_redfish_toolkit/api/service_root.py, line 1 at r1 (raw file):

#!./redfish-venv/bin/python

not needed.

oneview_redfish_toolkit/api/service_root.py, line 42 at r1 (raw file):

        self.redfish["Name"] = "Root Service"
        self.redfish["RedfishVersion"] = "1.2.0"
        self.redfish["UUID"] = "85775665-c110-4b85-8989-e6162170b3ec"

According to Adriane, hpOneView team added endpoints to recover this info... but they didn't launched a new version yet.
I guess we should leave as it is for now.

oneview_redfish_toolkit/blueprints/service_root.py, line 28 at r1 (raw file):

@service_root.route('/', methods=["GET"])
def show():
    obj = ServiceRoot(current_app.schemas_dict["ServiceRoot"])

we definitely can improve this, ServiceRoot will always be built using this parameters... any suggestions?
obj = ServiceRoot() seems the goal to me, it already knows its schema will be the one with "ServiceRoot" key...
What if our Validator knew the loader?

oneview_redfish_toolkit/blueprints/service_root.py, line 29 at r1 (raw file):

def show():
    obj = ServiceRoot(current_app.schemas_dict["ServiceRoot"])
    json_str = obj.Serialize(True)

not sure if we should serialize the pretty version to the end user...

oneview_redfish_toolkit/tests/test_blueprint_service_root.py, line 45 at r1 (raw file):

        with open(
            'oneview_redfish_toolkit/tests/mockups/ServiceRoot.mok'

if this is a pure json file, please do not use this extension (i think it is related to audio files) it is a nightmare to open it for editing.

oneview_redfish_toolkit/tests/test_blueprint_service_root.py, line 47 at r1 (raw file):

            'oneview_redfish_toolkit/tests/mockups/ServiceRoot.mok'
        ) as F:
            mok_json = F.read()

let's leave uppercase letters to class names and constants, ok?

oneview_redfish_toolkit/tests/test_redfish_json_validator.py, line 27 at r1 (raw file):

class TestRedfishJsonValidator(unittest.TestCase):

shouldn't we be testing validation and serialization functions here?

oneview_redfish_toolkit/tests/test_redfish_json_validator.py, line 29 at r1 (raw file):

class TestRedfishJsonValidator(unittest.TestCase):

    def test(self):

not sure how this can go wrong

oneview_redfish_toolkit/tests/test_util_load_config.py, line 34 at r1 (raw file):

    def test_invalid_config_file(self):
        # Tests if passing a file that does not exists returns false.
        self.assertFalse(util.load_config('non-exist.ini'))

should we test for None instead?

oneview_redfish_toolkit/tests/test_util_load_config.py, line 85 at r1 (raw file):

                        self.config_file))

if __name__ == '__main__':

we do not need this...

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 38 at r1 (raw file):

        self.assertFalse(util.load_schemas('non-exist-schema-dir', schemas))

    def test_valid_schema_dir_invalide_dict(self):

nit: invalid

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 46 at r1 (raw file):

        self.assertFalse(util.load_schemas(self.schema_dir, schemas))

    def test_valid_schema_dir_valide_dict(self):

nit: valid_dict

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 58 at r1 (raw file):

if __name__ == '__main__':

we do not need this...

Comments from Reviewable

Reviewed 22 of 250 files at r1, 7 of 228 files at r2.
Review status: all files reviewed at latest revision, 23 unresolved discussions.

Comments from Reviewable

Review status: 25 of 28 files reviewed at latest revision, 24 unresolved discussions.

oneview_redfish_toolkit/app.py, line 23 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
as i expected load_config returns false (should be None) but we are not testing it here before using it...
the whole application should fail gracefully when this happens, right?

fixed

oneview_redfish_toolkit/app.py, line 26 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
same as above...

fixed

oneview_redfish_toolkit/api/redfish_json_validator.py, line 51 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
_validate

fixed

oneview_redfish_toolkit/api/redfish_json_validator.py, line 70 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
serialize

fixed

oneview_redfish_toolkit/api/redfish_json_validator.py, line 84 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
self._validate()

fixed

oneview_redfish_toolkit/api/redfish_json_validator.py, line 31 at r2 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
Review some words in the docs, as Serrialize and validatrion for example.

fixed. next time point the lines where the errors are

oneview_redfish_toolkit/api/service_root.py, line 42 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
According to Adriane, hpOneView team added endpoints to recover this info... but they didn't launched a new version yet.
I guess we should leave as it is for now.

living for when the release is available

oneview_redfish_toolkit/api/service_root.py, line 42 at r1 (raw file):
Previously, danielreed (Daniel Reed) wrote…
I might be getting ahead of myself here but I thought UUID was supposed to be populated from this OV REST call: https://{appl}/rest/appliance/nodeinfo/version

waiting for new release

Comments from Reviewable

Review status: 25 of 28 files reviewed at latest revision, 24 unresolved discussions.

oneview_redfish_toolkit/blueprints/service_root.py, line 28 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
we definitely can improve this, ServiceRoot will always be built using this parameters... any suggestions?
obj = ServiceRoot() seems the goal to me, it already knows its schema will be the one with "ServiceRoot" key...
What if our Validator knew the loader?

you requested to remove depencies from the class. my first version was like this and you requested to remove. so please, decide what you want and how you want.

oneview_redfish_toolkit/blueprints/service_root.py, line 29 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
not sure if we should serialize the pretty version to the end user...

if you want to see the results in a browser you should. And make it pretty is not a problem for interpreters. so I defend we should

Comments from Reviewable

Review status: 25 of 28 files reviewed at latest revision, 24 unresolved discussions.

oneview_redfish_toolkit/api/service_root.py, line 1 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
not needed.

removed

oneview_redfish_toolkit/blueprints/service_root.py, line 31 at r2 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
We can use status.HTTP_200_OK instead of hardcoded 200. The Flask status comes from the package: from flask_api import status

@ricardo do we HAVE to use this? this status will never change.

Comments from Reviewable

Review status: 25 of 28 files reviewed at latest revision, 24 unresolved discussions.

oneview_redfish_toolkit/tests/test_blueprint_service_root.py, line 45 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
if this is a pure json file, please do not use this extension (i think it is related to audio files) it is a nightmare to open it for editing.

changed to0 .json

oneview_redfish_toolkit/tests/test_blueprint_service_root.py, line 47 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
let's leave uppercase letters to class names and constants, ok?

lets build a rule book to avoid this. it´s really annoying fixing this kind of thing with no rule written. fixed

oneview_redfish_toolkit/tests/test_redfish_json_validator.py, line 27 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
shouldn't we be testing validation and serialization functions here?

I tested this on service root where there data available. need to test here too? it also will be retested on all class we make. let me know if you want a test here

oneview_redfish_toolkit/tests/test_redfish_json_validator.py, line 29 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
not sure how this can go wrong

is this a problem? as we do a lot in the constructor can have a error there.

oneview_redfish_toolkit/tests/test_service_root.py, line 18 at r2 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
Tests for redfish_json_validator.py? Maybe this comment is not necessary.

but does not hurt.

oneview_redfish_toolkit/tests/test_service_root.py, line 44 at r2 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
Change the method name teste_serialize(self) to test_serialize(self).

fixed

oneview_redfish_toolkit/tests/test_util_load_config.py, line 34 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
should we test for None instead?

fixed after change the functions

oneview_redfish_toolkit/tests/test_util_load_config.py, line 85 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
we do not need this...

if someone while editing the ini delete or change something

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 38 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
nit: invalid

fixed

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 46 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
nit: valid_dict

fixed

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 58 at r1 (raw file):
Previously, ricardoas (Ricardo Araújo) wrote…
we do not need this...

hurts?

Comments from Reviewable

Review status: 19 of 28 files reviewed at latest revision, 24 unresolved discussions.

oneview_redfish_toolkit/blueprints/service_root.py, line 27 at r1 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
This method also need documentation. And I guess that get_service_root() it's a better name...

fixed

Comments from Reviewable

Reviewed 1 of 251 files at r1, 10 of 10 files at r3.
Review status: all files reviewed at latest revision, 12 unresolved discussions.

Comments from Reviewable

Reviewed 11 of 251 files at r1, 2 of 228 files at r2, 8 of 10 files at r3.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

oneview_redfish_toolkit/tests/test_blueprint_service_root.py, line 47 at r1 (raw file):
Previously, ffdarkpenguin wrote…
lets build a rule book to avoid this. it´s really annoying fixing this kind of thing with no rule written. fixed

no need for that: https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables

oneview_redfish_toolkit/tests/test_util_load_schemas.py, line 58 at r1 (raw file):
Previously, ffdarkpenguin wrote…
hurts?

a lot!

Comments from Reviewable


Fix Rails/HttpPositionalArguments offenses

This branch fixes all the Rails/HttpPositionalArguments offenses, including these auxiliary changes:

Removes mokey-patches that expedited those offenses;
Enables the Rails/HttpPositionalArguments cop

More details at MO Developers, ruby 2.7.6 and rails 6.1
There is no manual test -- all changes are in test, rather than app

Coverage remained the same at 93.065% when pulling 1f42d6a4da33d824e9c11ca98701f0214ed10cb8 on joe-fix-test-kwargs into f9c8977692c838eab25c8764da7ba947fb5c4e1b on master.

@JoeCohen If this removes the use of check_for_params and extract_body maybe those methods should be deleted too.
I believe that fixing the kwarg issue for 2.7 will require further changes to functional_test_case methods, since they do not send the args to Rails test_case the way it wants them. Waiting for advice from Jason about that. But that should be a separate PR.

Thanks @nimmolo!
You're right about check_for_params and extract_body. I had  it in mind to remove them (as part of removing the old monkey-patches), but then completely forgot to do that.
I'm interested in who you find out about the Ruby 2.7 kwargs warnings.

I'll get to work on the Codeclimate/RuboCop offenses. I'm not sure why there are so many of them.

@JoeCohen I think it's that your line length in VS Code is not set to 80? I am happy to open and save the file, that will fix it.
Also -- I believe I solved the kwargs issue once and for all. Pushed it to this branch.
Also -- fixed a rubocop "Prefer index_with to each_with_object in NameControllerTest just now.

Hi @JoeCohen -
I was mistaken, Rubocop doesn't do line length.
It's another setting: hit command-, for settings, then search for line length. You'll find it under HTML>Format: Wrap Line Length
Here are the configs to set up rubocop with VS Code, in case you need them

.

There's one more kwarg thing to fix, in session_extensions.rb:104. Commit coming soon.

Thank you again!

HTML>Format: Wrap Line Length was set to 120.
I can use the Ruby > Rubocop settings. But I will leave that for
another day.
The latest version of RuboCop does some line length autocorrection.
We're on an old version. I'll update us after I get done with this PR.

On Sat, May 28, 2022 at 4:27 PM andrew nimmo @.***>
wrote:

Hi @JoeCohen https://github.com/JoeCohen -
I was mistaken, Rubocop doesn't do line length.
It's another setting: hit command-, for settings, then search for line
length. You'll find it under HTML>Format: Wrap Line Length
Here are the configs to set up rubocop with VS Code, in case you need them
[image: Screen Shot 2022-05-28 at 4 15 49 PM]
https://user-images.githubusercontent.com/1948095/170845823-5fa9a999-923e-4979-a6f5-f0f17c6b07d9.png
.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/957#issuecomment-1140343084,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFBNTCLFEHBSZP7GC23VMKTUJANCNFSM5XHGQSXQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@JoeCohen I believe this is now good to go. The "Rails/HttpPositionalArguments" cop is incorrect, as far as I can understand, with respect to our calls to http get etc.
See the rails code here. It seems to me it expects it like we're serving it.

Thanks.
I'll have to look at it in about an hour. I'm being called to dinner now.
On Sat, May 28, 2022 at 5:44 PM andrew nimmo @.***>
wrote:

@JoeCohen https://github.com/JoeCohen I believe this is now good to go.
The "Rails/HttpPositionalArguments" cop is incorrect, as far as I can
understand, with respect to our calls to http get etc.
See the rails code here
https://github.com/rails/rails/blob/aa7c4179ff3b0dba6c14e45cecaf853ac9446d41/actionpack/lib/action_controller/test_case.rb.
It seems to me it expects it like we're serving it.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/957#issuecomment-1140350836,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFD35LGNSKQGO2TOJATVMK4YBANCNFSM5XHGQSXQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'm not at home but thought of another consideration. When a test inherits from functional_test_case, which the tests that inherit from controller_extensions and session_extensions may or may not do, MO intercepts all calls to get etc to do our check_for_unsafe_html. These methods certainly expect `get(action, **args) like the test_case classes they inherit from.

Urk, that was quite a flurry of emails in this thread!!  I didn't take the
time to read and understand everything.  Is there anything that I should be
particularly aware of??
On Sat, May 28, 2022 at 10:35 PM codeclimate[bot] @.***>
wrote:

Code Climate has analyzed commit c0329e9
https://github.com/MushroomObserver/mushroom-observer/commit/c0329e99ed4ccf2d94d2328b6f2c53c64fec8b46
and detected 5 issues on this pull request.
Here's the issue category breakdown:
Category Count
Bug Risk 5
View more on Code Climate
https://codeclimate.com/github/MushroomObserver/mushroom-observer/pull/957
.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/957#issuecomment-1140364671,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIOI26ZNS3J73J4HRTVMLJXVANCNFSM5XHGQSXQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@pellaea - This PR fixes dozens of HttpPositionalArguments errors, except for 5 in controller_extensions and session_extensions.
I believe the cop is throwing a false positive in those.
The native Rails test_case method get(action: **args) expects a positional argument, plus however many kwargs. The cop complains when we send exactly that, from our own "get"-like (and "post"-like) methods (such as post_without_redirecting and reget). I don't know any way to solve it, but i'm no splat doctor.

PS - in case you're reading on email and didn't catch the typo i edited after sending, the native Rails method is of course get(action, **args) not get(action: **args). It is used like get(:show, params)

@pellaea: There's nothing that you should be particularly aware of.
We (i.e., 99% Andrew) are on top of things, and all the changes are in
test, so they can't break anything in production.
@nimmolo: I'd like to wait on merging this, so I will make it a Draft PR to
prevent accidental merger.
In particular, I want to see if updating RuboCop will fix the false
positive HttpPositionalArguments offenses.
My plan:

New branch.

Review the default protocol for updating RuboCop

Update our RuboCop gems (rubocop, rubocop_rails, rubocop_performance)

Update RuboCop configuration.

Update rubocop.todo

Push the branch

If everything passes and it's OK with you, merge it to master

Merge master to Fix Rails/HttpPositionalArguments offenses #957

Rev

On Sun, May 29, 2022 at 3:48 AM andrew nimmo @.***>
wrote:

PS - in case you're reading on email and didn't catch the typo i edited
after sending, the native Rails method is of course get(action, **args)
not get(action: **args). It is used like get(:show, params)
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/957#issuecomment-1140422877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFBGUO7PFXFMACKJLMLVMNDRLANCNFSM5XHGQSXQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

I've resolved the conflicts locally, but am getting 18 errors.
I will push it with errors so that everyone can see what's going on.
I suspect that the changes I had are now incorrect in light of changes @nimmolo made on other branches.

Oh wait. I think I messed up the merger. I will try to fix it, then push if successful.

I'm done for tonight.
I'm fine with merging this.

Sounds good to me.  Great work!
On Mon, May 30, 2022 at 12:18 AM Joseph D. Cohen @.***>
wrote:

I'm done for tonight.
I'm fine with merging this.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/957#issuecomment-1140677014,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNLIDFR3V2433ZFKPH3VMQ6RTANCNFSM5XHGQSXQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

nothing urgent. The 5 stickers are in controller extwnsions and session extensions. I think we can resolve later

On May 28, 2022, at 7:52 PM, Jason Hollinger @.***> wrote:
Urk, that was quite a flurry of emails in this thread!! I didn't take the
time to read and understand everything. Is there anything that I should be
particularly aware of??
On Sat, May 28, 2022 at 10:35 PM codeclimate[bot] @.***>
wrote:

Code Climate has analyzed commit c0329e9
https://github.com/MushroomObserver/mushroom-observer/commit/c0329e99ed4ccf2d94d2328b6f2c53c64fec8b46
and detected 5 issues on this pull request.
Here's the issue category breakdown:
Category Count
Bug Risk 5
View more on Code Climate
https://codeclimate.com/github/MushroomObserver/mushroom-observer/pull/957
.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/957#issuecomment-1140364671,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIOI26ZNS3J73J4HRTVMLJXVANCNFSM5XHGQSXQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.


Adding a hint to the XLA op metadata, set when the op is updating a variable

The hint can be used for ensuring that the buffer allocated to a variable remains at the same place.  For a static graph compiler, this prevents an extra copy at the end of the execution.

Can one of the admins verify this patch?

ok - i've run all the XLA unit tests and there is something wrong - will look into that immediately


Reduce memory footprint of gen_prediction_chunks.py and add progress bar

…output

PR checklist

[X] This comment contains a description of changes (with reason)
[ ] CHANGELOG.md is updated
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] Documentation in docs is updated
[ ] If necessary, also make a PR on the nf-core/metapep branch on the nf-core/test-datasets repo

Reduces the memory footprint of gen_prediction_chunks.py by about 40% and add progress output.

Looks great!

Looks great!


Fix issue when CsWinRTInputs contains multiple items and the timestamp picks the last item instead of the most recent.

MSBuild takes the timestamp of the last item when CsWinRTInputs contains multiple files. Instead use the rsp file as the marker for uptodate.

/azp run

/azp run