You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to add code completion to Swift-Colab, and I came across a technical roadblock that I cannot overcome. If you make a Colab notebook with a language other than Python or R in its "kernelspec", the editor will never support rich completions.
For Swift-Colab, this is bad news. In order to enable code completion, I now have to make the Colab notebook syntax-colored like Python. Also, the editor would make comments start with # when you do Cmd + /. You need comments to start with // in Swift. Given that the user can deal with the un-ergonomic experience of Python syntax coloring, the frontend will now correctly send complete_request messages to the Jupyter kernel. From there, I can perform Swift code completions inside the custom Jupyter kernel.
Before S4TF "shut down", it seems Colab did not have this awkward restriction. In tensorflow/swift-apis#562 (comment), there is an image of Colab having both working Swift code completion and correct Swift syntax coloring with the old Jupyter kernel. This image seems strikingly similar to Google Colab in dark mode, and not reminiscent of a local Jupyter notebook's interface.
I studied the 5000-line file external_polymer_binary.js by going to a Colab notebook > Inspect Element > Sources > colab.research.google.com/v2/external/external_polymer_binary.js. That JS file contains the entire Colab client-side runtime. It seems that this is the only file where one could restrict complete_request messages to the Python and R languages. I saw one spot that sets some value to null if the language is not Python or R (line 3130), but I couldn't trace it to the only spot that executes a complete_request command (line 5110).
I don't know if this is the proper place to ask this of Google, but I want them to remove the restriction in external_polymer_binary.js that prevents complete_request from being called with foreign languages. This would not only help Swift-Colab, but also provide more flexibility for other third-party kernels such as the Julia kernel. They may have added that restriction after they shut down S4TF and wanted to avoid spending money maintaining Swift support on Colab. But unlike hosting a Jupyter kernel and 2 GB toolchain on their servers (which is active support), the patch I suggest to external_polymer_binary.js is passive support. It should only involve adding a few bytes to a Javascript file, which shouldn't cost any significant amount of money.
P.S. external_polymer_binary.js seems like a concatenation of several open-source Javascript files. Some are from Polymer (although I can't locate them in the Polymer repository), while for others I have no clue where they originate. If you could direct me to the repositories from which external_polymer_binary.js originates, I could file an issue there.
The text was updated successfully, but these errors were encountered:
We used to have a completer for Swift, seems like we could put something in more generic for the 'long tail' of languages used in Colab. Investigating.
Is there anything else you could say about how this issue is being tracked internally? For example, are there plans to create a new API for code completion in any language? If that will take a long time to implement, perhaps there could be a short-term backdoor to let kernel developers enable code completion.
I am trying to add code completion to Swift-Colab, and I came across a technical roadblock that I cannot overcome. If you make a Colab notebook with a language other than Python or R in its "kernelspec", the editor will never support rich completions.
For Swift-Colab, this is bad news. In order to enable code completion, I now have to make the Colab notebook syntax-colored like Python. Also, the editor would make comments start with
#
when you doCmd + /
. You need comments to start with//
in Swift. Given that the user can deal with the un-ergonomic experience of Python syntax coloring, the frontend will now correctly sendcomplete_request
messages to the Jupyter kernel. From there, I can perform Swift code completions inside the custom Jupyter kernel.Before S4TF "shut down", it seems Colab did not have this awkward restriction. In tensorflow/swift-apis#562 (comment), there is an image of Colab having both working Swift code completion and correct Swift syntax coloring with the old Jupyter kernel. This image seems strikingly similar to Google Colab in dark mode, and not reminiscent of a local Jupyter notebook's interface.
I studied the 5000-line file
external_polymer_binary.js
by going to a Colab notebook > Inspect Element > Sources > colab.research.google.com/v2/external/external_polymer_binary.js. That JS file contains the entire Colab client-side runtime. It seems that this is the only file where one could restrictcomplete_request
messages to the Python and R languages. I saw one spot that sets some value tonull
if the language is not Python or R (line 3130), but I couldn't trace it to the only spot that executes acomplete_request
command (line 5110).I don't know if this is the proper place to ask this of Google, but I want them to remove the restriction in
external_polymer_binary.js
that preventscomplete_request
from being called with foreign languages. This would not only help Swift-Colab, but also provide more flexibility for other third-party kernels such as the Julia kernel. They may have added that restriction after they shut down S4TF and wanted to avoid spending money maintaining Swift support on Colab. But unlike hosting a Jupyter kernel and 2 GB toolchain on their servers (which is active support), the patch I suggest toexternal_polymer_binary.js
is passive support. It should only involve adding a few bytes to a Javascript file, which shouldn't cost any significant amount of money.P.S.
external_polymer_binary.js
seems like a concatenation of several open-source Javascript files. Some are from Polymer (although I can't locate them in the Polymer repository), while for others I have no clue where they originate. If you could direct me to the repositories from whichexternal_polymer_binary.js
originates, I could file an issue there.The text was updated successfully, but these errors were encountered: