Bug: Assign the eraser to a pen button

Describe the issue
Following up the discussion on the Forum, here the bug report / feature request
Steps to reproduce the issue

Open a freehand drawing
Use the Pen buttons

Expected behavior
I would like to assign the pen buttons to do something useful, e.g. the eraser function
Observed behavior
Nothing happens when pressing any of the buttons.
Version information
2.11.0
Platform
Joplin Desktop v3.0.9
Logs
input.log
Additional information
Currently using the Lenovo precision pen 2

Thank you for the input log!
Based on that, the app is receiving pen events with type mouse and buttons = 1, which is specified to be one of the following:

Left Mouse,
Touch contact,
Pen contact

If this is on Linux, I see that a similar upstream Chromium bug exists (Joplin uses Electron, which is based on Chromium) (links to this StackOverflow post and this GH issue comment).

Looking at the Chromium source code, it looks like Chromium (and hence Joplin) might support stylus eraser events when running under Wayland[^1]. This comment suggests that this code might only apply on ChromeOS, and that code might need to be modified to use different events (this function?)

Possible workaround:
- I could create a keyboard shortcut that, while pressed, switches to the eraser tool and, when released, switches back to the previous tool.
- I'm not sure whether it would be possible or convenient to then map the stylus eraser button to this keyboard shortcut.
[^1]: Start Joplin with --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

Note: this StackOverflow post summarizes support for pen/stylus pointer events in desktop browsers as of July 2024.

Closing as a duplicate of https://github.com/personalizedrefrigerator/js-draw/issues/52.


demo issue

Hello friend, I'm sorry to bother you again. I used the "pip install pymagsac" command to install pymagsac, but ran the demo.py command in readme and the result was incorrect. I hope to receive your help again.（Teacher Danini's project was not successfully installed, so I used "pip install pymagsac" to install it）

Hi! It doesn't matter which way you choose to install MAGSAC. Now it's easy to install it through pip, but please pay attention to different arguments from what I used, e.g, correspondences = [x1, y1, x2, y2] in (n, 4).

Sorry for the delay in responding. Thank you for your help. Wishing you a Merry Christmas in advance!

 Hello friend, I'm sorry to bother you again. I used the "pip install pymagsac" command to install pymagsac, but ran the demo.py command in readme and the result was incorrect. I hope to receive your help again.（Teacher Danini's project was not successfully installed, so I used "pip install pymagsac" to install it）

您好，我和您产生了一样的错误，我想请问一下您这个是怎样解决的？谢谢


Implement shared lock

Coverage decreased (-1.4%) to 78.677% when pulling 6649daed7bc413536b7f87077b884ffb057e27c5 on shz117:master into c4fab1ac1bec58281ad0667dc3f0907a9476ac47 on samuel:master.


Create a permanent URL for the signing service

We need a permanent URL for the mobile signing service; its currently using one that is specific to the cluster. It should be a vanity URL so we don't need to be concerned with the cluster it runs on.

@ShellyXueHan Just occurred to me that the mobile signing serves should have a vanity URL so we can move it to a new cluster? Once we move it the URL will change because its using a pathfinder based URL.

archiving this service


nginx with nginxModules.echo is broken on nixos-17.09

Issue description
As per the title, nginx with nginxModules.echo is broken on revision 670b4e29adc16e0a29aa5b4c126703dcca56aeb6
Steps to reproduce
git clone https://github.com/NixOS/nixpkgs-channels
cd nixpkgs-channels
git checkout 670b4e29adc16e0a29aa5b4c126703dcca56aeb6
nix-build -I nixpkgs=. -E "with import <nixpkgs> {}; let stable = import <nixpkgs/pkgs/servers/http/nginx/stable.nix>; in pkgs.callPackage stable { modules = [nginxModules.echo]; }"

Technical details

System: 17.03.1820.a0e6a891ee
Nix version: nix-env (Nix) 1.11.14
Nixpkgs version: 670b4e29adc16e0a29aa5b4c126703dcca56aeb6
Sandboxing enabled: no

Usually these issues are closed when a fix is committed to master, but it can still take a few days for that change to make its way to nixos-17.09. My actual issue is that I can't build nginx on 17.09, so can I ask that this remain open until that is fixed?

I also added it to 17.09. I don't think there is much value in keep it open, as it will be resolved automatically on the next channel update.

You're completely right, thanks for your help!


Run MACE relaxation on Delta via Globus Compute

(Will to add more detail later)
Assumptions:

Acceptance Criteria
Given..., when..., then...

Did it, and recorded steps here: https://github.com/Garden-AI/remote-relaxation/tree/main/delta_deployment


make timeout time configurable

When running odo, if the connection to the cluster is slow, it will fail with an are you authenticated error?
Timeout time needs to be configurable on:

global odo config file. @kadel Is this global odo config file something we should consider?
per command flag, as global configuration and not command specific flag

We should also revisit which commands need to check that you're connected to the cluster, as a odo app create xxx command failed on me and it shouldn't really check it.

we are implementing odo config command as per issue https://github.com/redhat-developer/odo/issues/122 so after PR https://github.com/redhat-developer/odo/pull/589 gets merged we can extend odo config for specifying the time-out
this is how we are implementing it now
odo config --help
Modifies Odo specific configuration settings within the config file.

Usage:
  odo config [flags]
  odo config [command]

Aliases:
  config, configuration

Examples:
  # Get the current configuration
   odo config get

  # Set a configuration value
   odo config set UpdateNotification false

I've sent a PR https://github.com/redhat-developer/odo/pull/757 for this, which will allow the user to modify the default timeout value by explicitly configuring it on ~/.kube/odo file using odo utils config command
./odo utils config
Modifies Odo specific configuration settings within the config file.

Available Parameters:
UpdateNotification - Controls if an update notification is shown or not (true or false),
Timeout            - timeout(in seconds) for openshift server connection check(1 to 99)

so, for example, the user can modify the timeout by
$ odo utils config set timeout 5

@kadel We need to look into the format of this file the sooner the better


Different portion of text with different color in echo_via_pager

Currently we can show one text group with one color.
It would be pretty handy to be able to show multiple text groups with different colors.
An example can be the output of "git diff"

This is already supported. Use click.style calls in whatever combination you want, then pass the result to echo_via_pager. See also #183.


Bootstrap glyphicons fonts should be in "fonts/bootstrap"

Bootstrap _variables.scss points to "../fonts/bootstrap/"
$icon-font-path: if($bootstrap-sass-asset-helper, "bootstrap/", "../fonts/bootstrap/") !default;
But currently the font files are located at "../fonts"

The minified (I'd assume non-minified) bootstrap CSS is affected too.

I can't get this to work. I tried altering the path and also tried moving the fonts/ folder. Nothing shows. How did you resolve?


Remove hardcoded ARN partition information

This change will allow us to seamlessly support other AWS partitions
such as aws-us-gov.
what

Support other AWS partitions (such as aws-us-gov).
This change is a NOOP for existing resources.

why

The module hardcodes the partition component of the ARN, making it impossible to use this module in other partitions.

references

See Amazon ARN syntax

/rebuild-readme

/terraform-fmt

/test all


[crypto] maintain the crypto agility with ValidatorSet

Motivation
This is the missing piece from @huitseeker 's previous work.
Have you read the Contributing Guidelines on pull requests?
Y
Test Plan
Existing tests.
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

@bors-libra r=davidiw

:pushpin: Commit 23dcfcd has been approved by davidiw

:hourglass: Testing commit 23dcfcd7aa5b3a3c21895d2c433676a98e110c28 with merge d2934e82aa5f68e68f44d4391eaa16ecb9a88d8b...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: davidiw
Pushing d2934e82aa5f68e68f44d4391eaa16ecb9a88d8b to master...


Remove sleep command from deployment file

By having sleep command by default causes an issue of pod missing logs as pods aren't in active status due to sleep command.

@Nickomang - can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi, @madhav5589, can you show me where you run into this issue? Thanks!

The issue that I was facing with my application is pod logs were missing. After removing sleep command, it worked fine. I realized that this may not be the case for busybox example  though. Please feel free to reject the PR if you think so. Thanks!


Documentation on running in browser with webpack

Hi, I'm interested in getting this running in my browser (I know I can get around the cors issues with CORS-proxy, so I'm not too worried about that). I'm wondering if you've documented any steps to get it built with Webpack though.

Hi there - the only docs on that so far are here:
https://github.com/tiagosiebler/binance#browser-usage
If you include the bundled js file with a script tag on a page, you'll have a global variable called binanceapi that should expose all parts of the library. Hope that helps you get started - would appreciate if you can help improve the docs once you've spent time with it!

Debugging this is really painstaking though as I have to replace the silly loglevel messages I'm interested in with console.log to get output (I haven't tried actually setting up the logger with silly logging because I assume it would be too noisy... does this sound right?). If you have any guidance on how to set things up so logging works better for debugging it'd be helpful. I may see if I can monkey patch ping/pong onto the websocket object so that it works as expected as well.

Thanks for spending time on this! You can override the default logger by passing your own implementation into the second parameter of the WebsocketClient constructor. There's an example in the websocket demo in the readme:
https://github.com/tiagosiebler/binance#websockets
const logger = {
  ...DefaultLogger,
  silly: (...params) => { console.log(...params); },
};

const wsClient = new WebsocketClient({
  api_key: key,
  api_secret: secret,
  beautify: true,
}, logger);

Something like this should enable the silly logger again.

What I found was that ws.ping is failing because it doesn't exist on the ws object.

It must be this part that's throwing:
https://github.com/tiagosiebler/binance/blob/master/src/websocket-client.ts#L216-L217
I'm not sure yet how to approach this. If I remember right, the browser websocket implementation doesn't provide ways to send the ping/pong frames: https://stackoverflow.com/questions/10585355/sending-websocket-ping-pong-frame-from-browser
The main purpose of this logic is to send something upstream at an interval and start a timer. If the server doesn't send a reply downstream before the timer expires, we assume the connection dropped and being the resurrection process (by first closing the existing connection):
https://github.com/tiagosiebler/binance/blob/master/src/websocket-client.ts#L341-L344
This works well in node where those functions trigger pong frames, but an alternative will be needed for browsers where those functions don't exist... anything to trigger some kind of server response on the same stream.

Thanks for the detailed response @tiagosiebler ! I may try to get together a PR working to resolve the issues if I have time over the next couple of weeks.
I'm wondering how you'd feel about removing isomorphic-ws as a dependency (it hasn't been updated in 3 years) with ws on node, and either using the native browser WebSocket or a different library for the browser bundle?
I haven't investigated this too much yet, I just noticed isomorphic-ws doesn't support ping/pong, or terminate, so it might defeat the purpose of using it in the first place if there are a lot of things that have to be handled differently.

How to build browser binanceapi.js
mkdir binance && cd binance
git clone https://github.com/tiagosiebler/binance.git .
npm install
npm install webpack
npm run build
npm run pack

Go to dist/ directory where binanceapi.js is located.

How to build browser binanceapi.js
mkdir binance && cd binance
git clone https://github.com/tiagosiebler/binance.git .
npm install
npm install webpack
npm run build
npm run pack

Go to dist/ directory where binanceapi.js is located.

No need to npm install webpack, it's included in the dev dependencies so it will automatically get installed when you run npm install

@tiagosiebler Help please. Я хочу использовать вашу SDK в браузере, но при попытке установки получаю ошибка. Как мне решить проблему?


Update field image

Updated the field image from CENTERSTAGE to INTO THE DEEP (courtesy of Juice 16236 for the image).

Thank you!


MDTT-18: Quality check of the tool

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@0777ebc). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             main     #15   +/-   ##
======================================
  Coverage        ?   2.89%
  Complexity      ?     132
======================================
  Files           ?      20
  Lines           ?     380
  Branches        ?       0
======================================
  Hits            ?      11
  Misses          ?     369
  Partials        ?       0

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 0777ebc...f6a2e5e. Read the comment docs.


Ag3.plot_aim_heatmap() better error message if aims param value is wrong

Hard to remember the correct values (e.g., 'gambcolu_vs_arab') and if give wrong value (e.g., 'gambcolu_arab') get a cryptic error message.

It looks like the error messages here concern not being able to find the zarr metadata file at the expected location, i.e. FileNotFoundError: '.zmetadata' and KeyError: '.zmetadata', which I think I've traced to the _aim_calls_dataset() function in ag3.py, copied below.
This function simply interpolates the aims param value into a path template and then tries to load the zarr from there:
def _aim_calls_dataset(self, *, aims, sample_set):
    release = self._lookup_release(sample_set=sample_set)
    release_path = self._release_to_path(release)
    path = f"gs://vo_agam_release/{release_path}/aim_calls_20220528/{sample_set}/{aims}.zarr"
    store = init_zarr_store(fs=self._fs, path=path)
    ds = xr.open_zarr(store=store, concat_characters=False)
    ds = ds.set_coords(["variant_contig", "variant_position", "sample_id"])
    return ds

I suppose we could check the value of aims against a list of expected values during this function, and then raise a better error message when the value is not in the whitelist.
I also suspect that we might want to make the aim_calls_20220528 part of that path easier to modify, eventually.


Does jupyter support other language?

Is it possible to make jupyter support other language like julia and R?
Or at least provide some interface for other extension to integrate.

@clouds56, at the moment no.

This would be a good spot to have people vote on other languages. Which one's do you want besides python?

Julia?

R?

Haskell?

C#/F#?

Scala?

Bash ?

SAS?

cling?

I don't see any point in voting on languages here — supporting two languages should be the same as supporting all languages.
That is, when you open a Jupyter notebook file (.ipynb), the kernelspec.name metadata should tell you the name foo of the kernel to run.   You then look for a kernelspec file foo/kernel.json in the standard location.    This file looks something like
{
  "display_name": "Julia 1.2.0",
  "argv": [
    "/Applications/Julia-1.2.app/Contents/Resources/julia/bin/julia",
    "-i",
    "--startup-file=yes",
    "--color=yes",
<EMAIL_ADDRESS>    "/Users/me/.julia/packages/IJulia/fRegO/src/kernel.jl",
    "{connection_file}"
  ],
  "language": "julia",
  "env": {},
  "interrupt_mode": "signal"
}

and tells you exactly how to launch the kernel (via the argv). You create a connection file,  pass this for the {connection_file} argument when starting the kernel, and then talk to the kernel over ZMQ in exactly the same way that you talk to the Python kernel.

Unfortunately supporting a kernel is not the same as supporting a language.  None of those work without figuring out a language neutral or per language way to do them.
We will be supporting other kernels long before we support other languages. This item here:
https://github.com/microsoft/vscode-python/issues/3123
has the beginnings of how this will work.
@hochshi has implemented picking a kernel in remote situations here (which will hopefully go in soon)
https://github.com/microsoft/vscode-python/pull/7790

Supporting just the the script itself, as an interactive notebook, without the Jupyther dependency would be even better.

Supporting just the the script itself, as an interactive notebook, without the Jupyther dependency would be even better.

@alexeypetrushin can you elaborate more? Jupyter is just a framework for hosting a process that's running your code. I don't think we'd reinvent this ourselves. Is there something you don't like about having jupyter installed?

You don't need a dependency on the Jupyter software stack if you simply speak the Jupyter messaging protocol to the kernel.   e.g. nteract does this.

Unfortunately supporting a kernel is not the same as supporting a language.  None of those work without figuring out a language neutral or per language way to do them.

By "theming" I guess you mean syntax highlighting etcetera?  Why can't you simply read the language field of the kernelspec file and activate the syntax mode for the corresponding language?
Not sure what you mean by "startup directories" … the kernelspec file also tells you exactly how to launch a kernel, including any relevant environment variables.
I'm not speaking theoretically — JupyterLab and nteract do this in a language-neutral way already.

There's code we run (python code) that does the following:

Tell jupyter to create SVGs as well as PNGs
Change the working directory of the kernel
Query for variables

This is the stuff that is not platform neutral at the moment, with variables being the toughest to implement. This is really our problem, and not a jupyter specific issue.
We could talk directly to the kernel through stdin/stdout, but then we'd be reinventing the server code that jupyter has for remote situations and it wouldn't work for already running jupyter servers. There's no benefit for us, other than perhaps performance.

Given all of that, why do you care if we have a dependency on the jupyter server? Is this causing bugs? Is the download too large? (We might make something simpler if we were to implement this ourselves).

Tell jupyter to create SVGs as well as PNGs

The Jupyter protocol allows the kernel to send data in multiple formats, including both SVGs and PNGs, so I'm not sure what you're referring to here — there is no need to tell it you want SVGs or any specific format in general, because objects supporting rich display will typically send you data in multiple supported formats and you can pick which one to display.
Maybe you are referring to Matplotlib, which by default does not send SVGs for inline display in order to speed up the display of complicated plots?    But in that case there is a standard way for the user to request SVG inline plots, with no need for intervention by the front-end.

Query for variables

The Jupyter protocol already has a language-neutral introspection API.
If there is some other form of introspection that you need, I'm sure @minrk and the other Jupyter developers would be open to discussing adding it to the protocol.

Change the working directory of the kernel

Normally in Jupyter the working directory is the directory where the notebook file is located.
Why do you think you need to change directories?  The kernelspec file tells you how to launch the kernel, including any path information.

We could talk directly to the kernel through stdin/stdout.

The Jupyter protocol uses zeromq, not stdio.   Have you looked at the messaging spec?

why do you care if we have a dependency on the jupyter server?

Because you are hooking into it in a language-dependent way. If you simply spoke the Jupyter protocol the way it was intended to be used, I personally don't care too much what your software dependencies are, but it's not clear to me why a Jupyter-server dependency would remain.

There is no current JMP for querying variable values. The %who line magic might be used, but it certainly won't page in MBs of dataframe data. We use python code to do this now.
We also switch directories in the kernel based on where the user ran code from. This would be simpler to add a message to the protocol and the %cd line magic can do this too. Although I'm not sure if line magics are supported in all kernels.
SVG formatting is similar. We use a line magic to do this now. Not sure it will work in all kernels.
Our usage of jupyter-server is orthogonal to language independence. It's our python code that we use that's the crux of the problem.
In fact it sounds like you don't care that we use jupyter at all. You just want us to eliminate our python code and push that same functionality into jupyter itself.
This might be what we do to solve multiple languages. Or we might solve different problems with other solutions. Variable enumeration and data fetching might be accomplished by talking to an attached debugger in the kernel. At least for python attaching a debugger has very negligible overhead.

There is no current JMP for querying variable values. The %who line magic might be used, but it certainly won't page in MBs of dataframe data. We use python code to do this now.

Why do you need to query variable values in the front end?
You can always send an execute_request to the kernel to ask it to evaluate a variable, given the name, and send you back a mimebundle that tells you how to display the value.

We also switch directories in the kernel based on where the user ran code from.

Isn't this just the directory of the notebook file?   Normally Jupyter front ends do this by simply running the "launch kernel" command from the directory of the notebook, or whatever working directory you want to use.
"Magics" like %cd are specific to the IPython kernel — they aren't part of the Jupyter spec.

SVG formatting is similar. We use a line magic to do this now. Not sure it will work in all kernels.

SVG rich object display is possible for any kernel that sends image/svg+xml data as part of a mimebundle (e.g. in a display_data message`).
If the user wants to tell a particular software package, e.g. matplotlib, to use a particular output format, they should do that themselves (e.g. by executing a notebook cell with the relevant line magic in the matplotlib case).  I don't understand why you need to get involved.

We query variables here in the front end:

That's our variable explorer. It lists out the variables active in the current kernel and allows you to open a data viewer for anything that supports it. Opening the data viewer  executes a bunch of python code to page in the data.
Switching directories in the kernel is done when more than one file is run in the same kernel. We might remove this (and instead have one kernel per file), which would mean the startup directory could be used.
SVG formatting is for our plot viewer support. We use it so we can open high res plots in a separate window.

Internally we ask Jupyter to output both SVG and PNG (with a %config line magic). When the user clicks on that little expand button, we open the SVG. We're likely going to get rid of this too as it slows down Jupyter a bunch on really complicated stuff and potentially inject something into matplotlib or the ipython kernel to instead give us the necessary data to draw a high res plot.
Variable support is really the biggest blocker right now. The other stuff can probably just be dropped.
(We also used to enforce a styling on matplotlib, but we got rid of that code as it caused more trouble than it was worth).

For the variable explorer, in the short term you could simply not support it for non-Python kernels.
In the long term, you would need:

a message to request a list of variables — the Jupyter folks might be willing to add this to the messaging spec.

for each variable, you could simply send an execute_request to get a "static" view of the variable (e.g. a mimebundle)

for more dynamic views of the variable (e.g. a zoomable plot or whatever), the language-independent way to do this would be to use Jupyter's widget framework to allow the kernel to communicate with a Javascript widget dynamically.

Is there something you don't like about having jupyter installed?

A little bit off-topic, feel free to ignore it. I don't care about Jupyter, I don't want to see it or know about it and I don't want to have an extra layer to debug in my code. Basically the only thing I need is a REPL with support for Images (graphs) and VSCode syntax and auto-corrections. The easier it will be the better. Seems like straightforward way would be - just start Python process, send it code, get back result and image, show it in VSCode, no need for Jupyther.

It might be possible to leverage SoS for this, particularly SoS Notebook, which uses a superkernel in Python to access other kernels in a single notebook. It's pretty mature and actively maintained.
I've routinely used it for the past year with Python, R, F#, Torch, and Java. AFAIK you can "drop in" any Jupyter kernel. Special extensions are only needed for features like sending data between kernel (which I never use because you can always hit the disk).
Tagging @BoPeng for his thoughts.

I think the medium term plan here should really be to actually move the Jupyter Notebook support out of the Python extension, and revitalize the Jupyter extension, so that it supports notebook support in a language neutral form. I think anything else is really at odds with the Jupyter goals/philosophy, to be honest.

I agree with @davidanthoff that Jupyter support should be removed from the Python extension, and be enhanced to support more languages.

@rchiodo Thank you for all your work on this extension! I want to highlight that most people are voting directly on the languages rather than upvoting the main issue post, so while the issue itself has only 10 votes, Julia now has 73 votes and R has 35. It seems like there is a fair amount of interest in broader language support.
I’m a contributor to one of the VSCode R extensions and I would love to start adding features to take advantage of R Notebooks in VSCode. If there is something that I can do to help this process along please let me know.
Thank you!

Hi @andycraig. This is something we're actively pursuing but is waiting right now on VS code doing some work to support notebooks better. We're waiting for VS code to finalize their designs and then we'll be able to describe how other languages will/can work.

@rchiodo I appreciate the update and great to hear that there’s still a plan for broader language support for Notebooks in VSCode.

This is something we're actively pursuing

@rchiodo that's great news. Where is the best place to follow this progress? FWIW, I just posted on the dotnet-interactive group about .Net integration to the VS Code Jupyter integration:
https://github.com/dotnet/interactive/issues/179
Would this be appropriate as a separate feature request, or is it already being effectively tracked here (or elsewhere)?

.NET in particular is being tracked here:
https://github.com/microsoft/vscode-python/issues/7145
Otherwise, yes, this issue is the one to track.

@rchiodo do you plan to move the Jupyter Notebook out of the Python extension entirely and into a language agnostic package?

Short answer, not at this time no.
Longer anwer:
We require the code in the python extension just to get jupyter to run with all of the different environments that are supported. However there's a bunch of stuff in flux about starting jupyter, starting the kernel, what UI we use etc. So the future may change where all of this lives.

So even when the new notebook stuff in VSCode itself lands, the Python extension would register itself as the "handler" for Jupyter notebooks? To be honest, that seems really, really unfortunate and not in the spirit of the Jupyter project... Other projects (like nteract) handle this properly, one can easily install nteract, Julia and its Jupyter support and everything works, with no piece of Python installed anywhere. I think supporting that scenario should be a high priority for the VS Code Notebook story.
In my mind this all amounts to almost being a "bad citizen" in this ecosystem: essentially the Python extension here is "grabbing" a file format that is not Python specific but explicitly language neutral... (and just to be clear, I see zero bad intention around this from anyone invovled, please don't interpret the language I'm using here in any case as a criticism of any person involved!! It just seems the easiest language to describe the technical situation here).

So even when the new notebook stuff in VSCode itself lands, the Python extension would register itself as the "handler" for Jupyter notebooks?

This is unclear at this time. We may only register as the provider of the IPython kernel and nothing else. We may create another jupyter extension that uses the python extension as a dependency in order to start jupyter. (Depends upon how cells are going to be run in the new VS code world).
But I'm not sure why anybody would care which extension they need to install? It's an implementation detail really. Is it merely the branding?

uses the python extension as a dependency in order to start jupyter

I don't understand that. Why would you want to involve the Python extension or Python at all in starting Jupyter kernels? I think that is really the crux here, I think the right way to implement this is to completely leave out anything Python in that step. You just look in these locations for kernel.json files, and start the binaries specified in there directly, with no need for anything Python at all.

But I'm not sure why anybody would care which extension they need to install? It's an implementation detail really. Is it merely the branding?

Folks that use Jupyter notebooks with other languages don't want to install something like the Python extension, which adds UI around Python, notifications around Python etc. If I'm a Julia user that uses Jupyter notebooks, why should I have to add an extension that adds lots of Python related commands, settings etc. into VS Code to edit Jupyter notebook files that have nothing to do with Python?

I  don't understand that. Why would you want to involve the Python extension or Python at all in starting Jupyter kernels?

It's not to start the kernel, it's to start Jupyter itself. We attempt to launch jupyter using the user's python environment. There's a lot of code to get different terminals, virtual environments, etc to work. The python extension already has this code to run normal python files, we reuse it to start the jupyter server.
We implemented talking to the kernel this way so we'd talk to a local server or a remote server the same way. (Both local jupyter server and remote jupyter server uses the exact same code to execute cells, etc. We use the jupyter_lab APIS)

Folks that use Jupyter notebooks with other languages don't want to install something like the Python extension, which adds UI around Python, notifications around Python etc.

If they don't use Python, then none of these things should get in the way. I guess we'd only consider not using the python extension if we got a ton of negative feedback from a large population of non python users. So far that hasn't happened.

As explained above, in principle you don’t need a jupyter process at all.  You just talk directly to the kernel with ZMQ. This is what e.g. nteract does. Ideally, your goal should be to eliminate the jupyter dependency.

Here is another way to look at this:
From the Julia extension point of view, we will want to have support for Jupyter Notebooks in VS Code that works without a Python installation. If the only Jupyter notebook support that MS ships is going to be inside the Python extension and will require that Python is installed on a user machine (that is how I understand your current plans, right?), I'm 99% sure that we will roll our own support for Jupyter notebooks once the core notebook UI lands in VS Code.
Is that the vision MS has for this scenario? That every langauge extension ships its own support for Jupyter notebooks? I.e. the Python extension, the Julia extension, the R extension etc. each register themselves as an editor for ipynb files and then ship with their own implementation of Jupyter notebooks?
That seems really less than ideal, for at least two reasons:

it will lead to a bad user experience, because if a user now has both the Julia and Python extension installed, I assume they would have to make a choice which of these extensions should handle the ipynb file whenever one opens one, right?
it seems a really unfortunate duplication of effort, and one that the Jupyter team tried super hard to avoid by designing a language neutral story... I.e. the whole philosophy of Jupyter to me at least really seems to avoid exactly this kind of design/situation.

Is that the vision MS has for this scenario? That every langauge extension ships its own support for Jupyter notebooks? I.e. the Python extension, the Julia extension, the R extension etc. each register themselves as an editor for ipynb files and then ship with their own implementation of Jupyter notebooks?

No that's not the plan at the moment. Each of those would ship support for a kernel more than likely. Which would go along with language server support, debugging, etc. The idea is to have each extension be responsible for executing cells in its own language (at least that's what we've been bandying about internally).
We might use Jupyter in the python extension. Julia might just talk directly to the julia kernel instead.
Or we might make a generic jupyter extension that supports multiple kernels, where each extension just installs the kernel, but there's an inbetween extension that sits between VS code and actually executing.
Or maybe we'll split our remote server support into a separate extension and then the python extension just talks directly to an IPython kernel. The Julia extension talks directly to the Julia kernel, the R extension etc ...
However, right now, multiple language support is not high on the priority list. Our initial push was to support python data scientists, as that was the majority of the DS market.
I will use this conversation to inform what we ask for from VS code though.

Each of those would ship support for a kernel more than likely.

The idea is to have each extension be responsible for executing cells in its own language

Why would a VS Code extension like the Julia extension be responsible for executing Jupyter notebook cells? In the Jupyter design that is the responsibiliy of the kernel, so that part seems entirely solved by Jupyter, with no need to involve language specific VS Code extensions at all?

Which would go along with language server support, debugging

My understanding of the Jupyter plans around debugging are that they are extending the base Jupyter protocol to support debugging (and have working code for that). In that scenario the debugging support would also be provided by the kernel and not a language specific VS Code extension.

Julia might just talk directly to the julia kernel instead.

Why would Julia talk to the julia kernel? The notebook implementation should talk with the Julia kernel via ZMQ messages.

Or we might make a generic jupyter extension that supports multiple kernels, where each extension just installs the kernel, but there's an inbetween extension that sits between VS code and actually executing.

Why would the VS Code extensions install kernels? I think pretty much every Jupyter language already has an existing kernel setup story that is independent of VS Code, it seems not a good idea to get into the way of that by having VS Code extensions start to install kernels.

No that's not the plan at the moment.

However, right now, multiple language support is not high on the priority list. Our initial push was to support python data scientists, as that was the majority of the DS market.

I don't see how these two statements square. If you continue to ship a Python only notebook implementation in the Python extension, then we will exactly end up in the situation that I outlined above, and which you described as not being the plan :)

I will use this conversation to inform what we ask for from VS code though.

I've been following the notebook branch on the VS Code repo closely, and everything I'm seeing there is exactly spot on and how I think things should be done (namely, nothing Jupyter or language specific at all). I'm specifically worried about the direction the Jupyter integration is taking here.
Here is how I think the Jupyter integration should look like: there should be one VS Code extension called "Jupyter". It should register itself as the handler for ipynb files. It should be entirely language neutral. It should, like nteract, communicate with kernels via ZMQ. It should not rely on any Python Jupyter implementation in any way. It should ideally use the debug extensions of the Jupyter protocol to support debugging scenarios. If there are other features that the current existing Python extension has that can't be handled in a language neutral way, it would be fantastic if the MS team could reach out to the Jupyter team and try to find extensions of the Jupyter protocoll that enable such scenarios.
Is the group at MS that is working on the Jupyter stuff in contact with the core Jupyter team? If not, I think that would be very helpful, just to make sure the high level strategies are somewhat aligned. I'm sure you have those contacts, if not, let me know, happy to put you in touch (a large fraction of the Jupyter team is here on campus). I do think that when a big player like MS starts to enter an area like Jupyter, with a vibrant existing community, that it is important that the big player tries to reach out to that community, engages with it and tries to be a "good player" in that space by roughly aligning with the core philosophy of something like Jupyter. Right now, at least from the outside, the strategy that MS seems to have (at least to me) seems not alighed with the core Jupyter philosophy and design decisions.
Now, having said all of that, MS is obviously free to to whatever they want :) I think if the MS plans stay as Python-centric around Jupyter as they appear right now, then maybe the authors of some of the key language extensions that are interested in a notebook extension that follows the Jupyter spirit should band together and just create a language neutral extension ourselves? Maybe MS would be willing to hand the deprecated "Jupyter" extension over to the core Jupyter group and it could be hosted there? Or something like that.

javascript/typescript

Just to summarize here:

You think it's a bad idea to have extensions install kernels because there's already a process for installing kernels.
You think there should be a single 'jupyter' extension that supports all languages and it would find and talk to the different kernels (but not using jupyter itself)
You think this extension would also support debugging once the debugging APIs are finalized.
And if MS doesn't provide it, the community will.

I think this all depends upon how much work each of these steps are (and what our goals around these steps are).
For example, we run jupyter now for a number of reasons (instead of the kernel directly). Switching to a kernel only mode might be a lot of work, and not something we see as necessary.
We might also install the IPython kernel directly because we don't want customers to have to install it. We might install a number of other kernels too. (Especially if we have the one 'jupyter' extension).
I think the one jupyter extension goes against the spirit of VS code though. VS code provides a base experience and extensions support different areas. Is jupyter an area too big for an extension? I think that's a matter of opinion. Maybe not. They are creating uber extensions (like the Remote one) that encompasses larger bits. It would be nice to make it possible for other extensions to enhance the notebook experience though.
Oh and this bit:

If you continue to ship a Python only notebook implementation in the Python extension, then we will exactly end up in the situation that I outlined above, and which you described as not being the plan

Is not likely once the VS code API is complete. The notebook implementation will live inside of VS code itself. We'll either be providing just the code necessary to run python notebooks (in the python extension) or we'll make it more generic to support all notebooks (and possibly move it into a different extension). It depends upon a number of factors like branding and cost to implement.

To answer this question:

Why would a VS Code extension like the Julia extension be responsible for executing Jupyter notebook cells? In the Jupyter design that is the responsibiliy of the kernel, so that part seems entirely solved by Jupyter, with no need to involve language specific VS Code extensions at all?

Yes the kernel is still responsible for executing the code. There still needs to be a piece of code that:

Finds the kernel
Starts the kernel in whatever environment is appropriate (for python this requires running the kernel with a specific set of environment variables)
Translates the new VS code API they're creating into the ZMQ protocol.

At first glance it seems like VS code should just use the ZMQ protocol directly (maybe we can get them to change to this), and VS code should just use the registered kernels on the system and start them directly.
I don't think VS code is going to want to search for kernels though. It will leave that up to an extension.

@rchiodo thanks for the pointer to #7145.
And, as a casual observer/user, your above post makes sense to me. FWIW, I will second a comment above that being Jupyter support being tied to this Python extension was initially confusing for me when trying to "discover" the extension I needed, as I knew already that Jupyter was multi-platform. Took 5 min, so no biggie, but it could be a barrier to adoption/discoverability.

Just to summarize here:

Yes, your summary of my view is spot on!

I think the one jupyter extension goes against the spirit of VS code though. VS code provides a base experience and extensions support different areas. Is jupyter an area too big for an extension? I think that's a matter of opinion. Maybe not. They are creating uber extensions (like the Remote one) that encompasses larger bits. It would be nice to make it possible for other extensions to enhance the notebook experience though.

I think you raise an excellent point: there is a bit of a tension between the VS Code model (one extension per language) and the Jupyter model (language neutral protocols that make it feasible to have one UI that works well across different languages without language specific extensions in the client). I'm not sure what the right balance there is, to be honest... I could imagine something like this: a Jupyter VS Code extension speaks with many kernels. It uses some Jupyter protocoll spec for debug, but then maybe has also some hook to allow the Python/Julia/R extension to provide say the language server for the code in a Jupyter notebook. But not clear to me whether that kind of extension-to-extension integration is actually feasible in the VS Code extension model right now?
I think this is an area where it would be particularly valuable if the MS team reached out to the Jupyter team and came up with a collaborative solution.

If you continue to ship a Python only notebook implementation in the Python extension, then we will exactly end up in the situation that I outlined above, and which you described as not being the plan

Is not likely once the VS code API is complete. The notebook implementation will live inside of VS code itself. We'll either be providing just the code necessary to run python notebooks (in the python extension) or we'll make it more generic to support all notebooks (and possibly move it into a different extension). It depends upon a number of factors like branding and cost to implement.

I don't understand this. What do you mean by "python notebooks"? The key question is which piece of code registers itself as the editor for the ipynb file type. My understanding of the core VS Code plans is that the core VS Code product will not register itself as the handler for ipynb files. I think that is exactly the right strategy! So it will have to be an extension that registers itself for that file type. If the Python extension registers itself as the handler for that file type, then I'm pretty sure extensions like the Julia extension will also register themsevles for the same file type and bring along their own notebook implementation, because we want a way to interact with ipynb files without a need to install Python. If MS ends up providing the Jupyter extension as the handler for ipynb files on the other hand, well, then all is good, that is exactly what I am recommending :)

There still needs to be a piece of code that:

Finds the kernel

How to do that is clearly speced here, that really doesn't strike me as very complicated? There are essentially just a bunch of file locations that you need to look at...

Starts the kernel in whatever environment is appropriate (for python this requires running the kernel with a specific set of environment variables)

That is completely speced in a language neutral form here as well! There is no need to do anything Python specific. You read the kernel.json, you run the stuff specified in the argv element and set the env variables to the values in the env element. The whole thing seems really not involved at all.

Translates the new VS code API they're creating into the ZMQ protocol.

Yes, that seems like one of the main "tasks" of a Jupyter extension. But that is code that must already existed here in the Python extension, right? Presumably the Python extension currently is communicating via ZMQ with the Python kernel?

At first glance it seems like VS code should just use the ZMQ protocol directly (maybe we can get them to change to this), and VS code should just use the registered kernels on the system and start them directly.

I really hope that is not the direction! I think the notebook support in VS Code itself should be entirely language and notebook tech stack neutral. All this info about kernels, ZMQ etc. is Jupyter specific, but there are many other notebook implementations and stories out there, and I think the support for notebooks in VS Code core should be entirely neutral with respect to which notebook stack it supports. So in my opinion it should have zero dependency on anything that is Jupyter specific (kernels, ZMQ or anything like that). The implementation they are working on right now follows that model exactly, i.e. what they are building right now has nothing Jupyter specific in it, which is great.
I think a Jupyter extension should find these registered kernels, and implement the Jupyter protocoll (via ZMQ), and understand the ipynb file format (i.e. provide the load and save functionality).

Finding kernels and launching kernels is easy if

A working jupyter is already installed
The user doesn't want to run a different python than the one registered in the kernel.
The kernels were installed in the default spot. (This isn't always the case)

Right now number 1 is a prerequisite for us, but number 2 is a non-option. The python extension supports running all sorts of python environments on the user's box and we don't want to make them install a kernel for each. This is where the python specific knowledge comes in.
So ideally there'd be a base Jupyter extension that just supports talking and using the kernels registered with the user's jupyter install, and then another way for other extensions to register their own  notebook executors (which don't even need to use the jupyter kernels).
The python extension would do its own custom execution (well probably just install ipython like we do ptvsd, and run the user's python environment to setup the write python paths, etc, and then talk over ZMQ to the ipython kernel). And we're not using ZMQ at the moment. We use the jupyterlab rest APIs. This allows us to talk to a local and remote jupyter server the same way.
Language servers should end up being handled the way they are now. VS code will just pass the 'document' for the notebook to the appropriate language server. We do that now in our custom notebook implementation (although notebooks with multiple languages might be tougher).
Perhaps we'll end up with something like so:

A jupyter kernel extension. It finds jupyter kernels and allows them to be used to execute any code. It would talk to them all through the ZMQ protocol.
A python extension. It allows the user to use any python environment to execute code on a notebook. It doesn't use the kernel.json to run the kernel, but instead ships IPython itself. This allows non jupyter users to run python code in notebooks and the Interactive Window.
A remote extension. This would support talking to a remote jupyter server and would use the Jupyter lab REST API.
Language servers implemented by other extensions. These should just work as long as VS code gets the TextDocument for the server correct. VS code is currently discussing whether or not Language servers will need to know about notebook cells or not.

All of that should solve our requirements (python still working the way it does now) and not require everybody under the sun to have their own notebook execution.

Finding kernels and launching kernels is easy if: A working jupyter is already installed

A working jupyter does not need to be installed, and in fact is not involved at all.
You just look into the documented filesystem locations for a kernel.json file, parse that file with JSON, and it tells you exactly the path of the executable to launch, the arguments, and the required environment variables.

The user doesn't want to run a different python than the one registered in the kernel.

Then they should install another kernelspec file.  This is how Jupyter works — each "kernel" specifies one path and one environment, and you install multiple kernelspecs if you want multiple options.  Why is this so bad?

The kernels were installed in the default spot.

The kernelspec file gives you the absolute path of the executable, regardless of where it was installed.   The Jupyter spec says that the kernelspec files themselves can only be installed in a finite number of possible locations, configurable by the user via the JUPYTER_PATH environment variable

You just look into the documented filesystem locations for a kernel.json file, parse that file with JSON, and it tells you exactly the path of the executable to launch, the arguments, and the required environment variables.

We've found this documentation to be lacking in some cases. In those cases, Jupyter itself could find the kernels because they were installed next to jupyter (but they weren't in the documented locations)

Then they should install another kernelspec file. This is how Jupyter works — each "kernel" specifies one path and one environment, and you install multiple kernelspecs if you want multiple options. Why is this so bad?

Because users don't normally have to install kernelspecs. They just run Jupyter and it works (likely because they run Jupyter from the appropriate environment). Additionally we want to support users that don't know about or care about kernels. They just have some '.ipynb' file that somebody gave them and they want to use it. Somebody using VS code doesn't necessarily even know what Jupyter is.

The kernelspec file gives you the absolute path of the executable, regardless of where it was installed.
This is also not always true. Sometimes it just says 'python'.

Microsoft does talk with the jupyter development team on a number of things. I believe that's premature in this case though. VS Code is coming up with an extensibility model for executing cells inside of VS code. When this is more finalized, then they'd put out a general call for comments. I believe at that time we'd have a discussion with Jupyter. Not sure what we'd even discuss right now (other than possibly the discrepancies in the docs vs reality).

This would be a good spot to have people vote on other languages. Which ones do you want besides python?

Julia, please!
Also, R & Haskell would be nice as well.

C#, F#, R

Additionally we want to support users that don't know about or care about kernels. They just have some '.ipynb' file that somebody gave them and they want to use it.

To use an Jupyter notebook file, I don't see how you can get around requiring that the corresponding language's kernel software be installed.   But you want to handle the case where the software is installed but misconfigured (missing a kernel file)?

To use a Jupyter notebook file, I don't see how you can get around requiring that the corresponding language's kernel software (e.g. ipython) be installed. But you want to handle the case where the software is installed but misconfigured (missing a kernel file in the standard location)?

We will still be using the IPython kernel to run their code. We just plan on installing it for them (either directly into their environment or next to our extension and just pointing the correct sys paths to it). This is a work in progress and is mostly motivated by the 1000s (out of 10,000s of users) of failures we get with jupyter running or getting kernelspecs to change.

But a Python-centric non-ZMQ non-kernelspec implementation of Jupyter notebooks is really abandoning most of the Jupyter ecosystem and will be a continuing headache going forward.

We don't have this now, nor do we plan on going this way. Our current implementation is using jupyter itself to talk the kernels. This is rather messy because jupyter expects to be run from a single environment (well in most cases). Relying on the user's jupyter installation is turning out to be rather fragile. Talking directly to kernels (over ZMQ) seems like it will be much simpler. The question just becomes who does this talking for other languages. Will we (meaning the python extension) talk to all kernels? Will we create another extension that encompasses all of them?
I'm personally worried about having a monolithic Jupyter extension for VS code that is supposed to be all things for all users. VS code's ecosystem doesn't normally work this way.
Here's an example, you as a Julia developer want to add something that tracks dataframe usage in notebooks so you can present some nice new UI in VS code. How would you do that without being the one true Jupyter extension? Would you have to figure out how to modify the Julia kernel then? Does the Jupyter extension have a way to allow listeners for executing code?
I think the answers to this last question will determine where and how Jupyter users run their kernels.

A very good answer was already proposed by @davidanthoff:

I could imagine something like this: a Jupyter VS Code extension speaks with many kernels. It uses some Jupyter protocoll spec for debug, but then maybe has also some hook to allow the Python/Julia/R extension to provide say the language server for the code in a Jupyter notebook.

Just to paraphrase in my own words (since i deem some misunderstandings here):
The kernels themselves should not be touched by any VS Code extension, they have their task, and that is running code. The Jupyter VS Code extension could communicate I/O of the UI via the VS Code API. It has to be the task of the VS Code language extensions to account for say syntax highlighting or visualization of tables, so they will have to have some hooks to the Jupyter VS Code extension on the VS Code side where they possibly launch some language server in the running kernel for further language specific communications.

Hello, I am using jupyter lab mostly with R for the moment. vscode-python would display the cached images, code perfectly - which is already very useful.
But I really wish it can take my installed R kernel and work directly in vscode. Currently, vscode python can find all the python installations on my system, but for the R kernel, it displays:
"Couldn't find kernel R that the notebook was created with".
Is there an option/confirmation that I can supply vscode python the kernel binary path?'
Thanks a lot
_

@ipstone  It's just not supported at the moment. We're filtering out all kernels that aren't python.
This item here is to investigate supporting the C# kernel (which is currently in progress)
https://github.com/microsoft/vscode-python/issues/7145
Once that's finished, I imagine all kernels should be at least minimally supported. Colorization and intellisense probably won't be correct, but at least you'll be able to run code from other kernels.

ruby via https://github.com/SciRuby/iruby

Hello,
I'm using Julia and Python kernel frequently So that I desire the Julia support.
Could you tell me your plan or progress on this request?

The long term plan is to support all languages. Or at least all kernels. It will likely be many months before that happens as notebook support is being revamped.
VS code proper will control all of the editor features, and our team will most likely support language server (for python), running kernels (python and any other on your box), and providing handlers for different mime types. It looks like anybody will be able to provide an extension that can do these things and some parts may come from multiple extensions.

The long term plan is to support all languages. Or at least all kernels. It will likely be many months before that happens as notebook support is being revamped.
VS code proper will control all of the editor features, and our team will most likely support language server (for python), running kernels (python and any other on your box), and providing handlers for different mime types. It looks like anybody will be able to provide an extension that can do these things and some parts may come from multiple extensions.

Thank you for your information. I expect it so much!
I hope that I can use it before 2021.

Thank you for the good work. The ones I use most often besides of Python are Coconut and Clojure.
I use a number of extensions with Clojure, like Parinfer. It would be good to have an editor like VSC that supports these extensions to edit the code in the cells of the notebook and that supports running the cells, displaying the plots, etc., like VSC for Python.

The long term plan is to support all languages. Or at least all kernels. It will likely be many months before that happens as notebook support is being revamped.
VS code proper will control all of the editor features, and our team will most likely support language server (for python), running kernels (python and any other on your box), and providing handlers for different mime types. It looks like anybody will be able to provide an extension that can do these things and some parts may come from multiple extensions.

Thank you for your information. I expect it so much!
I hope that I can use it before 2021.

Reemphasize, hope before 2021 mean available in 2020 :). Thanks a lot.

I am also very excited for this feature. It should be noted that this feature is available as an extension in atom https://nteract.io/atom although it's not really as high-powered as the jupyter extension for python is for vscode.
Theirs is built with the design decision that the core functionality should work with any kernel and specific languages are provided by new extensions.

It's great to see Jupyter notebooks in Julia working on VS Code. How can we get Julia syntax highlighting in the jupyter files that are running with the Julia kernel?

@hdavid16 Julia syntax highlighting requires us to find the language-configuration.json file for the julia language in the global extensions folder for VS code. It looks like VS code does not ship a language for Julia so we won't find the language tmlanguage file.
For example, in my install of VS code, I have this directory here:
C:\Users\Rich\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\csharp

That has a language-configuration.json file for C# that looks like so:
{
	"comments": {
		"lineComment": "//",
		"blockComment": ["/*", "*/"]
	},
	"brackets": [
		["{", "}"],
		["[", "]"],
		["(", ")"]
	],
	"autoClosingPairs": [
		["{", "}"],
		["[", "]"],
		["(", ")"],
		{ "open": "'", "close": "'", "notIn": ["string", "comment"] },
		{ "open": "\"", "close": "\"", "notIn": ["string", "comment"] }
	],
	"surroundingPairs": [
		["{", "}"],
		["[", "]"],
		["(", ")"],
		["<", ">"],
		["'", "'"],
		["\"", "\""]
	],
	"folding": {
		"markers": {
			"start": "^\\s*#region\\b",
			"end": "^\\s*#endregion\\b"
		}
	}
}

If there was a similar file for Julia, the syntax highlighting should start working. Since VS code doesn't ship one, you'd have to add one manually to that location or change our code to look elsewhere for it.

Thank you @rchiodo for pointing me in the right direction. I was able to get it to work by adding a julia folder inside the extensions folder you mentioned and copying the necessary files from https://github.com/julia-vscode/julia-vscode. Syntax highlighting with Jupyter files running on Julia now works.

@rchiodo Thanks for the workaround. It works perfectly for Julia on my laptop. Nevertheless it doesn't seem to work if the notebook is running on a linux server. Is it possible to also have a similar trick to deal with the remote case?

@rchiodo I don't think it is kosher to have the Julia extension install that language support. See julia-vscode/julia-vscode#1620

Can you help us navigate the process to get this into vscode in a way that would be compatible with the jupyter/notebook extension features?

@jlperla, The long term support for Julia and other languages will just work once we switch over to VS code's native notebook support. (Cells will be treated like a normal text document instead of the hacky stuff we're doing now in the python extension).
So I don't think it's worthwhile to hack something together so that we can find the tmlanguage file. It's really just a temporary solution. Although your issue you filed will likely make it work.

@FuZhiyu I would suspect the hack we have isn't working with remote because you need to put the language configuration file in a specific location on the remote machine. Look for a folder with the resources\app\extensions and put the language configuration file under a similar location as to where you put it on windows.

@rchiodo Thanks so much.  Looks like things are moving forward on doing it right!  https://github.com/microsoft/vscode/issues/105229#issuecomment-683688014
Are there any other things that we should consider getting integrated for first-class julia support in the extension?
As an aside: From a discoverability perspective in the medium-term, were you guys thinking about renaming your extension to make things directly connected to python - or splitting into a jupyter/datascience and a python extension (where the first might require the second?)

Are there any other things that we should consider getting integrated for first-class julia support in the extension?

The last remaining bit I can think of Julia support is support for the variable explorer. We attempted to make variable gathering language neutral but it doesn't seem to work.
There's a setting in the extension:
                "python.dataScience.variableQueries": {
                    "type": "array",
                    "description": "Language to query mapping for returning the list of active variables in a Jupyter kernel. Used by the Variable Explorer in both the Interactive Window and Notebooks. Example: \n'[\n{\n   \"language\": \"python\",\n   \"query\": \"%who_ls\",\n  \"parseExpr\": \"'(\\\\w+)'\"\n}\n]'",
                    "scope": "machine",
                    "examples": [
                        [
                            {
                                "language": "python",
                                "query": "_rwho_ls = %who_ls\\nprint(_rwho_ls)",
                                "parseExpr": "'(\\w+)'"
                            },
                            {
                                "language": "julia",
                                "query": "whos",
                                "parseExpr": "'(\\w+)'"
                            }
                        ]
                    ]
                },

That is supposed to allow a user to specify how to retrieve the list of variables. The parseExpr is a regex that we use to split up the results. With each result we then pass that onto a inspect request from the kernel to get the value.
The last time I tried this with Julia the inspect request wasn't working (maybe the returned format doesn't look the same as the format returned by ipython so we fall apart trying to extract the string value). So not sure if this is something you could look at or not. It might require changes in our extension or changes in the Julia kernel.

As an aside: From a discoverability perspective in the medium-term, were you guys thinking about renaming your extension to make things directly connected to python - or splitting into a jupyter/datascience and a python extension (where the first might require the second?)

I believe we're looking into making a 'jupyter' extension. This is at least being discussed. Ideally it would be language neutral and provide the glue to make jupyter kernels and languages work in VS code all up. It would likely have a dependency on the python extension for the cases when our ZMQ libraries don't work.

Looks like the Jupyter extension now exists: https://github.com/microsoft/vscode-jupyter

Yes, over the next few days, we'll be moving these issues over to that repo.
Please have a look at the native notebook support in the new extension (we do support more languages in that notebook) & also https://github.com/microsoft/vscode-jupyter/issues/273 for support of other languages in interactive window


[WIP] space-age: Add generator

Why?

space-age exercise needs a generator
What?

added generator for space-age
How Has This Been Tested?

rake test:space-age
rubocop -D
Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (non-breaking change which adds functionality)
[ ] Breaking change (fix or enhancement that would cause existing functionality to change)
[ ] Gardening (code and/or documentation cleanup)

References and Closures

references #396

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] My change relies on a pending issue/pull request
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Hi There! First off, thank you for your help converting this exercise to use generated tests!
There has been some really awesome new work on generators by @hilary that has changed how we implement new generators. Check out the updated documentation, for some tips on upgrading this to the new pattern!
Thank you again for your work and time! 😄

You might also find it helpful to see what the final version of the etl PR looked like: exercism/xruby#575.

Awesome, thank you both. I've read over the final etl PR and I'll take a look at the new docs as soon as I can this week.

I think I've moved everything where it belongs, please let me know if I missed anything.

Sorry for all the complications here @ajwann you're on the bleeding edge of test generation right now! :hocho:

I think we are finally good to go!

This is looking good @ajwann , sorry we keep moving the goalposts on you!

@Insti I've made all the requested updates, but I am having trouble testing the changes. I rebased off of master, but when I attempt to run bin/generate space-age I get an error saying that a generator currently doesn't exist for spage-age. My generator is still in exercises/space-age/.meta/generator/ so I'm not sure what's causing the issue.

@ajwann I'll have a look into this for you when I get a chance.

@ajwann

when I attempt to run bin/generate space-age I get an error saying that a generator currently doesn't exist for spage-age. My generator is still in exercises/space-age/.meta/generator/ so I'm not sure what's causing the issue.

The expected filename has changed, it should now be called space_age_case.rb (no 's' on 'case').

Awesome! Thanks for all your work on this @ajwann. I've merged it now, so any more changes we make to the process will be our responsibility to fix! 😄


[typo fix] operatingSystem

Fixed small typo.
operatingSytem to operatingSystem

What kind of changes does this PR include?

Minor content fixes (broken links, typos, etc.)

Description

Closes #
What does this PR change? Give us a brief description.
Did you change something visual? A before/after screenshot can be helpful.

operatingSytem to operatingSystem

Thank you for this helpful correction! Welcome to Team Docs, @cgathergood!  🥳


Added dockerignore ext and build using Docker

Fixes #[ISSUE]
Fixes #303
Changes proposed:

[x] Add
[ ] Prepare
[ ] Delete
[ ] Fix

Things I've done:

[x] I've pulled the latest master branch
[x] I've run npm install to install all the dependenies
[x] I've checked my code, it is clean.
[x] I've run ESLint.
[x] My pull request fixes an issue, I referenced the issue.
[x] My pull request is not too big, otherwise I've already squashed it.
[x] I've run npm run build to build the extension. (If I had done something with the extension.)

[short comment]
This adds support for the .dockerignore extension but also introduces a Dockerfile to build the code using docker, preventing any npm errors and install on the user's local system.
ps: I'm not sure how the icons.json file got created or modified - Is this from the npm run build?

Regarding your question: Yes, it is from npm run build.

@jens1o I saw it in the code, but not understanding how it's used?

It is used for the legal way of providing our icons. VS Code uses this icons.json to look for all extensions provided by us.

@jens1o is there a reason it's not part of the distribution folder like the other scripts?

Yes, because this file is for vscode(and not for building the extension), and shouldn't be touched by anyone.

@jens1o Maybe I'm missing the part of what gets loaded by vscode and how it does it... (n00b I know)

It is referenced in the package.json. Look here


[PKG-3354] antlr4-python3-runtime v4.9.3

PKG-3354 antlr4-python3-runtime 4.9.3

upstream: https://github.com/antlr/antlr4/tree/4.9.3
dependency files:

https://github.com/antlr/antlr4/blob/4.9.3/runtime/Python3/setup.py

conda-forge: https://github.com/conda-forge/antlr-python-runtime-feedstock
pypi: https://pypi.org/project/antlr4-python3-runtime/

Destination channel: defaults
Changes

exact version, new versioned feedstock
fix recipe, remove entry point

Dependency for

omegaconf v2.3.0 ❄

we downgrade the package here, is not the case described here:
https://github.com/anaconda-distribution/perseverance-skills/blob/ccd5ec3a8f2a26321a857d72c42f49eae4dfc90c/sections/02_Package_building/01_How_tos/Creating_versioned_feedstocks_from_existing_packages.md#creating-versioned-feedstocks-from-existing-packages
where we should create a separate git submodule ?

we downgrade the package here, is not the case described here: https://github.com/anaconda-distribution/perseverance-skills/blob/ccd5ec3a8f2a26321a857d72c42f49eae4dfc90c/sections/02_Package_building/01_How_tos/Creating_versioned_feedstocks_from_existing_packages.md#creating-versioned-feedstocks-from-existing-packages
where we should create a separate git submodule ?

It should be exactly that case. I created the submodule in the folder antlr4-python3-runtime-4.9.3-feedstock (note the version), as described in the link.

antlr4-python3-runtime 4.9.3

@M-Waszkiewicz-Anaconda note also that I am merging into master-4.9.3 and not master. The submodule will use master-4.9.3 as base branch


How do I combine and use multiple rules? Like frequency and blacklist.

HI,
How do I combine and use multiple rules? Like frequency and blacklist.
Thanks.

One file cannot contain multiple rules

This is by design, so there's nothing I can do.


[Don't Merge, Service rollout ~March/1/18 ] Swagger for new API changes 2017-12-01

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] Swagger for new business model changes API
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@AutorestCI rebuild azure-sdk-for-go

Automation for azure-sdk-for-go

@revas89 Please abandon this PR. We've restructured our swagger files. This is not needed any more.


AVRO-3144 Support for enabling and disabling default value validation through SchemaBuilder

Make sure you have checked all steps below.
Jira

[x] My PR addresses the following Avro Jira issues and references them in the PR title. For example, "AVRO-1234: My Avro PR"

https://issues.apache.org/jira/browse/AVRO-3144
In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[x] My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[x] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain Javadoc that explain what it does

It looks like this just needs a mvn spotless:apply for automatic code formatting, and we can merge it to appear in the next major release.

It looks like this just needs a mvn spotless:apply for automatic code formatting, and we can merge it to appear in the next major release.

Just got the email about this from the build bot. Fixed and updated.


Speeding up sparse feature matching

Hi @weigao95
I've profiled surfelwarp and it seems like surfelwarp::device::buildColliderKeyValueKernel takes up 40-50% of CUDA time (and most of it seems to be spent on waiting to synchronize).
Do you have any suggestions on how this might be improved?
On a related note, I've tried increasing num_trees in PatchColliderRGBCorrespondence, but any value above 5 results in a crash in PatchColliderRGBCorrespondence::FindCorrespondence.
Do you think it's worth trying to improve the sparse matching based on GPC or should I look into alternative methods?
Thanks

Tree search is not very friendly with GPU, and I remember the fusion4d paper reports a similar problem. Their solution is to use thread-level parallelism to run image processing and reconstruction concurrently, which is not implemented in this repo yet.
Perhaps a learned optical flow would be better than GPC? Seems to be a good candidate.


function() does not accept a number as argument

Describe the bug
Vim can represent a numbered function via the notation function('123').
But I can't use the same notation when I need "function('123')" to be evaluated; it raises E129 and E475.
To Reproduce
Write this in /tmp/vim.vim and source the file:
let adict = {'data': [0, 1, 2]}
fu adict.size()
    return len(self.data)
endfu
echo adict

The last command outputs:
{'data': [0, 1, 2], 'size': function('123')}
                            ^^^^^^^^^^^^^^^

Now, execute this Ex command:
echo eval(string(adict))

The errors E129 and E475 are raised:
E129: Function name required
E475: Invalid argument: 123

And the dictionary is not echo'ed with its original value:
{'data': [0, 1, 2], 'size': 0}

In the output, the value of the size key is 0, while it was function('123') in adict.
Expected behavior
No error is raised, and the command outputs the original dictionary adict.
Environment

Vim version:  8.2 Included patches: 1-7
OS: Ubuntu 16.04.6 LTS
Terminal: XTerm(322)

Additional context
It seems inconsistent:

You can read function('123') in some command output, but you can't write it in an evaluated expression.
If I can read function('123'), I would expect I can write it too.

:echo eval(string(adict)) works with most dictionaries; it only fails when the dictionary contains a numbered function.
I would expect :echo eval(string(adict)) to work all the time, not most of the time.

I'm using the vim-quickhl plugin.
The latter runs a :windo command to install some match in all windows.
This breaks the layout of my windows; I want all unfocused windows to be squashed to 0 lines.
But when I use a command from the plugin, the height of the unfocused windows is reset to 1 line.
Here is a minimal example.
Run this shell command:
git -C /tmp clone https://github.com/t9md/vim-quickhl

Then write this in /tmp/vim.vim:
set rtp^=/tmp/vim-quickhl
set wmh=0
sp
au VimEnter * call timer_start(0, {-> execute('wincmd _')})

Start Vim like this:
vim -Nu /tmp/vim.vim

The unfocused bottom window should be squashed to 0 lines.
Now, call a function from the plugin:
call quickhl#manual#this_whole_word('n')

The height of the bottom window has been reset to 1 line.
To fix this, I would need to replace :windo with map() + win_execute(), because the latter doesn't suffer from this undesirable side-effect.
That is, this block:
let winnum = winnr()
let pwinnum = winnr('#')
noa windo call call(a:func, [], a:obj)
if pwinnum != 0
    exe pwinnum..'wincmd w'
endif
exe winnum..'wincmd w'

should be replaced with this one:
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ 'call call('..string(a:func)..', [], '..string(a:obj)..')')})

But it fails for the same reason as reported earlier.
a:func and a:obj contain dictionaries which themselves contain numbered functions.
Vim is ok with passing those dictionaries to string(); but Vim is not ok with giving back the dictionaries when evaluating the contents of the resulting strings.
For the moment, I've fixed the issue by passing the dictionaries to call() via temporary global variables, in order to avoid the evaluation step:
let g:Quickhl_Funcref = a:func
let g:quickhl_obj = a:obj
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ 'call call(g:Quickhl_Funcref, [], g:quickhl_obj)')})
unlet g:Quickhl_Funcref g:quickhl_obj

But it seems awkward.

Not all dictionaries have a string representation, also for other reasons.
Sounds like what you are asking for is a new function
win_call({id}, {func}, {args}[, {dict}]) where {id} is used like with win_execute() and {func}, {args}, {dict} are call()-like arguments.

Ok, if it's not a bug, I close the issue and I'll try to open a feature request later.
In the meantime, I'll try to refactor the plugin to avoid numbered functions, for this reason and others.

What happens if you do
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ 'call call(a:func, [], a:obj)')})

Or
let l:func = a:func
let l:obj = a:obj
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ 'call call(l:func, [], l:obj)')})

What happens if you do
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ 'call call(a:func, [], a:obj)')})

That's what I tried at first, but it raises E121 and E116:
E121: Undefined variable: a:func
E116: Invalid arguments for function call

I think that's because the :call call(...) command is not run in the context of the current function; so it can't access the variables in the a: scope.
I thought about asking for the {command} argument of win_execute() to be able to be a lambda, because a lambda expression can access outer scope variables, so I could have fixed the bug by writing:
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ {-> call(a:func, [], a:obj)})})

but then I realized that it would change the meaning of win_execute(). I think the latter is really meant to execute an Ex command, not calling a function.

Or
let l:func = a:func
let l:obj = a:obj
call map(range(1, winnr('$')),
    \ {_,v -> win_execute(win_getid(v),
    \ 'call call(l:func, [], l:obj)')})

It raises E704:
E704: Funcref variable name must start with a capital: l:func

If I uppercase the name of the variable, I get – again – E121 and E116:
E121: Undefined variable: l:Func
E116: Invalid arguments for function call

Maybe give the lambda a hint to capture the variables: [win_execute(...), l:func, l:obj][0]?

@Houl's suggestion is quite accurate.
func A()
    let l:foo = 'bar'
    " works
    call map(range(1,3), 'execute("echo l:foo v:val", "")')
    " doesn't work (l:foo not captured)
    call map(range(1,3), {_,v->execute('echo l:foo v', '')})
    " works (forces l:foo to be captured)
    call map(range(1,3), {_,v->[execute('echo l:foo v', ''), l:foo][0]})
    " works
    call map(range(1,3), function({foo,_,v->execute('echo foo v', '')}, [l:foo]))
endfunc
call A()

I also think in this case using a lambda is more complicated than using an old-school eval string because it introduces an additional function scope.  @lacygoill, you should be able to rewrite similar to
call map(range(1, winnr('$')),
         \ 'win_execute(win_getid(v:val), "eval a:func()")')

or
call map(range(1, winnr('$')),
         \ 'win_execute(win_getid(v:val), "eval a:obj.size()")')

Yes, you are right, all of these fix the bug where the height of a squashed window is reset to 1:
call map(range(1, winnr('$')),
    \ "win_execute(win_getid(v:val), 'call call(a:func, [], a:obj)')")

call map(range(1, winnr('$')),
    \ {_,v -> [win_execute(win_getid(v), 'call call(a:func, [], a:obj)'), a:func, a:obj]})

call map(range(1, winnr('$')),
    \ function({func,obj,_,v -> win_execute(win_getid(v), 'call call(func, [], obj)')}, [a:func, a:obj]))

So the rules seem to be:

a lambda has access to the outer scope:
fu Func()
    let l:var = 123
    echo map([1], {_,v -> v + l:var})
endfu
call Func()
[124]

execute() inside a lambda which does not contain any reference to the outer scope does not have access to the latter:
fu Func()
    let l:var = 123
    call map([1], {-> execute('echo l:var', '')})
endfu
call Func()
E121: Undefined variable: l:var

execute() inside a lambda containing a reference to a variable in the outer scope has access to the latter:
fu Func()
    let l:var = 123
    call map([1], {-> [execute('echo l:var', ''), l:var]})
endfu
call Func()
123

execute() inside an eval string has access to the outer scope:
fu Func()
    let l:var = 123
    call map([1], "execute('echo l:var', '')")
endfu
call Func()
123

IIUC, it means that the command passed to execute() and win_execute() is run in its own separate context which can access the immediate outer scope (be it the lambda or Func()), but not further.
That is, even if execute() (E) can access the lambda scope (L), and the lambda can access the outer function scope (OF), that does not mean that execute() can access the outer function scope:
¬ ("E can access L" ∧ "L can access OF" ⇒ "E can access OF")

IOW, the mechanism which allows an expression to access variables outside its scope is not transitive.
So, this works:
func A()
    let l:var = 123
    call map([1], 'execute("echo l:var", "")')
endfunc
call A()

because echo l:var has access to the A() scope.
This fails:
func A()
    let l:var = 123
    call map([1], {-> execute('echo l:var', '')})
endfunc
call A()

because even though echo l:var has access to the lambda scope, and the latter has access to the A() scope, echo l:var does not have access to the A() scope (the access mechanism is not transitive).
And this works:
func A()
    let l:var = 123
    call map([1], {-> [execute('echo l:var', ''), l:var][0]})
endfunc
call A()

because:

l:var has been moved in the lambda scope, since it was referred to inside the expression
call map([1], {-> [execute('echo l:var', ''), l:var][0]})
                                              ^^^^^

echo l:var has access to the lambda scope

Finally, this works:
fu Func()
    let l:var = 123
    call map([1], function({var -> execute('echo var', '')}, [l:var]))
endfu
call Func()

because:

l:var has been bound to the lambda {var -> execute('echo var', '')}, creating a partial
map() evaluates the partial, like it would evaluate any kind of expression

In conclusion, if you need to access a variable in the outer scope from an execute() or win_execute() expression, you can:

use an eval string (not a lambda)
use a lambda and move the variable in its scope by referring to it inside the lambda but outside the execute()
use a partial

And I didn't know that:

the mechanism which allows an expression to access variables outside its scope is not transitive
you can move a variable from the outer scope to the lambda scope simply by referring to it inside the lambda (but outside execute(), probably because the latter is run in its own separate context)

Now, I realize that a lambda is not always better than an eval string:

it can introduce an additional function scope which prevents the access to a variable in the outer scope
it's slower

On my machine, this outputs a duration between 2.5s and 3s on average:
vim -Nu <(cat <<'EOF'
set vbs=1
let time = reltime()
call map(range(999999), {_,v-> v+1})
echo matchstr(reltimestr(reltime(time)), '\v.*\..{,3}')..' seconds to run the command'
qa!
EOF
)

While this outputs a duration of 0.5s on average:
vim -Nu <(cat <<'EOF'
set vbs=1
let time = reltime()
call map(range(999999), 'v:val + 1')
echo matchstr(reltimestr(reltime(time)), '\v.*\..{,3}')..' seconds to run the command'
qa!
EOF
)

It seems 5 to 6 times slower.
I have a mapping to refactor a '... v:val ...' into a {_,v -> ...v...}.
I think the reverse refactoring is not so useless as I thought initially; I'll try to implement it (although I suspect dealing with escaping quotes will be tricky).

Anyway, I used your first – and imo simplest – solution (an eval string) to write and submit a PR which fixes the bug. Thank you very much @Houl, @andymass.
P.S. Now that I think about it, I wonder whether the fact that :windo does not restore the height of a squashed window to 0 lines when leaving it could be considered as a bug; at least, I find it unexpected.


completed assignment 1

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
provided code for assignment completion
What did you learn from the changes you have made?
using algorithms to solve coding problems
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
None
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
None
How were these changes tested?
run on vscode
A reference to a related issue in your repository (if applicable)
N/A
Checklist

[x] I can confirm that my changes are working as intended

Changes added and can be found in the Files changed section.


Formalize Provider config and doc-gen.

This paves the way for the lift manifest format to be doc-gen'd as well.

There was no functionality change, but the delta is large; so I also ran this over in scie-pants with success:
$ cargo run -p package -- --science ../../a-scie/lift test --tools-pex-mismatch-warn

The new doc looks like so:

@sureshjoshi I think I've addressed your feedback. It should be easier to not go astray now if you happen to read these docs. I'm going to push ahead and merge. I'd like to finish this doc detour today and would like to get lift manifest format doc-gen and science doc open for local docs correct-for-your-version both in the 0.2.0 release.

https://science.scie.app/providers.html


Twitter @UNVofficial failed with error 500

Since I'm running the current master this looks to not be the issue discussed in #1225 #1226 #1231 #1236 #1240 and fixed in #1232
Error message: The requested resource cannot be found! Please make sure your input parameters are correct! cUrl error:  () PHP error: file_get_contents(https://twitter.com/UNVofficial): failed to open stream: Redirection limit reached, aborting
Query string: ``
Version: git.master.cf525c9

I'm running the bridge that way:
$ php index.php action=display bridge=TwitterBridge u="${1}" format=JsonFormat

It produces:
Exception: Required parameter(s) missing in /home/illwieckz/dev/rss-bridge/lib/error.php:24
Stack trace:
#0 /home/illwieckz/dev/rss-bridge/lib/error.php(33): returnError('Required parame...', 400)
#1 /home/illwieckz/dev/rss-bridge/lib/BridgeAbstract.php(232): returnClientError('Required parame...')
#2 /home/illwieckz/dev/rss-bridge/actions/DisplayAction.php(124): BridgeAbstract->setDatas(Array)
#3 /home/illwieckz/dev/rss-bridge/index.php(38): DisplayAction->execute()
#4 {main}

{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "",
    "home_page_url": "https:\/\/github.com\/RSS-Bridge\/rss-bridge\/",
    "feed_url": "http:\/\/",
    "items": [
        {
            "id": "1172623fe642ec2867dd49746bf3047258af5893",
            "title": "Bridge returned error 400! (18105)",
            "date_modified": "2019-07-28T06:03:48+00:00",
            "content_html": "
\n\t
Twitter Bridge<\/strong> was unable to receive or process the\nremote website's content!
\nError message: `Required parameter(s) missing`
\nQuery string: ``
\nVersion: `git.master.cf525c9`<\/p>\n\t
\n\t\t
\n\t\t\t
Press Return to check your input parameters<\/li>\n\t\t\t
Press F5 to retry<\/li>\n\t\t\t
Check if this issue was already reported on GitHub<\/a> (give it a thumbs-up)<\/li>\n\t\t\t
Open a GitHub Issue<\/a> if this error persists<\/li>\n\t\t<\/ul>\n\t<\/div>\n\t\n\t\t<button>Search GitHub Issues<\/button>\n\t<\/a>\n\t<button>Open GitHub Issue<\/button><\/a>\n\t
pmaziere<\/p>\n<\/section>"
        }
    ]
}

This should be fixed by #1234! PR #1232 needed some additional changes for the file_get_contents() fallback mode to work.

Good to see someone else using my configuration, I thought I was the only one!
@Roliga is correct, #1234 will fix this once merged. Meanwhile you can paste this into lib/contents.php: https://github.com/RSS-Bridge/rss-bridge/blob/e753bf16a412fae5ed9582d8b1ad3ab3d28945fc/lib/contents.php

@triatic I confirm this fixes the issue on my end

#1234 has been merged !


bugfix: Fix duplicated cache key

Ⅰ. Describe what this PR did
Fix duplicated cache key in table meta cache.
For mysql
1.remove the single quote
2.Is case sensitive base on databaseMetaData.supportsMixedCaseIdentifiers().

For oracle
1.Is case sensitive base on double quote.
(because Oracle does not implement databaseMetaData.supportsMixedCaseIdentifiers())
2.remove the double quote.

Ⅱ. Does this pull request fix one issue?
#1928
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1929 into develop will decrease coverage by 0.01%.
The diff coverage is 41.66%.

@@              Coverage Diff              @@
##             develop    #1929      +/-   ##
=============================================
- Coverage      55.16%   55.14%   -0.02%
  Complexity      2402     2402
=============================================
  Files            429      429
  Lines          14246    14269      +23
  Branches        1668     1670       +2
=============================================
+ Hits            7859     7869      +10
- Misses          5679     5692      +13
  Partials         708      708

Impacted Files
Coverage Δ
Complexity Δ

...ource/sql/struct/cache/AbstractTableMetaCache.java
84.84% <ø> (-0.45%)
10 <0> (-1)

...asource/sql/struct/cache/OracleTableMetaCache.java
6% <0%> (-0.39%)
3 <0> (ø)

...tasource/sql/struct/cache/MysqlTableMetaCache.java
80% <55.55%> (-4.79%)
11 <2> (+1)

...server/store/file/FileTransactionStoreManager.java
56.5% <0%> (+0.31%)
29% <0%> (ø)
:arrow_down:


Defender for Cloud Storage Accts - Logging to a LA Workspace on a different sub

I'm trying to log to a Sentinel LA Workspace that lives in a different subscription. It looks like I can only see Workspaces from the subscription that the Storage account resides in. This is not mentioned in the article. Can you confirm whether this limitation is real or if I'm missing something?
Thanks.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 2b92c195-c670-2e27-2422-fd131586bdd7
Version Independent ID: 75ad901d-8064-bfbe-67f5-de507bede1bc
Content: Protect your Azure storage accounts using Microsoft Defender for Cloud - Azure Storage
Content Source: articles/storage/common/azure-defender-storage-configure.md
Service: azure-storage
Sub-service: storage-common-concepts
GitHub Login: @dcurwin
Microsoft Alias: normesta

@callahan22
Thanks for your feedback! We will investigate and update as appropriate.

@callahan22
Thank you for bringing this to our attention. You are correct that by default, when you try to enable Azure Defender for Storage for a storage account in one subscription, you can only select a Log Analytics workspace that is in the same subscription as the storage account. This is because the Log Analytics workspace needs to be in the same Azure Active Directory (Azure AD) tenant as the storage account.
However, it is possible to enable Azure Defender for Storage for a storage account in one subscription and select a Log Analytics workspace that is in a different subscription, as long as the subscriptions are associated with the same Azure AD tenant. To do this, you need to grant the necessary permissions to the Log Analytics workspace in the other subscription.
Here are the general steps to enable Azure Defender for Storage for a storage account in one subscription and select a Log Analytics workspace that is in a different subscription:
Grant the Storage Account Contributor role to the Log Analytics workspace in the other subscription. This allows the workspace to access the storage account.
Grant the Log Analytics Contributor role to the user or service principal that will enable Azure Defender for Storage for the storage account. This allows the user or service principal to select the Log Analytics workspace in the other subscription.
Enable Azure Defender for Storage for the storage account and select the Log Analytics workspace in the other subscription.
Please note that these are general steps and the specific configuration steps may vary depending on your environment and requirements. I recommend consulting the documentation for Azure Defender for Storage and Log Analytics for more detailed guidance on how to enable Azure Defender for Storage for a storage account in one subscription and select a Log Analytics workspace that is in a different subscription.
I hope this information helps!


Unable to use paket in vscode

Unable to find paket.exe
I get this notification when using the Ionide-paket extension

Ionide just tries to detect it in your project. /cc @k_cieslak
Am So., 3. Feb. 2019, 18:33 hat thirteenturtles<EMAIL_ADDRESS>geschrieben:

Unable to find paket.exe
I get this notification when using the Ionide-paket extension
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3496, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNLlVrkbcp_Z8CkwwTmY7VLBNrEzIks5vJx1ogaJpZM4agN05
.

I created my paket from source, so I do have the folder but it doesn't have an .exe.
It does have a .sh and .cmd file

You need to download the bootstrapper and put it in that folder. More under
https://fsprojects.github.io/Paket/bootstrapper.html#Magic-mode
Am So., 3. Feb. 2019, 21:08 hat thirteenturtles<EMAIL_ADDRESS>geschrieben:

I created my paket from source, so I do have the folder but it doesn't
have an .exe.
It does have a .sh and .cmd file
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3496#issuecomment-460083814,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNMJgMPVCGzSTcpIk2YkOlxr61tlHks5vJ0HLgaJpZM4agN05
.


EditText Message

I'm using EditTextPreference in this way:
<com.lb.material_preferences_library.custom_preferences.EditTextPreference
            android:defaultValue="@string/a"
            android:hint="@string/a"
            android:inputType="number"
            android:key="@string/b"
            android:title="@string/c"
            app:dialogMessage="@string/d" />

but the description isn't shown. Where am I wrong?
Thank You

I don't see you've set the description. Only similar thing you used is the dialog message.
If you want a description below the title of the EditTextPreference , you need to use android:summary .
It's not something new. It was always there:
https://developer.android.com/reference/android/preference/Preference.html#attr_android:summary

Sorry, I used a wrong term. I don't see the "dialogMessage" that I've set.

You wrote it in the end :
"app:dialogMessage="@string/d""
But I see it doesn't work for some reason. will need to investigate and fix this.

OK, fixed. Try newest version now.

Thank you very much!