Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propagate and handle connection/disconnection events #1142

Merged
merged 14 commits into from
Mar 22, 2023

Conversation

sebjulliand
Copy link
Collaborator

Changes

This PR follows changes introduced by #1110.
Disconnecting and connecting to another IBM i would leave the extension in a state where some part would remain initialized for the previous connection:

  • Debug was not checked again
  • CL prompting tool was not checked again
  • Last connection setting was not updated
  • The member file system provider remained configured for the previous connection's settings

The PR mainly reorganize the extension initialisation process and leverage the connected / disconnected events to handle connection changes.

Noticeable changes:

  • Available events are now enumerated using the IBMiEvent type (makes it easier to use and find event references)
  • member file system provider now dynamically adapts to the current connection's settings and its changes. Most of the related code has been reorganized and converted to TypeScript
  • Some extension's subscriptions have been moved from instantiate.ts to extension.ts
  • Some initialization methods have been split in two: actual initialization and on connected event intialization; mainly for Debug, Deployment, Instantiate and QSysFS
  • Every command requiring a connection is now only visible in the command palette when connected

Checklist

  • have tested my change
  • eslint is not complaining

@chrjorgensen
Copy link
Collaborator

@sebjulliand I cannot comment on the code, but a quick run showed the following:

  • A click on the force reconnect button billede in the bar does not reconnect to same system, but goes to list of previous connections. Is that intended?
  • You took out Enable Source Dates from the restart group, but changing the settings does not change the behavior of the connection. After disabling and enabling, the source dates are not shown. Even after a complete VS Code restart there are no source dates - and I can't make them appear again at all in any system, although the source dates settings are enabled.
  • I opened a filter in Object Browser and source files appeared, restarted VS Code fully and reconnected to same system - and now no source files appear before I refresh the Object Browser:
    billede
    This also happens when I do a complete VS Code restart: First click on a filter in Object Browser opens the filter but shows no filter content.
  • When disconnecting from a system and connecting to another system, the Object Browser shows the content from the previous system, and only after a while is the filters from the current system shown.

Enough for now... 😉

@sebjulliand
Copy link
Collaborator Author

sebjulliand commented Mar 18, 2023

Superb feedback @chrjorgensen , thanks!
I think I got it all sorted out.

A click on the force reconnect button billede in the bar does not reconnect to same system, but goes to list of previous connections. Is that intended?

More or less! When I worked on the Connect to previous PR, I changed the way commands worked, and the one bound to this button showed the list of system ordered by date of connection.
Now, since we can disconnect gracefully, I thought that button served no purpose anymore. So I removed the setting to show/hide the disconnect/reconnect buttons, removed the reconnect button and showed the disconnect button permanently.

You took out Enable Source Dates from the restart group, but changing the settings does not change the behavior of the connection. After disabling and enabling, the source dates are not shown. Even after a complete VS Code restart there are no source dates - and I can't make them appear again at all in any system, although the source dates settings are enabled.

My bad...I called references to methods instead of the date handler instance's methods, which resulted in a crash (your console should have been full of those). Now it's ok, instance methods get called, the date shows and if the date settings is changed with opened member, a warning is issued to ask to close the editors to apply the change.

I opened a filter in Object Browser and source files appeared, restarted VS Code fully and reconnected to same system - and now no source files appear before I refresh the Object Browser:
billede
This also happens when I do a complete VS Code restart: First click on a filter in Object Browser opens the filter but shows no filter content.

This one I'm not sure about. I reorganized the call to the views' refresh when connecting, hopefully it should fix the issue. The views will also refresh synchronously on disconnect to empty them. There should not be any remaining items from a previous connection this way.

When disconnecting from a system and connecting to another system, the Object Browser shows the content from the previous system, and only after a while is the filters from the current system shown.

Fixed!

Enough for now... 😉

Right! Enjoy your week-end 😉

@worksofliam
Copy link
Contributor

Woah, big change indeed. I've had a review and I appreciate your notes about the significant changes. The biggest change here that I am worried is to the member file system, in particular continuing to support 'edit' and 'diff' mode when source dates are enabled.

