Annotate Linseed user

Description
We encountered a situation where linseed user was recreated, but Linseed was still referencing the old password causing the following errors to show up on all APIs:
[status 500] server error: elastic: Error 401 (Unauthorized): unable to authenticate user [tigera-ee-linseed-yeidobci-secure] for REST request [/tigera_secure_ee_benchmark_results.yeidobci.cluster.%2A/_search]

After restart, Linseed errors were resolved. At further inspection, the container that got restarted was referencing the new password, while the one that did not get restarted was still using the old password.
For PR author

[ ] Tests for change.
[ ] If changing pkg/apis/, run make gen-files
[ ] If changing versions, run make gen-versions

For PR reviewers
A note for code reviewers - all pull requests must have the following:

[ ] Milestone set according to targeted release.
[ ] Appropriate labels:

kind/bug if this is a bugfix.
kind/enhancement if this is a a new feature.
enterprise if this PR applies to Calico Enterprise only.

Could you change the PR name such that it is useful as a release note summary?


Fix add disable_auto_compaction for show data

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


[share] [auto-build] swoole(pecl install) + php7(latest) @ alpine < 19Mb

[auto-build] swoole(pecl install) + php7(latest) @ alpine < 19Mb
Link:
https://github.com/cmptech/auto_alpine_php7_runtime_with_swoole/

https://github.com/cmptech/auto_alpine_php7_runtime_with_swoole_latest
up to swoole1.8.8-beta, no need to patch the linux header (the previous version install from PECL have to patch the sources due to the linux header incompatible)
Enjoy swoole in docker!


Using <FocusScope> results in 'nodeToRestore' being set on Undefined (NEXT.js)

🐛 Bug Report
Trying to run any useSelect example from https://react-spectrum.adobe.com/react-aria/useSelect.html results in TypeError: Cannot set properties of undefined (setting 'nodeToRestore'). Searching for this error doesn't really return anything useful anywhere.
Wrapping on SSRProvider does nothing. Commenting <FocusScope /> and running the application works, but you lose almost all functionality related to dismissing popovers.
🤔 Expected Behavior
Example code should run without problems.
😯 Current Behavior
Unhandled Runtime Error
TypeError: Cannot set properties of undefined (setting 'nodeToRestore')

Call Stack
eval
<EMAIL_ADDRESS>(393:0)
commitHookEffectListMount
../../node_modules/react-dom/cjs/react-dom.development.js (23150:0)
invokeLayoutEffectMountInDEV
../../node_modules/react-dom/cjs/react-dom.development.js (25120:0)
invokeEffectsInDev
../../node_modules/react-dom/cjs/react-dom.development.js (27351:0)
commitDoubleInvokeEffectsInDEV
../../node_modules/react-dom/cjs/react-dom.development.js (27327:0)
flushPassiveEffectsImpl
../../node_modules/react-dom/cjs/react-dom.development.js (27056:0)
flushPassiveEffects
../../node_modules/react-dom/cjs/react-dom.development.js (26984:0)
commitRootImpl
../../node_modules/react-dom/cjs/react-dom.development.js (26935:0)
commitRoot
../../node_modules/react-dom/cjs/react-dom.development.js (26682:0)
performSyncWorkOnRoot
../../node_modules/react-dom/cjs/react-dom.development.js (26117:0)
flushSyncCallbacks
../../node_modules/react-dom/cjs/react-dom.development.js (12042:0)
eval
../../node_modules/react-dom/cjs/react-dom.development.js (25651:0)

🔦 Context
I'm trying to have JSX elements inside a custom <Select> component, just like in the StyledComponents example.
But any of the examples will crash.
💻 Code Sample
Can't seem to be able create a Next.js app on codesandbox as of now.
Locally, I just ran yarn create-next-app --ts myApp, copied the files to a folder and yielded the same error.

Just came across this too and downgrading from React 18 to 17.x helps run the example.

Make sure you aren't using React StrictMode

Hi, should this issue be reopened? So we can track if this will be fixed one day? Thanks.

We're tracking StrictMode here https://github.com/adobe/react-spectrum/issues/779

Hi, any progress on this, I've created a reusable component using datepicker for this which I'm now having to abandon because my team are not comfortable with developing an App without strict mode.
At the very least, could it please be mentioned prominently in: https://react-spectrum.adobe.com/react-spectrum/getting-started.html so people are aware of it?

This was fixed by https://github.com/adobe/react-spectrum/pull/3878 and will be included in the next release. It is available in the nightly build now.

@reidbarber I'm still getting the same problem with datepicker

@char502 I just confirmed locally that this is fixed in Next.js with the nightly build. Be sure you're using the nightly release in your package.json. If there is still an issue, feel free to post more information about your setup.

@reidbarber I think I put this in the wrong group, I'm using CRA not Next.js, is there a CRA group reporting this problem and is it fixed there?

@char502 This fix is related to React Strict Mode, so it applies to both CRA and Next.js when they have strict mode enabled.

ok, will take a look, thanks

@reidbarber I have installed "react-aria": "3.22.1-nightly.3690" in storybook where there is no error (with strict mode set), however, i have tried to implement this in another repo (as this is a reusable component) and I am still getting:
Uncaught TypeError: Cannot set properties of undefined (setting 'nodeToRestore')

@reidbarber I've just implemented this and It's now working! 🎉 Thanks for letting me know re the update

@reidbarber I have installed "react-aria": "3.22.1-nightly.3690", the fix appears to work with storybook in strict mode but I have implemented the datepicker in another repo (I have used it as a reusable component) and I am still getting the error message: Uncaught TypeError: Cannot set properties of undefined (setting 'nodeToRestore')

That's great that you've confirmed the nightly has the fix. When we release (in the next couple weeks) that means the fix will be available for your other repo. We appreciate your patience and understanding.

@snowystinger it didn't fix it unfortunately, I hadn't actually switched strict mode back on, when I did, the error returned so this hasn't fixed it

Sorry to hear that. Can you provide a reproduction showing the issue?

I'm not allowed to show you our codebase, but I am using something very close to this: https://codesandbox.io/s/reverent-faraday-5nwk87?file=/src/DatePicker.js which uses a number of react-aria components.

I get the same error when I apply strict mode to this sandbox: https://codesandbox.io/s/lively-sound-u57mnb?file=/src/index.js

Ah, thank you for the extra info. That is not using the nightlies. I can see it is working as expected here https://codesandbox.io/s/priceless-mahavira-6y8zee. It's the same as the codesandbox you provided, just has the latest nightly installed.
One thing to note, while FocusScope has been updated to work with React StrictMode, many of the date hooks have not yet. This is a work in progress. You may find some other issues still.

Ok, so I'll need to find an alternative. I appreciate this is a lot of work to change but a warning here: https://react-spectrum.adobe.com/react-spectrum/getting-started.html would be helpful to those that have production deadlines to meet but now have to find an alternative.

I added the nightlies for React stately and react aria just as you have in the amended sandbox above but I'm still getting the same error message

Unfortunately, I cannot see your setup and it's not reproducing in a codesandbox currently, so I do not know what happened for you locally.
I have a guess, if you use a nightly, you must use all the nightlies of every package at the same nightly version, otherwise you can end up with duplicate packages installed. That doesn't usually result in the particular error you're seeing, but might be worth looking into.
Otherwise, we will need you to do some more debugging on your end to provide more information. For instance, there are only two places where nodeToRestore is set on an object in the FocusScope module. You could determine which of these is the problematic statement.
https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/focus/src/FocusScope.tsx#L820
https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/focus/src/FocusScope.tsx#L841
Once you determine one of these, you could put in a console.trace and determine where it's being called from.
Other information about what version of React you're running, or what browser/OS you're on would be helpful too. Also, are you using any of the concurrent features? (they are what StrictMode is meant to help you with)
BTW. I ran our StrictTests against the date hooks, and they all appear to be working, so that is some good news for you.

@snowystinger thanks for taking another look and for confirming re the date hooks, I appreciate it, I'm having to go with another option for now but I will take another look when I get the chance

@char502 @snowystinger I have converted https://react-spectrum.adobe.com/react-aria/useCalendar.html to typescript components.
May be you have to use exact below versions instead of react-aria:  ^3.22.1-nightly.3690.
"react-aria": "3.22.1-nightly.3690", "react-stately": "3.20.1-nightly.3690",
It worked with reactStrictMode: true in nextjs.

https://www.npmjs.com/package/@internationalized/date?activeTab=versions
but I'm not sure what the type error is that you're seeing. If there is one, would you mind opening a separate issue?


Dark Theme support

Please add Dark Theme support to windows app. The application is too bright.

Hi @superherointj feel free to submit one - Theme support is currently not in our immediate roadmap.

Dark theme support would be brilliant. The application is far too bright for work at night.

@wonea if you have an easy way to get this added, I'm all for it!

@FrenchBen I believe I found an easy way, I don't know how to compile all the code to test if modding this variable is on the right path.
it is currently set like:
@body-bg:               #fff; (white)
could be changed to:
@body-bg:               #000; (black)
https://github.com/docker/kitematic/blob/3d40e1334aae598eff99dbf3910906ed5ad9727b/styles/bootstrap/variables.less#L28
currently running macOS if help to test is needed.

Created a dark theme style, see my fork.

any chance that this will get implemented with the main application since the fork hasn't recieved updates since 2019?


Menu Improvements and Update How To Play Menu

Description
This PR has some small changes that increase visibility of the buttons and update the How To Play menu with new animals.
Fixes / Closes # (issue)
#528
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] This change requires a documentation update

How Has This Been Tested?
This has been tested manually and worked properly.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

HLTH, SPD, Enter seed labels aren't very visible now, could you fix this if you have time

Please change the how to play values to the correct ones in npcconfigs

Please change the how to play values to the correct ones in npcconfigs

