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

Upgrade xterm to 3.11.0 and remove vendored addon #787

Closed
wants to merge 2 commits into from

Conversation

betatim
Copy link
Member

@betatim betatim commented Feb 13, 2019

The goal of this PR is to get us to xterm.js 3.11.0.

I had hoped that this was just a matter of editing package.json but alas no :(

My guess is that something needs changing in our webpack config because xterm.js is no typescript based??

The state of this PR results in the following error in the console after running npm run webpack && python3 -m binderhub -f testing/minikube/binderhub_config.py (with nvm version showing v11.7.0)

screen shot 2019-02-13 at 10 19 51

I don't think this has anything to do with the addon because if you remove all reference to the addon you get:
screen shot 2019-02-13 at 10 24 38

So I think something about how we import the xterm stuff needs to change. Could someone point me in a/the right direction for reading material?

@betatim
Copy link
Member Author

betatim commented Feb 14, 2019

I'm going to need an assist from @captainsafia or @yuvipanda (or someone else who understands what we are doing in terms of JS and TS and webpack).

I've updated the code. I think this is how you should use the xterm extensions mechanism. Visiting http://localhost:8585 gives me this error:

screen shot 2019-02-14 at 07 54 20

To setup things:

  • checkout this PR
  • npm install and npm run webpack
  • python3 -m binderhub -f testing/localonly/binderhub_config.py (no need for minikube and friends)

@@ -144,7 +143,7 @@ function build(providerSpec, log, path, pathType) {
image.onStateChange('*', function(oldState, newState, data) {
if (data.message !== undefined) {
log.write(data.message);
log.fit();
fit(log); //log.fit();
Copy link
Member Author

Choose a reason for hiding this comment

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

Turning this around so that you don't need applyAddon is what jupyter lab does as well and seems to work.

@betatim
Copy link
Member Author

betatim commented Feb 15, 2019

With the changed way of using fit() things are working ... except the fit addon struggles with us hiding the parent HTML element (NaNs start appearing in its calculation of the height and width)

Copy link
Collaborator

@captainsafia captainsafia left a comment

Choose a reason for hiding this comment

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

Sorry for the delay in getting back to you. I'm going to give this a whirl now.

@@ -444,6 +444,9 @@ def initialize(self, *args, **kwargs):
kubernetes.config.load_kube_config()
self.tornado_settings["kubernetes_client"] = self.kube_client = kubernetes.client.CoreV1Api()

else:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this change related to the upgrade?

Copy link
Member Author

Choose a reason for hiding this comment

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

I needed this (as a hack) to be able to run in "frontend dev only mode". I didn't spend a lot of time trying to work out why this change or how else one could fix it. Once this PR works we should think about the proper way of fixing this (or punting to a new PR).

@betatim
Copy link
Member Author

betatim commented Mar 5, 2019

Just read some feedback from a workshop that used Binder and one comment was "I wouldn't have ever thought of unfolding that logging pane" which makes me wonder: should we have it open by default?

Less tidy but easier to discover and maybe gives more of an impression of "wow, stuff is happening!".

If we started toggled open I think that would solve the problem here of the plugin being confused about starting from size zero. So we could still have the toggle to hide the logs for those who aren't calmed by seeing them.

Reflecting on my personal usage pattern I almost always unfold the logs to see what is up and I think in the few cases where I don't care about keeping track of progress I'd probably also not care about a busy log scrolling by.

@yuvipanda
Copy link
Collaborator

I too prefer the logs to be open by default...

@captainsafia
Copy link
Collaborator

In that case, maybe it is worth exploring having the logs open by default as a way to workaround the issue @betatim mentioned and to provide this to users. Might kill two birds with one stone.

@manics
Copy link
Member

manics commented Sep 20, 2021

See #1365

@manics manics closed this Sep 20, 2021
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.

4 participants