I need to sit down for a few hours and just use Code for IBM i on this branch to give it some real testing - and that's exactly what I'm going to do tomorrow (Sunday) morning.

  • Editing with source dates disabled
  • Editing with dates enabled in edit mode
  • Editing with dates enabled in diff mode
  • Compiling source code in each of those modes
  • Ensure that deploy continues to work
  • Ensure CL installation works on first connect and subsequent connections
  • Ensure debugging is checked on each system

@sebjulliand @chrjorgensen Seeing as this is the largest PR at the moment, would you say this should go to the top of the queue with highest priority?

Great work. I admire your skill!

@sebjulliand
Copy link
Collaborator Author

As always, thanks for your appreciation, it means a lot 😊
The FS change change is indeed the most important here - hopefully nothing got lost during the refactoring.

AFAIC, I would say this PR should be merged as soon as it's approved, given the amount of changes in there and the fact it fixes/enhance the "Disconnect gracefully" PR that's already been merged.

@worksofliam
Copy link
Contributor

Ok, after my testing this is what I've found:

  • Compiling works as expected in all edit modes as expected
  • CL program gets installed on every reconnect as expected

Here's a couple of issues:

Deploy

Deploy status bar item was not showing up on the first connection even with a local folder open:

Screenshot 2023-03-19 at 11 45 25 AM

Though if I disconnected and connected to the same system again, it was shown:

Screenshot 2023-03-19 at 11 46 34 AM

Source dates

On first time connect, it was mostly working. The logic to track edits looks like it was working correctly - this is the important part!

When opening a file though, the gutter was not appearing even when I had source dates enabled (usually it has to render when the file has been opened also).

Screen.Recording.2023-03-19.at.11.42.14.AM.mov

Lastly, the biggest issue was that the gutter was not showing at all if I disconnected and reconnected to the same system. Couldn't really understand why.

Copy link
Contributor

@worksofliam worksofliam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see my review above.

@sebjulliand
Copy link
Collaborator Author

@worksofliam I fixed it all (well...at least what you found!).
The deploy action bar now shows correctly and source gutter is displayed correctly.

@worksofliam
Copy link
Contributor

@sebjulliand i will play some more tonight! Great work!

Copy link
Contributor

@worksofliam worksofliam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just gave your changes a whirl. I am very happy with this change. I am just have a stroll through the code and take a look and how you managed it!

@chjorgensen Would you also mind giving this another go? I think we're getting close to merging this in.

getConnection() {
return this.connection;
}
private connection: IBMi | undefined;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is welcome change. Fingers crossed anyone using our extension API isn't using these!

worksofliam
worksofliam previously approved these changes Mar 22, 2023
Copy link
Contributor

@worksofliam worksofliam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy with my testing and the code - how grateful I am. This will allow for a much improved switch between systems. A welcome UX change.

@chrjorgensen Before we merge, I'd like your overview also. If you agree with me that it runs stable, I think we can go ahead and merge.

Copy link
Collaborator

@chrjorgensen chrjorgensen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebjulliand A quick review found the following:

  • Disconnecting with a branch open in the object browser gives the following message:
    billede
  • When disconnecting, the message Disconnecting from... stays on screen. Should be Disconnected from....
    billede

It's great to be able to change the source date settings and just reopen the editor and not having to disconnect + reconnect! 👌

@sebjulliand
Copy link
Collaborator Author

@chrjorgensen thanks for the testing!

Disconnecting with a branch open in the object browser gives the following message:
billede

Fixed...

When disconnecting, the message Disconnecting from... stays on screen. Should be Disconnected from....
billede

...and fixed!

Copy link
Collaborator

@chrjorgensen chrjorgensen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebjulliand LGTM - no further problems found.

@worksofliam I'll let it be up to you to approve - I have not found any more issues.

worksofliam

This comment was marked as duplicate.

Copy link
Contributor

@worksofliam worksofliam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy too. Let's merge! This will be released tonight in 1.7.6.

@worksofliam worksofliam merged commit 1df788a into master Mar 22, 2023
@sebjulliand sebjulliand deleted the feature/disconnectionPropagation branch March 23, 2023 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants