The bottom drawer is now expanded by default

General information
Associated issues:  #208
Checklist
Author:

[X] One or more reviewers have been assigned.
[ ] Automated tests have been included in this pull request, if possible, for the new feature(s) or bug fix.
[X] The associated GitHub issues are included (above).
[X] Notes have been included (below).

Reviewers:

[ ] All automated checks are passing (green check next to latest commit).
[ ] At least one reviewer has signed off on the pull request.  Reviewers have two business days to review the pull request, after which the author may merge in the pull request unilaterally.

Notes

The Pathway table is now shown by default.
When creating a new network, it should fit the available network area.

@mikekucera:
I noticed that the newly created network doesn't fit the canvas area properly, but I can't figure out why.
The controller is calling  this.cy.fit(DEFAULT_PADDING) on _setZoomMinMax() after applying the layout, but if you click the "Fit Figure to Screen" button after creating a network or restoring it to its initial layout, it then zooms out a little bit more to fit it as expected.
Could you please help me find the problem here?

Its because the first time fit() is called before the compound nodes are added to the network.

I'll fix it and add a commit to this branch

Nevermind that didn't fix it, still working on it 😤

Ok I think I got it.
The fit() function must be called after... 1) the compound nodes are created, 2) the style is applied, 3) the labels are ready.
Currently node.data('label') is set in the SearchControler.fetchAllPathwaysInNetwork() function. So the extra width of the labels isn't taken into account when the network itself is done loading, because the labels aren't set until after the pathway list is fetched.
I propose we go back to the previous way of doing labels, using the memoized function in network-style.js that's currently commented out (but without the truncation). I would create a utility function for parsing the pathway name and share it between network-style.js and the SearchController
What do you think?

Ok, let's do that then. Thanks!


HTML

#HTML
User Story
As a bootcamp student
I want the prework notes to be structured on a webpage
so that I can easily find and read information
Acceptance Criteria
GIVEN a Prework Study Guide Website
WHEN I visit the site in my browser
THEN I see four boxes titled HTML, CSS, GIT and JavaScript with associated notes listed

done


Torch flash mode for Camera (including Video)

Hello!
Is it real to implement torch flash mode?
Thank you.

Why would anyone want torch flash mode, in a library devoted to taking pictures and recording videos?

Thank you for the quick response.
I am developing an application in which I want to provide users torch flash mode while taking photos or recording videos. It is useful feature while using camera in the dark. Also stock camera on most devices does it.

OK, I'll look into adding this in a future update.

Dear @commonsguy,
Thanks you for your concern on this feature. I would like to implement this feature but I'm kind of getting lost in the process. My initial thought is if I can somehow gain access to the underlying Camera of ClassicCameraEngine then I can do something like this:
            params = camera.getParameters();
            params.setFlashMode(Parameters.FLASH_MODE_TORCH);
            camera.setParameters(params);

However both ClassicCameraEngine and CameraTwoEngine are singleton and there's no way to access the underlying Camera object.
Would you please give me a starting point on how to properly implement this?
Thanks you so much for your time.

Hi @commonsguy, no need to worry about this anymore. I've partially solve this issue. All thanks to your awesome lib.

Hello @vxhviet!
Could you show the way you gain access to the Camera please?
Thank you!

pls check out my updated comment

Problem solved, I'll put complete code here when I've finished putting everything together.
In a meanwhile, look at @batrand comment in  issue #126 for the code snippet.

Complete solution:
In FlashMode add the following:
public enum FlashMode {
  ...
  TORCH(Camera.Parameters.FLASH_MODE_TORCH,
          CameraCharacteristics.FLASH_MODE_TORCH);
  ....

  static FlashMode lookupClassicMode(String classicMode) {
   ....
    else if (classicMode.equals(TORCH.getClassicMode())) {
      return(TORCH);
    }

    return(null);
  }

  static FlashMode lookupCameraTwoMode(int cameraTwoMode) {
    ....
    else if (cameraTwoMode==TORCH.getCameraTwoMode()) {
      return(TORCH);
    }

    return(null);
  }
  ....
}

In your fragment extended from CameraFragment:
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        ...
        if(mHasFlash){
            mFlashButton = (ImageView)v.findViewById(R.id.mycwac_cam2_flash_button);
            mFlashButton.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View v) {
                    if(mIsFlashOn){
                        addFlashMode(FlashMode.OFF);
                        mIsFlashOn = false;
                    }else{
                        addFlashMode(FlashMode.TORCH);
                        mIsFlashOn = true;
                    }
                }
            });
        }
        ...
        if(mHasFlash){mFlashButton.setEnabled(false);}
        ...
}

