[$1000] Drop user back to the last chat they were on when they leave a room.

Problem:
Currently, if you leave a Room or Group you are dropped into your Concierge DM. The best reasoning for this is that you might have a support question or request. This is an assumption that, when weighed up against other options, feels less intuitive or useful.
Solution:
Drop users into whatever chat they were previously viewing before the viewed the room or group they left. Dropping a user into a chat they were just viewing is more likely to be useful than dropping a user into a Concierge DM.
E.g.:

Views #social
Views DM with Vit
Leaves DM with Vit
Drops into #social

On mobile, you should be dropped into the "chats screen".
Let me know if you have any questions or need clarification with anything, thanks.
This was reported here: https://expensify.slack.com/archives/C049HHMV9SM/p1697506231709359
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01c9dae839c28297cd
Upwork Job ID:<PHONE_NUMBER>593899520
Last Price Increase: 2023-11-06

This improvement was discussed here: https://expensify.slack.com/archives/C049HHMV9SM/p1697506231709359

Proposal
I would like to work on it. According to the comment on the issue we need to change this lines of code to navigate the user to the last report using ReportUtils.findLastAccessedReport
https://github.com/Expensify/App/blob/3db5ff4a1924156c748291d25eb9d774d82f879e/src/libs/actions/Report.js#L2074-L2078

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01477bce71bc1bc694

@getusha Can you please review the above proposal, this is part of wave8 milestone and we want to get this shipped ASAP, thanks.

We can store a value in Onyx like LAST_VIEWED_REPORT_ID. Whenever reportID from route is changed we will update this key if this reportID is valid.

@dukenv0307 is there any reason, to store the value in Onyx? can't we do it without introducing a new key?

@dukenv0307 could you point me where we will update the value of the ref from? i feel like there is a better way to get the navigation history and use it for this case instead of storing a new value.

@dukenv0307 If the previous report is another room and when we leave that room again where will the navigation land? in this case we will have the previous room path saved and it'll navigate to a room that doesn't exist, that's why i am not confidence in using a ref or any sort of state to store the path.
@techievivek Should we also address the scenario of a reload? In my opinion, I believe we should simply navigate to the Concierge in such cases.

@sourcecodedeveloper i was testing your proposal is there any reason you removed it for?

@getusha I have not found reliable solution. The ReportUtils.findLastAccessedReport is not reliably returning last accessed reports. The call to sortReportsByLastRead() is sorting on 'lastReadTime' but the 'lastReadTime' is not being updated reliably so the room that was previously left is returned as the last accessed report.

We can store a value in Onyx like LAST_VIEWED_REPORT_ID. Whenever reportID from route is changed we will update this key if this reportID is valid.

I don't think storing a single reportID will work, if we need to make it work we will need to store a stack of reportIDs in the order they were accessed. But that info is already available to us through navigation stack so maybe we can just reuse that?

@getusha

Should we also address the scenario of a reload? In my opinion, I believe we should simply navigate to the Concierge in such cases.

Do we reset the navigation stack when we reload the page, or does it persist? I would guess it persists so can't we figure out the last report they were on from it?

Can we not use findLastAccessedReport or getTopmostReportId to find the last report the user was on? If, in any case, we are unable to determine, then we can drop them to concierge chat.

But that info is already available to us through navigation stack so maybe we can just reuse that?

Yes i also that's something we should reuse. @dukenv0307 @rayane-djouah could you take a look at this approach and update your proposals if possible?

Do we reset the navigation stack when we reload the page, or does it persist? I would guess it persists so can't we figure out the last report they were on from it?

It think the state will reset incase of a reload, can confirm that logging navigationRef.getState().

Doubled the pricing since this will require a little work debugging the navigation stack.

We have a problem that is if we visit a report many time. Navigation stack will have many screen of this report. And then when we leave this room, in navigation stack still have this screen.

In this case we can filter out the screen, i don't think it differs from filtering from stored paths, if take that approach.

I'm pretty sure the the stack is reset after reloading.

I see, but when I am testing this locally it correctly takes me back to the chats I accessed even after I have refreshed the page, how does that work? Is it because of findLastAccessedReport?

We have a problem that is if we visit a report many time. Navigation stack will have many screen of this report. And then when we leave this room, in navigation stack still have this screen.

I am not sure how this is a problem. Can you explain this with an example of how you think this could be a problem? For now, I think we know which chat the user is leaving so we can look at the content of the navigation stack from the top and find the first report which doesn't match the given reportID and that will be our destination, no? The important thing that we will need to consider here is that we will need to pop all the entries until the destination reportID.

I think we should handle the following cases.
Case 1

Open DM with User A
Open #room1
Leave #room1
Drops to DM with User A

Case 2

Open #room1
Open #room2
Leave #room2
Drops to #room1
Leave #room1
Drops to the chat before room1 if there is any, otherwise navigate to Concierge

Case 3

Open DM with User A
Open #room1
Reload the page
Leave #room1
Drops to DM with User A

Advertised on slack https://expensify.slack.com/archives/C01GTK53T8Q/p1699258134099569

Late to the party but interesting conversation here.
Going through the previous comments to see if I can put in my 2 cents here.

Proposal
Please re-state the problem that we are trying to solve in this issue.
after the user leaves room, the user should navigate to previous chat if possible otherwise navigate to concierge.
What is the root cause of that problem?
user is dropped to concierge chat.
What changes do you think we should make in order to solve the problem?
Need to store stack of reportIDs sorted by lastreadtime. Introduce sortedNavigationStack in sidebarlinksdata.js
let index = _.findIndex(sortedNavigationStack, (report)=> report.reportID === currentReportID);
if(index === -1)
{
if(currentReportID != '')
{
sortedNavigationStack.push({
reportID: currentReportID,
lastReadTime: DateUtils.getDBTime()
});
}
}
else{
sortedNavigationStack[index].lastReadTime = DateUtils.getDBTime();
}
const sortedNavigationStackData = _.sortBy(sortedNavigationStack, 'lastReadTime');
if(sortedNavigationStackData)
{
SidebarUtils.setSortedNavigationStack(sortedNavigationStackData);
}
use withOnyx to subscribe to changes to sortedNavigationStack for react component
sortedNavigationStack: {
key: ONYXKEYS.SortedNavigationStack,
},

We can store a value in Onyx like LAST_VIEWED_REPORT_ID. Whenever reportID from route is changed we will update this key if this reportID is valid.

I don't think storing a single reportID will work, if we need to make it work we will need to store a stack of reportIDs in the order they were accessed. But that info is already available to us through navigation stack so maybe we can just reuse that?

@getusha  added proposal using stack of reportIDs. Seems to functioning as expected. Try testing the proposal.

@getusha Can you please prioritize reviewing the above proposals? 🙏

@sourcecodedeveloper could you please share your branch so i can test it?
@techievivek based on the complexity of getting the last accessed report from the navigation state, it's must to store a stack of report ids to solve this issue.

Proposal
Please re-state the problem that we are trying to solve in this issue.

We want user to be able to go back to previous accessible chat once they leave the room.
Currently there are two ways user can leave the room:

Click on the Leave Room from Details
Or be removed from the Workspace.

What is the root cause of that problem?

Its a new feature that we are adding to the app.

What changes do you think we should make in order to solve the problem?

We will need to create a findLastAccessibleReportID function that will return the last accessible report ID.

This function will sort all the reports using sortReportsByLastRead function.
After that we will filter reports using shouldReportBeInOptionList function, as we want user to navigate to an accessible report.
Finally we will add a parameter to findLastAccessibleReportID function that which will be like filterReportIDs, to filter the current room from the list.
Lastly we will return the last report ID from the list.

We will use this leaveRoom function
https://github.com/Expensify/App/blob/d5725c52bead4baa02ecec38915fc7c8c4316a4a/src/libs/actions/Report.js#L2024

and we will add below code in isWorkspaceMemberLeavingWorkspaceRoom condition scope.
const lastAccessibleReportID = ReportUtils.findLastAccessibleReportID( [reportID] );
if (lastAccessibleReportID) {
   Navigation.dismissModal(lastAccessibleReportID);
   return;
}

We will also need to update ReportScreen.js.
https://github.com/Expensify/App/blob/d5725c52bead4baa02ecec38915fc7c8c4316a4a/src/pages/home/ReportScreen.js#L303-L312

And we will add same code as above here but without any parameters. As this is triggered without any action from user, and triggered when user is removed of the access from active chat.

Removing User From Workspace
https://github.com/Expensify/App/assets/78416198/eef9b4d0-b41b-402d-a9e3-5cb52b2118ea

Leaving From Room
https://github.com/Expensify/App/assets/78416198/0de73c0a-e11f-4975-af5f-f6be8b0ff182

What alternative solutions did you explore? (Optional)

N/A

@sourcecodedeveloper could you please share your branch so i can test it?
@techievivek based on the complexity of getting the last accessed report from the navigation state, it's must to store a stack of report ids to solve this issue.

@getusha
https://github.com/sourcecodedeveloper/App/tree/production

@getusha

based on the complexity of getting the last accessed report from the navigation state, it's must to store a stack of report ids to solve this issue.

I don't find much benefit in keeping a collection of reportIDs apart from just helping with this particular use case, and it's possible that handling the associated logic could be complicated as well. I would still stick with creating a helper method to retrieve the reportID from the navigation state, even if that's a bit of work.

@rayane-djouah your proposal is not working.
https://github.com/Expensify/App/assets/75031127/62987c2b-84c9-47eb-ba8f-fa619b90c0cc

@rayane-djouah there are no console errors

Proposal
Please re-state the problem that we are trying to solve in this issue.
Drop user back to the last chat they were on when they leave a room.
What is the root cause of that problem?
The root cause of this issue if that we redirect page to concierge after leave a room, see
https://github.com/Expensify/App/blob/da2c79e52860e6b367e92cda70c827e52c0edd34/src/libs/actions/Report.js#L2080-L2084
What changes do you think we should make in order to solve the problem?
To drop user to the most recently access chat, we need to trace the access records of opened reportIDs/chats and navigate to the most recent reportID after leaving a room.
To achieve it,

Add a state event listener of the Report screen by changing this line

https://github.com/Expensify/App/blob/da2c79e52860e6b367e92cda70c827e52c0edd34/src/libs/Navigation/AppNavigator/Navigators/CentralPaneNavigator/BaseCentralPaneNavigator.js#L15
to
        <Stack.Navigator
            screenListeners={{
                state: (e) => {
                    const reportID = lodashGet(e, 'data.state.routes[0].params.reportID', '');
                    if (reportID) {
                        console.log('state changed, reportID = ', reportID);
                        Report.updateRecentlyAccessedReportID(reportID);
                    }
                },
            }}
        >

See https://reactnavigation.org/docs/navigation-events#state

Add a method updateRecentlyAccessedReportID in Report.js to trace the more recently accessed reportIDs, like

let recentlyAccessedReportIDs = [];
Onyx.connect({
    key: ONYXKEYS.RECENTLY_ACCESSED_REPORT_ID_LIST,
    waitForCollectionCallback: true,
    callback: (val) => {
        recentlyAccessedReportIDs = val;
    },
});

/**
 * Update recently accessed reportID
 *
 * @param {String} currentReportID
 * @param {Boolean} shouldRemoveCurrentReportID
 * @returns {String} Returns the most recent accessed reportID
 */
function updateRecentlyAccessedReportID(currentReportID, shouldRemoveCurrentReportID = false) {
    const reportIDs = _.filter(recentlyAccessedReportIDs, (reportID) => reportID !== currentReportID);
    if (!shouldRemoveCurrentReportID) {
        reportIDs.push(currentReportID);
    }

    // We can discuss the number of reportIDs need to be saved
    if (reportIDs.length > 10) {
        reportIDs.shift();
    }

    console.log('current recentlyAccessedReportIDs = ', reportIDs);

    // We want to save recently accessed reportIDs to Onyx to be used after refreshing the page
    Onyx.set(ONYXKEYS.RECENTLY_ACCESSED_REPORT_ID_LIST, reportIDs);

    return reportIDs.length > 0 ? reportIDs[reportIDs.length - 1] : '';
}

Change

https://github.com/Expensify/App/blob/da2c79e52860e6b367e92cda70c827e52c0edd34/src/libs/actions/Report.js#L2080-L2084
to
    const lastAccessedReportID = updateRecentlyAccessedReportID(reportID, true);
    if (lastAccessedReportID) {
        Navigation.dismissModal(lastAccessedReportID);
    } else {
        const participantAccountIDs = PersonalDetailsUtils.getAccountIDsByLogins([CONST.EMAIL.CONCIERGE]);
        const chat = ReportUtils.getChatByParticipants(participantAccountIDs);
        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(chat.reportID));
    }

What alternative solutions did you explore? (Optional)
N/A

@techievivek @getusha I also proposed a solution which uses state event listener to trace the opened reportID instead of inspecting the state stack by brute force method. The code will be clean and maintainable. You can checkout this branch https://github.com/Expensify/App/compare/main...eh2077:App:30778-drop-user-to-most-recently-accessed-report-after-leaving-a-room, if you want to test it.

@eh2077 Please check this comment, we're not looking to store report IDs in Onyx.

@jeet-dhandha I will test your proposal, will it handle all of these cases?

@sourcecodedeveloper could you please share your branch so i can test it?

@getusha feedback is appreciated. The proposal does handle your test scenarios.

@sourcecodedeveloper please check this comment https://github.com/Expensify/App/issues/30778#issuecomment-1798298915

based on the complexity of getting the last accessed report from the navigation state, it's must to store a stack of report ids to solve this issue.
I don't find much benefit in keeping a collection of reportIDs apart from just helping with this particular use case, and it's possible that handling the associated logic could be complicated as well. I would still stick with creating a helper method to retrieve the reportID from the navigation state, even if that's a bit of work.

@techievivek You were on the right path storing stack of report ids and I agree with @getusha comments

I would still stick with creating a helper method to retrieve the reportID from the navigation state, even if that's a bit of work.

@techievivek I checked the NavigationRoot and the navigation state changes not only when the user is dropping out of chat but also when visiting profiles or visiting other links.  Navigation state is also not holding any information on last accessed reportid.

I have added videos for two scenarios, i will add for remaining scenarios in few hours. Only one scenario is covered in the videos, rest 2 i will add.

@getusha Update Proposal https://github.com/Expensify/App/issues/30778#issuecomment-1797115161

Videos for all three cases.
Added reason for marking unread messages, its related to lastReadTime.
Added extra Condition to check for hidden rooms.

This should cover up all the edge cases.

Very interesting proposals/discussions here. Thank you all for working on this one. Let me go through the comments, and I will get back to you.

@jeet-dhandha Your proposal uses findLastAccessibleReportID and sortReportsByLastRead , but it looks like that is unreliable as the last read doesn't always get updated when you visit a report. Check out this comment by @sourcecodedeveloper https://github.com/Expensify/App/issues/30778#issuecomment-1791596823

@techievivek as mentioned in my proposal the issue is that lastReadTime is not updated. Which should be first resolved by internal team using a BE change in /OpenReport API and then we can use my proposal to handle all the scenarios. Also look at the videos whenever you have time.

@sourcecodedeveloper @eh2077 I see both of your proposals uses a stack of reportIDs. My only concern in this case is that we can have an infinitely growing stack to implement this feature correctly.
@eh2077
From your proposal

// We can discuss the number of reportIDs need to be saved

if (reportIDs.length > 10) {
    reportIDs.shift();
}

@techievivek Quick question:
For this case where user opens up the app in mobile and then leave room should he be navigated to,

concierge
Or last opened room based on read time
Or the last visited chat in that local navigation

@sourcecodedeveloper @eh2077 I see both of your proposals uses a stack of reportIDs. My only concern in this case is that we can have an infinitely growing stack to implement this feature correctly.
@eh2077 From your proposal
// We can discuss the number of reportIDs need to be saved
    if (reportIDs.length > 10) {
        reportIDs.shift();
    }

What if we keep leaving the rooms? We can definitely agree on a number and drop user to the concierge room if the stack becomes empty. Maybe this is not a problem then?

@techievivek Yes, it won't be a problem. We can choose a reasonable size of stack and just fall back to redirect to concierge room if there's no available saved reportID in the stack.

On mobile, you should be dropped into the "chats screen".

@jeet-dhandha from the GH OP.

@jeet-dhandha

as mentioned in my proposal the issue is that lastReadTime is not updated. Which should be first resolved by internal team using a BE change in /OpenReport API and then we can use my proposal to handle all the scenarios. Also look at the videos whenever you have time.

This is on purpose that if the user has already read the chat then we don't want to touch the DB updating the last read. So I don't think we will be making a BE change in this case.

@techievivek the stack of reportIDs resets after logout.  Although the app is not keeping count of the number of rooms or chat reports so the stack of reportIDs also does not need to have count.

Got it

@jeet-dhandha

as mentioned in my proposal the issue is that lastReadTime is not updated. Which should be first resolved by internal team using a BE change in /OpenReport API and then we can use my proposal to handle all the scenarios. Also look at the videos whenever you have time.

This is on purpose that if the user has already read the chat then we don't want to touch the DB updating the last read. So I don't think we will be making a BE change in this case.

got it @techievivek thanks.

@techievivek the stack of reportIDs resets after logout.

This is fine, we just to handle the case for a particular session.

@techievivek are we fine going with the storing reportId stack approach?

Updating my proposal then

Yeah, I think reportID approach is fine, we will just need to add a limit on the number of reports. And if we have an empty stack at any time then we can drop the user to concierge chat.

@sourcecodedeveloper It seems like using the local time to keep track of the reports a user has visited might not be necessary, based on @eh2077's proposal.
By listening for navigation changes and updating the stack to put the current report on top when the user navigates to the report page, there may be no need to store the lastReadTime. What do you think?

Quick question:
If a user is on a different tab then should this be handled for that tab only ?

If a user is on a different tab then should this be handled for that tab only ?

I think we can handle this per session per device or per browser. We don't need to be specific per tab.

As i think it should be based on tabs as user might be working on different tabs for different things and when user leaves the room, last accessed chat per tab should be opened.

@jeet-dhandha could you also include the branch when you update your proposal?

Sure @getusha

I will need some time on this @getusha.

@eh2077 could you please point me if there is a considerable difference between your and @sourcecodedeveloper's proposal? https://github.com/Expensify/App/issues/30778#issuecomment-1794651547 other than storing lastReadTime

@eh2077 could you please point me if there is a considerable difference between your and @sourcecodedeveloper's proposal? https://github.com/Expensify/App/issues/30778#issuecomment-1794651547 other than storing lastReadTime

@getusha The main differences are the elegant way to trace accessed reportIDs by event listener and the extendable way to update and maintain a stack of recently accessed reportIDs.

@getusha added stack limit and branch can be tested.

@getusha can we get the proposals reviewed today? Let me know if you need any help, thanks.

Testing proposals, i will update today.

@eh2077 I tested your proposal and it's not handling case 2 https://github.com/Expensify/App/issues/30778#issuecomment-1794269537
https://github.com/Expensify/App/assets/75031127/0b481b58-6acb-4703-a521-eae15033952b
@sourcecodedeveloper here is what i am seeing while testing your proposal,

RHN is not closed when leaving a room
navigated to the room i left after closing the RHN

https://github.com/Expensify/App/assets/75031127/a7350421-d946-40c1-adf0-f8c76857c44a

@jeet-dhandha do you think you'll be able to update your proposal today, so we can consider it?

@rayane-djouah while your proposal work for case 1 it is not handling case 3 as described here which i don't think can be achieved without storing report ids.
https://github.com/Expensify/App/assets/75031127/a68cc2f4-4fd7-45f7-b760-1fcba4fca423

@getusha Thanks for testing proposals!
I just updated the branch to fix a flaw of stale recentlyAccessedReportIDs, see this commit.
Now it can passes the 3 cases, see demo video

Click to see demo video of case 1
https://github.com/Expensify/App/assets/117511920/26139806-90aa-45b3-86ea-350c567a80c9

Click to see demo video of case 2
https://github.com/Expensify/App/assets/117511920/11ec6d1f-4b8d-48b1-b6ab-59da660a9bdf

Click to see demo video of case 3
https://github.com/Expensify/App/assets/117511920/c37af4fd-8399-4511-90c6-80203976fc08

@eh2077 tested it and again and works well for the cases i mentioned.
Thanks everyone for the proposals and valuable inputs, I like @eh2077's proposal. It handles all the cases well for now and is the most complete, and lets go with their proposal.
🎀 👀 🎀  C+ reviewed!

Please consider this fix to this issue I think it might overlap with the approach you are following. Need to use one or the other 👍

@getusha Sory for my late. We have already had the method findLastAccessedReport - that used to display the last access report when user launch app by deep link, so is creating a new reportIDstack redandunt?

Proposal
Please re-state the problem that we are trying to solve in this issue.

Drop user back to the last chat they were on when they leave a room.

What is the root cause of that problem?

Currently, we are navigate user to Conciege report after leaving room.
https://github.com/Expensify/App/blob/dee9b3110a7ebe0aa250c3f966d6a69925d916f4/src/libs/actions/Report.js#L2084-L2088

What changes do you think we should make in order to solve the problem?

We have already had the method findLastAccessedReport - that used to display the last access report when user launch app by deep link, so i think creating a new reportIDstack is redundant. Because using the findLastAccessedReport can solve issue "Drop user back to the last chat they were on when they leave a room.". We can do it by updating:

https://github.com/Expensify/App/blob/dee9b3110a7ebe0aa250c3f966d6a69925d916f4/src/libs/actions/Report.js#L2084-L2088
to
 if (isWorkspaceMemberLeavingWorkspaceRoom) {
        const reports = {...allReports};
        delete reports[reportID];
        const lastReportID = getLastAccessedReportID(reports);
        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(lastReportID));
    }

There is an issue with the getLastAccesedReportID, so we need it is fixed in issue https://github.com/Expensify/App/issues/30868#issuecomment-1793304559

What alternative solutions did you explore? (Optional)

NA

But I think it is efficient memory-wise to only save a few last accessed report Ids (maybe 5) instead of a lastVisitTime field for every single reports a user has. 👍

It is efficient memory-wise to only save a few last accessed report Ids (maybe 5) instead of a lastVisitTime field for every single reports

@FitseTLT I think it is not a reason for us to use the stackedAccessedReportIDs rather than the lastVisitTime for each report because we have already created a lot of fields for each report just to fix the special issue, so adding lastVisitTime is not a problem

I don't think there will be much benefit in storing lastVisitTime to each report than storing report IDs.
what do you think @techievivek?

Yeah, I agree. I don't see how one is better than the other. Also, @DylanDylann seems to be storing that in the REPORT_METADATA, which is reserved for performance-related stuff. So we will anyway need to introduce a new key.

@techievivek I think creating a new key is not a problem here, just to brief the proposal

@getusha I think there are a few benefits:

I think that using lastVisitTimes is more gereral than reportIDsStack because, from lastVisitTimes, we can get the reportIDsStack, but from ``````reportIDsStack, we cannot get the lastVisitTimes``. So lastVisitTimes can be used in other logics in the future.
Reducing the code changes

@DylanDylann could you raise this to expensify-open-source channel, with both approaches?
@techievivek I'm still ok with the other approach and the solution didn't made a lot of sense to me, but i don't mind accepting other's input.

@getusha Just raised to https://expensify.slack.com/archives/C01GTK53T8Q/p1699546215271289

@techievivek Should we re-select the proposal in this issue? Because the solution have been changed

@DylanDylann, I think @eh2077's proposal to utilize an event listener on the Stack Navigator was pivotal that others overlooked, which is also being used in your solution on the other GH. Additionally, building the solution by using a "last visited" timestamp for the reports doesn't appear to be complicated. I am confident that @eh2077 can manage any additional changes in their PR. So, I will keep this assigned to them.

@techievivek

I think the main difference between the two proposals is that: One uses the stacks to store the visited reports, and the other uses the lastVisitedTime. Before, you and other reviewers chose the @eh2077 `s proposal because of this difference.
In my proposal, I `ve mentioned that we should update the lastVisitedTime once we visit the reports, but does not indicate the detail because it is not the main and there are many ways to do that

I agree with @techievivek In my opinion it will be fair if we just resume the work on https://github.com/Expensify/App/pull/31097 @eh2077 just needs to update the PR using lastVisitTime after https://github.com/Expensify/App/pull/31424 is merged. it is clear that it initially uses stack to store report ids, but it doesn't change the fact that we are still using the stack navigator event listener.

@getusha My PR does not use the stack navigator event listener anymore. Please help re-check

@techievivek @getusha In my opinion, my proposal is an anchoring point for the discussion (using lastVisitTime) and help internal team make a decision with a better solution. It also makes @eh2077's proposal was outdated.

I came up the solution first and I think using event listener provided by react-navigation lib is key to solve this kind of problem correctly and elegantly.

@eh2077 I don't agree with this point, using "react-navigation lib" is not an anchoring point in this issue. Also my solution does not use  the "react-navigation lib" but still solve the problem. My
Just a note: In this issue, we also re-assigned to another contributor after discussing to find the best solution.

In my opinion, there was a decent of work done in the existing PR, it is not like the solution @eh2077 provided didn't work properly it is the internal team decision to go another route, leading to that issue being opened and @DylanDylann being assigned. I don't think we need a new proposal to update the PR using the new functionality.
If @eh2077 agrees to split the bounty and work with @DylanDylann it will also be preferable, I'll let @techievivek make the final decision, this is my idea of how we should handle this.

I just reported the redundant solution hoping we could choose one or the other approach and apply it to both issues not that they are duplicate issues. At the moment when I commented there was a redundant solution @eh2077 was already assigned for a properly working solution after a lot of discussion; I just commented to avoid a redundant solution to related problems (although these issues are different issues solving different problems) and after a discussion @DylanDylann approach is selected. But @DylanDylann in my perspective, I don't think that means you should be involved in this issue b/c there are many cases where we don't get compensated for our ideas and also most importantly exploit others' ideas without sharing our income (like commenting a better proposal building it on top of other's proposals or take ideas from the Expensify code base). 👍

Just continue discussions above. I also took a look at @DylanDylann 's PR which tracks accessed reportIDs using useEffect in ReportScreen. I have a few concerns about their implementation to add lastVisitTime

it'll trigger extra re-rendering when report is updated
the use effect maybe not triggered when pressing browser back button as the previous ReportScreen is cached and not updated

If you're interested in how we will solve https://github.com/Expensify/App/issues/30868 based on the idea to store a stack of reportIDs, see POC changes diff. It's quite straightforward, just subscribe recentlyAccessedReportIDs and use it in method findLastAccessedReport.
I think it'll be hard and time-consuming to find a perfect solution that everyone agrees. And I agree with @FitseTLT it'll better to have a consistent and holistic solution for this kind of problem after many discussions.
So, as the team has decided to add lastVisitTime, I think we can use event listener to track updating lastVisitTime, which is more reliable than using useEffect, see the latest POC changes use the focus event diff. Then we can move these issues forward.
cc @techievivek @getusha @shubham1206agra

Sorry for the delay here. You may start working here, and please merge PR after https://github.com/Expensify/App/pull/31424 hits prod (currently on staging)

Gentle bump @eh2077 @getusha ^

Not really. You will be paid only in the original issue where you worked. And @eh2077 would be paid here, as it was discussed internally to do our issue first due to priority, and later this. And any changes in our PR would naturally affect the solution here. And since @eh2077 RCA was right, and was first, for the good spirit, @eh2077 should be paid in full here after the completion of the PR.

Gentle bump @eh2077 @getusha ^

Got it. Will update soon!

I'm working on the PR and it'll be ready soon.

The PR https://github.com/Expensify/App/pull/31097 is updated and it's ready for review once the CI is happy.

^ false alarm

Adding bug label so a BZ member can help with the payment here, thanks for working on this.

@garrettmknight The bug has already been fixed and deployed, I added the bug label so a BZ member can help with the payment https://github.com/Expensify/App/issues/30778#issuecomment-1922813860, thanks.

Not overdue, the PR has already been merged, and we are currently in the regression testing phase.

All paid out - adding the bugzero checklist for @getusha
BugZero Checklist: The PR adding this new feature has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ]  [@getusha ] Please propose regression test steps to ensure the new feature will work correctly on production in further releases.
[ ]  [@garrettmknight] Link the GH issue for creating/updating the regression test once above steps have been agreed upon.

Regression Test Proposal
Case 1

Open a chat with User X
Create a new room named room-1
Leave room-1
Verify that you are navigated back to the chat with User X.

Case 2

Open a chat with User X
Create a new room named room-2 and room-3
Open room-2
Open room-3
Leave room-3
Verify that you are navigated back to room-2
Leave room-2
Verify that you are navigated back to the chat with User X.

Do we agree 👍 or 👎

cc @techievivek @eh2077


add a changelog guide

Summary of changes

Changes introduced in this pull request:

added a changelog guide

Reference issue to close (if applicable)

Closes
Other information and links

Change checklist

[x] I have performed a self-review of my own code,
[x] I have made corresponding changes to the documentation,
[x] I have added tests that prove my fix is effective or that my feature works
(if possible),
[x] I have made sure the
CHANGELOG is
up-to-date. All user-facing changes should be reflected in this document.

 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.


[AutoRelease] t2-appcontainers-2022-09-16-88199(Do not merge)

https://github.com/Azure/sdk-release-request/issues/2985
Live test fail, detailed info is in pipeline log(search keyword FAILED)!!!
https://dev.azure.com/azure-sdk/internal/_build?definitionId=1031

issue link:https://github.com/Azure/sdk-release-request/issues/2985


issue with type definitions for sanitize-html

It seems like I'm getting invalid javascript generated from sanitizeHtml.ts
this code
export const sanitizeHtml = (subject: string) => {
  return sanitize(subject, {
    // The default allowedTags list already includes _a lot_ of commonly used tags.
    // https://www.npmjs.com/package/sanitize-html#default-options
    //
    // I don't see a need for this to be configurable at the moment,
    // as it already covers all the layout tags, but we can revisit this if necessary.
    allowedTags: sanitize.defaults.allowedTags.concat([
      "button",
      "form",
      "img",
      "input",
      "select",
      "textarea",
    ]),
    // Setting allowedAttributes to false will allow all attributes.
    allowedAttributes: false,
  });
};

turns into
const sanitizeHtml = (subject) => {
    return (0, sanitize_html_1.default)(subject, {

        // The default allowedTags list already includes _a lot_ of commonly used tags.
        // https://www.npmjs.com/package/sanitize-html#default-options
        //
        // I don't see a need for this to be configurable at the moment,
        // as it already covers all the layout tags, but we can revisit this if necessary.
        allowedTags: sanitize_html_1.default.defaults.allowedTags.concat([
            "button",
            "form",
            "img",
            "input",
            "select",
            "textarea",
        ]),
        // Setting allowedAttributes to false will allow all attributes.
        allowedAttributes: false,
    });
};

which fails with
 TypeError: Cannot read properties of undefined (reading 'defaults')
    at sanitizeHtml (/Users/vijay/work/prj/workspace/node_modules/.pnpm/auto-playwright@1.8.1_@playwright+test@1.34.3/node_modules/auto-playwright/dist/sanitizeHtml.js:25:46)
    at getSnapshot (/Users/vijay/work/prj/workspace/node_modules/.pnpm/auto-playwright@1.8.1_@playwright+test@1.34.3/node_modules/auto-playwright/dist/getSnapshot.js:7:46)

If i manually adjust the javascript file in dist to be like
const sanitizeHtml = (subject) => {
    return (0, sanitize_html_1)(subject, {

        // The default allowedTags list already includes _a lot_ of commonly used tags.
        // https://www.npmjs.com/package/sanitize-html#default-options
        //
        // I don't see a need for this to be configurable at the moment,
        // as it already covers all the layout tags, but we can revisit this if necessary.
        allowedTags: sanitize_html_1.defaults.allowedTags.concat([
            "button",
            "form",
            "img",
            "input",
            "select",
            "textarea",
        ]),
        // Setting allowedAttributes to false will allow all attributes.
        allowedAttributes: false,
    });
};

it all seems to work...  looking at the underlying type in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/sanitize-html/index.d.ts it seems correct to me...

Do you have skipLibCheck set to true?

@lucgagan facing the same issue

I have the same issue :)

Having this issue as well, using the default project created by calling npm init playwright.
Might be worth looking into if this is the 'default' out of box experience when using Playwright
I wonder if it's an issue with your tsconfig @lucgagan, as it appears that the JS coming from your .ts files is invalid outside your project.


Fix notebooks and download data

Just added a link to the data and some functions to download the data.
Also fixed some of the headings in Andy's notebooks. The number of # represents the heading level and it is only allowed (in the tool creating the website) to go one level down, e.g going from # to ### is not allowed. Also the document need to start with a # heading.

I have # heading at the top and use ## / ### in all other markdown cells, will that work okay?

@finsberg I have # heading at the top and use ## / ### in all other markdown cells, will that work okay?

Yes, this looks fine :)


Add hwInfo to credentials

Allows for storing hardware wallet information with wallet credentials.  Support for TEE hardware (e.g., stores TEE hardware wallet id).

Coverage remained the same at 94.314% when pulling f63e92b32afad324e3e9abf38dcf504939dc367b on ajp8164:patch-1 into a23b4eaebb3a9a0a1855f8d23302ae5816e53be6 on bitpay:master.


As a developer, I want to make sure the bootstrap process is efficient and reliable, and the failure scenarios understood

Aspects to work on:

Very slow bootstrap when running the node locally, investigate why
Bootstrap sometimes can get stuck (rare on servers, common for local nodes), investigate why
Fetching of snarked ledger parts can be optimized if we reuse the previous lerger, look into improving reuse
Expose relevant information to the frontend

Update:
Been working on top of the internal kademlia branch using our p2p implementation (instead of libp2p) which has solved all the connectivity-related issues mentioned in the previous update.
Worked on reimplementing the snarked ledger's sync process so that:

It is more aggressive in the fetching of accounts (now they are fetched in batches of 64 instead of 2, allowing us to skip most intermediary hash queries)
Only sync up the accounts that have changed from the previous snarked ledger (genesis -> staking -> next epoch -> root)
Proper validation of the peer responses (right now we panic if a peer sends us an incorrect hash)

More aggressive account fetching already makes the snarked ledger sync process much faster (from 3-5 minutes down to 20 seconds on my computer), the logic to only update what has changed is in place too but the previous ledgers are not yet copied to make them the starting point (working on that now). All validations are still pending.

New ledger sync algorithm and progress estimation calculations are already implemented. Finishing the implementation of the enabling conditions for two of the new actions and better handling of a few edge cases (to reuse partial root ledger after target changes mid-sync). Then pending a final review from Zura before merging.
Full bootstrap still doesn't complete with the new p2p implementation. Alexander found that peers disconnect us when we start fetching blocks from them.


Feature/implement protobuf reader

Tickets addressed: 241
Review: By commit
Merge strategy: Merge (no squash)

Description

This feature should add a new C++ class ProtobufReader that can parse all of the binary data from a file and distribute this data during gameplay. The commits are organized by first adding the ProtobufReader and Implementation, then connecting this class to the ProtobufActor, and finally cleaning up extraneous files and UE Settings.
Verification
Validated by viewing that the vizmessage contents were printed to the screen as expected during play game.
Documentation
No Documentation needed
Future work

Modifying or removing/replacing the ProtobufActor as we learn what the best methods are to distribute the data from the ProtobufReader to actors in the scene.

Just to ensure you are aware, changes made to address PR comments will need to be rebased so that they occur in the commit where they originate. I'm happy to help with this.


Cannot read property 'parentNode' of undefined

Hey,
I can't use this plugin.
When I use advanced settings I have error - Cannot read property 'parentNode' of undefined - https://jsfiddle.net/6c029v1k/
When I use simple method I can't click - https://jsfiddle.net/aeg073ew/1/
Please help - what is wrong ?
Thanks
Michael

Gonna take a look at it. What do you mean by this?

When I use simple method I can't click

I clicked into the second link and the plugin is working good. Would you please elaborate? I'll look into the problem Cannot read property 'parentNode' of undefined and get back to you.


fix: fix mxnet failed to update StartTime and CompletionTime

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

/assign @johnugeorge

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 6 (0.0%)  changed or added relevant lines in 1 file are covered.
9 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.03%) to 39.949%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controller.v1/mxnet/mxjob_controller.go
0
6
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/mpi/mpijob_controller.go
9
78.03%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
2333

Relevant Lines:
5840

💛  - Coveralls


Why .hidden is forbidden in init of supportedPositions ?

Short description
I see .hidden is removed from supportedPositions during initialization. Why? Could you leave it as is?
Expected behavior
I want to set it so, then call panel in hidden state and stop playing with weird case .tip: return nil:
        var initialPosition: FloatingPanelPosition {
            return .hidden
        }

Actual behavior
But now .hidden is is removed from supportedPositions, and it obviously leads to crash

assert(supportedPositions.contains(layout.initialPosition),
"Does not include an initial potision((layout.initialPosition)) in supportedPositions((supportedPositions))")

Library version
1.4.0
Installation method

[ ] CocoaPods

iOS version(s)
10
Xcode version
10.1

Your proposal makes sense to me!  The reason why is just because I don't expect the use case when .hidden is used as an initial position.
I created PR #156. It will allows you to use .hidden initial position

This is a very useful feature! Look forward to seeing it in the new version! Thanks for the work!

+1 Waiting to this feature


chore: bdd-nh-1577375117 to 0.0.1

chore: Promote bdd-nh-1577375117 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Fix failing test on non-Windows.

https://github.com/aspnet/Coherence-Signed/issues/225
cc @pranavkm @NTaylorMullen @dougbu

:shipit:


[contrast] Add re-export of src/contrast/index.js to src/index-fn.js

Adds a missing re-export of the contrast functions to src/index-fn.js.
From https://github.com/LeaVerou/color.js/pull/162#issuecomment-1306232139:

Is it correct that the named contrast functions e.g. contrastAPCA are not included in colorjs.io/fn?

They should be. If not, it's a bug. But I believe they are exported en masse from contrast/index-fn.js, so if you're searching the source for contrastAPCA it won't find anything.

I've updated the TypeScript tests to make sure the contrast methods are importable through src/index-fn.js, but I'm not sure if there's anything to change for the tests in tests/.

@LeaVerou When can we expect a new release, with all the changes?


[JSDOC] Document missing APIs related to vertex attributes

The PR includes the following changes (with motivation):

Fix invalid jsdoc for parameter description (in pc.VertexFormat constructor) by moving it to a new interface pc.VertexAttributeDescription.
Add a second interface pc.VertexAttributeElement, which inherits all properties from the above interface (to avoid jsdoc duplication) as well as adding its own.
Rename properties in object pc.VertexFormat#elements to conform to the new interface (which will avoid duplication of jsdoc comments). Thus fully documenting pc.VertexFormat#elements.
Fix all references to old pc.VertexFormat#elements object properties, but keep backward-compatibility just-in-case (even though it was never documented).
Document pc.VertexIteratorAccessor and its methods.
Fix missing type for property pc.VertexIterator#element.

I confirm I have signed the Contributor License Agreement.

@willeastcott Feel I need to add some more explanation here since this PR includes code changes which I strongly want to avoid when my objective is to fix typings and documentation.
The biggest challenge I had with this PR was to document pc.VertexFormat#elements properly, since it shares a lot with parameter description (in the pc.VertexFormat constructor). Basically, I had two options:

Either document pc.VertexFormat#elements as-is and duplicate lots of existing documentation from the big object parameter description (in the pc.VertexFormat constructor).

Or rename a few properties in the pc.VertexFormat#elements object and share lots of jsdoc documentation thus avoiding duplication. This has also the side benefit of unifying the two objects pc.VertexFormat#elements and parameter description which improves API consistency and making it more intuitive.

I went with option 2 because I believe duplication will not only hurt readability and maintainability but also eventually lead to de-sync and confusing code documentation.

Just wanted to drop a quick comment in here. I've scanned the changes here and my reflex reaction is that I suspect this has the potential to break the Editor and certain PlayCanvas apps that leverage this part of the API. I'd have to do a more thorough investigation to weigh up the risks around that. But in short, I can't merge this as fast as your other PRs from yesterday.

@willeastcott If you are wary about the code changes, I could go with option 1 as described in my previous comment:

Keep pc.VertexFormat#elements as-is and duplicate all the documentation from the object type parameter description (in the pc.VertexFormat constructor), but use pc.VertexFormat#elements  specific property names.

@willeastcott Any updates?

Hello @willeastcott,
I've reverted all jsdoc for the description param in the VertexFormat constructor and removed VertexAttributeDescription, as discussed.
Also simplified VertexAttributeElement by removing the constructor params (since it's never meant to be constructed by user code). And as mentioned in a previous comment, I still think there is a stronger need for VertexAttributeElement (because the object is shared among multiple engine classes).
Let me know if you have any more comments or thoughts.

Let me put my concern another way. After this PR is merged, I would consult the API ref and assume I can do this:
pc.app.root.findComponent('model').meshInstances[0].mesh.vertexBuffer.format.elements[0] instanceof pc.VertexAttributeElement

But that would return false.

@willeastcott I'm all for it (was just trying to avoid code changes this time around). VertexAttributeElement is now changed to a regular class and instantiated inside VertexFormat. The behavior and properties are all the same.

@willeastcott Any chance we could merge or close this PR?
I have a subtle feeling you are not the biggest fan of it :)

@willeastcott Would it help if I just removed VertexAttributeElement. I'm happy to do that if that is what it takes. That's probably what you've been trying to say to me this whole time :)

Yeah, sorry this PR is still in limbo. 😞
Actually, it's still pc.VertexAttributeElement that I'm not keen on. I think I've mentioned before, this PR is documented a new PlayCanvas class just to circumvent a deficiency in the JSDoc -> TSD toolchain. Sure, it's harder to fix the issue there, but that's where the problem lies, not PlayCanvas' API.
As for pc.VertexIteratorAccessor, that method of iterating vertices in vertex buffers is incredibly inefficient. It's pretty much legacy. We're in the process of developing a new API for fast creation and editing of procedural meshes: https://github.com/playcanvas/engine/pull/1960  This part of the API will be even more irrelevant once we're done with that. I can imagine we might deprecate entirely sometime soon. I feel polishing these APIs, adding more public classes etc, is just encouraging developers to use it, when actually we want to do the opposite.

@willeastcott Thank you for responding.
I know you mentioned before that you're not keen on new classes just to fix typings. I responded by trying to argue that pc.VertexAttributeElement is different, but obviously failed :)
Anyhow, I hear you. I agree, iterating vertices in a interleaved vertex buffer is inefficient. The thing is, that interleaved data still considered to have better rendering performance. And from what I've seen in #1960, that PR will not provide a complete substitute for creating and accessing a interleaved buffer. And if a developer only needs to update/create a "procedural" mesh once, they should still have the option of choosing these "legacy" APIs for highest draw performance.
Additionally, as you know we're trying to write an glTF exporter for PlayCanvas. And having proper access to APIs like VertexIteratorAccessor is necessary to export vertex data efficiently without copying each attribute separately and re-creating the interleaved buffer ourselves in glTF.

Alright, @willeastcott.
I've removed the new class VertexAttributeElement. This PR now only improves documentation for existing classes. No new classes just to circumvent a deficiency in tsd-jsdoc. PR description is updated.
I'm just making one existing class pc.VertexIteratorAccessor public, which is already used by devs and exposed by pc.VertexIterator.html#element, This PR only improves upon that existing documentation. Please consider it. Proper documentation and type-safety and avoids a lot of unnecessary bugs.
Additionally, as mentioned before, the new procedural mesh API won't completely replace the need for pc.VertexIteratorAccessor.

This looks in good shape now. But I have merge #1960 first - a word of warning: there will be some merge conflicts after that. But hopefully they'll be easy to resolve.

Thanks for your patience on this one, @aidinabedi. Feels great to finally merge it. :tada:


translation of skills

Hey, I use your generator for a while now, pretty accurate results. Good job on that :)
My question tho: I play the game in German and sadly need to translate the skill names everytime. Nothing serious, but it would be nice to have the option to translate the skill names. I tried to add that functionality on my own, but I never worked with angular and this (little) project was overwhelming to me...

Do you just need the generated macro to be translated or is it more than
that?
On Tue, Apr 7, 2015 at 11:59 AM Ch. König<EMAIL_ADDRESS>wrote:

Hey, I use your generator for a while now, pretty accurate results. Good
job on that :)
My question tho: I play the game in German and sadly need to translate the
skill names everytime. Nothing serious, but it would be nice to have the
option to translate the skill names. I tried to add that functionality on
my own, but I never worked with angular and this (little) project was
overwhelming to me...
—
Reply to this email directly or view it on GitHub
https://github.com/doxxx/ffxiv-craft-opt-web/issues/55.

The macro should be enough. Skills are clear thanks to the icons (also I know the english translation).

I haven't been able to find a machine readable form of the crafting skills and their translations, which means I will have to construct my own. When I have the structure in place, I would appreciate your help putting in the German translation.

Sorry for my late response.
I created JSON files with translations for the english, german and french translations.
You can find them here: https://gist.github.com/CKing/908a348d846ae29bd81b

You rock! I'm working on this right now.

The site has been updated with the new version. I also included German and French xivdb tooltips. :)


API format changed and ticker is dead

[  ] fix ticker

Fixed in https://github.com/vegaprotocol/ticker-service/commit/ff9867c132a8c677a5ba9298fe6581786fa0e358


[IGNORE-ME] feat: draft pr for execute root fragment at FE instead of CN

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
PLEASE DO NOT LEAVE THIS EMPTY !!!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)

While debugging this pr, I found madsim test with more than 100 times still succeed, while the normal e2e test can reproduce this in 50% chance.
madsim:
MADSIM_TEST_NUM=100 ./risedev sslt -- "e2e_test/batch/basic/func.slt.part"

normal e2e
./risedev p

# Try twice or more and will fail in my PC
./risedev slt -p 4566 -d dev './e2e_test/batch/basic/func.slt.part'

Published this out for possibilities for investigating potential bug in madsim, cc @wangrunji0408 . Feel free to try this out and hope this help.
I will continue to debug this PR until the problems in normal e2e is solved, and will not amend the reproduced commit hash.

Here is another potential design:

Add some logic in StageExecution, e.g. if it's root stage, we create an async to run its plan fragment
Modify QueryResultFetcher to accept a channel rahter rpc

This way we don't need to do much modify scheduling logic and avoid code repeating.

Here is another potential design:

Add some logic in StageExecution, e.g. if it's root stage, we create an async to run its plan fragment
Modify QueryResultFetcher to accept a channel rahter rpc

This way we don't need to do much modify scheduling logic and avoid code repeating.

My understanding:

in StageRunner::run, if we detect root fragment, then we should treat it differently with other fragments: execute locally and write results into a channel.
QueryResultFetcher get the channel receiver, poll results one by one.

Do you mean that? I think LGTM

Here is another potential design:

Add some logic in StageExecution, e.g. if it's root stage, we create an async to run its plan fragment
Modify QueryResultFetcher to accept a channel rahter rpc

This way we don't need to do much modify scheduling logic and avoid code repeating.

My understanding:

in StageRunner::run, if we detect root fragment, then we should treat it differently with other fragments: execute locally and write results into a channel.
QueryResultFetcher get the channel receiver, poll results one by one.

Do you mean that? I think LGTM

Yes

Here is another potential design:
Add some logic in StageExecution, e.g. if it's root stage, we create an async to run its plan fragment
Modify QueryResultFetcher to accept a channel rahter rpc
This way we don't need to do much modify scheduling logic and avoid code repeating.

Implemented


Add -Wimplicit-fallthrough to most C++ targets

Explicitly not used in llvmSupport, which has intentional use of
implicit fallthrough

@swift-ci please smoke test

Yeah. I'll have to look up how to set per target flags in CMake...

@swift-ci please smoke test

Changed to xcconfig, added to CMakeLists.txt, and fixed up llvm files with attribute labels/pragmas where appropriate.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@jakepetroules BTW, thanks for the comments on this. I think I made a much more solid change overall. 👍


Harris Corner Detection

Hi, I'm a GSSoC`21 participant and want to contribute to this. I have good knowledge about Harris Corner Detection and want to apply my knowledge to practice, So can you please assign me this issue.
@geekquad sir and @kritikaparmar-programmer ma'am.

Hey @Ashishsingh619, this issue has already been assigned to someone. Please check #27.


Custom map layers

Add support for adding custom GeoJson layers to the map. This could be used for showing the coverage of the location service directly in NeoStumbler. At least BeaconDB provides its coverage as a GeoJson: https://beacondb.net/map/6.geojson

ichnaea provides coverage as a tile layer, are you planning to add support for that as well or only geojson?

ichnaea provides coverage as a tile layer, are you planning to add support for that as well or only geojson?

Custom map tiles should also be doable, but I'll do GeoJson first. Maybe create a new issue for custom map tiles?


Coordinate property missing iOS GoogleMaps in MapView.Marker onPress

Is this a bug report?
Yes

Have you read the Installation Instructions?
Yes
Environment
<EMAIL_ADDRESS>react: 16.0.0
react-native: 0.50.3
Target Platform: iOS 11.1.2 iPhone 6S
Map: GoogleMaps

Steps to Reproduce

Add a MapView.Marker to a MapView
Add a onPress prop to the MapView.Marker
In the callback function the value of the event's nativeEvent, the coordinate property is missing.

Expected Behavior

I expected to see a coordinate property in the event object.
Actual Behavior

The coordinate property is non-existent. If I remove the map provider and use AppleMaps then the coordinate value shows, GoogleMaps (our required platform) returns no coordinate property.
Reproducible Demo

https://snack.expo.io/ByIuKY9EM

@rborn I include this fix on #2011

@rafaellincoln so we can close this one?

@rborn yes.

Closing as per comments

@rafaellincoln when will be this PR be included on the update?

@jass-trix it's in master merged with #2011 . Use the git version.


do not use function signature hash for the checking functions equality

Codecov Report

Merging #5165 into udf will decrease coverage by 0.19%.
The diff coverage is 94.59%.

@@             Coverage Diff             @@
##                udf    #5165     +/-   ##
===========================================
- Coverage     82.59%   82.39%   -0.2%
+ Complexity    11196    11179     -17
===========================================
  Files          1349     1349
  Lines         45619    45624      +5
  Branches       5727     5729      +2
===========================================
- Hits          37677    37592     -85
- Misses         5266     5339     +73
- Partials       2676     2693     +17

Impacted Files
Coverage Δ
Complexity Δ

...te/operation/udf/UserDefinedFunctionsMetaData.java
91.83% <100%> (+0.17%)
22 <13> (+2)
:arrow_up:

...rate/operation/udf/UserDefinedFunctionFactory.java
36.36% <100%> (-9.8%)
1 <0> (ø)

...ons/UserDefinedFunctionAlreadyExistsException.java
80% <100%> (ø)
1 <0> (ø)
:arrow_down:

...ate/operation/udf/UserDefinedFunctionMetaData.java
80.18% <75%> (-0.59%)
25 <3> (+2)

...rate/operation/udf/UserDefinedFunctionService.java
92.15% <85.71%> (-3.59%)
16 <0> (+1)

.../main/java/io/crate/planner/PositionalOrderBy.java
41.02% <0%> (-41.03%)
9% <0%> (-4%)

...arch/indices/recovery/BlobStartPrefixResponse.java
66.66% <0%> (-33.34%)
3% <0%> (-2%)

...in/java/io/crate/data/CollectingBatchConsumer.java
69.23% <0%> (-15.39%)
4% <0%> (-1%)

...rc/main/java/io/crate/analyze/UnboundAnalyzer.java
75% <0%> (-15%)
2% <0%> (ø)

...transport/executionphases/ExecutionPhasesTask.java
83.33% <0%> (-12.04%)
21% <0%> (-3%)

... and 28 more

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 ef34c57...2a8be4a. Read the comment docs.


Adjust Basic Auth Timeout

We are using "local" auth in combination with pam_radius to authenticate via DUO proxy (i.e. RADIUS server with MFA) and found the BasicAuth timeout was statically set to 5 seconds. This does not leave users enough time to respond to MFA requests before the context deadline drops the connection.
This removes the static 5 seconds and adds a configuration setting for "BasicAuthTimeout" with a default of 5 seconds, but is configurable in cases such as these where longer timeouts are prefereable.

Awesome!


add integration tests on CLI

Codecov Report

Merging #42 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #42   +/-   ##
=======================================
  Coverage   91.51%   91.52%
=======================================
  Files          14       14
  Lines        1273     1274    +1
=======================================
+ Hits         1165     1166    +1
  Misses        108      108

Impacted Files
Coverage Δ

subaligner/predictor.py
89.63% <100.00%> (+0.03%)
: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 e624419...0c7c298. Read the comment docs.


User should not be asked to select language at every start

One of the feedback from the MOSAIC English Conversation group was that it'd be great if the user doesn't get asked to select the language every time the user launch the AA app (see screen shots). Entering this as an issue based on our discussion at Apr 10 Design Sprint

ACs:

When opening the app for the first time, see the language selector and onboarding flow
When opening the app for a subsequent time, opens straight on the Recommended Topics page
Start the app for the first time, quit the app during the onboarding flow, start the app again, see the language selector and onboarding flow.
Open the app for the first time, accept English as current locale, open the app a subsequent time, does not show the language selector.

Tested on staging app v 1.0.18:

When opening the app for the first time, see the language selector and onboarding flow --> PASSED

When opening the app for a subsequent time, opens straight on the Recommended Topics page --> PASSED

Start the app for the first time, quit the app during the onboarding flow, start the app again, see the language selector and onboarding flow. --> FAILED (see issue

Open the app for the first time, accept English as current locale, open the app a subsequent time, does not show the language selector. --> PASSED

If you want to demonstrate the app including the welcome screen, go into settings on the device, look  up the arrival advisor app, and delete all memory related to the app. This is a more complete delete all data than what is available from within the app help screen.


Edit Event Start and End times are incorrect

When clicking to edit an event the edit form date time is displaying the incorrect time. It appears the time is being converted to UTC rather than retaining the original local time.
This might be easier to fix after merge of #1154
Time in event display page (correct):

Time in event edit page (incorrect):

@stevejgordon just rebased for #1154 and waiting on merge. Not too sure if it will fix the problem, as any work with DateTimeOffset was abstracted away with #1154, so the problem may still persist. If it does persist, I'd be happy to pick this up.

@mgmccarthy iirc this is a locale issue. I think the date under the task is being rendered by razor and is in american format mm/dd/yyyy, where as the dates in the form are rendered in JS using UK format dd/mm/yyyy.
you may not be able to reproduce it due to your systems locale settings.

@dpaquette is this related to any work you are doing?

@tonysurma, my best guess is this is related to a bug that @dpaquette fixed last week sometime that fixed how the TimeTagHelper worked. Based on Dave's changes, this bug should be fixed.

@tonysurma I can pull the latest and test it quickly.

Looks like start date/time still has issue for me...

I thought I tested this in my local branch recently and it was working as expected. I will review. The problem is with aligning the formatting used by the bootstrap datetime component and the formatting used by the server.

I will have this fixed as part of PR #1416

Can this be assigned to me? This is related to the javascript datetime formatting issue I mentioned in the standup today.
Note this was not fixed as part of PR #1416. That PR grew out of control so decided to split it out.

Confirmed this with @stevejgordon today. This is partially fixed in that the times are no longer being shifted but the month and date are still being swapped around. I need to do some more testing to see if that is a problem or not.


191 add exercise 1 diagram and update text

Summary
Closes #191

add diagram to exercise 1 page
updated text to match language in lesson pages

Screenshots

I think that it makes more sense to just use a png with the text than to use the svg, since we need to put in the text for the svg, which is kind of a pain.

This is the result I got just putting in a screenshot lol.

Fixed png styling to scale correctly for small screens
Before:

After:


[BP-1.13][FLINK-22001] Fix forwarding of JobMaster exceptions to user

Backport of #15715 to release-1.13.

Thanks for the review @rmetzger. I will address your comment while merging this PR. The failing test case

Manually merged via ca9595317ba984120da00bc284c6109d0b4655d4


[Feature Request] Handle errors in keyword search better

Can we handle different type of errors separately:

Network issues
Connection issues (e.g. tls, incorrect endpoint, etc)
Unexpected Errors (not network related)
Others?

Originally posted by @alexey-temnikov in https://github.com/aws/graph-explorer/pull/243#discussion_r1515427925

Related to issue #275 and possibly resolved by PR #283

These errors are covered. If we come up with new errors to have specific messages for we can add a new GitHub issue.


Branch 141209775

Pushing internal commits.

since the other push is complete, can we close this one?


Unstable result in the GenericTensorNetwork example

          I see. I notice that although the code is much faster and all tests pass, the current version still can not produce the correct result in the following test case.

The output is probabilistic, hence it is very likely you did not sync threads after some computation. Can you please help me to make the following code produce correct result?
using GenericTensorNetworks, GenericTensorNetworks.Graphs
using CUDA
g = Graphs.random_regular_graph(200, 3)
optimizer = TreeSA(ntrials=3)
gp = IndependentSet(g; optimizer=optimizer)
contraction_complexity(gp)
@time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
using CuTropicalGEMM
# If you run the following line multiple times, the result changes.
@time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)

Originally posted by @GiggleLiu in https://github.com/ArrogantGao/CuTropicalGEMM.jl/issues/9#issuecomment-1737234657

I fixed the bug in a lazy way, I used 1D grid blocks to avoid the block overflow.
This simple test shows that the revision will not affect much the performance
julia> A = TropicalF32.(CUDA.rand(4096, 4096));

julia> B = TropicalF32.(CUDA.rand(4096, 4096));

julia> C = TropicalF32.(CUDA.zeros(4096, 4096));

julia> @benchmark CUDA.@sync mul!($C, $A, $B)
BenchmarkTools.Trial: 63 samples with 7 evaluations.
 Range (min … max):   4.613 μs … 13.549 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     13.545 ms              ┊ GC (median):    0.00%
 Time  (mean ± σ):   11.339 ms ±  4.983 ms  ┊ GC (mean ± σ):  0.00% ± 0.00%

                                                            █
  ▅▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁█ ▁
  4.61 μs         Histogram: frequency by time        13.5 ms <

 Memory estimate: 0 bytes, allocs estimate: 0.

Here are the result in the GenericTensorNetwork using the revised version of the package:
julia> using GenericTensorNetworks, GenericTensorNetworks.Graphs

julia> using CUDA

julia> using Random; Random.seed!(6)
TaskLocalRNG()

julia> g = Graphs.random_regular_graph(200, 3)
{200, 300} undirected simple Int64 graph

julia> item(x::AbstractArray) = Array(x)[]
item (generic function with 1 method)

julia> optimizer = TreeSA(ntrials=1)
TreeSA{Int64, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, GreedyMethod{OMEinsumContractionOrders.MinSpaceOut}, Any}(20, 0.01:0.05:14.96, 1, 50, 1.0, 0.2, :greedy, 0, Any[], GreedyMethod{OMEinsumContractionOrders.MinSpaceOut}(OMEinsumContractionOrders.MinSpaceOut(), 1))

julia> gp = IndependentSet(g; optimizer=optimizer)
┌ Warning: target space complexity not found, got: 28.0, with time complexity 33.47258510488839, read-write complexity 30.100720957270713.
└ @ OMEinsumContractionOrders ~/.julia/packages/OMEinsumContractionOrders/WpwIz/src/treesa.jl:229
IndependentSet{OMEinsum.SlicedEinsum{Int64, OMEinsum.DynamicNestedEinsum{Int64}}, NoWeight}(OMEinsum.SlicedEinsum{Int64, OMEinsum.DynamicNestedEinsum{Int64}}(Int64[], 18, 18 ->
├─ 18∘72, 18∘72 -> 18
│  ├─ 9∘72, 18∘9∘72 -> 18∘72
│  │  ├─ 9∘72
│  │  └─ 7∘18∘9, 7∘72 -> 18∘9∘72
│  │     ├─ 41∘22∘7, 41∘18∘22∘9 -> 7∘18∘9
│  │     │  ├─ 7∘41, 7∘22 -> 41∘22∘7
│  │     │  │  ⋮
│  │     │  │
│  │     │  └─ 22∘176∘9∘90, 9∘41∘22∘18∘176∘90 -> 41∘18∘22∘9
│  │     │     ⋮
│  │     │
│  │     └─ 72, 7∘72 -> 7∘72
│  │        ├─ 72
│  │        └─ 7∘72
│  └─ 18∘72
└─ 18
), SimpleGraph{Int64}(300, [[44, 158, 182], [66, 126, 167], [67, 85, 113], [10, 76, 105], [145, 148, 171], [56, 104, 180], [22, 41, 72], [149, 166, 173], [72, 90, 174], [4, 69, 129]  …  [55, 63, 137], [49, 86, 158], [15, 127, 176], [36, 102, 176], [120, 134, 178], [32, 94, 118], [30, 96, 113], [28, 81, 165], [45, 98, 189], [71, 75, 108]]), NoWeight(), Dict{Int64, Int64}())

julia> contraction_complexity(gp)
Time complexity: 2^33.47258510488839
Space complexity: 2^28.0
Read-write complexity: 2^30.100720957270713

julia> @time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
 31.197158 seconds (54.31 M allocations: 3.654 GiB, 2.21% gc time, 93.08% compilation time: <1% of which was recompilation)
0-dimensional CuArray{Tropical{Float32}, 0, CUDA.Mem.DeviceBuffer}:
89.0ₜ

julia> using CuTropicalGEMM

julia> @time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
  0.502034 seconds (539.53 k allocations: 32.931 MiB, 80.44% compilation time: 87% of which was recompilation)
0-dimensional CuArray{Tropical{Float32}, 0, CUDA.Mem.DeviceBuffer}:
89.0ₜ

julia> @time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
  0.110021 seconds (192.73 k allocations: 9.086 MiB)
0-dimensional CuArray{Tropical{Float32}, 0, CUDA.Mem.DeviceBuffer}:
89.0ₜ

julia> @time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
  0.116131 seconds (192.73 k allocations: 9.086 MiB)
0-dimensional CuArray{Tropical{Float32}, 0, CUDA.Mem.DeviceBuffer}:
89.0ₜ

julia> @time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
  0.110667 seconds (192.73 k allocations: 9.086 MiB)
0-dimensional CuArray{Tropical{Float32}, 0, CUDA.Mem.DeviceBuffer}:
89.0ₜ

julia> @time CUDA.@sync solve(gp, SizeMax(); usecuda=true, T=Float32)
  0.214065 seconds (222.74 k allocations: 10.002 MiB, 33.76% gc time, 2.98% compilation time)
0-dimensional CuArray{Tropical{Float32}, 0, CUDA.Mem.DeviceBuffer}:
89.0ₜ

julia> VERSION
v"1.10.0-beta2"

I made some efforts to enhance the perform of this package on mul between thin martices, but meet some strange bugs in CUDA, I will list that as a issue and try to improve that in the future.

Since this bug is fixed with #15, this issue is now closed.

solve by #15, which is already merged.


publish from MQTT to ROS

I am not able to publish from mqtt to ros2
below is the configuration
mqtt_client:
  ros__parameters:
    broker:
      host: <IP_ADDRESS>
      port: 1883
    bridge:
      ros2mqtt:                     # Object specifying which ROS topics to map to which MQTT topics
        ros_topics:                 # Array specifying which ROS topics to bridge
          - /ping/ros               # The ROS topic that should be bridged, corresponds to the sub-object in the YAML
        /ping/ros:
          mqtt_topic: pingpong/ros  # MQTT topic on which the corresponding ROS messages are sent to the broker
      mqtt2ros:                     # Object specifying which MQTT topics to map to which ROS topics
        mqtt_topics:                # Array specifying which ROS topics to bridge
          - pingpong/ros            # The MQTT topic that should be bridged, corresponds to the sub-object in the YAML
        pingpong/ros:
          ros_topic: /pong/ros      # ROS topic on which corresponding MQTT messages are published

MQTT publisher on topic
topic = "pingpong/ros"
if I do ros2 topic list I would expect to see /pong/ros but I am not seeing it.
What do I miss?
By the way I can publish from ros2 to mqtt with ros2 topic /ping/ros and mqtt topic pingpong/ros
Cheers

What type of data are you publishing, how does the payload look like?
Please note that the mqtt_client is primarily intended to bridge ROS topics via MQTT, i.e., to bridge ROS messages. If you are sending an MQTT payload with another MQTT client (i.e., not the mqtt_client ROS package), the receiving mqtt_client cannot deserialize the payload to a ROS message.
We do, however, support such exchanges for primitive message types. Please read through the dedicated README section and then try to set primitive: true for the mqtt2ros connection in your config file.

Thank you. It works
I added primitive: true to my configuration file
To answer your question, I am publishing a primitive data type, string


Fix code coverage

[Current coverage][cc-pull] is 62.11%