Done

 HLTH, SPD, Enter seed labels aren't very visible now, could you fix this if you have time

Done


Force threads when compiling web editor instead of erroring out

This makes the build process more seamless. A similar option is already forced for initial memory when needed.

Thanks!

Cherry-picked for 3.5.


EVEREST-239 Added cluster-info endpoint

@oksana-grishchenko https://github.com/percona/percona-everest-cli/blob/main/pkg/install/operators.go#L877 please update your CLI =)


Provide fromDate or fromEpoch to create ZonedDateTime

🙋 Feature Request
I would love to be able to either fromDate(date: Date, timeZone: string) or fromEpoch(value: number, timeZone: string). Unless I'm missing some way to do this in the current @internationalized/dates library?
Currently I'm doing parseAbsolute(new Date(epoch).toISOString(), tz)

We'd be happy to expose those, would need to export them from here and add it to the docs.

Hey @LFDanLu  and @jokull
Do you guys mind if I can contribute on this ?
Please confirm so that I can continue with the changes and purpose a PR.


feat: add script for grouping conventional commits for newsletter

Related issue
Closes #927 [Feature] Generate Newsletter
Scope of work
Introduce a Node.js script that generates a grouped output of our conventional commits for a given git log range.

Example shell command:
node scripts/create-gitlog $GIT_RANGE
$GIT_RANGE can be anything git log understands, most commonly two git tags separated by .., e.g.:
node scripts/create-gitlog @storefront-ui/vue@0.5.0<EMAIL_ADDRESS>for the complete git log between the 0.5.0 and 0.6.0 versions. But also fancy stuff like:

"last 10 commits" -> node scripts/create-gitlog -10
"everything since last tag" -> node scripts/create-gitlog $(git describe --tags --abbrev=0 @^)..@
"... in reversed order" -> ... --reverse

If you're on macOS you can automatically copy the script's output to clipboard by piping it to pbcopy like so:
node scripts/create-gitlog $GIT_RANGE | pbcopy
Any POSIX-compatible shell also always direct writing to files, as usual via
node scripts/create-gitlog $GIT_RANGE > newsletter.md

Notes & Details

The output format is Markdown, as this is quite universal, directly rendered by GitHub and others and is still somewhat readable if not rendered.
The script prepends the short commit hash to all log entries and links them to our GitHub repo by using standard MD syntax. Although GitHub would detect the commit hashes and link to the appropriate commit automatically, I think it's nice to have the output directly usable for other platforms too.
The known categories the script tries to put commit entries into are:

✨ NEW FEATURES
💥 BREAKING CHANGES
🐛 FIXES
♻ REFACTOR
📝 DOCS

If it is not able to infer the category from the conventional commit (e.g. because it wasn't conventional), the commit goes into the "fallback category":

🔔 Other Noteworthy Goodies

The order the category headlines are printed are determined by the JS Map TEMPLATE_HEADINGS (line 6).
If a log entry contains one of the following strings, it is filtered out (=not added):

"chore(release)"
"merge branch"
"merge remote"
"revert"

Filters can be added by modifying the array FILTER_ENTRIES (line 21). (IMHO this is a rather infrequent action and, if done, should be persisted for future runs, hence I didn't add a command-line action for that.)
More static content can be added to the TEMPLATE constant (line 14), if needed.
I didn't put much complexity into the script for insignificant performance optimizations; the script is fast by itself. Generating a log for our all-time git history takes far less than a second.

Screenshots of visual changes
See example output below.
Checklist

[x] No commented blocks of code left
[x] Run tests and docs
[x] Self code-reviewed

If applicable:

[x] I followed composition rules for my component
[x] I tested the component in most common device sizes (can be tested in Storybook from viewport addon in top menu)
[x] I accept Individual Contributor License Agreement

⬇⬇⬇ EXAMPLE OUTPUT ⬇⬇⬇
$ node scripts/create-gitlog @storefront-ui/vue@0.5.0<EMAIL_ADDRESS>

💚 Storefront UI Newsletter Mar 21 2020 💚

✨ NEW FEATURES

(5f0065bb) feat(example): Thank you page (#742)
(e8ad2c96) feat: add SfProductCardHorizontal (#716)
(bd505235) feat(example): error page (#759)
(6df9f810) feat: add font-display: swap rule to google fonts (#771)
(da1a32ce) feat: add v-focus directive (#753)
(efb079ee) feat: pull request template update (#749)
(486a1599) feat: add quantity to cart icon in SfHeader (#734)
(c708062b) feat: add default aria-label to SfQuantitySelector (#735)
(cbb59c31) feat: add required slots to SfTabs (#736)
(9241efb5) feat: add hasCarousel prop for mobile SfGroupedProduct (#715)
(58d67f1d) feat: add stylelint for .scss in shared packages (#732)
(d362cf68) feat: add isMobile observer (#701)
(3584689f) feat: add SfBadge to SfProducCard (#693)

💥 BREAKING CHANGES

(15a6fcd5) BREAKING CHANGE: adjust css variable to default pattern (#744)
(a06d9aca) BREAKING CHANGE: replace SCSS variable to CSS variable (#673)

🐛 FIXES

(2c1059ff) fix: ssr in SfScrollable (#855)
(53322009) fix: ssr error in SfHeader(#854)
(3d1f1d58) fix: badge icon radius (#811)
(9f622edb) fix: title props name in SfSidebar (#810)
(8f2c01ae) fix: a11y for SfTab component (#787)
(8c5e8440) fix: missing hasCarousel prop in stories (#798)
(1dcb2ba3) fix: add transparent bcg to SfButton outline modifiers (#791)
(df1ad2f7) fix: too bright hover color on SfButton(#793)
(57b07712) fix: add openTab in SfTabs stories (#789)
(f0f84020) fix: add type to show-password button (#786)
(cc7e7903) fix: position of SfProductCard add to card button (#779)
(a89b96a8) fix: set initial slide in SfGallery (#760)
(0bc6ac0d) fix: small ssr bugs (#776)
(3601b27f) fix: docs for CSS custom properties (#775)
(b15eea45) fix: overlay transition opacity conflicting (#773)
(d21c8f7e) fix: add variable for z-index (#725)
(e39fb8ee) fix: docs build fails due to outdated links (#751)
(362fc233) fix: Add aria-label in SfCircleIcon stories (#727)
(b995ae01) fix: a lot imports of global CSS variables (#731)
(05b5ca6b) fix: double pictures is not adjusted to size (#683)
(8422bc05) fix: prevent glide mount for empty container (#694)
(9c2b9c4a) fix(ui): cheating lerna
(554c6d73) fix(ui): rever sfui css
(01b24d17) fix(ui): sfui css

♻ REFACTOR

(08fca6a1) refactor: remove sfui.scss file (#794)
(7f0475aa) refactor: SfModal and SfSidebar on mobile (#755)
(17aefa55) refactor: updated SfColor stories (#774)
(de923891) refactor: change is-active and is-disabled to modifiers (#770)
(46fb4f26) refactor: remove SfOptions component (#769)
(421ba48e) refactor: remove calc from SfChevron (#758)
(fc6f2f8e) refactor: adjust SfFooter to SfHeader and MegaMenu (#741)
(50f18938) refactor: chang logic for showing content in SfTabs (#738)
(7134e418) refactor: remove all unused --secondary modifiers (#691)
(d40be4bb) refactor: add isSticky props to SfHeader (#739)
(13382bd0) refactor: clean organisms stories (#707)
(c7a82ce6) refactor: replace camelCase slot names with kebab-case (#717)
(c5f6d536) refactor: remove usage of yarpm and require yarn (#730)
(d1fa6988) refactor: remove SfCounter component (#705)
(8cb79dc6) refactor: add label to SfBottomNavigation (#706)
(568f6e42) refactor: remove min from SfQuantitySelector (#720)

📝 DOCS

(25da463e) docs: reorder core team members
(1ec9a24d) docs: updated github labeling guide (#785)
(a9929a20) docs: update github guideliness (#784)
(7f90034c) docs: update installation guide (#778)
(c0eb91d9) docs: add Storefront UI gitflow (#756)
(18ef34fc) docs: addjust docs to CSS custom properties (#748)
(5728e2ee) docs: add Marta Radziszewska to core team (#762)
(0fb6fafb) docs: update contributing guide (#745)
(671fd685) docs: add colors palette and sizes to documentation (#609)

🔔 Other Noteworthy Goodies

(1a90e48b) chore: small improvements in examples (#796)
(b0294e11) chore: rename ReviewOrder to ConfirmOrder (#695)
(21b7e368) chore: remove unused nuxt package (#692)
(2d984f53) test(unit): fixing tests for component with provide/inject pattern (#662)
(397a1ced) test: add render test to missed components (#644)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

sorry for my delay, @EduardDopler it's an amazing script like always 🎖


Update types-of-emails-github-sends.md

Added research emails to intro & added a section

Why:

What's being changed:

Check off the following:

[ ] All of the tests are passing.
[ ] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[ ] For content changes, I have reviewed the localization checklist
[ ] For content changes, I have reviewed the Content style guide for GitHub Docs.

Added research emails to intro & added a section

Why:
What's being changed:
Check off the following:

[ ]  All of the tests are passing.
[ ]  I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[ ]  For content changes, I have reviewed the localization checklist
[ ]  For content changes, I have reviewed the Content style guide for GitHub Docs.


Unexpected end of JSON input error when querying accounts

I believe this error was caused the the CORS issue we briefly had. I haven't been able to recreate this issue on prod

@n1tranquilla Back to you to repro.


Make MediaLinkExtension XML well-formed

Change <iframe allowfullscreen> to <iframe allowfullscreen="allowfullscreen">

Hm, allowfullscreen should be well formed for HTML5 at least. Do you expect to target something else?

It is valid HTML 5, but it is not valid XHTML 5 because of the omission of the attribute value assignment part, making the syntax not XML well-formed. Adding back the value assignment makes it valid for both HTML and XHTML.
https://www.w3.org/TR/html/infrastructure.html#boolean-attribute

Also, if the content is well formed XML, it can processed easily using the LINQ to XML API.

Closing this in favour of #281


Remove Babel and related dependencies

Removes Babel and related dependencies and code (such as the Jest integration). Although babel-jest is loaded automatically, none of it's functionalities are actually used.

Thanks 🎉🎉


Install of requirements failed

Running this command:
pip install -r https://raw.githubusercontent.com/dnouri/nolearn/master/requirements.txt
results in:
Failed building wheel for scipy
…
Command "/home/aflyax/anaconda3/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-yekvv38i/scipy/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-xdhx23wz-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-yekvv38i/scipy/

Looks like you are using Anaconda. You should probably install using Anaconda own's package manager,
conda install scipy

After what @unautre suggested, download the requirements.txt file and remove the lines with requirements that you have already satisfied via conda (maybe numpy, scipy).  Then run pip install -r requirements.txt with your local, modified requirements.txt file.
Please reopen if this does not fix your issue.


Unable to authenticate with the new keyrock release

Hi,
When starting the server and doing the initial authentication of the pep proxy user with keyrock, it fails with the following error:
2018-04-11 14:57:25.036  - INFO: Server - Starting PEP proxy in port 1080. IdM authentication ...
2018-04-11 14:57:25.040  - DEBUG: HTTP-Client - Sending  POST  to: http://idm:4000/v3/auth/tokens
2018-04-11 14:57:25.041  - DEBUG: HTTP-Client -  Headers:  { 'Content-Type': 'application/json' }
2018-04-11 14:57:25.042  - DEBUG: HTTP-Client -  Body:  {"auth":{"identity":{"methods":["password"],"password":{"user":{"name":"pep_proxy_8bb4f48b-4db7-452f-944b-e827c71cdac7","password":"pep_proxy_ec8dbe01-f776-463e-906a-6b2e716c5c10"}}}}}
POST /v3/auth/tokens 400 0.403 ms - 117
2018-04-11 14:57:25.056  - ERROR: Server - Error in keystone communication {"error":{"message":"Expecting to find name and password or token in body request","code":400,"title":"Bad Request"}}

It seems the new keyrock release uses a different payload than keystone and modifying the code to send the correct payload seems to fix this, but I'm not sure if this is the only place where this problem may be present.
Are you planning on updating the pep-proxy to work with the new keyrock release or is there a new version in the works (like with keyrock)?
Thanks,
Regards.

Hi,
Thanks for tour reply @PepeluDev. As you have said there was a bug when Wilma authenticate with Keyrock. We have already modified the request to solve this problem.
Then I have tried to get info about user and I think the problem is that you are trying to ge info from an API token and Wilma Pep Proxy only authenticates OAuth 2.0 tokens.

Hi @apozohue10 and thank you for your reply and the code modification :)
I think you are right, the token i have to use (OAuth 2.0 token) and the API one are differents. What is more, i have been checking my keyrock database and the 'oauth_access_token' table is empty for me.
I have been checking the Keyrock documentation but there are a lot of broken links and i cannot access to the full API description. Is there any document or website where i can learn how to generate the OAuth 2.0 tokens from keyrock? Thanks a lot in advance

Hi @PepeluDev, you can find the differents ways of generate an access token here. I hope it helps you.

Hi @apozohue10,
I've just tried the updated version and commit 3241c5cddd44f68a5ced5a9922ee02b4449449ad fixes it, so I'm closing the issue.
Thanks,
Regards.


added PHP 7.0-7.4, 8.0 to Travis

Coverage decreased (-1.1%) to 93.75% when pulling 9f39022d42b0514e9b7bb4a11cdcc0da35cee1f8 on freezy-sk:travis-php-versions into 8ef108914cab76c0c233258798b5eb40b5747f43 on vube:master.

Coverage decreased (-1.1%) to 93.75% when pulling 9f39022d42b0514e9b7bb4a11cdcc0da35cee1f8 on freezy-sk:travis-php-versions into 8ef108914cab76c0c233258798b5eb40b5747f43 on vube:master.


How to replace #[associated] with #[account(seeds = [...] Tutorial Basic 5: custom program error: 0xa1

Hi I was following the tutorial of in the examples folder of this repo...
except I have replaced  #[associated]
with #[account(seeds = [user_data.deposit_last.as_ref(), &[user_data.__nonce]])]
then it failed to read the associated account's values
 const userData = await program.account.userData.associated(wallet1, usdcMint);
So what is the correct way to update this soon-to-be-deprecated #[associated] ?
#[associated]
#[derive(Default)]
pub struct UserData {
  pub authority: Pubkey,
  pub deposit_last: i64,
  pub shares: u64,
  pub reward_debt: u64,
}

have updated the Rust program dependencies to Anchor 0.13.1 in the Cargo.toml file
also with updated project-serum/anchor to 0.13.1
Transaction simulation failed: Error processing Instruction 0: custom program error: 0xa1
Program 7ohmkEjMrZHtdGW2kQJutrvhjpPUo1RGkcWwLcxaYzoe invoke [1]
Program log: Custom program error: 0xa1
Program 7ohmkEjMrZHtdGW2kQJutrvhjpPUo1RGkcWwLcxaYzoe consumed 3131 of 200000 compute units
Program 7ohmkEjMrZHtdGW2kQJutrvhjpPUo1RGkcWwLcxaYzoe failed: custom program error: 0xa1
Translating error SendTransactionError: failed to send transaction: Transaction simulation failed: Error processing Instruction 0: custom program error: 0xa1
at Connection.sendEncodedTransaction (.../node_modules/@solana/web3.js/lib/index.cjs.js:4882:13)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Connection.sendRawTransaction (.../node_modules/@solana/web3.js/lib/index.cjs.js:4841:20)
at async Object.sendAndConfirmRawTransaction (.../node_modules/@solana/web3.js/lib/index.cjs.js:6668:21)
at async Provider.send (.../node_modules/@project-serum/anchor/dist/cjs/provider.js:84:22)
at async Object.rpc [as createToken] (.../node_modules/@project-serum/anchor/dist/cjs/program/namespace/rpc.js:11:31)
at async Context. (.../dragon-coin/tests/dragon-coin.js:161:5) {
logs: [
'Program 7ohmkEjMrZHtdGW2kQJutrvhjpPUo1RGkcWwLcxaYzoe invoke [1]',
'Program log: Custom program error: 0xa1',
'Program 7ohmkEjMrZHtdGW2kQJutrvhjpPUo1RGkcWwLcxaYzoe consumed 3131 of 200000 compute units',
'Program 7ohmkEjMrZHtdGW2kQJutrvhjpPUo1RGkcWwLcxaYzoe failed: custom program error: 0xa1'
]
}
 Error: Invalid account discriminator
  at AccountClient.fetch (/mnt/sda5/0Programming/Solana/anchorRepo0000/node_modules/@project-serum/anchor/dist/cjs/program/namespace/account.js:90:19)
  at processTicksAndRejections (node:internal/process/task_queues:96:5)
  at async AccountClient.associated (/mnt/sda5/0Programming/Solana/anchorRepo0000/node_modules/@project-serum/anchor/dist/cjs/program/namespace/account.js:177:16)
  at async Context.<anonymous> (tests/dragon-coin.js:211:22)

0xa1 in hex is 161 in decimal
then the possible error codes:
#[msg("The account discriminator was already set on this account")]
AccountDiscriminatorAlreadySet = 160,
#[msg("No 8 byte discriminator was found on the account")]
AccountDiscriminatorNotFound,
Please help. Thank you

It seems I have to add __nonce for unknown reason...
#[account(seeds = [user_data.authority.as_ref(), &[user_data.__nonce]])]
#[derive(Default)]
pub struct UserData {
  pub authority: Pubkey,
  pub deposit_last: i64,
  pub shares: u64,
  pub reward_debt: u64,
  pub __nonce: u8,
}

Then I got this: Error Invalid account discriminator
const userData = await program.account.userData.associated(wallet1, usdcMint);

Also this UserData PDA account somehow already has "nonce": somehow already existing, does not matter whether you define it in the PDA struct or not!!!???
pub nonce: u8
SO, Never define a variable named "nonce" in an PDA!!!

This #[associated] feature is being removed in the next release. Please don't use it.

#[associated] is being removed. Your transformation is correct except your seeds must be changed to
#[account(seeds = [b"anchor", user_data.authority.as_ref()], bump = user_data.__nonce)]

Hi thanks for replying. my user's PDA is now:
#[account]
#[derive(Default)]
pub struct UserPda {
  pub num: u8,
  pub user_acct: Pubkey,
  pub authority: Pubkey,
  pub reward_debt_temp: u64,
  pub stake_amounts: [u64; 20],
  pub stake_times: [u32; 20],
  pub shares_array: [u64; 20],
  pub reward_debts: [u64; 20],
  pub __nonce: u8,
  //pub nonce: u8, somehow already existing!!!
}

but if I change #[account] to  #[account(seeds = [b"anchor", user_data.authority.as_ref()], bump = user_data.__nonce)]
I got errors:
error: custom attribute panicked
--> programs/farm/src/lib.rs:528:1
|
528 | #[account(seeds = [b"anchor", user_data.authority.as_ref()], bump = user_data.__nonce)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: message: Only two args are allowed to the account attribute.
error[E0433]: failed to resolve: use of undeclared type UserPda
--> programs/farm/src/lib.rs:516:39
|
516 |   pub user_pda: ProgramAccount<'info, UserPda>,
|                                       ^^^^^^^ use of undeclared type UserPda
error[E0412]: cannot find type UserPda in this scope
--> programs/farm/src/lib.rs:467:39
|
436 | pub struct Stake<'info> {
|                       - help: you might be missing a type parameter: , UserPda
...
467 |   pub user_pda: ProgramAccount<'info, UserPda>,
|                                       ^^^^^^^ not found in this scope
error[E0412]: cannot find type UserPda in this scope
--> programs/farm/src/lib.rs:516:39
|
514 | pub struct InitUserPda<'info> {
|                             - help: you might be missing a type parameter: , UserPda
515 |   #[account(init, associated = authority, with = user_acct)]
516 |   pub user_pda: ProgramAccount<'info, UserPda>,
|                                       ^^^^^^^ not found in this scope
error[E0412]: cannot find type UserPda in this scope
--> programs/farm/src/lib.rs:546:39
|
544 | pub struct UpdateUserPda<'info> {
|                               - help: you might be missing a type parameter: , UserPda
545 |   #[account(mut, associated = authority, with = user_acct)]
546 |   pub user_pda: ProgramAccount<'info, UserPda>,
|                                       ^^^^^^^ not found in this scope

After reducing the array sizes:
#[account]
#[derive(Default)]
pub struct UserPda {
  pub num: u8,
  pub user_acct: Pubkey,
  pub authority: Pubkey,
  pub stake_amounts: [u64; 10],
  pub stake_times: [u32; 10],
  pub shares_array: [u64; 10],
  pub reward_debts: [u64; 10],
  pub __nonce: u8,
  //pub nonce: u8, somehow already existing!!!
}

The input struct is working now:
#[derive(Accounts)]
pub struct InitUserPda<'info> {
  #[account(zero, seeds = [b"anchor", authority.key().as_ref(), user_acct.key().as_ref()],
    bump,)]
  pub user_pda: Account<'info, UserPda>,

  #[account(signer)]//authority should sign this txn
  pub authority: AccountInfo<'info>,

  pub user_acct: Account<'info, UserAcct>,
  pub rent: Sysvar<'info, Rent>,//for init
}


Linux OS LVM support needs updated

The Troubleshooting section on this page makes this comment:
The OS disk uses a Logical Volume Manager (LVM) scheme. Although limited LVM data disk support is available, an LVM OS disk isn't.
According to this page, OS with LVM is supported:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/disk-encryption-overview#supported-vms-and-operating-systems
Please revise this page to remove this comment. It appears to be outdated.
Thanks

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

ID: a70007bc-222d-5ed7-4fdb-04edf1b9606e
Version Independent ID: ea5d0c8d-4e24-fb45-0f1b-60d0dade9a93
Content: Troubleshooting Azure Disk Encryption for Linux VMs - Azure Virtual Machines
Content Source: articles/virtual-machines/linux/disk-encryption-troubleshooting.md
Service: virtual-machines
Sub-service: disks
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@mihammer -
Thanks for brining this to our attention. We will investigate it further and update you shortly.

@mihammer -
Thanks again for bringing this to our attention. We have updated the Doc and it will be live once its merged.  We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Access global injected vue

Does it support injected prop to global Vue instance?
For example this.$dlg or this.$toast and so on...
If yes , how to access ?

I think it would depend on how those properties are created.
For example, if they are created like this, it should work, but only within the Vue 2 apps:
Vue.prototype.$toast = function (methodOptions) {
	// some logic ...
}

i mean Vue 3 app


[Feature]: App Developer can see more detailed stack info withcf buildpacks

Blockers/Dependencies
Follow up to https://github.com/cloudfoundry/cf-k8s-controllers/issues/349
Background
Today the output looks like:
 $ cf buildpacks

position   name                                      stack   enabled   locked   filename
1          tanzu-buildpacks/dotnet-core-lite         base    true      false<EMAIL_ADDRESS>2          tanzu-buildpacks/nodejs-lite              base    true      false<EMAIL_ADDRESS>3          tanzu-buildpacks/go-lite                  base    true      false<EMAIL_ADDRESS>4          tanzu-buildpacks/python-lite              base    true      false<EMAIL_ADDRESS>5          tanzu-buildpacks/java-native-image-lite   base    true      false<EMAIL_ADDRESS>6          tanzu-buildpacks/java-lite                base    true      false<EMAIL_ADDRESS>
Where the stack column lacks detail: base
We want to take the id field from the default ClusterBuilder status.stack:
  stack:
    id: io.buildpacks.stacks.bionic
    runImage: gcr.io/cf-relint-greengrass/cf-k8s-controllers/kpack/beta@sha256:0f5c4717bd2b51e5131e2278dbaa5405fdc64ed65f4d88cb997777225de11818

Acceptance Criteria
GIVEN I have cf-on-k8s and all prerequisites installed +  RBAC
WHEN I run cf buildpacks
THEN I see that the output of the stack column matches the status.stack.id of the default ClusterBuilder
Dev Notes
No response

Closing: this was addressed by https://github.com/cloudfoundry/cf-k8s-controllers/pull/576


Suggestion : Remove infrastructure from Ripsaw

Currently Ripsaw attempts to manage other operators, which has been a struggle.
Why did we have Ripsaw launch other operators?
We wanted to have the application be managed via the Operator framework for testing the workload, and to provide an end to end solution.
What is wrong with this approach?
It causes complexity that we continuously have to work around. Broken CI, which slows down our ability to accept PRs
What can we do to replace/remove this dependency for infrastructure?
Instead of Ripsaw managing other operators, we could have our CI/Testing use statefulsets to deploy applications like mongodb, and we simply update our YCSB CR to point at the mongodb deployed with statefulsets.

The approach of having an operator manage/launch another operator might not be necessarily novel, but still waiting to hear from the operator-sdk community on how they tackle an operator launching/managing another operator and its resources.
I vote in favor of it, as there doesn't seem to be a clear/supported way of doing this that's provided by the operator framework

It will be much simpler for us to focus efforts on Ripsaw running only workloads, that's for certain. However, since we have discussed a completely automated benchmark lifecycle, we cannot accomplish that end-to-end without also automating the infrastructure/application under test. If we remain committed to the end-to-end automation, then something will need to take the place of Ripsaw in standing up the application stacks. It seems inefficient to maintain another tool outside of Ripsaw to do this job.
If, on the other hand, we are willing to defer to the Ripsaw user to first deploy and configure the application as a prerequisite, then sure, let's get rid of the infras altogether.
I'm not sure that this alleviates the CI problem much at all, regardless. The pain is in automating the stand-up and tear-down of the infra, and if we still need to automate this inside the CI in order to validate the workload, then we still have most of the same headaches. If we can automate it for the CI, why not leverage it in the benchmark workflow directly?
Whether we deploy infras via other operators or just use pods or stateful sets is a separate question, I think. Testing some stateful applications properly may almost necessitate an operator-based deployment.

It will be much simpler for us to focus efforts on Ripsaw running only workloads, that's for certain. However, since we have discussed a completely automated benchmark lifecycle, we cannot accomplish that end-to-end without also automating the infrastructure/application under test. If we remain committed to the end-to-end automation, then something will need to take the place of Ripsaw in standing up the application stacks. It seems inefficient to maintain another tool outside of Ripsaw to do this job.
If, on the other hand, we are willing to defer to the Ripsaw user to first deploy and configure the application as a prerequisite, then sure, let's get rid of the infras altogether.

My suggestion was to remove the operator aspect. This gets us out of the discussion of which operator we support. We could still provide a mechanism to deploy mariadb/mongodb/etc just without using an operator.
If we wanted to keep some form of infra in Ripsaw to have a end-to-end I think we simply go with the above approach.

I'm not sure that this alleviates the CI problem much at all, regardless. The pain is in automating the stand-up and tear-down of the infra, and if we still need to automate this inside the CI in order to validate the workload, then we still have most of the same headaches. If we can automate it for the CI, why not leverage it in the benchmark workflow directly?

Not suggesting it is the silver-bullet for CI, however it does seem to always be a pain-point (operator managing other operators).

Whether we deploy infras via other operators or just use pods or stateful sets is a separate question, I think. Testing some stateful applications properly may almost necessitate an operator-based deployment.

If an application requires an operator based deployment, I think we defer that application to be deployed outside of Ripsaw. For example, if Couchbase doesn't have a straight-forward way for us to deploy using statefulsets -- similar to the work @aakarshgopi did with mongodb, I suggest we defer the user to Couchbase documentation on operator based deployments, but discuss how we point Ripsaw's YCSB CR at an existing Couchbase DB.

My suggestion was to remove the operator aspect. This gets us out of the discussion of which operator we support -- For example today there are two mongodb and postgres Operators on Operatorhub.io. We could still provide a mechanism to deploy postgres/mongodb/etc just without using an operator.

Alright, this doesn't jive with your issue title here. If we want to keep infras, where reasonable, but not deploy those infras via other operators, then we will still need to maintain some structure to the repo and the CI system accordingly. I'm still thinking about PR #104 and how to get better organized in general, so this decision can affect that.

If we wanted to keep some form of infra in Ripsaw to have a end-to-end I think we simply go with the above approach.

So we by default rule out any lifecycle automation of a workload that requires an infra that is best deployed via operator? Maybe that won't be an issue in the end, but I'm trying to think ahead to what could get in our way as we expand workloads.

Not suggesting it is the silver-bullet for CI, however it does seem to always be a pain-point (operator managing other operators).

The layered operator is part of the problem, though I think I've mostly solved that with the finalizer and some adjustments to how the catalogsource is deployed. The other and probably bigger problem is that we likely cannot use one basic approach to an operator-based infra for both k8s and OCP 4. This second problem might bite us in a very similar way even if using statefulsets for infra.

If an application requires an operator based deployment, I think we defer that application to be deployed outside of Ripsaw. For example, if Couchbase doesn't have a straight-forward way for us to deploy using statefulsets -- similar to the work @aakarshgopi did with mongodb, I suggest we defer the user to Couchbase documentation on operator based deployments, but discuss how we point Ripsaw's YCSB CR at an existing Couchbase DB.

Fair enough.

Our intent is to test the performance of the platform. However, if CrunchyDB or name your favorite database operator wants to test their specific implementation of SQL - there is no reason they couldn't use Ripsaw. Our focus shouldn't be the application, it is platform + application, not a specific implementation.

So to my question about what to do with the work already put into the existing infras... Do we maintain the work somehow, or scrap it altogether. I see three approaches:

Scrap it. We can reference the work in forks and dev branches as needed.
Keep it in Ripsaw, but in an "unsupported" or "experimental" structure of some kind that bypasses CI.
Move it into something like SNAFU for reference outside of ripsaw but inside of cloud-bulldozer.

As agreed on the call, we've removed all infra from Ripsaw. To ensure that the work we put into, can still be made use of and leveraged, I created an infra-operator codenamed cloud-builder. This has all the roles and work related to infra. I've also tried to test mongo and it worked fine. I also tried postgres on minikube but ran into some issues.
closing this as #122 got merged and removed the current-infra that we'd


Capture more auditing metadata in the lock file

(From https://github.com/pypa/pipenv/pull/1865#issuecomment-377440298)
The --keep-outdated and --pre options to pipenv lock mean that re-running pipenv lock without those options may result in a different lock file.
Lock file generation is also inherently time dependent: if you want to recreate a previously locked lock file from a given Pipfile, you need to exclude any releases that weren't available at the time that lock file was generated.
I believe adding the following three fields to the lock files _meta section would provide enough info to allow a historical lock file to be reconstructed:

locked_at: when the Pipfile.lock was generated (so an auditing and/or recreation tool knows to exclude any releases made after that date and time)
kept_versions: which versions in the current lock file have been retained from a previous version of the lock file by --keep-outdated (a list of package names would suffice, since the exact versions are down in the package entries)
prereleases_allowed: boolean setting

Although, given --keep-outdated, perhaps the locked_at metadata should be on the individual entries? Then it could be carried forward to each new version, and the lock file would inherently track how long it had been since each dependency had been updated.
Alternatively, instead of a kept_versions field, there could be an outdated_versions field that recorded which packages had newer versions available at the time the lock file was generated that met the Pipfile constraints, but had been ignored due to --keep-outdated.

@ncoghlan my rough understanding of the underlying implementation is that —keep-outdated should make no effort to update anything that doesn’t conflict with the specified package. That saves us having to re-download and run setup.py against various packages which can really speed things up. That might be wrong or it might require keeping actual specifiers in the lockfile along with pins.
For _meta we may want to differentiate a few things: generated_at, updated_at, and perhaps a list of keys representing top level packages so we can operate without a Pipfile?
Possibly we would want to store for each package then: specifiers, locked_at, updated_at, requires?
Requirement metadata is out of scope I realize, just tossing it in as a piece of the data structure puzzle as we think about the hierarchy

Checking "What's the latest available version?" should only need a single query to the index server's simple API per package, so building a list of outdated packages should be much cheaper than actually resolving those versions. I agree it would be more expensive than skipping build that list, though.
The "operate-without-a-Pipfile" question is an interesting one, as it raises the question of whether or not a hash is the best way to be detecting the "Pipfile changed since Pipfile.lock was last generated" situation: since TOML supports comments, there are plenty of cosmetic changes that can be made without really altering the file from a dependency resolution perspective - the real questions are "Did the top level dependencies change?" and "Did the project settings that affect dependency resolution change?".

I've been thinking about this general question of "assessing lockfile freshness" a bit, and realised that another useful date to track would be when pinned dependencies were last checked for security vulnerabilities.
I think if we had a well-defined concept of what it meant for a lock file to be "fresh" or "stale", then we could potentially warn about stale lock files when relying on them, and recommend running pipenv check or pipenv lock to refresh them.
And given that kind of warning on pipenv sync and pipenv install, then it could become reasonable to switch pipenv install itself over to a minimalist --selective-upgrade as the default behaviour, rather than opportunistically updating everything to the latest available version by default.

How often would we recommend that I wonder?

I'm not sure, as the most suitable default varies based on the kind of code you're writing.
However, my initial inclination would be towards emitting a warning after something like 90 days (~3 months) or 180 days (~6 months), as "You should check your dependencies for security vulnerabilities at least 2-4 times a year" seems like a pretty reasonable maintenance recommendation to me. While it's honestly a bit low for full-time professional software development, it's much higher than is typical for hobbyist projects, and should also be manageable for work projects that are nevertheless a sideline to someone's main job.
pipenv install and pipenv sync could then accept a --fresh-until N option to say that entries are considered fresh until N days after they were either last updated, or last checked for security vulnerabilities.


Single item crafting (feature request)

Issue description:
When requesting multiple items of same type, and inventory can accept it from craffter (ex. chest), all items for all requested item are pushed if available in system.
What happens:
Some machines can craft only one item per time, but have more items slots in inventory and this broke recipe for crafting, or buffor is required before crafting ex: Runic Altar from Botania or items need to be split through few inventories (ex. Fusion Crafting from Draconic evolution or Empowerment from Actaully Additions)
What you expected to happen:
Option in crafter or module for crafter that allow single item craft when multiple of them is requested.
Items for next operation are pushed when previous crafting is done and crafted item is in system.
Steps to reproduce:
Version (Make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: <IP_ADDRESS>4
Refined Storage: 1.2.22

Does this issue occur on a server? [yes/no] yes
If a (crash)log is relevant for this issue, link it here:

already in 1.11. might get on 1.10 eventually


Self-Hosted agent configuration will ambiguously fail authorization when organization URL has trailing slashes

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops#required-options
It may be helpful to point out that the CLI doesn't seem to take trailing slashes; it just gives a VS30063: You are not authorized to access $url error.

@cutecycle -- Nina, thank you for your suggestion.
@steved0x -- Steve, please look into this issue.


Combine webpack 3 PRs

What kind of change does this PR introduce?
PR combine

Does this PR introduce a breaking change?
yes

PRs
https://github.com/webpack/webpack/pull/4764
https://github.com/webpack/webpack/pull/4738
https://github.com/webpack/webpack/pull/4704
https://github.com/webpack/webpack/pull/4144
https://github.com/webpack/webpack/pull/4143

Got this warning during the build:
(node:84752) DeprecationWarning: Chunk.modules is deprecated. Use Chunk.getNumberOfModules/mapModules/forEachModule/containsModule instead.

You can use node --trace-deprecation to find the origin.

Out of curiosity, what level of speed improvement are you seeing with these changes?


Upgrade to pangeo-forge-recipes==0.9.4

@scottyhq another bump to the pangeo-forge-recipes version. Apologies for the quick succession of PRs. Turns out there was a bug in the release added by #420, so made a quick follow-on release of 0.9.4.

Yes, looks like it! Thanks so much @scottyhq.
I noticed on #420 that you manually conda-locked the PR.
For my future reference, when is this necessary? (Guessing not here, because all tests are passing.)

The CI is not well setup for simultaneous PRs (if one is merged while another is open there tend to be merge conflicts in the lockfiles, so you have to rebase/merge and relock)

Gotcha! Makes sense.


Have request specs handle errors like production

Currently request specs that cause HTTP errors like 404 via RecordNotFound will raise exceptions instead of responding with 404.
Do one of these:

without_error_debugging (previously with_rails_error_handling) in a spec/support/error_helper.rb that is included with request specs: https://github.com/rails/rails/pull/11289#issuecomment-118612393
OR
Comment out action_dispatch.show_exceptions = false in config/environments/test.rb and set action_dispatch.show_detailed_exceptions = true

Prefer without_error_debugging option used as needed in specs. The 2nd option may suppress useful error information in other tests.

As an aside, this Rails change from 2010 is where the action_dispatch.show_exceptions = false was added to the test environment config. Its not yet clear what the reason was for choosing this as the default for all new Rails apps.
https://rails.lighthouseapp.com/projects/8994/tickets/4315-raise-exceptions-instead-of-rendering-exceptions-templates-in-test-environment

# spec/support/error_responses.rb
module ErrorResponses

  # See: https://github.com/rails/rails/pull/11289#issuecomment-118612393
  def respond_without_detailed_exceptions
    env_config = Rails.application.env_config
    original_show_exceptions = env_config["action_dispatch.show_exceptions"]
    original_show_detailed_exceptions = env_config["action_dispatch.show_detailed_exceptions"]
    env_config["action_dispatch.show_exceptions"] = true
    env_config["action_dispatch.show_detailed_exceptions"] = false
    yield
  ensure
    env_config["action_dispatch.show_exceptions"] = original_show_exceptions
    env_config["action_dispatch.show_detailed_exceptions"] = original_show_detailed_exceptions
  end

end

RSpec.configure do |config|
  config.include ErrorResponses, type: :request
end

Usage:
    it "responds with 400 Bad Request HTTP status for no params" do

      no_parameters = {}.to_json

      respond_without_detailed_exceptions do
        post "/api/v1/sessions", no_parameters, json_request_headers
      end

      expect(response).to have_http_status(:bad_request)
      expect(response.content_type).to eq("application/json")

      expect(json).to eq(status: "400", error: "Bad Request")
    end

To configure within a spec to have all examples use production-like error handling:
  around :each do |example|
    respond_without_detailed_exceptions do
      example.run
    end
  end

WIP: incorporating the above into #96

Closed by #96

Very useful, thank you!

@brunofacca Since this change its been refined a little further, latest code is at https://github.com/eliotsykes/rails-testing-toolbox/blob/master/error_responses.rb

Thanks for this. Looks like the usage guide is no longer available. Is it posted elsewhere?


this nullptr assumption with As

Part of C++ the standard is that calling a method on a pointer that is nullptr, is undefined behavior. This is even the case if the method does not access this. Moreover if a method tries to test for nullptr, it is too late because a test of (this == nullptr) is determined to always be false because this can never be nullptr, because that is undefined behavior. Both gcc and clang detect this producing warnings and/or replacing the test with the result this can never be nullptr.
Slang did have code that assumed this could be tested for nullptr used in As where the intention was that you could do
Blah* x = thing->As<Blah>();

And inside of As it would test for nullptr, thus handling the case if thing was nullptr.
Unfortunately because of the standard it is not possible to have a method that works this way. The code base has been adjusted such the test is removed, and from the test suit any time the problem was hit code was added to handle the case outside of the cast.
This is a somewhat fragile fix - because there could be correct slang code that does take a path that passes nullptr into As.
A suggested solution was to do the casting with a free function, and then this free function can do the test for nullptr, before anything else is done. Something like
template <typename T>
T* dynamicCast(Type* in)
{
   if (in)
   {
       return nullptr;
   }
   /// ... do cast
   return ...;
}

Using dynamicCast instead of As will mean there will never be the issue of this being nullptr.
Concerns are that this will hit a lot of code, and if you know that the pointer isn't nullptr, then the test is unnecessary. If we try and unify around a mechanism lets say 'dynamicCast' then we can only determine different versions of implementation based on unique type. So having having two implementations one for RefObject and one for something derived from RefObject could create problems.
We could work around this problem by giving the casting method a different name if it has a different behavior.

Final issues have been cleared up with #831


I want to promote Langchain in China and publish a book about it. Can I have your permission?

Issue you'd like to raise.
My name is Even Kang and I am a Chinese developer studying Langchain in China. We have translated the Langchain Chinese documentation (www.langchain.asia / www.langchain.com.cn) and launched the website on May 7th. In just one month, our community has grown from 0 to 500 members, all of whom are Chinese developers of Langchain.
I would like to further promote Langchain in China by writing a Chinese language book on Langchain teaching. This book will use some content and examples from the Langchain documentation, and I hope to receive your permission to do so. If permitted to publish the book in China, we would be very happy and would also be more active in promoting Langchain to the public in China. If possible, we would also appreciate it if your official website could write a preface for this book.
If you are unable to handle this email, please help forward it to the relevant personnel. Thank you. We look forward to your reply.
Suggestion:
No response

MIT also applies to Langchain doc, right? Thank you!

Yes, all part of the same GitHub repository.

Thank you!      ---------------<<@


Are you trusting client information here?

Are you trusting client information here?
Shouldn't we use server-side authentication info?
https://github.com/oshalygin/gqlgen-pg-todo-example/blob/master/resolvers/todo.go#L46

Oh yes certainly @frederikhors , but that would dive far into the complexity side of things and I am refraining from that.  Surely we can mint tokens and set it on the request context, but I want to keep this repo as lean as possible.

Ok.


Support Qwen2VL

Description
Add ColQwen2
Added

Add Qwen2-VL support

Changed

Greatly simplify routing logic in Trainer selection and when feeding arguments to the model forward pass (refacto)
Bumped transformers version to 4.45.0 to get Qwen2-VL support

Fixed

Fix bug in HardNegCollator since 0.3.0

Notes: Tentative PR
Still some things to fix / figure out:

How do we deal with the variable image resolution (and not squared)
--> allow for arbitrary shape ? set it in the config ? arbitrary is probably best but code should be adapted to be okay with that !
-> what perf impact does it make ?
Padding (left vs right, what can be done etc)
verifying that token pre-processing is "sufficiently" in domain and makes sense (I think it does)

Variable Image Resolution:
Qwen2-VL supports Naive Dynamic Resolution, allowing it to handle arbitrary image shapes. We can set the minimum and maximum vision tokens in the config file like this. We can go for max tokens similar to the paligemma model to keep the memory requirement low.

Padding:
The model uses left padding by default, and we can keep it this way.

Added

Add Qwen2-VL support

Changed

Greatly simplify routing logic in Trainer selection and when feeding arguments to the model forward pass (refacto)
Bumped transformers version to 4.45.0 to get Qwen2-VL support

Fixed

Fix bug in HardNegCollator since 0.3.0

@tonywu71 pretty sure we can merge and release 0.3.1

LGTM! Can you address the few comments I've made pls?
Before merging, I'll add a commit to rename the all the *qwen2*.py to *qwen_2*.py to follow the name convention that we chose for idefics_2 and colpali_2.

Why though ? The model is named Qwen2, not Qwen_2, and similarly, the HF modeling files are named modeling_qwen2_vl...
So I don't agree with adding an underscore for no reason... But at the same time I don't really care so do it if you want haha ;)

LGTM! Can you address the few comments I've made pls?
Before merging, I'll add a commit to rename the all the *qwen2*.py to *qwen_2*.py to follow the name convention that we chose for idefics_2 and colpali_2.

Why though ? The model is named Qwen2, not Qwen_2, and similarly, the HF modeling files are named modeling_qwen2_vl... So I don't agree with adding an underscore for no reason... But at the same time I don't really care so do it if you want haha ;)

Ah you're right, I thought they had used an underscore in transformers but I was wrong! Let's keep it like that, and I'll rename colpali_2 to colpali2 in https://github.com/tonywu71/transformers/tree/main 😉


How to Activate Shopify Web Pixel Extension on Production Store?

Issue:
Hi, I'm trying to activate a Shopify web pixel extension on a production store. The web pixel extension is configured in the Shopify Remix app template. The backend is wired to Express.js.
What I've tried:
Approach_1:
I was able to activate it on the dev/test store using the Shopify app dev GraphQL by following this guide https://shopify.dev/docs/apps/build/marketing-analytics/build-web-pixels#:~:text=To activate a web pixel,extension.
However, I couldn't apply it on the production store since i cannot run shopify app dev on production store to open up the shopify GraphQL console.
mutation {
  # This mutation creates a web pixel, and sets the `accountID` declared in `shopify.extension.toml` to the value `123`.
  webPixelCreate(webPixel: { settings: "{\"accountID\":\"123\"}" }) {
    userErrors {
      code
      field
      message
    }
    webPixel {
      settings
      id
    }
  }
}

Approach_2:
I've also tried this guide that activates the pixel using shopify remix app's loader function. Unfortunately it didn't work as well.  https://community.shopify.com/c/extensions/how-do-you-actually-activate-the-web-pixel/m-p/2496617
shopify remix app template > app app._index.jsx
export const loader = async ({ request }) => { // Authenticate with Shopify const { admin } = await authenticate.admin(request);
const mutationResponse = await admin.graphql( #graphql
        mutation webPixelCreate($webPixel: WebPixelInput!) {
          webPixelCreate(webPixel: $webPixel) {
            userErrors {
              field
              message
            }
            webPixel {
              settings
              id
            }
          }
        }
      , { variables: { webPixel: { settings: { "accountID": 'Account_ID_45466_this_is_as_per_toml'
}, }, }, } );
if (!mutationResponse.ok) { console.error('Request failed', mutationResponse); return; }
const data = await mutationResponse.json(); console.log(data);
return mutationResponse;
};

const loaderDataForWebPixel = useLoaderData();

Is it Working For You ? Which approach did you take ?


Improve chat markdown, don't allow embeds in live streams

[ ] also check what happens on live streams (right now you can embed images)
[ ] see what Xander posted in live stream chat with nested indents
[ ] make links open in new tabs

This was getting brought up and abused in the salty stream

Would be better to leave the embeding images on chat feature as optional for the user if its possible


Use a more consistent paginated endpoint for fetching all prisoners for activity candidates

The previously used endpoint would have occasionally returned the list in a different order, which would have messed up the pagination on the frontend. This endpoint is more consistent

Codecov Report
Patch and project coverage have no change.

Comparison is base (30c9b51) 84.96% compared to head (c74d728) 84.96%.

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #419   +/-   ##
=========================================
  Coverage     84.96%   84.96%
  Complexity     2103     2103
=========================================
  Files           285      285
  Lines          7997     7997
  Branches        457      457
=========================================
  Hits           6795     6795
  Misses          942      942
  Partials        260      260

Impacted Files
Coverage Δ

...t/prisonersearchapi/api/PrisonerSearchApiClient.kt
40.90% <0.00%> (ø)

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


add webhooks folder and article titles

Docs Build status updates of commit 6b980b5:
:warning: Validation status: warnings

File
Status
Preview URL
Details

msteams-platform/messaging-extensions/how-to/action-based-commands/respond-to-task-module-submit.md
:warning:Warning

Details

msteams-platform/index.md
:warning:Warning

Details

msteams-platform/webhooks/Allow outside apps to post team content with incoming webhooks
:white_check_mark:Succeeded

msteams-platform/webhooks/Post messages to outside apps with outgoing webhooks
:white_check_mark:Succeeded

msteams-platform/messaging-extensions/how-to/action-based-commands/respond-to-task-module-submit.md

Line 12: [Warning] Invalid file link:(~/foo.md).
Line 13: [Warning] Illegal link: `<a href="#respond-with-a-task-module">Another task module</a>` -- missing bookmark. The file messaging-extensions/how-to/action-based-commands/respond-to-task-module-submit.md doesn't contain a bookmark named respond-with-a-task-module. NOTE: This Suggestion will be elevated to a Warning on 8/26/2019. Please fix invalid bookmarks as soon as possible.
Line 278: [Warning] Invalid file link:(~/foo.md).
Line 280: [Warning] Invalid file link:(~/includes/messaging-extensions/learn-more.md).

msteams-platform/index.md

[Warning] Illegal link: `<a href="#get-started">Get Started</a>` -- missing bookmark. The file index.md doesn't contain a bookmark named get-started. NOTE: This Suggestion will be elevated to a Warning on 8/26/2019. Please fix invalid bookmarks as soon as possible.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Cannot view monitoring page while garbage collection running

Gitea version (or commit ref): d077fd0
Git version: 2.9.3
Operating system: Ubuntu 16.10
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[X] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[X] No (I do not have admin access)
[ ] Not relevant

Log gist:

Description
I cannot access monitoring while garbage collection is running. I get this error: "template: admin/monitor:52:15: executing "admin/monitor" at <.Pid>: Pid is not a field of struct type *process.Process"
How to reproduce:

Upload some repositories (so it takes some time to do garbage collection)
Run the garbage collection action in the admin
While it is running, try and view the monitoring page in the admin

https://github.com/go-gitea/gitea/blob/d077fd084a3cc8d96ba80d8fcf950b21523644b2/templates/admin/monitor.tmpl#L52

fixed by #1037


update to v15

— I updated incrementally all angular versions
— updated the flagpack-core package from 0.0.43 to 2.0.0 (newest version)
Build succeeds, maybe it's usable, it's my first contribution to open source & my first angular package creation/update
Let me know, if I can improve something

@daoneandonly ready for review


Update README.md with PhearJS link

For a while I have been working on PhearJS now, to the point that it's pretty stable. Because the other mentioned resources are aimed towards testing and not scraping, PhearJS might be good addition.

We would consider adding your project to http://phantomjs.org/related-projects.html, but it is not nearly prominent or widely-used enough to get mentioned in the README, sorry.


Alphabetical order

I wish I could reorder my CSS alphabetically. Way of arranging should be customizable in Settings page (issue #2).

:+1:


Use Submariner 0.14.1 in KIND deployments

Signed-off-by: Sridhar Gaddam<EMAIL_ADDRESS>

/cc @tpantelis @skitt

/lgtm
/approve


Can't "restart" notebook debug session

Start debugging a cell
Click "restart"
Get an error about a missing debug adapter descriptor

Need to handle debugging being started this way too, not just through the command

Is this it? this is the only error I get

That's not it - it will fail to start because it calls our debug adapter descriptor factory without doing the setup that we do when the command is run.

Why wouldn't it be supported?

Its not supported today in Interactive window, hence I'm assuming its the same reason its not supported in run by line as well.
Either we fix it (which we haven't for over 2 years the bug has been around) or we notify users via a message.
I'm up for fixing it, thats better than some hacky warning about not supporting something (when it works in traditional Python).


Fix common data issues

Fixes and improvements for common-data

Please @juanignaciosl check this PR. Thx

restest this please

retest this please

I've done a couple of not important comments, LGTM :+1:

retest this please

retest this please

retest this please

retest this please


Projection handling function

@Rikuoja
This bounds min/max seems odd:
https://github.com/City-of-Helsinki/bestpractice/blame/master/docs/resources/maps.md#L103
Idea is to pick X and Y of northwest corner?

Yeah, doesn't it work correctly?

Well, bounds here is an array, not a bounds object with min.x and max.y attributes 😬
I wanted to clarify what's actually required (and how to get the bounds correctly)

Argh, well yeah the northwest is the one that we need, if I read this correctly 😁


path resolve is not support folder

Describe the bug
A clear and concise description of what the bug is.
System Info

required vite version:0.11.3
required Operating System:
required Node version:10.13.0
Optional:

npm/yarn version
Installed vue version (from yarn.lock or package-lock.json)
Installed @vue/compiler-sfc version

Logs

why ?

use import { IS_PRD } from './utils/index.js' instead

use import { IS_PRD } from './utils/index.js' instead

some packages used import xxx from 'xxx' in node_modules directory


Rust: Buffer with capacity

@andygrove Is it possible to create empty Buffer with allocated data of given size, so we can allocate Buffer and then fill data?

Yes, absolutely. You should create a builder using this method: https://github.com/apache/arrow/blob/master/rust/src/builder.rs#L40-L49
Then call slice_mut to get the buffer that you can write to.
Finally, call finish to get the Buffer<T>

@andygrove Perfect, thanks!


Unable to use pregenerated XML

config.delete[:pregenerated]

… should (at least) be
config.delete(:pregenerated)

Source: https://github.com/jameskilton/rbgccxml/blob/b8fb1f8427273c9a114029986b7b7920359f1c69/lib/rbgccxml/parser.rb#L11

As a workaround, instead of using RbGCCXML.parse, I did this funny little thing:
my_hash = { pregenerated: path_to_pregenerated_xml }
class << my_hash
  alias :delete :to_hash
end

rbgccxml_parsed_xml = RbGCCXML.parse([], my_hash

It’s a solution for now.

See #9 for further discussion. This in particular is fixed.


MINOR: Add attributes processedKeys and processedValues to MockProcessorSupplier

This would allow for easier testing of topologies using the following pattern:
// in Scala
val builder = new KStreamBuilder
val stream: KStream[K, V] = builder.stream(KSerde, VSerde, topic)

val processedStream: KStream[K, VR] =createTopology(stream, builder)

val processorSupplier = new MyMockProcessorSupplier[K, VR]
processedStream.process(processorSupplier)

val streamDriver = new MyKStreamTestDriver(builder, TestUtils.tempDirectory())
streamDriver.setTime(0L)

streamDriver.process(topic, somethingK, somethingV)
streamDriver.flushState()

val results = (processorSupplier.processedKeys zip processorSupplier.processedValues).toMap
results(expectedK) should be(expectedVR)

Without breaking any existing tests that rely on the processed ArrayList. Of course it's not as elegant as rewriting the logic here, as we're (almost) duplicating the information in the processed array.
@guozhangwang any thoughts?

I'm wondering if the above testing could still be supported in the existing processed API? I.e. what's the difference between
results(expectedK) should be(expectedVR)

and
val results = processorSupplier.processed
results should be (expectedKVString)

The use case is supported, but it feels more natural to keep the objects with the type information intact.
Not sure the proposed API here with processedKeys and processedValues is that great though.
With this approach we could either

deprecate processed or
compute it on the fly based on the two others as not to break code or
leave it as originally proposed in this PR even though we're duplicating some data

I'm not sure why processed today contains strings, but I guess part of it is wanting something like an array of tuples - which would be ideal, but not trival in Java.

I agree that processed returning a string in format of key:value is not intuitive, because originally when we design the API we were not particularly interested in making it general as it is an internal class only which is not exposed to users.
But as I have observed more and more people like you who have been very actively using this package in their own unit testing I start thinking maybe it's a good idea to expose o.a.k.test for better testability for Streams users, for example. Will try to create a more general story JIRA and include this PR as a sub-task to consider.

Thanks @guozhangwang,
I think that will be a good step in the right direction. Feel free to link to the ticket here when you've made it!

I’d say it depends on what soon is. If soon is 1 month, then lets leave this. If it’s 6, then consider merging it or something similar.

@mewwts Thanks for the feedback. We have a JIRA for adding mocks: https://issues.apache.org/jira/browse/KAFKA-6473 But no concrete timeline. I'll just merge this so it can be shipped with 1.1 release.

Thanks for the PR.
Merged to trunk and 1.1 branch.

Great! Thanks @mjsax 👍


Inline markup shouldn't greedily consume trailing whitespace.

The parser currently introduces an awkward situation by greedily consuming whitespace trailing the command. This is fine for many cases where the whitespace will be insignificant, but in the case of inline markup this ruins the typesetting of the line.
For example in the current SILE manual on page 8 (section 1.3) the following code:
into \em{frames} on

…is rendering without a space after the italicized word 'frames':

into frameson

I've just run SILE on the documentation file again, and I do get a space after "frames". I think what happened was that I was fiddling with the documentation and also the regression tests while still working on getting the grammar correct, and I must have accidentally checked in a version of the manual compiled while the grammar was still broken. But the manual is also broken for other reasons (text overflowing the frame at the bottom of that page, for instance), so I'll sort it separately.
Anyway, the grammar is correct, I think:
local lineEndLineStartSpace = (lpeg.S(" ")^0 * lpeg.S("\r\n")^1 * lpeg.S(" ")^0)^-1


Build step timeout without any error message

I want to deploy a static reach website using Amplify but the application is timing out  in the build step without any actionable error message
region: US West (Oregon)us-west-2
app id: d2isybtpucqc1p

[x] Reviewed existing issues
[x] Researched online forums for a solution
[x] Reviewed FAQ
[ ] More details on why the build failed / timed out

yml file
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - yarn install
    build:
      commands:
        - yarn run build
  artifacts:
    # IMPORTANT - Please verify your build output directory
    baseDirectory: /
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*
test:
  artifacts:
    baseDirectory: cypress
    configFilePath: '**/mochawesome.json'
    files:
      - '**/*.png'
      - '**/*.mp4'
  phases:
    preTest:
      commands:
        - npm ci
        - npm install wait-on
        - npm install pm2
        - npm install mocha mochawesome mochawesome-merge mochawesome-report-generator
        - npx pm2 start npm -- start
        - 'npx wait-on http://localhost:8080'
    test:
      commands:
        - 'npx cypress run --reporter mochawesome --reporter-options "reportDir=cypress/report/mochawesome-report,overwrite=false,html=false,json=true,timestamp=mmddyyyy_HHMMss"'
    postTest:
      commands:
        - npx mochawesome-merge cypress/report/mochawesome-report/mochawesome*.json > cypress/report/mochawesome.json
        - npx pm2 kill

Build Log
                                 # Starting phase: preBuild
                                 # Executing command: yarn install
2021-06-16T16:41:39.572Z [INFO]: yarn install v1.22.0
2021-06-16T16:41:39.687Z [INFO]: [1/4] Resolving packages...
2021-06-16T16:41:40.105Z [INFO]: [2/4] Fetching packages...
2021-06-16T16:41:53.680Z [INFO]: info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2021-06-16T16:41:53.682Z [INFO]: info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
                                 info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
                                 info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2021-06-16T16:41:53.682Z [INFO]: [3/4] Linking dependencies...
2021-06-16T16:41:53.685Z [WARNING]: warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>2021-06-16T16:41:53.695Z [WARNING]: warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>2021-06-16T16:41:53.696Z [WARNING]: warning " ><EMAIL_ADDRESS>has unmet peer dependency "mocha@>=7".
2021-06-16T16:42:05.749Z [INFO]: [4/4] Building fresh packages...
2021-06-16T16:42:16.934Z [INFO]: Done in 37.37s.
2021-06-16T16:42:16.958Z [INFO]: # Completed phase: preBuild
                                 # Starting phase: build
2021-06-16T16:42:16.958Z [INFO]: # Executing command: yarn build
2021-06-16T16:42:17.082Z [INFO]: yarn run v1.22.0
2021-06-16T16:42:17.104Z [INFO]: $ npm-run-all clean webpackBuild server
2021-06-16T16:42:17.355Z [INFO]: $ rm -rf dist/
2021-06-16T16:42:17.671Z [INFO]: $ webpack --mode production --config webpack.build.config
2021-06-16T16:42:23.925Z [INFO]: Hash:<PHONE_NUMBER>460fc1ace7
                                 Version: webpack 4.46.0
                                 Time: 5533ms
                                 Built at: 06/16/2021 4:42:23 PM
                                 Asset       Size  Chunks                    Chunk Names
                                 ./index.html  607 bytes          [emitted]
                                 public/css/main.css   4.02 KiB       0  [emitted]         main
                                 public/imgs/home-symbol.png   1.44 KiB          [emitted]
                                 public/imgs/lake.jpg    232 KiB          [emitted]
                                 public/js/bundle.js    321 KiB       0  [emitted]  [big]  main
                                 Entrypoint main [big] = public/css/main.css public/js/bundle.js
                                 [5] (webpack)/buildin/harmony-module.js 573 bytes {0} [built]
                                 [6]<EMAIL_ADDRESS>+ 1 modules 459 bytes {0} [built]
                                 |    2 modules
                                 [7] ./src/js/config/constants.js 1.2 KiB {0} [built]
                                 [8] ./node_modules/history/esm/history.js + 2 modules 30.6 KiB {0} [built]
                                 |    3 modules
                                 [11] ./src/js/layout/Layout.js 1.74 KiB {0} [built]
                                 [22] ./node_modules/formik/dist/formik.esm.js + 114 modules 145 KiB {0} [built]
                                 |    115 modules
                                 [80] ./src/js/App.js 4.71 KiB {0} [built]
                                 [81] ./src/js/routing/Routes.js 2.48 KiB {0} [built]
                                 [82] ./src/js/pages/Home.js 2.04 KiB {0} [built]
                                 [89] ./src/js/pages/About.js 3.01 KiB {0} [built]
                                 [91] ./src/js/pages/Awards.js 4.31 KiB {0} [built]
                                 [92] ./src/js/pages/Feedback.js 7.47 KiB {0} [built]
                                 [93] ./src/js/pages/ContactUs.js 4.45 KiB {0} [built]
                                 [101] ./src/index.js 566 bytes {0} [built]
                                 [223] ./src/css/main.css 39 bytes {0} [built]
                                 + 238 hidden modules
                                 WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
                                 This can impact web performance.
                                 Assets:
                                 public/js/bundle.js (321 KiB)
                                 WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
                                 Entrypoints:
                                 main (325 KiB)
                                 public/css/main.css
                                 public/js/bundle.js
                                 WARNING in webpack performance recommendations:
                                 You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
                                 For more info visit https://webpack.js.org/guides/code-splitting/
                                 Child html-webpack-plugin for "index.html":
                                 1 asset
                                 Entrypoint undefined = ./index.html
                                 [0] ./node_modules/html-webpack-plugin/lib/loader.js!./src/index.html 289 bytes {0} [built]
                                 Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!src/css/main.css:
                                 Entrypoint mini-css-extract-plugin = *
                                 [1] ./node_modules/css-loader/dist/cjs.js!./src/css/main.css 1.61 KiB {0} [built]
                                 [2] ./node_modules/css-loader/dist/cjs.js!./src/css/variables.css 376 bytes {0} [built]
                                 [3] ./node_modules/css-loader/dist/cjs.js!./src/css/helpers.css 751 bytes {0} [built]
                                 [4] ./node_modules/css-loader/dist/cjs.js!./src/css/global.css 723 bytes {0} [built]
                                 [5] ./node_modules/css-loader/dist/cjs.js!./src/css/typography.css 386 bytes {0} [built]
                                 [6] ./node_modules/css-loader/dist/cjs.js!./src/css/layout.css 1.5 KiB {0} [built]
                                 [7] ./node_modules/css-loader/dist/cjs.js!./src/css/skipnav.css 470 bytes {0} [built]
                                 [8] ./node_modules/css-loader/dist/cjs.js!./src/css/homelink.css 521 bytes {0} [built]
                                 [9] ./node_modules/css-loader/dist/cjs.js!./src/css/primarynav.css 549 bytes {0} [built]
                                 [10] ./node_modules/css-loader/dist/cjs.js!./src/css/forms.css 1.17 KiB {0} [built]
                                 + 1 hidden module

                                 Entrypoint undefined = ./index.html
                                 [0] ./node_modules/html-webpack-plugin/lib/loader.js!./src/index.html 289 bytes {0} [built]
                                 Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!src/css/main.css:
                                 Entrypoint mini-css-extract-plugin = *
                                 [1] ./node_modules/css-loader/dist/cjs.js!./src/css/main.css 1.61 KiB {0} [built]
                                 [2] ./node_modules/css-loader/dist/cjs.js!./src/css/variables.css 376 bytes {0} [built]
                                 [3] ./node_modules/css-loader/dist/cjs.js!./src/css/helpers.css 751 bytes {0} [built]
                                 [4] ./node_modules/css-loader/dist/cjs.js!./src/css/global.css 723 bytes {0} [built]
                                 [5] ./node_modules/css-loader/dist/cjs.js!./src/css/typography.css 386 bytes {0} [built]
                                 [6] ./node_modules/css-loader/dist/cjs.js!./src/css/layout.css 1.5 KiB {0} [built]
                                 [7] ./node_modules/css-loader/dist/cjs.js!./src/css/skipnav.css 470 bytes {0} [built]
                                 [8] ./node_modules/css-loader/dist/cjs.js!./src/css/homelink.css 521 bytes {0} [built]
                                 [9] ./node_modules/css-loader/dist/cjs.js!./src/css/primarynav.css 549 bytes {0} [built]
                                 [10] ./node_modules/css-loader/dist/cjs.js!./src/css/forms.css 1.17 KiB {0} [built]
                                 + 1 hidden module
2021-06-16T22:16:30.755Z [INFO]: $ node server.js
2021-06-16T22:16:30.858Z [INFO]: Server started on port 8080

Hi, seems like you start a server in build phase, so build stuck and timed out after 30 mins.

Thanks, so one which step should I start the server?

Something in your build is running node server.js, likely as part of the yarn run build command.  Remove anything that is running node server.js from the build script in the package.json and move it so it only runs as part of the npx pm2 start npm -- start command in your preTest phase.  Since you've deleted the app, I'm going to resolve this.  Please cut a new issue and reference this if you follow this guidance and have issues.


Feature for making symlinks relative

Sometimes it is desired that symlinks point to relative locations not to absolute ones. For example if a link in dir1 points to some file inside dir1 and then dir1 is moved or renamed. Then, if the link was relative instead of absolute, it is still functioning.

Was auto-closed by git. Reopening so it will be closed with PR #140


We need a way to hide the tray icon

Description of the new feature / enhancement
I feel there's has to be an option to hide the tray icon.
Scenario when this would be used?
I want a clean desktop
Supporting information
No response

Duplicate of #9526

Thanks for your suggestion! This issue is a duplicate.
I'm linking this issue to #9526 to centralize the discussion thread, please go to that thread for discussion.
Thanks for your help to make PowerToys a better piece of software!


Fixed typo for Brave Browser version 1.23.69.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

/azp run


Pass props to React Native TabNavigator

Hi All,
I'd like to get props from storybook/index.js and pass it to my components to control my router.
As my screen is a TabNavigator, my idea is to get the props and set it as the value of initialRouteName.
"@storybook/addon-actions": "^3.3.12",
 "@storybook/addon-links": "^3.3.12",
 "@storybook/addons": "^3.3.12",
"@storybook/react-native": "^3.3.12",

import Temp2 from "./temp2";

...

storiesOf("TabNavigator", module)
  .add("Home", () => <TabNavigator route="Home" />);
  .add("Setting", () => <TabNavigator route="Setting" />);
  .add("Account", () => <TabNavigator route="Account" />);

In my TabNavigator
export default TabNavigator(
  {
    Home: {
      screen: Home,
    },
    Account: {
      screen: Account,
    }
  },
  {
    initialRouteName: this.props.route
  }
);

How can I get the "route" props as "Home" in my component?

Got the answer!
Just warp your TabNavigator in a React component.
export default class Tab extends React.Component {
  render() {
    const MainTab = TabNavigator(
      {
        Temp1: {
          screen: Temp1
        },
        Temp2: {
          screen: Temp2
        }
      },
      {
        initialRouteName: this.props.route
      }
    );
    return (
      <View style={{ flex: 1 }}>
        <MainTab />
      </View>
    );
  }
}

storiesOf("Temp", module)
  .add("Temp2", () => {
    return <Tab route="Temp2" />;
  });

You are good to go 👍