private void addFlashMode(FlashMode flashmode){
        try {
            ctlr.stop();
            ArrayList<FlashMode> newFlashMode = new ArrayList<>();
            newFlashMode.add(flashmode); // This is the flash mode you want to change to
            ctlr.getEngine().setPreferredFlashModes(newFlashMode);
            ctlr.start();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
}

public void onEventMainThread(CameraEngine.OpenedEvent event) {
        if (event.exception==null) {
            ...
            if(mHasFlash){mFlashButton.setEnabled(true);}
            ...
        }
        ...
}

private void recordVideo() {
        ...
        else {
            try {
                ...
                if(mHasFlash){
                    mFlashButton.setEnabled(false);
                    mFlashButton.setVisibility(View.INVISIBLE);
                }
                ...
            }
            ...
        }
}

private void setVideoFABToNormal() {
        if(mHasFlash){mFlashButton.setEnabled(true);}
        ...
}

Feel free to re-enable the visibility of your flash button. In my app, it return after finishing recording so it's unnecessary.
I've also try to enable/disable flash while recording but the CameraController get reset in addFlashMode so the recording get stopped whenever flash button is clicked. Because of that I kind of mimic the way the stock camera handle this torch feature. I haven't tested this carefully so feel free to try it and correct me if I'm wrong.

Addressed in v0.6.0.


No event handler for long press?

On a long-press of a tag, the rest of the tags in the taglistview become unselected, which is an interesting and potentially useful behavior, but there is no event generated for the application to respond to the new selected tag-set.

Same issue, any solution?

same here


Transparency Loss in Palletized PNG Files - Regression in Version 3.0

Hello!
In version 3.0, there is a regression issue related to the loss of transparency in palette-based PNG files.
input.png
from PIL import Image
from pilkit.processors.utils import resolve_palette

img = Image.open('input.png')
new_img = resolve_palette(img)
new_img.save('output.png')

As a result of executing the provided code, the output image will lose its transparency and appear on a white background.
The root cause of the error is that, despite the image having transparency, the image.palette.mode property is equal to RGB.
Related commit

Hello @pix666, the regression you mentioned is caused by the fix of #44. Because I don't have so much free time (consider my late reply), can you try to think/test a solution that will work for your case and to still address the mentioned issue?

I will try to release new version in the coming days. Thank you again for your time.


no criminal investigations against HC

Thoughts on this?
He could end up prosecuting her later on, but as far as I remember he did promise this was on the top of his agenda.

Maybe these two policies should be merged?

Included in https://github.com/TrumpTracker/trumptracker.github.io/commit/f875f1888a6b35316faf8c27173940ae06d0cc0b


Fix debug C++03 builds with recent GCC versions.

Fix a runtime error that occurs when building Ninja in debug mode
with -std=c++03 and a recent GCC release. E.g.:
CXXFLAGS='-std=c++03' ./configure.py --debug --bootstrap && ./ninja_test

Will fail with:
bootstrapping ninja...
wrote build.ninja.
bootstrap complete.  rebuilding...
[31/31] LINK ninja
[10/384] BuildLogTest.MultiTargetEdge/usr/include/c++/11/debug/vector:445:
In function:
    std::__debug::vector<_Tp, _Allocator>::const_reference
    std::__debug::vector<_Tp,
    _Allocator>::operator[](std::__debug::vector<_Tp,
    _Allocator>::size_type) const [with _Tp = Node*; _Allocator =
    std::allocator<Node*>; std::__debug::vector<_Tp,
    _Allocator>::const_reference = Node* const&; std::__debug::vector<_Tp,
    _Allocator>::size_type = long unsigned int]

Error: attempt to subscript container with out-of-bounds index 0, but
container only holds 0 elements.

Objects involved in the operation:
    sequence "this" @ 0x0x55968842c0a0 {
      type = std::__debug::vector<Node*, std::allocator<Node*> >;
    }
Aborted

The root of the problem is that an expression like &(some_vector[0])
triggers runtime checks in the debug version of recent libstdc++ libraries,
which cause the failure above.
This issue was previously already worked-around for C++11 with the use of data(),
but this wasn't fixed for C++03. It is assumed here that the GCC/libstdc++ version
used on CI/CQ for C++03 verification are just older and do not include this runtime
check.
Fixing the issue allows developers to verify that their local modifications do
pass the C++03 build in debug mode (used during debugging) without having to install
an older toolchain or rely on CI/CQ.

Is this PR needed after https://github.com/ninja-build/ninja/pull/2089 is merged?

should be fixed now :)


Keystone engine error

I'm having an error when building wheel for keystone engine as the setup requirement has no path. I'm sure this is something on my end, however if anyone has the same issue and a solution it would be greatly appreciated.

Hi

@OGDirtBag113415 Please send the complete error log.


Support previous encoding versions.

Do we want to keep backwards-compatible on encoding? I'm not sure about this but Go allows bytes in previous versions: https://github.com/census-instrumentation/opencensus-go/blob/master/tag/map_codec.go#L191

Coverage remained the same at 81.583% when pulling 0106863b22a1e1ae4ebb3205daa7cbb3e199db21 on songy23:serialize into d6af87a040dd4f19e50e6298867d5f90f0122c90 on census-instrumentation:master.

Codecov Report

Merging #901 into master will not change coverage.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #901   +/-   ##
=========================================
  Coverage     79.52%   79.52%
- Complexity      938      939    +1
=========================================
  Files           159      159
  Lines          4170     4170
  Branches        396      396
=========================================
  Hits           3316     3316
  Misses          770      770
  Partials         84       84

Impacted Files
Coverage Δ
Complexity Δ

.../implcore/tags/propagation/SerializationUtils.java
94.91% <100%> (ø)
18 <0> (+1)
: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 d6af87a...0106863. Read the comment docs.

@bogdandrutu previously deserialize() will reject bytes encoded in older binary versions. However if we decided to keep backwards-compatible on encoding versions, I think it's better for deserialize() code with higher version to decode bytes in former versions.
On the other hand, if the bytes are encoded in a higher version than deserialize() code, deserialize() should still reject it.


Adding missing functions.

amin(), amax(), complex(), and polar() were all missing. Now they're not.

Tests failing due to floating point tolerance error in allclose(). Looking into mitigation.


multiple OnPositionChangedListener is not supported

i can't use multiple listener ☹ if you want i can help you

I've been out of the Android development world for a little while now, but are multiple listeners typically supported in libraries?
Can you not reasonably achieve what you need via one listener and then delegating out to others?

I will mention, the help is always appreciated. It's what keeps this library maintained.
Before you spend any development time on it, please convince me of the necessity of it. Then I'd be happy to accept a PR


Workspace - Error message for invalid phone number invite disappears fast

Details
Error message for invalid phone number invite disappears fast
On src/pages/workspace/WorkspaceMembersPage.js
clientMemberEmails should be filtered to only pass valid members, failure to do so will remove all non-exisiting members that should be displayed (e.g. non-exisiting members that should report an error) this is due to the merge from Onyx.
Every valid member has the "role" property, thus the filter is based on that property.
Fixed Issues
$ https://github.com/Expensify/App/issues/12265
PROPOSAL: https://github.com/Expensify/App/issues/12265#issuecomment-1307889721
Tests

Login with any account
Go to Settings -> Workspaces -> Select any workspace -> Manage members -> Invite
Invite any random non valid user (use an invalid phone number)
Make sure you see an error
Close sidebar
Open sidebar
Go to Settings -> Workspaces -> Select any workspace -> Manage members
Verify that the error is still there and verify that it won't disappear

[X] Verify that no errors appear in the JS console

QA Steps

Login with any account
Go to Settings -> Workspaces -> Select any workspace -> Manage members -> Invite
Invite any random non valid user (use an invalid phone number)
Make sure you see an error
Close sidebar
Open sidebar
Go to Settings -> Workspaces -> Select any workspace -> Manage members
Verify that the error is still there and verify that it won't disappear

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[X] I linked the correct issue in the ### Fixed Issues section above
[X] I wrote clear testing steps that cover the changes made in this PR