Merging [#107][cc-pull] into [portable-3.0][cc-base-branch] will increase coverage by 62.11%

@@           portable-3.0       #107   diff @@
==============================================
  Files                50         50
  Lines              2336       2336
  Methods             435        435
  Messages              0          0
  Branches            213        213
==============================================
+ Hits                  0       1451   +1451
+ Misses             2335        856   -1479
- Partials              1         29     +28

Powered by Codecov. Last updated by [7328fc2...6bf498f][cc-compare]
[cc-base-branch]: https://codecov.io/gh/NModbus4/NModbus4/branch/portable-3.0?src=pr
[cc-compare]: https://codecov.io/gh/NModbus4/NModbus4/compare/7328fc27ae1ca636b979bbe34056d81e2bde2948...6bf498f8e2b75ace78ec19747d0b4640282aefa9
[cc-pull]: https://codecov.io/gh/NModbus4/NModbus4/pull/107?src=pr


Refactor/error handling

I was looking for the 303 redirect functionality and didn't find it where I expected it to live, so in this PR I moved it to live next to where we handle other status codes.

I think another dependency (I suspect aiohttp) had it as a dependency but dropped it in a recent version. I've added the dependency explicitly now.

Thanks for the fix! Any other comments on my refactoring, or would you approve?

Thanks.


Git grep search error

Description
I'm encountering a failure when attempting to perform code searches in one specific repository of mine. This issue is exclusive to this particular repository; searching works fine in other repositories. Even when I try to create a new repository similar to the problematic one, I can't reproduce the issue.

Here's the additional information about the repository:

It has only one branch named "main".
All files are .md files.
There is a file named "readme.md".
The rest of the files have Chinese names, such as "通信协议.md".

Gitea Version
1.22.0+rc1
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
CentOS
How are you running Gitea?
docker compose
Database
SQLite

Could you login to the Gitea server and find the "repo.git", and "cat config" to see its content?

One more question: what's you git version?

Could you login to the Gitea server and find the "repo.git", and "cat config" to see its content?

Sorry, Gitea is deployed on the servers of the company I work for, and I'm off duty now. Also, due to the International Labor Day holiday, it'll be at least five days before I can send you the config and git version. I'll send the them once I'm back at work.

No problem. Since you are using CentOS, I guess the git version might be old. If it is possible, it's worth to try to upgrade to the latest git version.

If the search key word is Chinese, I got this error

Reproduced, will propose a fix.

->  Fix grep search #30843


Name of "System > All Displays" toggle should be more descriptive

Perhaps "Multiple Display Startup" or "Also Startup on External Displays"

Launch on All Displays


feat: support config functions with multi-compiler

What kind of change does this PR introduce?

feature
Did you add tests for your changes?

Yes, but let me know if inadequate.
If relevant, link to documentation update:

No documentation updates yet, but can provide. Arguably, the docs already imply that multiple functions are supported.
Summary

We already support configurations arrays for the multi-compiler, and configurations as functions in the singular case, but they don't seem to work together - until now.
Does this PR introduce a breaking change?

No.
Other information
Feel free to ask.

Thanks

Looks like we still need to support this for the programmatic API (i.e. webpack(options)).

Function support for the programmatic API proposed in https://github.com/webpack/webpack/pull/5585.


Footer class too thick when used in Grid

Thicc Boi
type: markdown
content: '# Appliances'
theme: LCARS Default
card_mod:
  class: footer-right

if you set "square: false" what do you get?

No change

Here's what's happening here:
The markdown card, because it's in the same row as larger card, is being forced to unnaturally match the height of its larger neighbor, thus stretching it's bottom border beyond its defined 10px. I assume this happens before it takes the size of the text into account, which could explain the little bit of overhang. How to fix this? I'm not sure, and I'm not sure it can be fixed as this is farther and farther into actual Home Assistant responsive behavior vs. simple CSS styling. (wait, nothing in this theme is simple) I'll be digging into this, but don't expect a fix soon.

In the meantime, you could try adding a blank line above your title in the Markdown, as described in the Tips and tricks section:
##
## Appliances

...adding or removing # to adjust the size of the blank line(s).


Release process: have a testing period for next major and minor releases

Make @latest releases more stable by adopting something to npm release process.
TL;DR: new version does not receives latest tag for some fixed time, until it battle-tested.  This allows to:

Still have a release with defined scope, which can be installed manually.
Have some testing period before declaring the release stable.

@j0tunn @DudaGod @sipayRT @eGavr

Can you give more details? I don't quite understand how it works and what should we do.

The main idea is to have some grace period before next release is declared stable. This should help  to reduce the number releases, which break not used by Yandex functionality (there were quite a few such releases lately).
The link in the description describes the process, npm uses for its CLI, which I think might be useful for gemini. Basically the whole idea boils down to delaying updating latest tag on npm package until some fixed time passed. For example, when we publish 4.12.0:

First publish is done with npm publish --tag next. This will allow version to be installed explicitly, but prevent automatic updates for ranges, like ^4.0.0. But if you want to have automatic updates to such version, you can still depend on gemini@next.
For some time (I would suggest a week) things stay stay that way. If critical bug is discovered in that time, we publish 4.12.1, 4.12.2 and so on as the next tag.
After grace period ended, we add latest tag to 4.12.x and enable automatic updates for semver ranges.

so after several failures user will get update from 4.12.1 to 4.12.7? and tags 4.12.2-4.12.6 will be ignored?

@sipayRT I would propose using it only for minor versions, since bug fixes should be delivered ASAP. So, in this case it will be more like:

if you have dependency on<EMAIL_ADDRESS>it will update from 4.11.3 to 4.12.6 without going throught presumably broken 4.12.0-4.12.6
Until 4.12 declared stable, you can install it explicitly with<EMAIL_ADDRESS><EMAIL_ADDRESS>or<EMAIL_ADDRESS>if you want autoupdates.
If you want to always live on a bleeding edge, use depend on gemini@next.

@SevInf so can I close this issue?

This functionality is implemented


Forbidden

Have panasonic updates something again?
I'm getting forbidden constantly now:
Traceback (most recent call last):
File "main.py", line 137, in
heat_pumps_status = get_panasonic_cloud_status()
File "main.py", line 86, in get_panasonic_cloud_status
panasonic_session.login()
File "C:\Program Files (x86)\Python 3.7\lib\site-packages\pcomfortcloud\session.py", line 99, in login
self._create_token()
File "C:\Program Files (x86)\Python 3.7\lib\site-packages\pcomfortcloud\session.py", line 132, in _create_token
raise ResponseError(response.status_code, response.text)
pcomfortcloud.session.ResponseError: Invalid response, status code: 403 - Data:

403 Forbidden

403 Forbidden

PR #44 should solve this, Panasonic has implemented a user-agent block now. Published as version 0.0.21


[Enhancement] Tabs Container styling

Sometimes we want to have a custom styles of containers in the tabs of the tab widgets. An option to add custom style to tabs like background color would be great.

Adding this to widget reskinning, will track it there.

Tested and verified.


Upgrade of volumio breaks NanoSound (no more remote, partial OLED)

After upgrading volumio to 2.599 (August 2nd) LIRC part of nanosound breaks (no more control).
Disable and enabling the plugin and watching the logs I find :
2019-08-24T16:36:30.654Z - info: Enabling plugin nanosound
2019-08-24T16:36:30.657Z - info: Loading plugin "nanosound"...
2019-08-24T16:36:30.658Z - info: Starting NanoSound Plug-in
2019-08-24T16:36:30.659Z - info: Applying required configuration parameters for plugin nanosound
2019-08-24T16:36:30.663Z - info: 1
2019-08-24T16:36:30.664Z - info: 2
2019-08-24T16:36:30.665Z - info: Starting NanoSound
2019-08-24T16:36:30.667Z - info: PLUGIN START: nanosound
2019-08-24T16:36:30.667Z - info: CoreCommandRouter::executeOnPlugin: system , getConfigParam
2019-08-24T16:36:30.840Z - info: NanoSound - Creating button triggers
2019-08-24T16:36:30.841Z - info: playPause on pin 13
2019-08-24T16:36:30.905Z - info: volumeUp on pin 10
2019-08-24T16:36:30.965Z - info: volumeDown on pin 9
2019-08-24T16:36:31.023Z - info: previous on pin 11
2019-08-24T16:36:31.073Z - info: next on pin 12
2019-08-24T16:36:31.121Z - info: shutdown on pin 4
2019-08-24T16:36:31.216Z - info: Done.
2019-08-24T16:36:31.237Z - info: Error enabling lirc-rpi overlay: Error: Command failed: /usr/bin/sudo /usr/bin/dtoverlay lirc-rpi gpio_in_pin=17
* Failed to apply overlay '2_lirc-rpi' (kernel)

2019-08-24T16:36:31.355Z - info: NanoSound OLED daemon started
2019-08-24T16:36:32.442Z - info: NanoSound lirc correctly started
2019-08-24T16:36:32.645Z - info: lirc correctly started

Looking into it.

This might be a problem related to the new kernel. lirc-rpi might be replaced by gpi-ir https://www.raspberrypi.org/forums/viewtopic.php?t=236240
/usr/bin/dtoverlay gpio-ir gpio_pin=17

seems to work. Produces the following in syslog :
[681096.223178] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver@19/rc/rc0
[681096.223440] input: gpio_ir_recv as /devices/platform/ir-receiver@19/rc/rc0/input0
[681096.223712] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter
[681096.777966] input: lircd as /devices/virtual/input/input1
[681098.587480] input: lircd as /devices/virtual/input/input2
[681133.770763] input: lircd as /devices/virtual/input/input3
[1714113.806490] input: lircd as /devices/virtual/input/input4
[1714482.694527] input: lircd as /devices/virtual/input/input5
[1714871.108491] Registered IR keymap rc-rc6-mce
[1714871.109182] rc rc1: gpio_ir_recv as /devices/platform/ir-receiver@11/rc/rc1
[1714871.109810] input: gpio_ir_recv as /devices/platform/ir-receiver@11/rc/rc1/input6
[1714871.110904] rc rc1: lirc_dev: driver gpio_ir_recv registered at minor = 1, raw IR receiver, no transmitter
[1714871.313293] input: lircd as /devices/virtual/input/input7
[1714881.897907] rc rc1: two consecutive events of type space

still not working ,but this might be because I seem to have lost my lirc configuration (not sure yet)

Here is an example of the code that does both dtoverlay : https://github.com/volumio/volumio-plugins/blob/master/plugins/accessory/ir_controller/index.js#L229-L257

Just upgraded to 2.609 and this is still an issue.
Although, a brief look at my notes from last time, doesn't appear to magically fix this, this time... but I need to check again (more slowly / carefully)
Anyway, @nanomesher, this problem still appears to be a problem.

hi all,
This is actually an issue caused by kernel 4.19 upgrade since volumio 2.599.
We have done a permanent fix with a new implementation and awaiting PR to be merged
Before it is merged and deployed to volumio repo, you can install it manually via method 3

Moverover, with this implementation you can adapt your own remote


Thoughts on adding support for Application Guard?

This would be a nice feature, and could possibly be extracted from the sources of Chromium Edge available at https://thirdpartysource.microsoft.com.

I honestly don't know if this is a good approach to getting access to this functionality for those reasons:

Microsoft Edge source tree is huge, it would add another 3GB of download just so we could pull it and extract the important parts;

Yes, we could build a patch set based on their code, but it would take some effort for the developers to read thru the changes and write the correct patches;

Most users are probably running Windows 10 Home or, if on Pro or Enterprise, not running with Application Guard enabled on their systems. We would be adding complexity to the build system to very little profit to the majority of the user base (probably);

You can use Microsoft's own browser extension paired with their companion app (downloadable from Microsoft Store) to achieve more or less the same functionality, even though I wouldn't recommend it as Microsoft collects telemetry trough their extension (check: https://chrome.google.com/webstore/detail/application-guard-extensi/mfjnknhkkiafjajicegabkbimfhplplj);

Even if you don't want to use Microsoft's own solution for cases like yours, there's solutions like Sandboxie-plus and Windows Sandbox that can be configured to provide a safe and isolated environment for your browser.

Those are my (more) than 2 cents.


loop_closure_handler.cpp line 144

Thank you for your excellent work. I have some questions about the code. The min index here is less than 6, which I don't quite understand. Is it required to return to the starting position of the robot before the loop detection is calculated? Doesn't it count when I run into a loopback check in the middle?
ROS_INFO("find loop: %i", min_index);
if(min_index < 6){
return min_index;
}

Thanks for pointing this problem. This was a test which I forgot to delete. It should be disabled. In our method, we provided three different methods (ScanContext, ORB, KDTree) for loop detection. You are welcome to try other two methods to find a better one.

Thanks for pointing this problem. This was a test which I forgot to delete. It should be disabled. In our algorithm, we provided three different methods (ScanContext, ORB, KDTree) for loop detection. You are welcome to try other two methods to find a better one.

Understand. Thank you again for your excellent work

Thank you! I appreciate your kind words. If you have any more questions, feel free to ask.


DOCS: Update version numbers and prereqs for 4x

Description
This PR includes updates to the prerequisites and version numbers for 4.x variables in the doc. I used the pom.xml file to get the latest version numbers and then updated the attributes.adoc variables which are used throughout the the docs.
Documentation
If enhancement: provide description with example code/config snippet or pointer to issue with the description
If feature: summarize feature and provide pointer to doc issue
If no doc impact: None

Note that this is how LRA is listed in the dependencies/pom.xml file. Does it need to be updated there?
<version.lib.microprofile-lra-api>2.0-RC1</version.lib.microprofile-lra-api>


[BUG] DRC exclusion workaround fails with interposer.py error

When running DRC with the drc_exclusions_workaround flag set, I get the following error in my CI logs:
- Running the DRC
ERROR:Unknown KiCad dialog: *(my pcb name here) — PCB Editor (pcbnew_do - interposer.py:355) (kibot - kiplot.py:123)
ERROR:Potential dialog messages: {'Refilling ', 'Tessellating ', 'Selection Filter', 'all ', 'copper ', 'Vias', 'Appearance', 'Pads', '352', 'zones...', 'H'} (pcbnew_do - interposer.py:356) (kibot - kiplot.py:123)
ERROR:DRC returned 9 (kibot.pre_run_drc - pre_run_drc.py:[71]

If I run the same script, but without drc_exclusions_workaround, the DRC runs (but the build fails when it discovers an excluded error that I expected to find on my PCB).
This is running as a GitHub Action, using the following:
jobs:
  Exports:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: INTI-CMNB/KiBot@v2_dk6
        with:
          config: ${{env.script}}
          dir: ${{env.dir}}
          schema: ${{env.schema}}
          board: ${{env.board}}

and my config file:
kibot:
  version: 1

global:
  # Use GUI version of the DRC engine. Slower, but correctly processes DRC exclusions
  drc_exclusions_workaround: true

preflight:
  update_xml: true
  run_drc: true
  check_zone_fills: true
  ignore_unconnected: false

outputs:
  (Sch)
  (BoM)
  (IBoM)
  (Gerbers)
  (Placement)
  (STEP)

Now KiAuto should discard main window title changes.
I reproduced it using a PCB with zones to be filled.
Thanks for reporting


Rename druid-win-shell to druid-shell

As part of platform independence, rename druid-win-shell to remove the
reference to a specific platform.
Also fixes druid-shell examples, which were slightly broken.
Normalizes line endings to LF (not CRLF).
Part of #13

One thing that came up, the druid-shell examples didn't compile, so we should make sure CI gets those. I think a good way to do that is set up a workspace; this should also help with RLS.


Propose an RFC process based on Rust's but lighter weight

RFC rendered
Template rendered

I just thought of another way we could potentially speed up our lighter-weight version of Rust's RFC process: make voting on an RFC happen in parallel with waiting on N days of FCP before merging, rather than waiting on votes and then sequentially starting N days of FCP.
----------------------------- time ------------------------------>

                    Rust's RFC Process
                    ==================

    |-------- FCP proposal --------|------- FCP ----------|
    ^                              ^                      ^
    |                              |                      |
    |                              |                      |
Team member                     All team                N days of FCP
proposes FCP                    members sign            have passed, so RFC
                                off                     is merged/closed

                    Lighter-weight RFC Process?
                    ===========================

                                       N days of FCP occur
                                       concurrently with team
                                       voting yay or nay on
                                       the RFC
                                           |
                                           V
    |------------------- FCP --------------|
    |-------- Team Voting ---------|
    ^                              ^
    |                              |
    |                              |
Team member                     All team
proposes vote                   members sign
                                off, but we
                                still have to
                                wait for N
                                days of FCP to
                                complete

What if a team member says we shouldn't move to FCP then? We'd already be in the middle of it. My understanding was that the team voting initiates FCP

What if a team member says we shouldn't move to FCP then? We'd already be in the middle of it. My understanding was that the team voting initiates FCP

I was imagining that it would cancel the FCP and we would go back to development, the same way new concerns raised during FCP can send the RFC back to development. Open to other suggestions as well, or also keeping the serialized voting and then FCP.

During our last WG meeting, @ashleygwilliams suggested adding some sort of "here is the outreach I've done to outside stakeholders" section to the template. I'll add something like that and then probably propose FCP (without the concurrent FCP and signing off discussed above).

I am proposing we enter Final Comment Period for this RFC that establishes our RFC process! :)
Disposition: merge
@rustwasm/core members to sign off:

[X] @fitzgen
[ ] @ashleygwilliams
[ ] @alexcrichton

👍 Looks great to me!

very excited for this. thanks for the effort @fitzgen

Enter the first :sparkles: Final Comment Period! \o/

FCP complete! The dawn of a new era! :tada:


Auto launcher

This PR adds the functionality to have ovr_test automatically launch with SteamVR. This does however require that the ovr_test.exe remains two directorys above the driver dll but that should always remain there. To set the launch arguments, there will be a file called args.txt which you just specify the arguments as you normally would on the command line.

I need to review this properly on a computer to make sure I'll happy with it all, but it looks fine in principle. It does conflict slightly with my personal use mode which is to use the running/not running of the external part as an easy way to not run the driver but it's probably better for most users.

You could always add in a setting to disable the autolauncher, just get the driver to read from the steamvr settings file

My latest commit 0e16b34 adds a basic feature that just displays where the Oculus sensors are in OpenVR space.


[Proposal]Encoding like shift-jis on export

Prerequisites

PHP version: 7.4
Laravel version: 5.7
Package version: 3.1

Description
To have a desire output on encoding with configuration since we can set encoding with import

It's not high on my prio list right now, but I'd consider merging a PR that adds it in a nice, clean, but most importantly opt-in way.