[X] I added steps for local testing in the Tests section
[X] I added steps for Staging and/or Production testing in the QA steps section
[X] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[X] I included screenshots or videos for tests on all platforms
[X] I ran the tests on all platforms & verified they passed on:

[X] iOS / native
[X] Android / native
[X] iOS / Safari
[X] Android / Chrome
[X] MacOS / Chrome
[X] MacOS / Desktop

[X] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[X] I followed proper code patterns (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product was added in all src/languages/* files
[X] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I followed the guidelines as stated in the Review Guidelines
[X] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] If a new component is created I verified that:

[X] A similar component doesn't exist in the codebase
[X] All props are defined accurately and each prop has a /** comment above it */
[X] The file is named correctly
[X] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[X] The only data being stored in the state is data necessary for rendering and nothing else
[X] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[X] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[X] All JSX used for rendering exists in the render method
[X] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots
Web
https://user-images.githubusercontent.com/16493223/202011484-c7134be8-89b7-46ae-9032-abb04e5bd8e6.mp4
Mobile Web - Chrome
https://user-images.githubusercontent.com/16493223/202011534-a8be2dc7-c2f1-4841-8f64-7ac69c1aeadb.mp4
Mobile Web - Safari
https://user-images.githubusercontent.com/16493223/202011567-7b19333b-77cf-42cf-bb70-d3c0beee5e19.mp4
Desktop
https://user-images.githubusercontent.com/16493223/202011605-2796e645-3233-4a88-afcf-4c2edc6fb4b4.mp4
iOS
https://user-images.githubusercontent.com/16493223/202011672-bf07927a-4b68-4ab7-983d-501194c037d2.mp4
Android
https://user-images.githubusercontent.com/16493223/202011750-109d29e1-8485-4a71-ab53-d9da9e29d7bb.mp4

I have read the CLA Document and I hereby sign the CLA

@jasperhuangg You accidentally deleted an extra line and I didn't catch that. Fixed now

The code from componentDidMount and componentDidUpdate is the same, we could extract it into a separate method, something like
    /**
     * Get members for the current workspace
     */
    getWorkspaceMembers() {
        /**
         * clientMemberEmails should be filtered to only pass valid members, failure to do so
         * will remove all non-existing members that should be displayed (e.g. non-existing members that should display an error).
         * This is due to how calling `Onyx::merge` on array fields overwrites the array.
         * see https://github.com/Expensify/App/issues/12265#issuecomment-1307889721 for more context
         */
        const clientMemberEmails = _.keys(_.pick(this.props.policyMemberList, member => member.role));
        Policy.openWorkspaceMembersPage(this.props.route.params.policyID, clientMemberEmails);
    }

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://user-images.githubusercontent.com/9059945/202226626-379c9c27-af75-4e3a-a365-69110bfaa660.mov

Mobile Web - Chrome

https://user-images.githubusercontent.com/9059945/202226574-d3b2b8e6-fee2-4229-aa15-b63a01cc5acd.mp4

Mobile Web - Safari

https://user-images.githubusercontent.com/9059945/202226665-17df5b65-179e-4687-8d2c-01ea3bb7d7d1.mov

Desktop

https://user-images.githubusercontent.com/9059945/202226691-06207a7b-3c7a-48b2-a039-efeda235cc8c.mov

iOS
https://user-images.githubusercontent.com/9059945/202226731-a57c8598-53f6-45be-8a83-4b1689f57c64.mov

Android

https://user-images.githubusercontent.com/9059945/202226533-f5d2552d-405f-483c-b3d9-8585bb0fdadf.mp4

🚀 Deployed to staging by @jasperhuangg in version: 1.2.29-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@jasperhuangg @eVoloshchak
I think we should adapt the second approach https://github.com/Expensify/App/issues/12265#issuecomment-1307889721

The proposed fix is only to pass members that have the "role" property (or not to pass those who have "pendingAction" and/or "errors" properties).

We should pass every member except those who have pendingAction or errors because on the first approach if we add a user but it was rejected then remove the error, that user use will not have role prop thus it won't be synced and it will stay on the workspace members list stuck

The issue happen when trying to remove a user that was rejected.
I think the issue is more related to the remove function, we should filter to only be able to remove members that are actually members. so I think the followed approach here is actually the correct one we just need to do the same with the remove function

Never mind, we chose the right approach.
If curious about the above problem it's covered here https://github.com/Expensify/App/issues/13034

FYI: I believe this PR caused this bug: https://github.com/Expensify/App/issues/15267


Always asks to restart

Updated to 20.02-2 yesterday. Keep getting messag e"It is detected that the Webmin web-server daemon was not restarted correctly on the last package upgrade....Manually restart using /etc/webmin/restart command". Restart works, but I keep getting this message every time I login to webmin. Don't know how to fix this. On
Redhat Enterprise Linux 6
Linux 2.6.32-754.35.1.el6.x86_64 on x86_64
Authentic theme: 20.02-2
Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, 12 cores

@iliajie any suggestions as our resident systemd expert?

I think the user installed Authentic Theme alone (ignoring a warning message) without installing Webmin itself.


Added missing section headers in Nautobot Version 2.0 release overvie…

Closes: #3303
What's Changed

Added missing section headers in the Nautobot Version 2.0 release overview and added TODO comments.
TODO

[x] Explanation of Change(s)
[x] Added change log fragment(s) (for more information see the documentation)
[ ] Attached Screenshots, Payload Example
[ ] Unit, Integration Tests
[x] Documentation Updates (when adding/changing features)
[ ] Example Plugin Updates (when adding/changing features)
[ ] Outline Remaining Work, Constraints from Design

Whoops - shouldn't this be against develop rather than next?

Whoops - shouldn't this be against develop rather than next?

In the story it was said to target next but it might be outdated. I will rebase to develop


Repository name is too general

The name of this repository makes sense as PowerShell/Modules but not rjmholt/Modules. Is it possible to rename this repo while it's in the early stages to something that makes sense as a standalone repo/fork/directory name?

Sort of being discussed here:
https://github.com/PowerShell/Modules/issues/27
Pretty easy to fix after fork, just edit the repository name. See:
https://github.com/JustinGrote/PowershellOfficialModules
I'm OK with it as-is, even if it is initially unintuitive.
On Fri, Feb 14, 2020 at 2:33 PM Robert Holt<EMAIL_ADDRESS>wrote:

The name of this repository makes sense as PowerShell/Modules but not
rjmholt/Modules. Is it possible to rename this repo while it's in the
early stages to something that makes sense as a standalone
repo/fork/directory name?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/Modules/issues/43?email_source=notifications&email_token=ADUNKURK6HRX7AJPSCOOVTLRC4L3BA5CNFSM4KVQ7IS2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INWGQWA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADUNKUX52AJBQF4D46UVJC3RC4L3BANCNFSM4KVQ7ISQ
.


Checkbox: Using the max attribute can limit the number of items that …

…can be checked (#14742)
Please make sure these boxes are checked before submitting your PR, thank you!

[x] Make sure you follow Element's contributing guide (中文 | English | Español | Français).
[x] Make sure you are merging your commits to dev branch.
[x] Add some descriptions and refer relative issues for you PR.

Checkbox: Using the max attribute can limit the number of items that can be checked (#14742)

@masongzhi
https://deploy-preview-15585--element.netlify.com/#/zh-CN/component/checkbox#ke-xuan-xiang-mu-shu-liang-de-xian-zhi
有 bug
实际：反选北京，上海变成 disabled
期望：反选北京，其他选项都应该是可选状态

@luckyCao min=1、max=2，我认为是至少选一个，所以剩下一个选项时不能取消选择

@luckyCao 抽出了isLimitDisabled computed


Update README.md

CATEGORY
Choose one

[ ] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS

Welcome aboard!

Codecov Report

Merging #8246 into master will increase coverage by 0.14%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8246      +/-   ##
==========================================
+ Coverage   65.58%   65.73%   +0.14%
==========================================
  Files         481      481
  Lines       23319    23319
  Branches     2572     2572
==========================================
+ Hits        15294    15328      +34
+ Misses       7887     7853      -34
  Partials      138      138

Impacted Files
Coverage Δ

superset/views/core.py
70.41% <0%> (+0.21%)
:arrow_up:

superset/models/core.py
81.93% <0%> (+0.63%)
:arrow_up:

superset/dataframe.py
94.48% <0%> (+1.57%)
:arrow_up:

superset/db_engine_specs/mysql.py
92.15% <0%> (+49.01%)
: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 0cd4ef5...c18e51e. Read the comment docs.


Helm3 test, supporting resources are also included as part of helm test status and considered as individual test

helm3 version : v3.4.1
The supporting resources required for test execution such as configmap and service accounts are considered as separate tests and included as part of helm test status.
`[root@vm-10-75-112-163 ckaf-kafka]# helm3 test alkf
NAME: alkf
LAST DEPLOYED: Mon Jan 24 12:46:36 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: kf-alkf-kf-test-sa
Last Started: Mon Jan 24 12:51:12 2022
Last Completed: Mon Jan 24 12:51:12 2022
Phase: Succeeded
TEST SUITE: kf-alkf-kf-test-configmap
Last Started: Mon Jan 24 12:51:11 2022
Last Completed: Mon Jan 24 12:51:12 2022
Phase: Succeeded
TEST SUITE: kf-alkf-kf-testpod-status
Last Started: Mon Jan 24 12:51:13 2022
Last Completed: Mon Jan 24 12:52:15 2022
Phase: Succeeded
`
How these supporting resources can be excluded from the helm test status
Note: the sa and configmap have the annotation : test, since they need to be spawned only when the helm test event is called.

hi @bacongobbler,
can you please take a look.
Thanks

/support


[Feature] Edit Speech Info.

Edit those speeches which upload to the database.

This could use Table and Modal. So that here no needs to route to another route, like  /:s_no/:speech_id/edit or /:s_no/edit/:speech_id/

Should the SpeechForm componet submit data to Serve?

Finish!


Require email verification before logging in

This code would simply break down both signup and login forms, can't merge. But you certainly spotted a missing thing here, validating the email confirmation. I'm gonna implement it but using a Django `EMAIL_CONFIRMATION_REQUIRED' setting, so it can be optional to force users confirm email before being able to log in.


server crash when going through a nether or end portal

Description
Going through the nether or end portal crashes instaltly the server
Reproduction steps
Plugins and mods installed: GriefDefender 1.5.10, LP 5.2.76, create mod 0.3e and JEI for 1.16.4
Running with: Forge .58 and mohist 400 for 1.16.5

Open the server.
Use a portal.
see crash log:  crash-2021-03-14_14.22.08-server.txt

(I also tried with 5.3.0 + a PR to solve mohist compatibility, but still happens)

I dont see how this is related to luckperms?

Okey, my bad, pretty new on this and the crash error shows something about LuckPerms +  only OP players can go through nether/end portal


probe-rs-cli: Panic while flashing ELF executable to nRF52840 DK

Describe the bug
Flashing an elf using probe-rs-cli panics with the following message:
thread 'main' panicked at 'Overlap in data, address 0x00000974 was already written earlier. This is a bug, please report it.', probe-rs/src/flashing/builder.rs:250:25

Reproduced with a nRF52840 DK board using the master branch of probe-rs (Commit ID: 2445d24ce58788d658e1f51c1fffc25b1aac9064).
To Reproduce
Steps to reproduce the behavior:

Connect nRF52840 DK
Run the following command to trigger the issue:

RUST_LOG=debug cargo run --bin=probe-rs-cli -- download --chip nRF52840_xxAA ../ate_repo/build/targets/stack_overflow_app

Expected behavior
The ELF program can be flashed without panicking.
Stacktrace
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `target/debug/probe-rs-cli download --chip nRF52840_xxAA ../ate_repo/build/targets/stack_overflow_app`
 DEBUG jaylink > libusb <IP_ADDRESS>97
 DEBUG jaylink > libusb has capability API: true
 DEBUG jaylink > libusb has HID access: true
 DEBUG jaylink > libusb has hotplug support: true
 DEBUG jaylink > libusb can detach kernel driver: true
 DEBUG jaylink > open_usb: device descriptor: DeviceDescriptor {
    bLength: 0x12,
    bDescriptorType: 0x1,
    bcdUSB: 0x200,
    bDeviceClass: 0xef,
    bDeviceSubClass: 0x2,
    bDeviceProtocol: 0x1,
    bMaxPacketSize: 0x40,
    idVendor: 0x1366,
    idProduct: 0x1015,
    bcdDevice: 0x100,
    iManufacturer: 0x1,
    iProduct: 0x2,
    iSerialNumber: 0x3,
    bNumConfigurations: 0x1,
}
 DEBUG jaylink > scanning 4 interfaces
 DEBUG jaylink > J-Link interface is #2
 DEBUG probe_rs::probe::daplink::tools > Device Bus 006 Device 001: ID 1d6b:0003
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 005 Device 001: ID 1d6b:0002
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 004 Device 001: ID 1d6b:0003
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 003 Device 003: ID 0b05:18f3
 DEBUG probe_rs::probe::daplink::tools > No device matches
 DEBUG probe_rs::probe::daplink::tools > Device Bus 003 Device 024: ID 1038:12b3
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 003 Device 023: ID 1366:1015
 DEBUG probe_rs::probe::daplink::tools > No device matches
 DEBUG probe_rs::probe::daplink::tools > Device Bus 003 Device 001: ID 1d6b:0002
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 002 Device 001: ID 1d6b:0003
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 001 Device 003: ID 8087:0029
 DEBUG probe_rs::probe::daplink::tools > No device matches
 DEBUG probe_rs::probe::daplink::tools > Device Bus 001 Device 002: ID 05e3:0610
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 001 Device 039: ID 413c:2113
 DEBUG probe_rs::probe::daplink::tools > No device matches
 DEBUG probe_rs::probe::daplink::tools > Device Bus 001 Device 040: ID 046d:c534
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Device Bus 001 Device 001: ID 1d6b:0002
 DEBUG probe_rs::probe::daplink::tools > Device open error Access
 DEBUG probe_rs::probe::daplink::tools > Attempting to open 1366:1015 in CMSIS-DAP v1 mode
 DEBUG probe_rs::probe::stlink::usb_interface > Acquired libusb context.
 DEBUG jaylink                                > open_usb: device descriptor: DeviceDescriptor {
    bLength: 0x12,
    bDescriptorType: 0x1,
    bcdUSB: 0x200,
    bDeviceClass: 0xef,
    bDeviceSubClass: 0x2,
    bDeviceProtocol: 0x1,
    bMaxPacketSize: 0x40,
    idVendor: 0x1366,
    idProduct: 0x1015,
    bcdDevice: 0x100,
    iManufacturer: 0x1,
    iProduct: 0x2,
    iSerialNumber: 0x3,
    bNumConfigurations: 0x1,
}
 DEBUG jaylink                                > scanning 4 interfaces
 DEBUG jaylink                                > J-Link interface is #2
 DEBUG jaylink                                > legacy caps: GET_HW_VERSION | READ_CONFIG | WRITE_CONFIG | SPEED_INFO | GET_MAX_BLOCK_SIZE | GET_HW_INFO | RESET_STOP_TIMED | SELECT_IF | GET_COUNTERS | GET_CPU_CAPS | EXEC_CPU_CMD | SWO | REGISTER | INDICATORS | TEST_NET_SPEED | GET_CAPS_EX
 DEBUG jaylink                                > extended caps: GET_HW_VERSION | READ_CONFIG | WRITE_CONFIG | SPEED_INFO | GET_MAX_BLOCK_SIZE | GET_HW_INFO | RESET_STOP_TIMED | SELECT_IF | GET_COUNTERS | GET_CPU_CAPS | EXEC_CPU_CMD | SWO | REGISTER | INDICATORS | TEST_NET_SPEED | GET_CAPS_EX | HW_JTAG_WRITE
 DEBUG probe_rs::probe::jlink                 > Attaching to J-Link
 DEBUG probe_rs::probe::jlink                 > Attaching with protocol 'SWD'
 INFO  probe_rs::probe::jlink                 > J-Link: S/N: 683057576
 DEBUG probe_rs::probe::jlink                 > J-Link: Capabilities: GET_HW_VERSION | READ_CONFIG | WRITE_CONFIG | SPEED_INFO | GET_MAX_BLOCK_SIZE | GET_HW_INFO | RESET_STOP_TIMED | SELECT_IF | GET_COUNTERS | GET_CPU_CAPS | EXEC_CPU_CMD | SWO | REGISTER | INDICATORS | TEST_NET_SPEED | GET_CAPS_EX | HW_JTAG_WRITE
 INFO  probe_rs::probe::jlink                 > J-Link: Firmware version: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 17 2020 14:43:00
 INFO  probe_rs::probe::jlink                 > J-Link: Hardware version: JLink 1.0.0
 INFO  probe_rs::probe::jlink                 > J-Link: Target voltage: 3.30 V
 DEBUG probe_rs::probe::jlink::swd            > Performing line reset!
 DEBUG probe_rs::probe::jlink                 > Sucessfully switched to SWD
 DEBUG probe_rs::probe::jlink                 > Attached succesfully
 DEBUG probe_rs::config::registry             > Searching registry for chip with name nRF52840_xxAA
 DEBUG probe_rs::probe::jlink::swd            > Performing 1 transfers (0 additional transfers)
 DEBUG probe_rs::probe::jlink::swd            > Transfer result 0: Ok(2ba01477)
 DEBUG probe_rs::architecture::arm::communication_interface > Debug Port version: DPv1
 DEBUG probe_rs::architecture::arm::communication_interface > Reading DP register DPIDR
 DEBUG probe_rs::probe::jlink::swd                          > Performing 1 transfers (0 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(2ba01477)
 DEBUG probe_rs::architecture::arm::communication_interface > Read    DP register DPIDR, value=0xDPIDR { .0: 2ba01477, revision: 2, part_no: ba, min: false, version: 1, designer: 23b, jep_cc: 4, jep_id: 3b }
 DEBUG probe_rs::architecture::arm::communication_interface > DebugPort ID:  DebugPortId {
    revision: 0x2,
    part_no: 0xba,
    version: DPv1,
    min_dp_support: NotImplemented,
    designer: JEP106Code({ cc: 0x04, id: 0x3b } => Some("ARM Ltd")),
}
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register ABORT, value=0xAbort { .0: 1e }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 1 transfers (0 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: 0, ap_sel: 0, ap_bank_sel: 0, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Requesting debug power
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register CTRL/STAT, value=0xCtrl { .0: 50000001, csyspwrupack: false, csyspwrupreq: true, cdbgpwrupack: false, cdbgpwrupreq: true, cdbgrstack: false, c_dbg_rst_req: false, trn_cnt: 0, mask_lane: 0, w_data_err: false, read_ok: false, sticky_err: false, stick_cmp: false, trn_mode: 0, sticky_orun: false, orun_detect: true }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Reading DP register CTRL/STAT
 DEBUG probe_rs::probe::jlink::swd                          > Performing 1 transfers (0 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(f0000041)
 DEBUG probe_rs::architecture::arm::communication_interface > Read    DP register CTRL/STAT, value=0xCtrl { .0: f0000041, csyspwrupack: true, csyspwrupreq: true, cdbgpwrupack: true, cdbgpwrupreq: true, cdbgrstack: false, c_dbg_rst_req: false, trn_cnt: 0, mask_lane: 0, w_data_err: false, read_ok: true, sticky_err: false, stick_cmp: false, trn_mode: 0, sticky_orun: false, orun_detect: true }
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register IDR
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 0, AP_BANK_SEL to 15
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: f0, ap_sel: 0, ap_bank_sel: f, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(261)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(24770011)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    IDR, value=0xIDR { REVISION: 2, DESIGNER: 23b, CLASS: MEMAP, _RES0: 0, VARIANT: 1, TYPE: AMBA_AHB3 }
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register IDR
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 1, AP_BANK_SEL to 15
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: 10000f0, ap_sel: 1, ap_bank_sel: f, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(24770011)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(24770011)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(2880000)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    IDR, value=0xIDR { REVISION: 0, DESIGNER: 144, CLASS: Undefined, _RES0: 0, VARIANT: 0, TYPE: JTAG_COM_AP }
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register IDR
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 2, AP_BANK_SEL to 15
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: 20000f0, ap_sel: 2, ap_bank_sel: f, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(2880000)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(2880000)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(0)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    IDR, value=0xIDR { REVISION: 0, DESIGNER: 0, CLASS: Undefined, _RES0: 0, VARIANT: 0, TYPE: JTAG_COM_AP }
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register IDR
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 0, AP_BANK_SEL to 15
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: f0, ap_sel: 0, ap_bank_sel: f, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(24770011)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    IDR, value=0xIDR { REVISION: 2, DESIGNER: 23b, CLASS: MEMAP, _RES0: 0, VARIANT: 1, TYPE: AMBA_AHB3 }
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register BASE
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(24770011)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(e00ff003)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    BASE, value=0xBASE { BASEADDR: e00ff, _RES0: 0, Format: ADIv5, present: true }
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register BASE2
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(e00ff003)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(0)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    BASE2, value=0xBASE2 { BASEADDR: 0 }
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register CSW, value=CSW { DbgSwEnable: 1, HNONSEC: 1, PROT: 6, CACHE: 3, SPIDEN: 0, _RES0: 0, MTE: 0, Type: 0, Mode: 0, TrinProg: 0, DeviceEn: 0, AddrInc: Single, _RES1: 0, SIZE: U8 }
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 0, AP_BANK_SEL to 0
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: 0, ap_sel: 0, ap_bank_sel: 0, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(0)
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register CSW
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(23000050)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    CSW, value=0xCSW { DbgSwEnable: 0, HNONSEC: 0, PROT: 2, CACHE: 3, SPIDEN: 0, _RES0: 0, MTE: 0, Type: 0, Mode: 0, TrinProg: 0, DeviceEn: 1, AddrInc: Single, _RES1: 0, SIZE: U8 }
 DEBUG probe_rs::architecture::arm::communication_interface > HNONSEC supported: false
 DEBUG probe_rs::architecture::arm::communication_interface > AP 0: MemoryAp(MemoryApInformation { port_number: 0, only_32bit_data_size: false, debug_base_address:<PHONE_NUMBER>, supports_hnonsec: false })
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register IDR
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 1, AP_BANK_SEL to 15
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: 10000f0, ap_sel: 1, ap_bank_sel: f, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(23000050)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(23000050)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(2880000)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    IDR, value=0xIDR { REVISION: 0, DESIGNER: 144, CLASS: Undefined, _RES0: 0, VARIANT: 0, TYPE: JTAG_COM_AP }
 DEBUG probe_rs::architecture::arm::communication_interface > AP 1: Other { port_number: 1 }
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register CSW, value=CSW { DbgSwEnable: 0, HNONSEC: 1, PROT: 2, CACHE: 3, SPIDEN: 0, _RES0: 0, MTE: 0, Type: 0, Mode: 0, TrinProg: 0, DeviceEn: 0, AddrInc: Single, _RES1: 0, SIZE: U32 }
 DEBUG probe_rs::architecture::arm::communication_interface > Changing AP to 0, AP_BANK_SEL to 0
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0xSelect { .0: 0, ap_sel: 0, ap_bank_sel: 0, dp_bank_sel: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(2880000)
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(2880000)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e000edf0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(2880000)
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register DRW
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(2880000)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    DRW, value=0xDRW { data: 1010001 }
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e000ed30 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 1f }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e000edf0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: a05f0001 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register CSW, value=CSW { DbgSwEnable: 0, HNONSEC: 1, PROT: 2, CACHE: 3, SPIDEN: 0, _RES0: 0, MTE: 0, Type: 0, Mode: 0, TrinProg: 0, DeviceEn: 0, AddrInc: Single, _RES1: 0, SIZE: U32 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e0002000 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(1010001)
 DEBUG probe_rs::architecture::arm::communication_interface > Reading register DRW
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(1010001)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Read register    DRW, value=0xDRW { data: 261 }
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e0002008 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e000200c }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e0002010 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e0002014 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e0002018 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register TAR, value=TAR { address: e000201c }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register DRW, value=DRW { data: 0 }
 DEBUG probe_rs::probe::jlink::swd                          > Performing 2 transfers (1 additional transfers)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 0: Ok(0)
 DEBUG probe_rs::probe::jlink::swd                          > Transfer result 1: Ok(261)
 INFO  probe_rs::flashing::download                         > Found loadable segment, physical address: 0x00000000, virtual address: 0x00000000, flags: 0x5
 INFO  probe_rs::flashing::download                         > Matching section: ".root_section"
 INFO  probe_rs::flashing::download                         > Matching section: ".text"
 INFO  probe_rs::flashing::download                         > Matching section: ".ARM.exidx"
 INFO  probe_rs::flashing::download                         > Found loadable segment, physical address: 0x00000984, virtual address: 0x20000000, flags: 0x6
 INFO  probe_rs::flashing::download                         > Matching section: ".data"
 INFO  probe_rs::flashing::download                         > Matching section: ".uninit"
 INFO  probe_rs::flashing::download                         > Found loadable segment, physical address: 0x00000974, virtual address: 0x00000974, flags: 0x4
 INFO  probe_rs::flashing::download                         > Matching section: ".ARM.exidx"
 INFO  probe_rs::flashing::loader                           > Found 3 loadable sections:
 INFO  probe_rs::flashing::loader                           >     Multiple sections at 00000000 (2436 bytes)
 INFO  probe_rs::flashing::loader                           >     Multiple sections at 00000984 (1256 bytes)
 INFO  probe_rs::flashing::loader                           >     .ARM.exidx at 00000974 (16 bytes)
 DEBUG probe_rs::flashing::loader                           > Adding data: ExtractedFlashData { name: [".root_section", ".text", ".ARM.exidx"], address: 0, data: "[..] (2436 bytes)" }
 DEBUG probe_rs::flashing::loader                           > Adding data at address 0x00000000 with size 2436 bytes
 DEBUG probe_rs::flashing::loader                           > Adding data: ExtractedFlashData { name: [".data", ".uninit"], address: 984, data: "[..] (1256 bytes)" }
 DEBUG probe_rs::flashing::loader                           > Adding data at address 0x00000984 with size 1256 bytes
 DEBUG probe_rs::flashing::loader                           > Adding data: ExtractedFlashData { name: [".ARM.exidx"], address: 974, data: "[..] (16 bytes)" }
 DEBUG probe_rs::flashing::loader                           > Adding data at address 0x00000974 with size 16 bytes
thread 'main' panicked at 'Overlap in data, address 0x00000974 was already written earlier. This is a bug, please report it.', probe-rs/src/flashing/builder.rs:250:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Desktop (please complete the following information):

Linux Ubuntu, 20.04 LTS

Additional context
The same elf executable can be flashed with version 0.10.1 of probe-rs.

I do not have my DK with me today, but I can grab it from the office tomorrow. Could you maybe provide the test ELF? I have a theory what could be wrong. Could you try with this commit: https://github.com/probe-rs/probe-rs/commit/8159a2c938a737ddad278a0df62f472384aee5e6?

Thanks for the quick reply! I just tested with https://github.com/probe-rs/probe-rs/commit/8159a2c938a737ddad278a0df62f472384aee5e6, but unfortunately the problem is still reproducible there. Here's the elf file:
https://github.com/Javier-varez/stack_overflow_dwt_protection/suites/2254698361/artifacts/46906242

Oh, I actually would have found the culprit in your debug output before too:
> Adding data: ExtractedFlashData { name: [".root_section", ".text", ".ARM.exidx"], address: 0, data: "[..] (2436 bytes)" }
 DEBUG probe_rs::flashing::loader                           > Adding data at address 0x00000000 with size 2436 bytes
> Adding data: ExtractedFlashData { name: [".data", ".uninit"], address: 984, data: "[..] (1256 bytes)" }
 DEBUG probe_rs::flashing::loader                           > Adding data at address 0x00000984 with size 1256 bytes
 DEBUG probe_rs::flashing::loader                           > Adding data: ExtractedFlashData { name: [".ARM.exidx"], address: 974, data: "[..] (16 bytes)" }
 DEBUG probe_rs::flashing::loader                           > Adding data at address 0x00000974 with size 16 bytes

0x00000000 + 2436 == 0x00000984. We can also see that it tries to include the .ARM.exidx section twice. Why that happens is a mystery to me. Do you know what that section does? I have never heard of it before.
Also, why this could have changed is because we went from goblin to object for parsing the ELF.

That is quite interesting, As far as I know 'ARM.exidx' is used for stack unwinding on C/C++ in ARM processors. I build with -fno-exceptions and -fno-rtti so this section is almost empty.
It seems probe-rs is trying to load a segment that is not marked as loadable:
$ arm-none-eabi-readelf -l build/targets/stack_overflow_app
Elf file type is EXEC (Executable file)
Entry point 0x891
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0x00000000 0x00000000 0x00984 0x00984 R E 0x1000
  LOAD           0x002000 0x20000000 0x00000984 0x004e8 0x004e8 RW  0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
  EXIDX          0x001974 0x00000974 0x00000974 0x00010 0x00010 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00     .root_section .text .ARM.exidx
   01     .data .bss .uninit
   02
   03     .ARM.exidx

I have created a change with a potential fix. Thanks for looking into this!

Yup, this has happened in the goblin -> ELF port and I have not spotted this in the review. I am very sorry!


merge from template-sync/template-arlac77-github

package.json

chore(deps): add ^15.3.30 remove ^15.3.29 (devDependencies.npm-pkgbuild)

.github/workflows/ci.yml

chore: add ubuntu-latest (jobs.release.runs-on)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

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

Totals

Change from base Build<PHONE_NUMBER>1:
0.0%

Covered Lines:
62

Relevant Lines:
71

💛  - Coveralls


Images have to have a height and width

This is just a note for other users and I am open for better suggestions.
I am working on a responsive site so by default, all my images are set to width: 100% and have no height.  There are situations where you may have a number of images that have not been loaded yet and will have a height of maybe 10px.  This will fake layzr into thinking each of them are inview.  My fix is to either make sure the placeholder image is the same resolution as the images you are going to replace or set a min height and width via css.

added a note to the docs describing that images w/o placeholders may have no height, or appear broken, before they're loaded


[Task]: Adjust onPageLoad logic w.r.t. module instances used inside modules

Description
Currently, when a module consumes other modules, references to those nested modules are treated as module instances. These nested module instances are hidden from direct use by the consumer but are triggered internally whenever the outermost module references them.
To ensure consistency, if the outermost module is set to run on page load, all nested module instances it references should also be marked to run on page load automatically. This adjustment is necessary to maintain the expected behavior and ensure that all dependent modules initialize correctly when the page loads.

Hello @subrata71
We picked this issue, and our finding is that modules is available in business edition,
so in current codebase we cannot fix anything about this issue.
Please confirm if our understanding is correct
@akshayvijayjain

Thanks, @Harshithazemoso for showing interest in solving this issue. Yes, you are correct! Modules is available in the business edition only.

Yes, that's correct. @akshayvijayjain


WIP: Make sources command

Reference issue
Part of discussion in #6707
What does this implement/fix?
This PR adds a command line function mne setup_source_space that wraps mne.setup_source_space and save its ouput to a file.
Additional info
A test has been implemented, but I'm not sure of which decorators to use and which cases has to be tested. Any suggestion @agramfort ?

command lines should has much as possible mimic the C unic commands (it's
atleast the case of other commands)

thx @vferat !
here is what I see from current C API:
$ mne_setup_source_space --help
usage: /Users/alex/MNE-2.7.4-3420-MacOSX-x86_64_2/bin/mne_setup_source_space [options]

     --overwrite             (to write over existing files)
     --subject subject       (defaults to SUBJECT environment variable)
     --morph subject         (morph the soure space to this subject)
     --spacing spacing [mm]  (defaults to 7 mm)
     --ico number            (use the recursively subdivided icosahedron or octahedron to create the source space)
     --oct number            same as --ico -number
     --all                   (include all vertices in the source space)
     --surface name          (defaults to white)
     --cps                   (create another source space file with patch information)

Minimal invocation:

/Users/alex/MNE-2.7.4-3420-MacOSX-x86_64_2/bin/mne_setup_source_space                      (SUBJECT environment variable set)
/Users/alex/MNE-2.7.4-3420-MacOSX-x86_64_2/bin/mne_setup_source_space --subject subject    (define subject on the command line)

I would be in favor of not allow --ico with negative number but have only the --oct option.
The help message of the python version should be reasonably close to this

or maybe we just don't expose the --cps option and make it true all the
time. We can
add it later if someone requests it.

Adding it now requires less effort than having to add it later.
By using a --nocps flag, people will no care about it unless they really don't want to add distance and patch information. ( More effort to use worser solution seems legit no ? )

Adding it now requires less effort than having to add it later.

https://en.wikipedia.org/wiki/You_aren't_gonna_need_it :)

Last Fix done @larsoner. Anything more that should be changed ?

@vferat can you update what's new page? thanks

Thanks @vferat !


Fix nacl warnings

I do not see any problem, although why do we keep the disabled tests in this state?

These are NaCl's built-in tests which are built/run at compile time. They deal with stuff we don't use anymore or have overwritten and libc generates warnings about them. We're just going to disable these this way instead of futzing with the build process much while getting rid of the warning overload.


[bug] Usage of Tauri with Next.js + App Router breaks React.js lifecycle hook calls in Tauri prod output

Describe the bug
Usage of useEffect (w/ or without an inner timeout/interval/invoke call) broken in production build output of tauri app when using Next.js 13+ w/ app router. App itself works just as expected in dev and prod (in browser, aside from the invoke call due to this being a tauri specific function)
Reproduction
Init a new tauri app within a Next.js 13+ application and call a command invoke within a timeout inside of a useEffect in your initial page. For some reason (as far as I've noticed) any timeouts/inteval calls in the client side either don't get triggered or only get triggered after a app refresh (window reload). This behavior only happens in a prod build, not in a prod build in browser or dev mode in the tauri window.
Expected behavior
What I would expect is that a production build in tauri wouldn't alternate in any core functionalities of frontend frameworks (like react). So for instance, I would expect a useEffect to just get fired in a production build of a tauri app.
Platform and versions
[✔] Environment
    - OS: Arch Linux TEMPLATE_VERSION_ID X64
    ✔ webkit2gtk-4.0: 2.42.1
    ✔ rsvg2: 2.57.0
    ✔ rustc: 1.75.0-nightly (df871fbf0 2023-10-24)
    ✔ cargo: 1.75.0-nightly (d2f6a0485 2023-10-20)
    ✔ rustup: 1.26.0 (2023-05-04)
    ✔ Rust toolchain: nightly-x86_64-unknown-linux-gnu (default)
    - node: 18.17.1
    - pnpm: 8.11.0
    - yarn: 1.22.21
    - npm: 10.2.4
    - bun: 1.0.7

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.4
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.5.1
    - @tauri-apps/cli [NPM]: 1.5.6

[-] App
    - build-type: bundle
    - CSP: default-src * 'self' data: tauri://*, https://app.graphite.dev
    - distDir: ../out
    - devPath: http://localhost:3000/
    - framework: React (Next.js)
    - bundler: Webpack

Stack trace
No response
Additional context
Github repo which can be used for reproduction as well: https://github.com/GlitchTech-Developments/GraphiteDesktop
Repo isn't doing anything too fancy, just opening a new window with a remote url if a fetch succeeds after a timeout.
As a bit of extra context, I both build and test the production output locally on windows + linux but also cross-build using a github action. Both outputs behave the same.

I do have to mention, that this is indeed my first issue on the tauri repo. But I'm familiar with issue handling from the web dev side + also a contributor on the Next.js repo. Just as a headsup + background. Thanks to anybody that might be able to help me with this issue or point me to the right direction 😄

Hmm, this sounds like a CSP issue to me (the csp is not applied in tauri dev). Can you try a debug build via tauri build --debug (output in target/debug/ !) and check the devtools console for errors?

The app router of Next doesn't work well with output: "export". Even if it would work with the pages you've got, once you add dynamic pages it breaks completely due to this bug in Next: https://github.com/vercel/next.js/issues/54393
I just migrated everything back to the page router because of this.

The app router of Next doesn't work well with output: "export". Even if it would work with the pages you've got, once you add dynamic pages it breaks completely due to this bug in Next: vercel/next.js#54393 I just migrated everything back to the page router because of this.

Yeah known about that issue tbh but since it doesn't create any issues in this specific project I'll just keep it on the app router for now.

Hmm, this sounds like a CSP issue to me (the csp is not applied in tauri dev). Can you try a debug build via tauri build --debug (output in target/debug/ !) and check the devtools console for errors?

Thanks for the suggestion man! seems I had a typo in the csp string that made the whole csp string invalid which triggered this odd behavior.

Closing issue since it's not a bug on Tauri's end. Behavior was created by having a typo in the security.csp config entry.