Graphql error -  Unknown operation named "Operations"

Expected Behavior
I passed the url and method I wanted to make the request, he asks that he needs the "operations" method
{ 	"errors": [ 		{ 			"message": "Unknown operation named \"Operations\".", 			"extensions": { 				"category": "graphql" 			} 		} 	] }

Actual Behavior
When I make a request it does not return the content that should be returned
Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
This problem happened in the new update that happened, at the moment everything was normal
Insomnia Version
2022.7.5
What operating system are you using?
Ubuntu
Operating System Version
Ubunut 22.04.1
Installation method
apt-get
Last Known Working Insomnia version
2022.7.4

This feels like a problem with your resource and not Insomnia, try using the StarWars API (free) https://studio.apollographql.com/public/star-wars-swapi/home?variant=current and hitting the example query. That will confirm whether its Insomnia, or the book.api

I just ran into this issue too and the StarWars API didn't work at first either. Using the StarWars API it was clearly able to pull in the schema, but when posting to the endpoint it gave a 500 and a similar response to @diogoX451. This was even worse than my localhost api, which was giving the weird "Unknown operation named \"Operations\" response but a 200.
I was eventually able to get the StarWars API to work after playing around with the query name, deleting a needing close parens, then adding the close parens back. After this is mysteriously worked. I was think able to get my local one to work after some similar finagling.
Now, if I have a trivial query like query Add {add(a: 1, b: 2)}, it works. But if I change the query name, it stops working, saying "message": "Unknown operation named \"Add\"" (even though at this point my operation name is Ad). If I remove the close parens, run the query, then add the close parens back and run the query again, it will then work with the new query name. When changing the name to a third thing, it doesn't reliably give either the original or the last working query name in the error message, so I am at a loss as to how that is working.

Hi @scottBowles  - it might be the case that when you first bumped into this issue you were using one of Insomnia's recent versions that had the unknown operation named problem.
I would recommend in this case that you upgrade to the latest Insomnia version, perhaps the beta release, try recreate a new graphql request and see if you can still reproduce the problem.

Using the beta version, the same error as always occurs, it would be the way I am performing the query differently or something from insonmia

Having the same issue as @diogoX451

I used postman, and all queries work perfectly, I thought it was something related to my request, but apparently not

Same, with Postman, worked. Even the Documentation fetch is better in Insomnia.

Similar error, but slightly different error message: No operation named ""

It happens when I'm trying to execute an unnamed query against the GitHub GraphQL API: {viewer{login}}. This is a perfectly valid GraphQL query. But Insomnia serializes the API requests into JSON as:
{"query":"{viewer{login}}","operationName":""}

The problem is the empty operationName parameter, which Insomnia shouldn't have added unless my GraphQL document has multiple named operations and my cursor is within one when I press “Send” in Insomnia.

Version: Insomnia 2022.7.5
Build date: 1/19/2023
OS: Darwin arm64 21.6.0
Electron: 22.0.0
Node: 16.17.1
V8: <IP_ADDRESS>-electron.0
Architecture: arm64

I just ran into this. Upgrading to Insomnia 2023.1.0-beta.1 did not help. It may have been caused by "Copy as cURL", the query worked fine before I did that. Notably, the operation name in the copied curl was truncated; I had query productBySku in my query and the operation name in the curl command ended up being query productByS, and the resulting error was Unknown operation named \"query productByS\" . I did this in version 2022.7.5.
Hopefully that info is helpful in some way. I did fix things by manually recreating the query, then everything worked. And in beta1, when I copy as curl the operation is no longer truncated.

+1 We had this same issue. Upgraded from Apollo 2->3 when it started to occur.

@mislav 👋 nice to see you around here!
I've also been running into a similar problem lately. Does clicking on operations and selecting the empty row work for you?

We hit this too. Insomnia is removing characters from the extracted operationName
query Test123456789 {
  fake {
    id
  }
}

Looking in the Timeline on Insomnia, you can see the operationName that it sends is has one less character....
{"query":"query Test123456789 {\n\tfake {\n\t\tid\n\t}\n}","operationName":"Test12345678","variables":{}}

We've confirmed that this bug does not exist in version 2022.6.0

Clicking here before "Send" resolves the issue...

To me, this indicates it's a UI issue. Meaning, when you're typing, the operationName stored in the state is being updated, but sometimes the last character you type doesn't make it into the state, so "Send" sometimes sends without the last character (or change). If you explicitly select the operationName from the drop-down, then it passes it in full.
Interestingly, the complete operationName is being extracted and getting into the drop-down ok.

Clicking here before "Send" resolves the issue...

Yes, that works  Hard to imagine how they've left this broken, as of 2022.7.5, still the download.
Thank you, @philwhln

I got the same error when I copy pasted the JSON directly from VSCode into Insomnia. I did not include query q { ... }, just the raw query like this { NAME_OF_QUERY() { ... } }
I got a workaround by prepending query q  and hit "Send". Then I can remove query q  and it is still working. Cheers! Hope it helps. Thanks for a nice piece of software btw 🍻

WTF! Insomnia manipulates the payload in some scenarios!

See the Timeline Tab:

With an explicit mutation name (and click at least once on it!) it does work properly:

Every named query I run does this. If you copy the request as cURL you can see that the operationName in the body does not match the query name. It seems like there's a state issue in insomnia where it sets the operationName to whatever it was before the last keyup event. It's been happening for a while, though all of the current beta releases and even in some of the stable releases leading up to the beta.
Downgrading to 2022.7.2 works, if you update the name of the query to cause it to update the operationName. Version picked somewhat arbitrarily, this issue seems to have been introduced some time late last year, older versions don't have the problem.

Interestingly, on 2022.7.5, up-to-date Windows 10, I'm not seeming to see this problem.
A named query works; if I alter the name, it alters in that UX visual also, and I don't have to touch it for things to work.
What may be different is that I'm using the no-install 'portable' version of Insomnia, though it's on the SSD of the laptop -- have any of you tried this?

I got the same error today

I just encountered the same error today. I wonder if anyone at Insomnia has seen this?

Encountered this on MacOS with Version: Insomnia 2023.1.0

Same version as @Nitrodist , with the same error, and the same observation about the named panel being "Operations". If I click on that, it's an empty dropdown.

Still reproduces on 2023.2.0

Same issue here, and the same GraphQL query works in Altair GraphQL client.

Still happening on 2023.2.2 😕

Same problem for me as well for a while:
Version: Insomnia 2023.2.2
Build date: 5/17/2023
OS: Darwin arm64 22.5.0
Electron: 22.0.0
Node: 16.17.1
V8: <IP_ADDRESS>-electron.0
Architecture: arm64

Disable automatic fetch. It'll will solve the issue.

I does not "solve" the issue - it is a way to avoid it until it is solved. Turning off features to enable other features to work is not a solution.

I does not "solve" the issue - it is a way to avoid it until it is solved. Turning off features to enable other features to work is not a solution.

You're right. But for now it allows to make request and overcome the error.

This is happening for me as well in:
Version: Insomnia 2023.2.2
Build date: 5/17/2023
OS: Darwin arm64 22.1.0
Electron: 22.0.0
Node: 16.17.1
V8: <IP_ADDRESS>-electron.0
Architecture: arm64

@filfreire you seem to have a lot of contributions this year. Can you relay this to the person that can resolve this? This bug is open for almost half a year now. Thanks 🙏

I don't really understand why this Operations feature was added. What does it solve?
Seems to me it mostly confuses users and causes bugs. Typically I use insomnia configurations generated by automation tools so the Operations are split into separate requests and the Operations selector is never set so nothing works.

And the issue is still there

This only seems to happen if you switch between named and unnamed queries with "Automatic Fetch" enabled. The easiest workaround is to exclusively use named or unnamed queries.
The other option is to select the empty operation name or setting a bogus name for the query and selecting the same from the operations tab 🤷.

+1
And the issue is still there

I can confirm that the issue is still there, version 2023.5.7
I find a workaround duplicating one of the request that works, and then named the query 'X'
query x {
	clients {
		id
		nit
		billingEmail
		clientType

	}
}

Working for me as well today. Wow, yesterday it was still not working!

I faced the issue after doing this steps:

I duplicated existing GQL request and moved it to new folder
I removed mutation that was in the request and replaced it with new query without name
Issue occurred
I tried naming query - Error message changed
I removed some empty lines bellow query
Everything works now :shrug:

Having the same issue on MacOS
Version: Insomnia 8.3.0
Build date: 10/13/2023
OS: Darwin arm64 22.6.0
Electron: 25.8.1
Node: 18.15.0
Node ABI: 116
V8: <IP_ADDRESS>-electron.0
Architecture: arm64

As of this moment it's still not fixed for me with the latest update:
Version: Insomnia 8.4.2
Build date: 11/15/2023
OS: Darwin x64 22.6.0
Electron: 27.0.3
Node: 18.17.1
Node ABI: 118
V8: <IP_ADDRESS>-electron.0
Architecture: x64
As a workaround, giving names to my mutations at least allows me to keep working.

It seems like the issue is still here with Insomnia v8.4.2 on MacOS ( node 18.14.2 )

Still having the same issue with Insomnia 8.4.5 on Ubuntu.

still not fixed 8.4.5 macOS apple silicon

A workaround that seems to consistently work for me:

Change from GraphQL to JSON
Remove ,"operationName":"Operations" from the end of the query
Send query (it should work now)
Switch back to GraphQL and try again

This page in the Insomnia docs gave me the idea with:
Note: It may be useful to know that this is how Insomnia stores the request body behind the scenes. Try converting the body type to JSON and back and see for yourself.

@cwalworth  Cameron, that's a really good idea, and thanks for showing h ow you worked it out.
I find this whole situation hard to imagine, if these Kong people are serious. They've taken forever to make an fix, and then somehow it seems people aren't getting it. Along with too-'clever' hacker-looking identities and 'chinese' code traps.
Here's what I did, considering that originally this was good work, by decent persons.

I removed Insomnia completely
downloaded the latest and installed

Then I was met with one more set of mousetraps.

there's now a required sign-in procedure
when you say you want to use email, it instead points you to using a Google identity.
the Google sign-in, I inspected, looked legitimate, but I still used a junk account -- what are these people trying to do??
then after I'd done this, an attempt to sell up to paid plan, sigh. With all this nonsense, I'd really have to think about that.
after the sell-up, yet another 'passphrase' -- with a 7 char minimum?  This is security?? And I don't want to use any of their cloud service, ,so why have to arrange it?  Are they taking my queries (and their security) off somewhere anyway?

I might suggest that Kong clean up their act.

@narration-sd  I completely agree, which is why I've been using Insomnium:
Insomnium is a fork of [Kong/insomnia at 2023.5.8](https://github.com/ArchGPT/insomnia), the last commit before compulsory account login was introduced. In a sense, Insomnium is a community response to [the latest product update that forces account creation w/o warning](https://news.ycombinator.com/item?id=37680522).
Unfortunately this bug came with the fork, but at least I don't have to sign in!

Addendum to the last comment, so it will be highly visibleL
You NOT have to sign up for an Insomnia account to use this latest version.
There is a tiny button at lower left on the big sign-in box, labeled with ScratchPad.
It doesn't look like a button, but use it.
Otherwise, you will run into one of the most arcane and dangerous-looking sign-up pages I think I've seen.
You'll be asked for a Google signin, even if you specify e-mail signin. It seemed to be legitimate, but I gave it a junk account just in case.
You'll be asked for some unrecognizable 'passphrase' business as well. With all kinds of caveats against their liability.
All this even though you've refused the push for paid account which cones, and denied you want to use any of their cloud.
Once I realized about the tiny button, I completely deleted this account.
It is also not helping their case to have developers presenting a hacker appearance, what childishness, complete with 'Chinese' puzzle code. Nor to have the months and months of delay fixing this current problem, if it is fixed. The code change looks like it might.
Insomnia has been a very good tool, put togeher by well-meaning persons. I think an adult will have to look at their current presentation, if they hope it will lead to subscriptions as a business. That's the best thought I can offer.

@cwalworth  Just got your reply, thanks for that.  And you'll see I put a few more things for the case...
I'll have a look at Insomnium, and maybe the fix here could be ported, as it's pretty small.
Take care, and hope you're enjoying nice holidays 🌲

Running into this as well:
Version: Insomnia 8.5.1
Build date: 12/21/2023
OS: Darwin arm64 22.6.0
Electron: 28.0.0
Node: 18.18.2
Node ABI: 119
V8: 12.0.267.8-electron.0
Architecture: arm64

cwalworth's workaround worked for me thank you

Why in the world was this terrible straight-up bug closed?  We have several people hitting this constantly.

Looks like they think they fixed it, back in October last year:  https://github.com/Kong/insomnia/pull/6733
I wonder about communications -- perhaps you might raise a fresh bug and link to here, as they're probably not seeing any comments since closing it.
I don't have much need these days, but when I do, I'm trying out the fork Insomnium, brought to attention here: https://github.com/Kong/insomnia/issues/5752#issuecomment-1870419823

Just ran into this as well...the kind suggestion of switching to json then deleting the operation worked nicely for me though, thank you

Our development team still experiences this issue.


react-flow__handle-connecting/valid class is not added to the handle

Describe the Bug
If the source handle and target handle are within the same node, the react-flow_handle-connecting and react-flow__handle-valid classes will not be added to the handle upon connection validation. So the handle cannot display validation results.
Your Example Website or App
https://reactflow.dev/docs/examples/interaction/validation/
Steps to Reproduce the Bug or Issue

set up isValidConnection on handles (the example above has it  set up already)
drag from one handle to another in the same node
target handle does not change colour regardless of the validation result
drag from one handle to another handle in another node
target handle does not change colour based on the validation result

Expected behavior
target handle should change color based on the validation result
Screenshots or Videos
No response
Platform

OS: macOS
Browser: Chrome
Version: 111.0.5563.146

Additional context
No response

Thanks! I just updated the example. You should pass the isValidationConnection handler to the ReactFlow component instead to the separate Handle components. Then it should work as expected.


[ConstraintSystem] Fix result builder discovery in leading-dot syntax…

… calls
Leading-dot syntax allows implicitly unwrapping result type to form
a base type of the call, getOpenedResultBuilderTypeFor needs to
account for that.
Resolves: https://github.com/apple/swift/issues/60586

@swift-ci please test


libmadmux missing functions

Like in Issue #25 , our Kuri has three versions of libmadmux. /opt/gizmo-master-cbb8e0c/lib/x86_64-linux-gnu and /opt/gizmo/lib/x86_64-linux-gnu have libmadmux version 0.3.0, and /opt/ros/indigo/lib has libmadmux version 0.2.0.
I have successfully got libmadmux to link to C++ code (see this CMakeLists file as an example). However, regardless of which of the three libmadmux files I link to, I get undefined reference errors when calling the functions: mdx_set_resolution, mdx_force_iframe, and mdx_set_bitrate. Note that the other functions listed in the docs, mdx_open, mdx_close, and mdx_register_cb all work.
The header files in both /opt/gizmo-master-cbb8e0c/include/madmux/madmux.h and /opt/gizmo/include/madmux/madmux.h include those functions. Therefore, the problem must be that the libmadmux.so itself does not include those functions.
Can you shed light on why this might be, and whether you have suggestions for changing the bitrate and resolution of camera streams?

It sounds like you are linking against the correct library at build time, but not at run time.
Also, /opt/gizmo should be a symbolic link to /opt/gizmo-master-cbb8e0c.
The leftover madmux lib in /opt/ros/indigo/lib is a known bug. After making a backup, could you try just removing anything pertaining to madmux in /opt/ros/indigo/lib?

Hi @po1,
I solved it! The core of the problem was, in fact, the duplicate madmux packages. The madmux.h files were actually different:
/opt/ros/indigo/include/madmux/madmux.h:
/**
 * madmux.h
 * madmux client library
 *
 * \author Paul
 * \date   2017-06-03
 */

#ifndef MADMUX_H
#define MADMUX_H

#include <stdint.h> /* uint* */

#ifdef __cplusplus
extern "C" {
#endif

struct mdx_stream;

typedef void (*mdx_cb)(uint8_t* buffer, uint32_t size, void* user_data);

/**
 * Open a madmux video channel
 * @param  socket the path to the UNIX socket for that channel
 * @return        the video stream handle
 */
struct mdx_stream* mdx_open(const char* socket);

/**
 * Close a madmux video channel
 * @param stream the stream to close
 */
void mdx_close(struct mdx_stream* stream);

/**
 * Register a callback to receive video frames
 * @param stream    the video stream handle
 * @param cb        the callback
 * @param user_data a pointer to a user data structure
 */
void mdx_register_cb(struct mdx_stream* stream, mdx_cb cb, void* user_data);

#ifdef __cplusplus
}
#endif

#endif /* end of include guard: MADMUX_H */

/opt/gizmo/include/madmux/madmux.h:
/**
 * madmux.h
 * madmux client library
 *
 * \author Paul
 * \date   2017-06-03
 */

#ifndef MADMUX_H
#define MADMUX_H

#include <stdint.h> /* uint* */

#ifdef __cplusplus
extern "C" {
#endif

struct mdx_stream;

typedef void (*mdx_cb)(uint8_t* buffer, uint32_t size, void* user_data);

/**
 * Open a madmux video channel
 * @param  socket the path to the UNIX socket for that channel
 * @return        the video stream handle
 */
struct mdx_stream* mdx_open(const char* socket);

/**
 * Close a madmux video channel
 * @param stream the stream to close
 */
void mdx_close(struct mdx_stream* stream);

/**
 * Register a callback to receive video frames
 * @param stream    the video stream handle
 * @param cb        the callback
 * @param user_data a pointer to a user data structure
 */
void mdx_register_cb(struct mdx_stream* stream, mdx_cb cb, void* user_data);

/**
 * Ask for a single frame on a still channel
 * @param stream    the video stream handle
 */
void mdx_snap(struct mdx_stream* stream);

/**
 * Force an i-frame in an h264 stream
 * @param stream    the video stream handle
 */
void mdx_force_iframe(struct mdx_stream* stream);

/**
 * Set the bitrate of a non-raw stream.
 * @param stream    the video stream handle
 * @param bitrate   bitrate in bps
 */
void mdx_set_bitrate(struct mdx_stream* stream, uint32_t bitrate);

/**
 * Set the resolution of a stream.
 * @param stream    the video stream handle
 * @param width     the width of the video in pixels
 * @param height    the height of the video in pixels
 */
void mdx_set_resolution(struct mdx_stream* stream, uint16_t width,
        uint16_t height);

#ifdef __cplusplus
}
#endif

#endif /* end of include guard: MADMUX_H */

Therefore, although I was linking against the right libmadmux in /opt/gizmo/, catkin was using the wrong .h file from /opt/ros/indigo.  I solved this by deleting all traces of madmux from /opt/ros/indigo:
sudo rm -r /opt/ros/indigo/include/madmux
sudo rm  /opt/ros/indigo/lib/libmadmux.so
sudo rm  /opt/ros/indigo/lib/libmadmux.so.0
sudo rm  /opt/ros/indigo/lib/libmadmux.so.0.2.0
sudo rm -r /opt/ros/indigo/share/madmux
I then re-built my workspace (catkin clean followed by catkin build).
I will post my minimal working example in a comment in case it helps anyone, but as of now this issue is solved for me.

Although this issue is solved (see above), I am posting my minimal working example in case it helps others. If I commented out lines 13-15 of the cpp file (mdx_set_resolution, mdx_force_iframe, and mdx_set_bitrate), it compiled fine. However, if I left them in, I got a linking error (see below).
kuri_camera_linking_issue/src/kuri_camera_linking_issue.cpp:
#include "ros/ros.h"
#include <madmux/madmux.h>

static void callback(uint8_t *buffer, uint32_t size, void *obj) {
  return;
}

int main(int argc, char **argv) {
  ros::init(argc, argv, "kuri_camera_linking_issue");

  mdx_stream* stream = mdx_open("/var/run/madmux/ch1.sock"); // works
  mdx_register_cb(stream, callback, NULL); // works
  mdx_set_resolution(stream, 1240, 720); // undefined reference
  mdx_force_iframe(stream); // undefined reference
  mdx_set_bitrate(stream, 30); // undefined reference
  mdx_close(stream); // works

  return 0;
}

CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.3)
project(kuri_camera_linking_issue)

set(libmadmux_path /opt/gizmo/lib/x86_64-linux-gnu)

find_package(catkin REQUIRED COMPONENTS
  madmux
  roscpp
)

catkin_package(
 CATKIN_DEPENDS madmux roscpp
)

include_directories(
  ${catkin_INCLUDE_DIRS}
)

# find libmadmux
set(libmadmux "libmadmux-NOTFOUND")
find_file(libmadmux libmadmux.so.0.3.0 ${libmadmux_path} NO_DEFAULT_PATH)

if (libmadmux)
  add_executable(kuri_camera_linking_issue src/kuri_camera_linking_issue.cpp)
  target_link_libraries(kuri_camera_linking_issue ${catkin_LIBRARIES} ${libmadmux})
else()
  message(ERROR "Did not find libmadmux")
endif()

package.xml:
<?xml version="1.0"?>
<package format="2">
  <name>kuri_camera_linking_issue</name>
  <version>0.0.0</version>
  <description>The kuri_camera_linking_issue package</description>
  <maintainer<EMAIL_ADDRESS>
  <license>TODO</license>

  <buildtool_depend>catkin</buildtool_depend>
  <build_depend>madmux</build_depend>
  <build_depend>roscpp</build_depend>
  <build_export_depend>madmux</build_export_depend>
  <build_export_depend>roscpp</build_export_depend>
  <exec_depend>madmux</exec_depend>
  <exec_depend>roscpp</exec_depend>

</package>

As I mentioned above, if I compile the code with lines 13-15 included, I get the following error:
mayfield@cococutkuri:~/workspaces/amal_ws$ catkin build kuri_camera_linking_issue
----------------------------------------------------------------------
Profile:                     default
Extending:          [cached] /opt/gizmo:/opt/ros/indigo
Workspace:                   /home/mayfield/workspaces/amal_ws
----------------------------------------------------------------------
Build Space:        [exists] /home/mayfield/workspaces/amal_ws/build
Devel Space:        [exists] /home/mayfield/workspaces/amal_ws/devel
Install Space:      [unused] /home/mayfield/workspaces/amal_ws/install
Log Space:          [exists] /home/mayfield/workspaces/amal_ws/logs
Source Space:       [exists] /home/mayfield/workspaces/amal_ws/src
DESTDIR:            [unused] None
----------------------------------------------------------------------
Devel Space Layout:          linked
Install Space Layout:        None
----------------------------------------------------------------------
Additional CMake Args:       None
Additional Make Args:        None
Additional catkin Make Args: None
Internal Make Job Server:    True
Cache Job Environments:      False
----------------------------------------------------------------------
Whitelisted Packages:        None
Blacklisted Packages:        None
----------------------------------------------------------------------
Workspace configuration appears valid.
----------------------------------------------------------------------
[build] Found '11' packages in 0.0 seconds.
[build] Package table is up to date.
Starting  >>> kuri_camera_linking_issue
___________________________________________________________________________________________________________________________________________________________________________________________________________
Errors     << kuri_camera_linking_issue:make /home/mayfield/workspaces/amal_ws/logs/kuri_camera_linking_issue/build.make.003.log
CMakeFiles/kuri_camera_linking_issue.dir/src/kuri_camera_linking_issue.cpp.o: In function `main':
kuri_camera_linking_issue.cpp:(.text+0xaa): undefined reference to `mdx_set_resolution'
kuri_camera_linking_issue.cpp:(.text+0xb6): undefined reference to `mdx_force_iframe'
kuri_camera_linking_issue.cpp:(.text+0xc7): undefined reference to `mdx_set_bitrate'
collect2: error: ld returned 1 exit status
make[2]: *** [/home/mayfield/workspaces/amal_ws/devel/.private/kuri_camera_linking_issue/lib/kuri_camera_linking_issue/kuri_camera_linking_issue] Error 1
make[1]: *** [CMakeFiles/kuri_camera_linking_issue.dir/all] Error 2
make: *** [all] Error 2
cd /home/mayfield/workspaces/amal_ws/build/kuri_camera_linking_issue; catkin build --get-env kuri_camera_linking_issue | catkin env -si  /usr/bin/make --jobserver-fds=6,7 -j; cd -
...........................................................................................................................................................................................................
Failed     << kuri_camera_linking_issue:make           [ Exited with code 2 ]
Failed    <<< kuri_camera_linking_issue                [ 0.9 seconds ]
[build] Summary: 0 of 1 packages succeeded.
[build]   Ignored:   10 packages were skipped or are blacklisted.
[build]   Warnings:  None.
[build]   Abandoned: None.
[build]   Failed:    1 packages failed.
[build] Runtime: 1.1 seconds total.
mayfield@cococutkuri:~/workspaces/amal_ws$

To be clear, after deleting all traces of madmux from /opt/ros/indigo (see above) this minimal working example compiled and ran fine.


Allow optional component declaration

Issue: #5542
Typically, when developing features in Angular, it is advantageous to use "feature modules" which provide a "context" for declared components including required imports, declarations, and providers.
To simulate this context in Storybook, we may want to use the component that has already been declared in its FeatureModule, rather than having to recreate this context manually (with imports, providers, and additional declarations) just to get the component to perform its basic functionality.
However, currently, the only way to display a component declared in its feature module is to refer to it indirectly in the template  property (e.g. template: '<my-component [prop1]="prop1"></my-component>') which is used by Storybook to dynamically create a component called DynamicComponent. While this works, we lose the following benefits:

Direct mapping between props and the @Inputs and @Outputs of the component we want to display.
Any potential benefits of type-checking for property names.

If we want to get the above benefits, we need to specify the component by its class (e.g. component: MyComponent). Unfortunately, the default behavior of Storybook for Angular is to declare specified components in a dynamic module, which prevents us from using the version of the component declared in our feature module (with its appropriate context), due to the fact that a component can only be declared in one module (else Angular will error out).
What I did
I added an optional flag called requiresComponentDeclartion to the NgStory object that the user specifies in the ".add()" method. When this flag is set to false, Storybook will not declare the specified component in the DynamicModule. This flag is set to true by default, which leaves the existing behavior (hence this is not a breaking change).
How to test

Is this testable with Jest or Chromatic screenshots?
Maybe? Please advise.
Does this need a new example in the kitchen sink apps?
Yes, added.
Does this need an update to the documentation?
The Storybook for Angular documentation does not seem to go very deep into specific configuration options.

Sorry, as with my other PR, snapshots were missing. Should be good now.

@kroeder @gaetanmaisse Would you be able to review this possibly? Sounds useful.


Update release-notes-known-issues35.md

update ArangoSearch LOKI

Applied to another PR: https://github.com/arangodb/docs/pull/160


Test Against 5.5 LTS

Now that 5.5 is released as a LTS I think its good to move the package to 5.5
I am not sure if any breaking changes will happen, but thats what my tests will tell me. Hopefully, 5.4 and 5.5 can work together.

Notes that might affect package:

Any fire methods present on your Artisan commands should be renamed to handle.
This could affect webhook/scripts/after jobs.

The $request->has method will now return true for empty strings and null
Double check my requests on what I'm checking.

Slight modification to webhook job console command, tests are passing as of now.

Solved with #4


Not receive notifcation when run on ios 8

Hello!
I have project cordova using this plugin, it running ok on ios 9, 10. But it not working on ios 8.1.2
What's problem in here !
Please help me.

Same here.


error thrown in react native --- buffer doesn't exist

ReferenceError: Property 'Buffer' doesn't exist
ReferenceError: Property 'Buffer' doesn't exist
    at base64UrlDecode (http://<IP_ADDRESS>:8081/node_modules/expo/AppEntry.bundle//&platform=ios&dev=true&hot=false&lazy=true:329743:12)
    at getUnauthedClaims (http://<IP_ADDRESS>:8081/node_modules/expo/AppEntry.bundle//&platform=ios&dev=true&hot=false&lazy=true:329729:68)```

solution in app.tsx:
npm install --save buffer

global.Buffer = Buffer;```

solved with https://github.com/whodisio/simple-jwt-auth/commit/697469659c312aacc3d6ad6f1d3e45b547b6f9ad


Surprising over-large diff

(1) A description of the issue. A screenshot is often helpful too.
I have a Java source file with various changes, including a small change in the middle of a large method, including extracting some code into a new method which comes immediately after the large method. When i diffed my change, i was surprised to see that the whole large method was shown as deleted and re-added, so that the diff could line up some common parts in the old version of the large method and the new extracted method.
See this diff from difft:

JSONFetcher.java.difft.txt

And this one from diff -u, which is much smaller:

JSONFetcher.java.diffu.txt

(2) A copy of what you're diffing.
See attached (you will need to rename these to remove the .txt):

JSONFetcher.baseline.java.txt
JSONFetcher.changed.java.txt

(3) The version of difftastic you're using (see difft --version) and your operating system.
$ difft --version
Difftastic 0.52.0
$ grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Ubuntu 18.04.6 LTS"

The expected diff should be more like this:

This looks like a bug with the 'split unchanged' logic, as the main differ is seeing three separate things to diff. The problem disappears with DFT_DBG_KEEP_UNCHANGED=y, although I don't recommend this debug setting in general (it's crucial for performance).


Fixed memory bug and added nonexistent file test for flare controller

What does this PR do?

Fixes a small memory bug in the flare controller when it would try to os.stat() a nonexistent file.
Motivation

Got a memory error when testing it.
Additional Notes

Possible Drawbacks / Trade-offs

N/A
Describe how to test/QA your changes

No functional or behavioral changes, should be covered by the test.
Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


lynphoma

Description
What the nost safe and accurate test exists for diagnosis of lynphoma or leucemia ?
(Optional:) Please add any files, screenshots, or other information here.
No response
(Required) What is this issue most closely related to? Select one.
Other
Internal issue ID
8e985fd0-b4c4-4893-914c-cc8083229392
Paper URL
https://arxiv.org/html/2406.10459v1
Browser
Firefox/127.0
Device Type
Android

Please contact the authors directly for questions on document content.
This repository only tracks the quality of the experimental HTML format. Thank you!


docs: update

docs: update

Rebased, and merged with some changes.
Thanks for your contribution !


fix: plugins can now query the API without content-security-policy re…

This is something tricky, plugins can now query the /graphql/ API. This update introduces the following pattern:
#  saleor/plugins/my_special_plugin/plugin.py
from .graphql.schema import schema  # schema created for the plugin

class MPlugin(BasePlugin):
    ...

    def webhook(self, request, path, previous_value):
        view = GraphQLView.as_view(schema=schema)
        return view(request)

And plugins can have their endpoints on /plugins/plugin_id/
Then we can federate the plugins with the base GraphQL API.

Kindly note that I wanted to access the plugin configuration in the schema of the GraphQLView above, and the only 2 way I could use are, either extend the GraphQLView and let it accept new parameters, or monkey-patch it on the request on the fly
    def webhook(self, request, path, previous_value):
        view = GraphQLView.as_view(schema=schema)
        request.plugin_config = self.configuration   # or whatever needed
        return view(request)

And this lets me think of, why don't we return the request.app that was removed in an issue before and set it to the requestor plugin instance, or app URL?

@korycins @patrys @maarcingebala
Not sure I know someone else here, can we discuss this?

@LeOndaz, could you start by describing the use case/problem you're trying to solve? I'm not sure I understand why that change is beneficial.

@LeOndaz, could you start by describing the use case/problem you're trying to solve? I'm not sure I understand why that change is beneficial.

Hello @patrys , it's nice to hear from you again, let me elaborate
Plugins extend the core functionality, but webhook are restful, we can make the plugins expose a GraphQL endpoint as well, but we do need the plugin to use the sae playground instead of copying it around just to edit the content security policy, plugins at the moment can't use playground.html because content security policy doesn't allow urls other than api_url and this update adds support for plugin urls as well.

@patrys So basically, we can't render the template from any urls other than {{ api_uri }}, but plugins need to render it because some plugins may want to add a GraphQL playground on their own then we federate all of them at the end, this is the first step towards allowing plugins to be GraphQL services, another step was suggested above and here's a demo:
The request.app is not related to this specific PR, but here's a use case
/plugins/my.plugin/

initiateOAuth2(provider: Google) {
    url
    state
}

OAuth2Callback(provider: Google, code: "code", state: "statex") {
     user {
        id
     }
}

and the implementation is
class initiateOAuth2Mutation(...):
    def perform_mutation(self, ...)
        # how can I know get the plugin's configuration here? I want client_id and client_secret of google to be able to use oauth2
        # here lies the benefit of request.app again,

@LeOndaz, I get it. That makes sense.

@patrys can you also give me your opinion about the request.app thing?

@patrys not sure why it is failing, I'll appreciate some help and how can this be merged

@maarcingebala
Should I PR adding request.app again?
look closely at my example above, the schema is rendered correctly but it has no access to the plugin configuration


Android Release Mode issue with chat

There is a chat issue with android in release mode but no in debug mode . Is there a different configuration between debug and release mode ?
Why in Release mode, Messages in chat  appear as sent by the bot and not by the user?

Hi @ivangoluuk ,
Thanks for writing to us. We'll look into this issue and update you here once resolved.
Regards,
Bhahirathan M,
Zoho SalesIQ.

Thank u 🙏🏻

Hi @ivangoluuk ,
Thank you for your patience. We have fixed this issue. We recommend you update to the latest version 3.1.0, and verify. Please feel free to write back to us at<EMAIL_ADDRESS>if the issue persists.
Regards,
Bhahirathan M
Zoho SalesIQ.


Cannot able to connect to ksql

Connecting to ksql keeps waiting for more than 30 minutes

Hi,
Please can you post details of this (including which Docker Compose you're running, machine memory allocated, output of docker ps -a etc) to the Kafka Connect category on https://forum.confluent.io/ and someone will hopefully help out there. thanks.


Add unknown T₂, Gaussian hyperparameterized models.

This PR adds two new models, one which learns Rabi frequencies with unknown T₂ processes, the other of which decorates two-outcome models with Gaussian hyperparameters based on a latent two-outcome variable. This allows for using QInfer to learn T₂ in cases where single-shot measurements are not directly observed, but are only observed through a secondary process that is Gaussian distributed.

Coverage decreased (-0.6%) to 73.582% when pulling 84eada59054f5d273e07d3517ddae93ff717fa4e on cgranade/unknown-T2 into 252ac0365372374427be62b359fecdb519e42553 on master.

The 4 CI failures look like they have nothing to do with this PR. Are they due to a new numpy thing?

Consider throwing a test or two into test_concrete_models.py. Untested:
class TestGaussianHyperparameterizedModel(ConcreteModelTest, DerandomizedTestCase):
    """
    Tests GaussianHyperparameterizedModel with CoinModel as the underlying model
    (underlying model has no expparams).
    """

    def instantiate_model(self):
        return GaussianHyperparameterizedModel(CoinModel())
    def instantiate_prior(self):
        return ProductDistribution(
               BetaDistribution(mean=0.5, var=0.1),
               ...
        )
    def instantiate_expparams(self):
return np.arange(100, 120).astype(self.model.expparams_dtype)

This looks great. I agree with @ihincks it is a good addition. It seems as we move forward experimentally there is an increasing focus on continuous outcome distributions. Once I find more time I want to focus on explicitly supporting continuous outcomes (right now IIRC it is maybe hinted at in the documentation but left to the user to figure out how to support them). This would also include supporting the branch me and Ian have been working on to support continuous outcomes natively include experiment design in smc.py. I will try and clean this up and get tests passing later this week so that I can submit a PR. There will be a decent amount of documentation and testing to get it in working condition. I hope that after @ihincks defends he might be able to help me review this and come up with a plan.

Sounds great, @taalexander! Thanks as well for the typo catch, @ihincks. I think this might be good to go once I can get the CI builds working. Would anyone mind if I merge in #135, since CI seems to work there again? That would mean deprecating 3.3 in favor of Python 2.7 or ≥ 3.4. Since 3.3 is now approximately six years old, I don't think that should be a problem...

Awesome, thanks for everything! 💕


Feat/endpoint authorization

Hey @mcollina, @ivan-tymoshenko.
Have a look on the initial draft for endpoint based access control.
Let me know if I'm missing out something.

I think the structure is not quite there.
After having a deeper look on fastify I think a valid approach would be:

Use the "onReady" hook that is alredy creating hooks for entities to create a "onRequest" hook
This onRequest hook would check on the request content and enpoint rules to allow or deny access to route handler
The "onReady" hook function would have to be refactor because if a rule that has no entity on it is processed it throws

I would follow a slightly different structure:

create an req.authorize(permissions) method as described in the issue first. This allows you to develop things in baby-steps.
Use the onRoute hook to add a onRequest hook that calls req.authorize()

Wdyt?

You mean to use a basic structure like this in platformatic.db.json?
{
  "rules": [
    {
      "endpoint": "/someCustomEndpoint",
      "authorizer": "<path to exported authorizer>"
    }
  ]
}

I was thinking about using a structure like the one used for entities for endpoints as well, but it seems reasonable to have different forms for both cases.
I'd like to hear your thoughts about how to be specific for a route (considering that a route is made of both HTTP Method and Path). This way only the Path is being considered.
More general questions are:

I think of authorizers returning either a boolean or throwing. Do you see any case in witch this is a problem?
Authorizer should actually be authorizers. This way an array can be passed and if any of the authorizers provided returns true the request handler is used.

I don't really get your previous comment.
The first step I recommended is to add a single req.authorize(permissions) function that would check a bunch of user-specified permissions before progressing. It should throw if the current user does not have the rights to perform the operation described in permissions. I would represent permission in a similar way we have represented all other rules.

Alright! I've just pushed with what I imagine that is the first step using the approach that you seem to be talking about.
Turns out the issue had a lot of different and incompatible ideas and I focused on what I think that would be easier to the end user/developer.
I followed the approach suggested by @ivan-tymoshenko to provide a method to be called inside the handler, but in terms of developer experience I think it would be better to do it before that and make it invisible for developers. It might be a bit more difficult to implement because of the way that we deal with request hooks and plugins at fastify core (I don't know much, it's my first time using it).
I still have a doubt about using on onRoute hook. In the way that I implemented it it looks like whenever a new route is registered by fastify a new onRequest hook is also created. Wouldn't it be enough just to use one single onRequest hook to check authorization?

wdyt @ivan-tymoshenko ?

Hey folks!
I was still working on this but it was nice to have a review from both of you.
At this point I think that there might be a few different ideas about how this should work.
I believe that it can be worked out before advancing on this.
If the spec becomes to big it might be worth to split it in a few features to have it fully covered.
My main concerns at this point are:

Where should authorization rules be kept? If it's passed to the authorize call I'd expect an array with all the roles that are allowed to access that specific endpoint (seems clean to me).
What should be the structure used for securing an endpoint? In the case above an array would be enough, but with rules coming from a config file this wold be important. As @ivan-tymoshenko said, using find, save, delete for a plugin sounds weird

closing for no updates


[LR]Precisely Characterizing Security Impact in a Flood of Patches via Symbolic Rule Comparison

https://blog.1pwnch.com/posts/precisely_char_sec_impact_patch_via_sym_comp/

https://blog.1pwnch.com/posts/precisely_char_sec_impact_patch_via_sym_comp/

Can you tell me what the standard control-dependency analysis is? I want to compile the patch source code to IR, but I don't know what and how to do it.


[Bug]: Problems with brew executable binary

Contact Details
No response
What happened?
The binary works fine and then another time a bit later I run into this error:
~/code/monokle-demo  ▶ monokle validate bundles
node:internal/modules/cjs/loader:936
  throw err;
  ^

Error: Cannot find module '/var/folders/7_/54m525216j753qdynl70gjjh0000gn/T/caxa/applications/monokle/urgds8hcn8/0/build/main.js'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

brew uninstall monokle-cli && brew install monokle-cli does not solve it. I have to manually go and delete caxa's temporary directory which is an awful experience.
Version
1.0.0 (Default)
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

For now we undocumented the brew install and we can revise this once there is more traction towards this.

NodeJs has a bit a bad reputation in Cloud-Native ecoystem so it's best to solely work with binaries and leave out the npm install. We noticed some bugs on recurrent usage for binary for MacOS. The firsts times it will work! Try it after a while and it stops working with above error.


Fixes homepage SVGs

Why:
We were having weird problems with SVGs on Firefox. This could be anything
from a small typo in our code to a bug in Firefox itself. After hours of
debugging, we decided to move the SVGs to object elements, which seems to work
fine as well. There are extra requests being made now, but at least it's
working
This change addresses the need by:

Moving all SVGs in the homepage to an object tag, instead of having them inline
Refactor the JS code for the animations to interact with the contents of the object, instead of directly in the DOM

:+1:


plakar rm is broken

Describe the bug
There is a regression with plakar rm causing it to fault when destroying an existing snapshot:
% plakar rm d79b854f-8528-41a1-91a5-a3500321919e
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x1027f7d3c]

goroutine 1 [running]:
github.com/poolpOrg/plakar/storage.(*Snapshot).Purge(0x140001700e0, 0x1400022e079, 0x24)
        /Users/gilles/Wip/github.com/poolpOrg/plakar/storage/snapshot.go:433 +0x3c
main.cmd_rm(0x102a54070, 0x140001537a0, 0x140000121d0, 0x1, 0x1)
        /Users/gilles/Wip/github.com/poolpOrg/plakar/cmd/plakar/cmd_rm.go:55 +0x250
main.main()
        /Users/gilles/Wip/github.com/poolpOrg/plakar/cmd/plakar/plakar.go:265 +0xa24

To Reproduce
Steps to reproduce the behavior:

create a snapshot
delete the snapshot

Expected behavior
The command should simply return and the snapshot should no longer be available.
Desktop (please complete the following information):

OS: any

Additional context
This was introduced with the rework into packages.

fixed in latest commit


putmem: Fix Floating point exception issue

Validate read() before calling __adu_putmem().
Also check end size in progress_tick().
Signed-off-by: Vasant Hegde<EMAIL_ADDRESS>

will send patch to mailing list.
-Vasant


Add recommend usage of FQDN policies

Explain the risk of setting FQDN rules with drop or reject actions

/skip-all


Remove old examples, add new

Remove the old stuff (everything?) from the examples dir

Created #4685 to remove Silverlight and WindowsPhone Apps

When https://github.com/NLog/NLog.Windows.Forms/pull/95 has been merged, then all Winforms-samples can be removed.

no steps plan anymore here


VS Code can't select the correct environment /interpreter for jupyter in bottom ringht

Environment data

VS Code version: 1.55.1
Jupyter Extension 2021.5.702919634
Python Extension 2021.3.680753044
VS Code setup in Windows10 and use Remote -SSH Extension(version 0.65.1) to login Linux(Ubuntu 16.04.5)
Anaconda version: 4.10.0
Jupyter server running: Local

Expected behaviour
I want to select the jupyter interpreter in bottom ringht, and I select python3.8.8 (the red box),as follows:

Actual behaviour
But it still use the interpreter python3.8.3:

And I notice that  the differen version interpreters have the same path(blue box).

And the conda python env:

I try to use "ctrl + shift +p" to select jupyter interpreter,I can see the python3.8.8 and the correct path, and select 3.8.8,but it doesn't work.

What should I do to select the correct interpreter for jupyter? Hope your help!

Sorry for the trouble. This looks like a bug in our kernel switcher. Just to confirm, are you using 2021.5.702919634 on the remote machine as well? They're not necessarily the same version locally vs remotely.

Another question: would you mind pasting the Jupyter extension's logs in a new comment below? You can find them at the bottom of VS Code in the terminal panel:

@litun-fkby
Please could you also provide the logs from Jupyter panel.

Attempt to repro the issue & then copy the output from the Jupyter output panel.

I also use jupyter 2021.5.702919634 on the remote machine:

And I creat a new jupyter notebook,the logs as follows:
Info 2021-04-13 18:48:53: Attempting to start a server because of preload conditions ...
Info 2021-04-13 18:48:53: findPreferredKernel score for python3.8 is 1
Info 2021-04-13 18:48:53: findPreferredKernel score for Python 3.8.3 64-bit ('anaconda3': virtualenv) is 1
Info 2021-04-13 18:48:53: findPreferredKernel score for python3_latest is 1
Info 2021-04-13 18:48:53: findPreferredKernel score for Python 3.8.8 64-bit ('python3.8': conda) is 1
Info 2021-04-13 18:48:53: findPreferredKernel score for Python 3.8.5 64-bit ('python3_latest': conda) is 1
Info 2021-04-13 18:48:53: findPreferredKernel score for Python 2.7.12 64-bit is 1
Info 2021-04-13 18:48:53: findPreferredKernel score for Python 3.5.2 64-bit is 1
Info 2021-04-13 18:48:53: Find kernel spec, Class name = D, completed in 4ms, has a truthy return value, Arg 1: Uri:/home/litun/GitLab_clone/litun-project/test/test2.ipynb, Arg 2: {"language_info":{"name":"python","nbconvert_exporter":"python"},"orig_nbformat":2}, Arg 3: {"_isCancelled":false,"_emitter":null}, Return Value: {"kind":"startUsingPythonInterpreter","kernelSpec":{"specFile":"/home/litun/.local/share/jupyter/kernels/python3.8/kernel.json","name":"python3.8","argv":["/home/litun/anaconda3/bin/python","-m","ipykernel_launcher","-f","{connection_file}"],"language":"python","path":"/home/litun/anaconda3/bin/python","display_name":"python3.8"},"interpreter":{"sysPrefix":"/home/litun/anaconda3","envType":"Conda","envName":"base","envPath":"/home/litun/anaconda3","path":"/home/litun/anaconda3/bin/python","architecture":3,"sysVersion":"3.8.3 (default, Jul  2 2020, 16:21:59) \n[GCC 7.3.0]","version":{"raw":"3.8.3","major":3,"minor":8,"patch":3,"build":[],"prerelease":[]},"companyDisplayName":"Anaconda, Inc.","displayName":"Python 3.8.3 64-bit ('base': conda)"},"id":".python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8"}
Info 2021-04-13 18:48:53: KernelProvider switched kernel to id = .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8}
Info 2021-04-13 18:48:53: Starting Notebook in kernel.ts id = .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8
Info 2021-04-13 18:48:53: Compute Launch Info uri = /home/litun/GitLab_clone/litun-project/test/test2.ipynb, kernelConnection id = .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8
Info 2021-04-13 18:48:53: Compute Launch Info uri = /home/litun/GitLab_clone/litun-project/test/test2.ipynb, changed false, .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8
Info 2021-04-13 18:48:53: Python Daemon (pid: 2228212): write to stderr: [I 18:48:53.676 NotebookApp] Creating new notebook in /GitLab_clone/litun-project/test
[I 18:48:53.676 NotebookApp] Creating new notebook in /GitLab_clone/litun-project/test
Info 2021-04-13 18:48:53: installMissingDependencies /home/litun/anaconda3/bin/python
Info 2021-04-13 18:48:55: Process Execution: > ~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py pip list

~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py pip list
Info 2021-04-13 18:48:55: Process Execution: > ~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py -c "import ipykernel"
~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py -c "import ipykernel"
Info 2021-04-13 18:49:02: Install Missing Dependencies, Class name = v, completed in 8959ms, has a falsy return value, Return Value: undefined
Info 2021-04-13 18:49:02: Check if a kernel is usable, Class name = b, completed in 9095ms, has a falsy return value, Arg 1: {"kind":"startUsingPythonInterpreter","kernelSpec":{"specFile":"/home/litun/.local/share/jupyter/kernels/python3.8/kernel.json","name":"python3.8","argv":["/home/litun/anaconda3/bin/python","-m","ipykernel_launcher","-f","{connection_file}"],"language":"python","path":"/home/litun/anaconda3/bin/python","display_name":"python3.8"},"interpreter":{"sysPrefix":"/home/litun/anaconda3","envType":"Conda","envName":"base","envPath":"/home/litun/anaconda3","path":"/home/litun/anaconda3/bin/python","architecture":3,"sysVersion":"3.8.3 (default, Jul  2 2020, 16:21:59) \n[GCC 7.3.0]","version":{"raw":"3.8.3","major":3,"minor":8,"patch":3,"build":[],"prerelease":[]},"companyDisplayName":"Anaconda, Inc.","displayName":"Python 3.8.3 64-bit ('base': conda)"},"id":".python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8"}, Arg 2: {"_isCancelled":false,"_emitter":{"_disposed":false,"_listeners":{"_first":{"next":{},"prev":{}},"_last":{"next":{},"prev":{}},"_size":1}}}, Arg 3: undefined, Return Value: undefined
Info 2021-04-13 18:49:02: Starting a new session for kernel id = .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8, name = python3.8
Info 2021-04-13 18:49:03: Python Daemon (pid: 2228212): write to stderr: [I 18:49:03.086 NotebookApp] Kernel started: f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e, name: python3.8

[I 18:49:03.086 NotebookApp] Kernel started: f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e, name: python3.8
Info 2021-04-13 18:49:03: Waiting for idle on (kernel): f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e -> unknown
Info 2021-04-13 18:49:03: Python Daemon (pid: 2228212): write to stderr: [W 18:49:03.106 NotebookApp] delete /GitLab_clone/litun-project/test/test2-449f996a-a902-490a-91fb-8a57f6a4cf6b.ipynb
[W 18:49:03.106 NotebookApp] delete /GitLab_clone/litun-project/test/test2-449f996a-a902-490a-91fb-8a57f6a4cf6b.ipynb
Info 2021-04-13 18:49:04: Finished waiting for idle on (kernel): f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e -> idle
Info 2021-04-13 18:49:04: Started session 9ef8181d-f3c6-4916-aa20-93fa4fcb47f1
Info 2021-04-13 18:49:04: Waiting for idle (session) 9ef8181d-f3c6-4916-aa20-93fa4fcb47f1
Info 2021-04-13 18:49:04: Waiting for idle on (kernel): f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e -> idle
Info 2021-04-13 18:49:04: Finished waiting for idle on (kernel): f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e -> idle
Info 2021-04-13 18:49:04: Initial setup for file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb starting ...
 User queued cell for execution
Info 2021-04-13 18:49:34: Cell Index:0, state:undefined, exec: undefined. Update cell state as it was enqueued
Info 2021-04-13 18:49:34: Hooked up kernel restart handler
Info 2021-04-13 18:49:34: Cell Index:0, state:undefined, exec: undefined. Ready to execute
Info 2021-04-13 18:49:34: Cell Index:0, state:undefined, exec: undefined. Before Execute individual cell
Info 2021-04-13 18:49:34: Cell Index:0, state:undefined, exec: undefined. Start execution
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: undefined. Send code for execution
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: undefined. Wait for jupyter execution
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: undefined. Kernel switching to busy
Info 2021-04-13 18:49:34: Notebook Session status file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb # Busy
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Update output
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Kernel switching to idle
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Jupyter execution completed
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Completed successfully
Info 2021-04-13 18:49:34: Notebook Session status file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb # Idle
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Update cell state 3 and message ''
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Completed successfully & resolving
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. After Execute individual cell 3
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Executed successfully in executeCell
Info 2021-04-13 18:49:34: Cell Index:0, state:3, exec: 1. Execution disposed
Info 2021-04-13 18:49:40: Dispose kernel file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb
Info 2021-04-13 18:49:40: Kernel got disposed as a result of notebook.onDisposed file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb
Info 2021-04-13 18:49:40: Kernel got disposed, hence there is no longer a kernel associated with file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb
Info 2021-04-13 18:49:40: Shutting down session file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb
Info 2021-04-13 18:49:40: Shutdown session - current session
Info 2021-04-13 18:49:40: shutdownSession f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e, .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8 - start
Info 2021-04-13 18:49:40: Session can be shutdown .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8
Info 2021-04-13 18:49:40: KernelProvider switched kernel to id = .python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda)}
Info 2021-04-13 18:49:40: Starting Notebook in kernel.ts id = .python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda)
Info 2021-04-13 18:49:40: Process Execution: > ~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py pip list

~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py pip list
Info 2021-04-13 18:49:40: Compute Launch Info uri = /home/litun/GitLab_clone/litun-project/test/test2.ipynb, kernelConnection id = .python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda)
Info 2021-04-13 18:49:40: Compute Launch Info uri = /home/litun/GitLab_clone/litun-project/test/test2.ipynb, changed true, .python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda)
Info 2021-04-13 18:49:40: Python Daemon (pid: 2228212): write to stderr: [I 18:49:40.758 NotebookApp] Kernel shutdown: f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e

[I 18:49:40.758 NotebookApp] Kernel shutdown: f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e
Info 2021-04-13 18:49:41: shutdownSession f0374c95-0fd6-4f99-8cee-c4c2fb16dd5e, .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8 - shutdown complete
Info 2021-04-13 18:49:41: Shutdown session - get restart session
Info 2021-04-13 18:49:41: Shutdown session - shutdown restart session
Info 2021-04-13 18:49:41: shutdownSession 62ace913-ecc1-4f7a-8a56-46e838b0bfa7, .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8 - start
Info 2021-04-13 18:49:41: Session can be shutdown .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8
Info 2021-04-13 18:49:41: Python Daemon (pid: 2228212): write to stderr: [I 18:49:41.162 NotebookApp] Creating new notebook in /GitLab_clone/litun-project/test
[I 18:49:41.162 NotebookApp] Creating new notebook in /GitLab_clone/litun-project/test
Info 2021-04-13 18:49:41: Python Daemon (pid: 2228212): write to stderr: [W 18:49:41.176 NotebookApp] Got events for closed stream None
[W 18:49:41.176 NotebookApp] Got events for closed stream None
Info 2021-04-13 18:49:41: Python Daemon (pid: 2228212): write to stderr: [I 18:49:41.177 NotebookApp] Kernel shutdown: 62ace913-ecc1-4f7a-8a56-46e838b0bfa7
[I 18:49:41.177 NotebookApp] Kernel shutdown: 62ace913-ecc1-4f7a-8a56-46e838b0bfa7
Info 2021-04-13 18:49:41: shutdownSession 62ace913-ecc1-4f7a-8a56-46e838b0bfa7, .python3.8./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.python3.8 - shutdown complete
Info 2021-04-13 18:49:41: Shutdown session -- complete
Info 2021-04-13 18:49:41: installMissingDependencies /home/litun/anaconda3/bin/python
Info 2021-04-13 18:49:41: Process Execution: > ~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py -c "import ipykernel"

~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py -c "import ipykernel"
Info 2021-04-13 18:49:41: Python Daemon (pid: 2228212): write to stderr: [W 18:49:41.386 NotebookApp] Got events for closed stream None

[W 18:49:41.386 NotebookApp] Got events for closed stream None
Info 2021-04-13 18:49:41: Install Missing Dependencies, Class name = v, completed in 380ms, has a falsy return value, Return Value: undefined
Info 2021-04-13 18:49:41: Spec argv[0] updated from '/home/litun/anaconda3/bin/python' to '/home/litun/anaconda3/bin/python'
Info 2021-04-13 18:49:42: Check if a kernel is usable, Class name = b, completed in 635ms, has a falsy return value, Arg 1: {"kind":"startUsingPythonInterpreter","kernelSpec":{"specFile":"/home/litun/.local/share/jupyter/kernels/python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394/kernel.json","name":"python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394","argv":["/home/litun/anaconda3/bin/python","-m","ipykernel_launcher","-f","{connection_file}"],"language":"python","path":"/home/litun/anaconda3/bin/python","display_name":"Python 3.8.8 64-bit ('python3.8': conda)","metadata":{"originalSpecFile":"/home/litun/anaconda3/envs/python3.8/share/jupyter/kernels/python3/kernel.json","interpreter":{"sysPrefix":"/home/litun/anaconda3","envType":"Conda","envName":"base","envPath":"/home/litun/anaconda3","path":"/home/litun/anaconda3/bin/python","architecture":3,"sysVersion":"3.8.3 (default, Jul  2 2020, 16:21:59) \n[GCC 7.3.0]","version":{"raw":"3.8.3","major":3,"minor":8,"patch":3,"build":[],"prerelease":[]},"companyDisplayName":"Anaconda, Inc.","displayName":"Python 3.8.3 64-bit ('base': conda)"}},"env":{"MANPATH":"/opt/sge/man:/usr/share/man:/usr/local/share/man:/usr/share/man:/mnt/nfs/software/man","XDG_SESSION_ID":"31437","SHELL":"/bin/bash","SSH_CLIENT":"<IP_ADDRESS> 21855 22","PERL5LIB":"/mnt/nfs/software/lib/perl5:/mnt/nfs/software/lib/perl/5.22.1","CONDA_SHLVL":"1","PYTHONUNBUFFERED":"1","SGE_ARCH":"lx-amd64","SGE_CELL":"default","CONDA_PROMPT_MODIFIER":"(base) ","VSCODE_EXTHOST_WILL_SEND_SOCKET":"true","PYTHONUSERBASE":"/mnt/nfs/software","PYTHONIOENCODING":"utf-8","USER":"litun","LS_COLORS":"","VSCODE_VERBOSE_LOGGING":"true","CONDA_EXE":"/home/litun/anaconda3/bin/conda","VSCODE_PIPE_LOGGING":"true","VSCODE_LOG_STACK":"false","LIBVIRT_DEFAULT_URI":"qemu:///system","VSCODE_INJECT_NODE_MODULE_LOOKUP_PATH":"/mnt/nfs/user/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/remote/node_modules","VSCODE_AMD_ENTRYPOINT":"vs/server/remoteExtensionHostProcess","_CE_CONDA":"","VSCODE_AGENT_FOLDER":"/home/litun/.vscode-server","PATH":"/mnt/nfs/user/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/bin:/home/litun/anaconda3/bin:/home/litun/anaconda3/condabin:/mnt/nfs/software/share/samtools-1.9:/mnt/nfs/software/share/bcftools-1.3:/mnt/nfs/software/share/FastQC:/mnt/nfs/user/chenly/pipe/medtest/modular/bin:/opt/sge/bin/lx-amd64:/mnt/nfs/software/share/ossutil64:/mnt/nfs/user/chenly/pipe/medtest/modular/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/share/games:/usr/local/sbin:/usr/sbin:/sbin:/home/litun/.local/bin:/snap/bin:/opt/sge/bin:/opt/sge/bin/lx-amd64:/home/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/dell/srvadmin/bin:/mnt/nfs/software/bin:/mnt/nfs/software/opt/texlive/bin/x86_64-linux:/home/litun/bin","MAIL":"/var/mail/litun","CONDA_PREFIX":"/home/litun/anaconda3","R_LIBS":"/mnt/nfs/software/lib/R","PWD":"/mnt/nfs/user/litun","VSCODE_HANDLES_UNCAUGHT_ERRORS":"true","DB_IP":"<IP_ADDRESS>","LANG":"zh_CN.UTF-8","SGE_ROOT":"/opt/sge","VSCODE_LOG_NATIVE":"false","_CE_M":"","HOME":"/home/litun","SHLVL":"4","APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL":"true","LANGUAGE":"zh_CN:zh","VSCODE_NLS_CONFIG":"{"locale":"zh-cn","availableLanguages":{"*":"zh-cn"},"_languagePackId":"b475c8051e44470192b4d0d6d26919c5.zh-cn","_translationsConfigFile":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn/tcf.json","_cacheRoot":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn","_resolvedLanguagePackCoreLocation":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn/08a217c4d27a02a5bcde898fd7981bda5b49391b","_corruptedFile":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn/corrupted.info","languagePackSupport":true}","CONDA_PYTHON_EXE":"/home/litun/anaconda3/bin/python","LOGNAME":"litun","XDG_DATA_DIRS":"/usr/local/share:/usr/share:/var/lib/snapd/desktop","SSH_CONNECTION":"<IP_ADDRESS> 21855 <IP_ADDRESS> 22","VSCODE_IPC_HOOK_CLI":"/run/user/64796/vscode-ipc-a6b0cab9-6248-4fb3-8977-9bfef14500a8.sock","CONDA_DEFAULT_ENV":"base","BROWSER":"/mnt/nfs/user/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/bin/helpers/browser.sh","SGE_CLUSTER_NAME":"yuce-dp","XDG_RUNTIME_DIR":"/run/user/64796","VSCODE_CWD":"/mnt/nfs/user/litun","":"/home/litun/anaconda3/bin/python"}},"interpreter":{"sysPrefix":"/home/litun/anaconda3","envType":"Conda","envName":"base","envPath":"/home/litun/anaconda3","path":"/home/litun/anaconda3/bin/python","architecture":3,"sysVersion":"3.8.3 (default, Jul  2 2020, 16:21:59) \n[GCC 7.3.0]","version":{"raw":"3.8.3","major":3,"minor":8,"patch":3,"build":[],"prerelease":[]},"companyDisplayName":"Anaconda, Inc.","displayName":"Python 3.8.3 64-bit ('base': conda)"},"id":".python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda)"}, Arg 2: {"_isCancelled":false,"_emitter":{"_disposed":false,"_listeners":{"_first":{"next":{},"prev":{}},"_last":{"next":{},"prev":{}},"_size":1}}}, Arg 3: undefined, Return Value: undefined
Info 2021-04-13 18:49:42: Starting a new session for kernel id = .python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda), name = python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394
Info 2021-04-13 18:49:42: Python Daemon (pid: 2228212): write to stderr: [I 18:49:42.050 NotebookApp] Kernel started: 7a487eb7-0933-476f-9978-1d4107545019, name: python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394
[I 18:49:42.050 NotebookApp] Kernel started: 7a487eb7-0933-476f-9978-1d4107545019, name: python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394
Info 2021-04-13 18:49:42: Waiting for idle on (kernel): 7a487eb7-0933-476f-9978-1d4107545019 -> unknown
Info 2021-04-13 18:49:42: Python Daemon (pid: 2228212): write to stderr: [W 18:49:42.062 NotebookApp] delete /GitLab_clone/litun-project/test/test2-adc97440-6d02-4894-aafb-7ece7ce06926.ipynb
[W 18:49:42.062 NotebookApp] delete /GitLab_clone/litun-project/test/test2-adc97440-6d02-4894-aafb-7ece7ce06926.ipynb
Info 2021-04-13 18:49:42: Finished waiting for idle on (kernel): 7a487eb7-0933-476f-9978-1d4107545019 -> idle
Info 2021-04-13 18:49:42: Started session 9ef8181d-f3c6-4916-aa20-93fa4fcb47f1
Info 2021-04-13 18:49:42: Waiting for idle (session) 9ef8181d-f3c6-4916-aa20-93fa4fcb47f1
Info 2021-04-13 18:49:42: Waiting for idle on (kernel): 7a487eb7-0933-476f-9978-1d4107545019 -> idle
Info 2021-04-13 18:49:42: Finished waiting for idle on (kernel): 7a487eb7-0933-476f-9978-1d4107545019 -> idle
Info 2021-04-13 18:49:42: Initial setup for file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb starting ...
Info 2021-04-13 18:49:42: UpdateWorkingDirectoryAndPath
Info 2021-04-13 18:49:42: Kernel switching to busy
Info 2021-04-13 18:49:42: Kernel switching to idle
Info 2021-04-13 18:49:42: Python Daemon (pid: 2228212): write to stderr: [I 18:49:42.765 NotebookApp] Creating new notebook in /GitLab_clone/litun-project/test
[I 18:49:42.765 NotebookApp] Creating new notebook in /GitLab_clone/litun-project/test
Info 2021-04-13 18:49:42: installMissingDependencies /home/litun/anaconda3/bin/python
Info 2021-04-13 18:49:42: Process Execution: > ~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py -c "import ipykernel"

~/anaconda3/bin/python /mnt/nfs/user/litun/.vscode-server/extensions/ms-toolsai.jupyter-2021.5.702919634/pythonFiles/pyvsc-run-isolated.py -c "import ipykernel"
Info 2021-04-13 18:49:42: Kernel switching to busy
Info 2021-04-13 18:49:42: Kernel switching to idle
Info 2021-04-13 18:49:42: Initial setup complete for file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb
Info 2021-04-13 18:49:42: Finished connecting 9ef8181d-f3c6-4916-aa20-93fa4fcb47f1
Info 2021-04-13 18:49:42: UpdateWorkingDirectoryAndPath
Info 2021-04-13 18:49:42: changeDirectoryIfPossible
Info 2021-04-13 18:49:42: Kernel switching to busy
Info 2021-04-13 18:49:42: Notebook Session status file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb # Busy
Info 2021-04-13 18:49:42: Kernel switching to idle
Info 2021-04-13 18:49:42: Notebook Session status file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb # Idle
Info 2021-04-13 18:49:43: Waiting for idle on (kernel): 7a487eb7-0933-476f-9978-1d4107545019 -> idle
Info 2021-04-13 18:49:43: Finished waiting for idle on (kernel): 7a487eb7-0933-476f-9978-1d4107545019 -> idle
Info 2021-04-13 18:49:43: Install Missing Dependencies, Class name = v, completed in 354ms, has a falsy return value, Return Value: undefined
Info 2021-04-13 18:49:43: Spec argv[0] updated from '/home/litun/anaconda3/bin/python' to '/home/litun/anaconda3/bin/python'
Info 2021-04-13 18:49:43: Check if a kernel is usable, Class name = b, completed in 685ms, has a falsy return value, Arg 1: {"kind":"startUsingPythonInterpreter","kernelSpec":{"specFile":"/home/litun/.local/share/jupyter/kernels/python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394/kernel.json","name":"python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394","argv":["/home/litun/anaconda3/bin/python","-m","ipykernel_launcher","-f","{connection_file}"],"language":"python","path":"/home/litun/anaconda3/bin/python","display_name":"Python 3.8.8 64-bit ('python3.8': conda)","metadata":{"originalSpecFile":"/home/litun/anaconda3/envs/python3.8/share/jupyter/kernels/python3/kernel.json","interpreter":{"sysPrefix":"/home/litun/anaconda3","envType":"Conda","envName":"base","envPath":"/home/litun/anaconda3","path":"/home/litun/anaconda3/bin/python","architecture":3,"sysVersion":"3.8.3 (default, Jul  2 2020, 16:21:59) \n[GCC 7.3.0]","version":{"raw":"3.8.3","major":3,"minor":8,"patch":3,"build":[],"prerelease":[]},"companyDisplayName":"Anaconda, Inc.","displayName":"Python 3.8.3 64-bit ('base': conda)"}},"env":{"MANPATH":"/opt/sge/man:/usr/share/man:/usr/local/share/man:/usr/share/man:/mnt/nfs/software/man","XDG_SESSION_ID":"31437","SHELL":"/bin/bash","SSH_CLIENT":"<IP_ADDRESS> 21855 22","PERL5LIB":"/mnt/nfs/software/lib/perl5:/mnt/nfs/software/lib/perl/5.22.1","CONDA_SHLVL":"1","PYTHONUNBUFFERED":"1","SGE_ARCH":"lx-amd64","SGE_CELL":"default","CONDA_PROMPT_MODIFIER":"(base) ","VSCODE_EXTHOST_WILL_SEND_SOCKET":"true","PYTHONUSERBASE":"/mnt/nfs/software","PYTHONIOENCODING":"utf-8","USER":"litun","LS_COLORS":"","VSCODE_VERBOSE_LOGGING":"true","CONDA_EXE":"/home/litun/anaconda3/bin/conda","VSCODE_PIPE_LOGGING":"true","VSCODE_LOG_STACK":"false","LIBVIRT_DEFAULT_URI":"qemu:///system","VSCODE_INJECT_NODE_MODULE_LOOKUP_PATH":"/mnt/nfs/user/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/remote/node_modules","VSCODE_AMD_ENTRYPOINT":"vs/server/remoteExtensionHostProcess","_CE_CONDA":"","VSCODE_AGENT_FOLDER":"/home/litun/.vscode-server","PATH":"/mnt/nfs/user/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/bin:/home/litun/anaconda3/bin:/home/litun/anaconda3/condabin:/mnt/nfs/software/share/samtools-1.9:/mnt/nfs/software/share/bcftools-1.3:/mnt/nfs/software/share/FastQC:/mnt/nfs/user/chenly/pipe/medtest/modular/bin:/opt/sge/bin/lx-amd64:/mnt/nfs/software/share/ossutil64:/mnt/nfs/user/chenly/pipe/medtest/modular/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/share/games:/usr/local/sbin:/usr/sbin:/sbin:/home/litun/.local/bin:/snap/bin:/opt/sge/bin:/opt/sge/bin/lx-amd64:/home/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/dell/srvadmin/bin:/mnt/nfs/software/bin:/mnt/nfs/software/opt/texlive/bin/x86_64-linux:/home/litun/bin","MAIL":"/var/mail/litun","CONDA_PREFIX":"/home/litun/anaconda3","R_LIBS":"/mnt/nfs/software/lib/R","PWD":"/mnt/nfs/user/litun","VSCODE_HANDLES_UNCAUGHT_ERRORS":"true","DB_IP":"<IP_ADDRESS>","LANG":"zh_CN.UTF-8","SGE_ROOT":"/opt/sge","VSCODE_LOG_NATIVE":"false","_CE_M":"","HOME":"/home/litun","SHLVL":"4","APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL":"true","LANGUAGE":"zh_CN:zh","VSCODE_NLS_CONFIG":"{"locale":"zh-cn","availableLanguages":{"*":"zh-cn"},"_languagePackId":"b475c8051e44470192b4d0d6d26919c5.zh-cn","_translationsConfigFile":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn/tcf.json","_cacheRoot":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn","_resolvedLanguagePackCoreLocation":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn/08a217c4d27a02a5bcde898fd7981bda5b49391b","_corruptedFile":"/home/litun/.vscode-server/data/clp/b475c8051e44470192b4d0d6d26919c5.zh-cn/corrupted.info","languagePackSupport":true}","CONDA_PYTHON_EXE":"/home/litun/anaconda3/bin/python","LOGNAME":"litun","XDG_DATA_DIRS":"/usr/local/share:/usr/share:/var/lib/snapd/desktop","SSH_CONNECTION":"<IP_ADDRESS> 21855 <IP_ADDRESS> 22","VSCODE_IPC_HOOK_CLI":"/run/user/64796/vscode-ipc-a6b0cab9-6248-4fb3-8977-9bfef14500a8.sock","CONDA_DEFAULT_ENV":"base","BROWSER":"/mnt/nfs/user/litun/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b/bin/helpers/browser.sh","SGE_CLUSTER_NAME":"yuce-dp","XDG_RUNTIME_DIR":"/run/user/64796","VSCODE_CWD":"/mnt/nfs/user/litun","":"/home/litun/anaconda3/bin/python"}},"interpreter":{"sysPrefix":"/home/litun/anaconda3","envType":"Conda","envName":"base","envPath":"/home/litun/anaconda3","path":"/home/litun/anaconda3/bin/python","architecture":3,"sysVersion":"3.8.3 (default, Jul  2 2020, 16:21:59) \n[GCC 7.3.0]","version":{"raw":"3.8.3","major":3,"minor":8,"patch":3,"build":[],"prerelease":[]},"companyDisplayName":"Anaconda, Inc.","displayName":"Python 3.8.3 64-bit ('base': conda)"},"id":".python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda)"}, Arg 2: undefined, Arg 3: true, Return Value: undefined
Info 2021-04-13 18:49:43: Starting a new session for kernel id = .python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394./home/litun/anaconda3/bin/python./home/litun/anaconda3/bin/python.Python 3.8.8 64-bit ('python3.8': conda), name = python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394
Info 2021-04-13 18:49:43: Python Daemon (pid: 2228212): write to stderr: [I 18:49:43.514 NotebookApp] Kernel started: 0c1f653f-0ee7-40bc-947f-61b32e1d1473, name: python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394

[I 18:49:43.514 NotebookApp] Kernel started: 0c1f653f-0ee7-40bc-947f-61b32e1d1473, name: python388jvsc74a57bd0742d1724008bf11cc0ead37b44625a7509b69950556c35d2cfc87edf7c4a5394
Info 2021-04-13 18:49:43: Waiting for idle on (kernel): 0c1f653f-0ee7-40bc-947f-61b32e1d1473 -> unknown
Info 2021-04-13 18:49:43: Python Daemon (pid: 2228212): write to stderr: [W 18:49:43.524 NotebookApp] delete /GitLab_clone/litun-project/test/test2-e5b863f4-e4e8-4dfe-8088-b75e41cb3db3.ipynb
[W 18:49:43.524 NotebookApp] delete /GitLab_clone/litun-project/test/test2-e5b863f4-e4e8-4dfe-8088-b75e41cb3db3.ipynb
Info 2021-04-13 18:49:43: Execute Cells request 1 0
Info 2021-04-13 18:49:43: Execute Cell 0 file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb in kernelWithMetadata.ts
Info 2021-04-13 18:49:43: Cell Index:0, state:1, exec: 1. User queued cell for execution
Info 2021-04-13 18:49:43: Cell Index:0, state:1, exec: 1. Update cell state as it was enqueued
Info 2021-04-13 18:49:43: Hooked up kernel restart handler
Info 2021-04-13 18:49:43: Cell Index:0, state:1, exec: 1. Ready to execute
Info 2021-04-13 18:49:43: Cell Index:0, state:1, exec: 1. Before Execute individual cell
Info 2021-04-13 18:49:43: Cell Index:0, state:1, exec: 1. Start execution
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: undefined. Send code for execution
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: undefined. Wait for jupyter execution
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: undefined. Kernel switching to busy
Info 2021-04-13 18:49:43: Notebook Session status file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb # Busy
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: undefined. Update output
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Kernel switching to idle
Info 2021-04-13 18:49:43: Notebook Session status file:///home/litun/GitLab_clone/litun-project/test/test2.ipynb # Idle
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Jupyter execution completed
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Completed successfully
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Update cell state 3 and message ''
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Completed successfully & resolving
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. After Execute individual cell 3
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Executed successfully in executeCell
Info 2021-04-13 18:49:43: Cell Index:0, state:3, exec: 1. Execution disposed
Info 2021-04-13 18:49:44: Finished waiting for idle on (kernel): 0c1f653f-0ee7-40bc-947f-61b32e1d1473 -> idle

Sorry for the last comment because the log info inconvenient to view,so I add the attechment for the jupyter log.
jupyter log.txt
Another qusetion, somtime I want to run code in jupyter,but I get the error  "invalid version -final",as follow:

So I have to select another version of jupyter extension,how can I do to  avoid this append?

Sorry for the trouble. This looks like a bug in our kernel switcher. Just to confirm, are you using 2021.5.702919634 on the remote machine as well? They're not necessarily the same version locally vs remotely.

Another question: would you mind pasting the Jupyter extension's logs in a new comment below? You can find them at the bottom of VS Code in the terminal panel:

I also use jupyter 2021.5.702919634 on the remote machine:

and the  jupyter log:
jupyter log.txt
Another qusetion, somtime I want to run code in jupyter,but I get the error  "invalid version -final",as follow:

So I have to select another version of jupyter extension,how can I do to  avoid this append?

@litun-fkby So sorry for the delayed response. Please could you confirm that this is still an issue with the latest versions of the Jupyter and Python extensions and VS Code 1.56.2?
Latest Jupyter version: v2021.6.832593372
Latest Python version: v2021.5.842923320

Closing for lack of activity.
@litun-fkby, please reopen if you can still repro on the latest release, both in the local and remote machines.


rtm.start behavior changing

Hello there!
I just received the following email from Slack:

As a contributor or owner of Karmabot that recently used the rtm.start Web API method, we wanted to inform you about two important changes coming to rtm.start:
November 30, 2021
New Slack apps and integrations will no longer be able to use rtm.start and must use rtm.connect instead.
September 20, 2022
The response from rtm.start will transform into the brief response found in the method that replaces it, rtm.connect.

I went through the bot's code but couldn't find where it is using the rtm.start method. Is there anything I should do to prevent the bot from breaking when they make the changes?
Thanks!
Cheers,
Gustavo

I think that was solved as we updated to a newer version of the Slack package. Thanks for the hint.


Operation not permitted when cron tries to execute script

I'm getting this error message when my cron executes:
/bin/sh: /Users/pnadolny/Documents/Git/GitHub/meltano/squared/data/.meltano/run/cron-ext/spreadsheets_anywhere_el.sh: Operation not permitted
It might be user error but I did make sure the permissions were updated to allow it to be executed. Is there any step I'm missing?
cc @WillDaSilva

@pnadolny13 Could this be an issue because you're running on macOS?
https://apple.stackexchange.com/questions/378553/crontab-operation-not-permitted

@WillDaSilva that was exactly it! Thanks for the link.


Micro optimizations

Make the code cleaner and more consistent:

use the useState({})[1] pattern for re-rendering the component
make the internal property names shorter in Cache
make the key prefixes in useSWRInfinite 3 chars (ctx@, inf@, len@), and internal cache property name shorter
make addRevalidator return the ubsubscriber

Closes #896.

@huozhi It seems like the linter didn't yell, so I think it's fine :)

@shuding care to point out what is the useState({})[1] trick? I'm curious on what it changes.

@ranisalt it's an implementation detail inside SWR, previously we are using const [,rerender] = useState(false) to create a re-render function, now it uses const rerender = useState({})[1].


When the page's width is big,the content will not be clear.How to deal with it?

Attach (recommended) or Link to PDF file here:
Configuration:

Web browser and its version:
Operating system and its version:
PDF.js version:
Is a browser extension:

Steps to reproduce the problem:
1.
2.
What is the expected behavior? (add screenshot)
What went wrong? (add screenshot)
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Closing since none of the requested information in the template is provided and the question is not clear at all, so it's not actionable.


Sending Welcome Email on user create not working with Mailgun

I am on Spark Plan and I am using Mailgun to deliver mails to my user when they create an account and delete it. I am following the mailgun-js docs and I am pretty sure I am doing things correctly.  But on my Firebase functions console I am getting error  error: getaddrinfo enotfound api.mailgun.net api.mailgun.net:443
Sorry if this is not a Firebase issue but I would be happy if anyone could provide me correct way to implement this feature using Mailgun.
Thank You,
Firebase

Okay I upgraded to Blaze Plan, and now it is working fine. I would suggest the maintainers/contributors of this project to please specify in the Readme that, outbound requests are not available in free version.. so to use sendgrid, Mailgun one needs to upgrade the plan. Thank you..

Just added a note for that. Thanks for pointing this out @coder3101


GH-34670: [Packaging][C++] Add support for customizing GDB plugin install directory

Rationale for this change
It's for conda package. We can't determine the final GDB plugin path on building. We can adjust the path by replacing a placeholder on installing.
What changes are included in this PR?
Conda package can specify a placeholder for GDB plugin path.
Are these changes tested?
Yes.
Are there any user-facing changes?
Yes.

Closes: #34670

@github-actions crossbow submit -g linux

@github-actions crossbow submit -g linux

@github-actions crossbow submit test-conda-python-3.10


Work?

Is this tool still work? i can't parser hotstar using this tool

As per https://github.com/Gotham25/hotstar-dl/issues/12 this no longer works.


Question: Combining results from lsp_refs , lsp_defs

Info
Hi, I think I asked this question before, now I'm trying to implement it.
I'm trying to reuse the code to query lsp results from fzf-lua but the function is not exposed
I have this so far.
      vim.keymap.set('n', 'gd', function()
        local lsp = require('fzf-lua.providers.lsp')
        lsp.definitions()
        -- lsp_typedefs = { "fzf-lua.providers.lsp", "typedefs" },
        -- lsp_references = { "fzf-lua.providers.lsp", "references" },
        -- lsp_definitions = { "fzf-lua.providers.lsp", "definitions" },
        -- lsp_declarations = { "fzf-lua.providers.lsp", "declarations" },
        -- lsp_implementations = { "fzf-lua.providers.lsp", "implementations" },
      end, opts)

Is it possible that we can expose those function or make it easier to reuse? Like exposing the functions those returning the results LSP only (not open fzf windows or something else), then I can combine them together and feed them to fzf_exec.

Operating System:
Shell:
Terminal:
nvim --version:
fzf --version:

[ ] The issue is reproducible with mini.sh

fzf-lua configuration

require('fzf-lua').setup({
})

Description

definitions is exposed publicly:
https://github.com/ibhagwan/fzf-lua/blob/15e9b1f1494dc1facaffe9543281d015c43b9eba/lua/fzf-lua/providers/lsp.lua#L373
but it’s not returning a simple set of results as your code suggests, it’s a bit more complicated with callback handlers (for the async option), your best bet is copying parts of the code and modifying it to woke shnc only and combine the items in one big table, or alternatively (but more complex), use the async method and keep the pipe open until all LSP callbacks from all your calls are complete.

alternatively (but more complex), use the async method and keep the pipe open until all LSP callbacks from all your calls are complete.

I think  this one would be ideal. Could you share with me which code should I copy from?

You'll have to follow this function, explore what it does and then copy the relevant parts:
https://github.com/ibhagwan/fzf-lua/blob/15e9b1f1494dc1facaffe9543281d015c43b9eba/lua/fzf-lua/providers/lsp.lua#L208

may I ask where can I reference the opts structure?

may I ask where can I reference the opts structure?

Opts is the table sent in the original call, i.e definitions({ <opts> }), I'm afraid you're gonna have to dig deeper into the code and lua of you want to make this work, copy-paste without a deeper understanding of where things come from won't work for your mission.

Is it possible that we consider this is a feature to add to fzf-lua? So instead of remembering 4 or 5 key mappings for lsp related actions like lsp_refs, lsp_defs, lsp_impls, lsp_typedefs, lsp_declarations, we only need to hit 1 key map to get all related information!

and in this code, you call all functions the same way: https://github.com/ibhagwan/fzf-lua/blob/main/lua/fzf-lua/providers/lsp.lua#L369-L387
How does it know which lsp query it needs to execute? The opts in those functions are the same with this default opts right?

okay I found
  ["references"] = {
    label = "References",
    resolved_capability = "find_references",
    server_capability = "referencesProvider",
    method = "textDocument/references",
    handler = location_handler
  },
  ["definitions"] = {
    label = "Definitions",
    resolved_capability = "goto_definition",
    server_capability = "definitionProvider",
    method = "textDocument/definition",
    handler = location_handler
  },
  ["declarations"] = {
    label = "Declarations",
    resolved_capability = "goto_declaration",
    server_capability = "declarationProvider",
    method = "textDocument/declaration",
    handler = location_handler
  },
  ["typedefs"] = {
    label = "Type Definitions",
    resolved_capability = "type_definition",
    server_capability = "typeDefinitionProvider",
    method = "textDocument/typeDefinition",
    handler = location_handler
  },
  ["implementations"] = {
    label = "Implementations",
    resolved_capability = "implementation",
    server_capability = "implementationProvider",
    method = "textDocument/implementation",
    handler = location_handler
  },

Is it possible that we consider this is a feature to add to fzf-lua? So instead of remembering 4 or 5 key mappings for lsp related actions like lsp_refs, lsp_defs, lsp_impls, lsp_typedefs, lsp_declarations, we only need to hit 1 key map to get all related information!

Maybe one day if I get in the mood and I’m bored but currently no plans to add yet more providers combining existing info.

and in this code, you call all functions the same way: https://github.com/ibhagwan/fzf-lua/blob/main/lua/fzf-lua/providers/lsp.lua#L369-L387
How does it know which lsp query it needs to execute? The opts in those functions are the same with this default opts right?

As I wrote above this is lua basics, fork the project, use it locally, change lines and you’ll figure it out, me feeding you question by question will get us nowhere.

I opened a PR for this in #671 . Could you help me take a look?

@sandangel, can you test the lsp_finder provider in the lsp_finder branch?
It's still WIP I have to add colors to the display and make async work but it's getting there, would love to have your feedback so I know this is on the right track.

Absolutely, let me try that branch later today. 🙏🙏🙏

@sandangel, this was completed in https://github.com/ibhagwan/fzf-lua/commit/5afd287adddeefed487e83b954212895b48f0783, you can customize it via setup under lsp.finder, see README#Default-options for all available settings, play around with it and lmk if this answers your need.

oh my god, you are so fast, I just pull the change and will try as much as possible today. Thanks a lottttt for giving this features 🙏🙏. Are you considering adding a post in reddit channel for new features updates? I really love to see this on neovim weekly news. 😀😀😀

oh my god, you are so fast, I just pull the change and will try as much as possible today. Thanks a lottttt for giving this features 🙏🙏. Are you considering adding a post in reddit channel for new features updates? I really love to see this on neovim weekly news. 😀😀😀

I probably won’t do it but feel free to customization the icons (or even without) and get some karma from it :)

Hi @ibhagwan , I think I ran into the first issue that I want to sort the order of result, for example the definition should go first, then reference. Can we change the order of providers config so the result from that provider will show first?

Actually I already thought of that, reconfigure the lsp.finder.providers table (as shown in the readme) and sort the providers any way yo wish.

Awesomeee. It works perfectly now. I will try it more for a few days and see. Thanks a lot.

@sandangel @ibhagwan Just want to say thank you for this feature!

Thanks @nyngwang

@ibhagwan Hi, firstly sorry for tagging you on a closed issue. I would like to know whether it is possible to do further customization. Currently, it's a common case that many different sources are pointing to the same destination, for example here the first four entries are all pointing to segment.py:8:18:

I would like to be able to merge all entries that lead to the same destination, so the information is more concise. About those tags decl,def,tdef,ref, etc, I would like to use one single char(and keep those distinguishable colors) for each of them after merge. (I know this part should better be put into a standalone issue if it's more complex than I think.) It will look like this:
D,d,t,r | segment.py:

@nyngwang, unfortunately not possible, this was done by combining providers in a generic way, the only processing possible is formatting one line (adding prefix), it is run async, there is no way to process the results with the awareness of the final result.

@ibhagwan Is it possible to customize the previewer of lsp_finder? That is I want to apply my custom previewer from #677. Currently, I have this:
diagnostics = {
  previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
  fzf_opts = { ['--keep-right'] = '' },
},
lsp = {
  previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
  force_uri = true, -- https://github.com/ibhagwan/fzf-lua/issues/336.
},
git = {
  previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
  status = { show_cwd_header = true },
  files = { show_cwd_header = true },
},

I thought it was:
setup {
  -- ..
  finder = {
    previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
  },
}

but it turned out to be this nested one inspired by the original PR line:
lsp = {
  previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
  force_uri = true, -- https://github.com/ibhagwan/fzf-lua/issues/336.
  finder = {
    previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
  },
},

but it turned out to be this nested one inspired by the original PR line. This is a little counter-intuitive since I would expect that if lsp.finder.previewer is not defined then lsp.previewer should be used.
.setup {
  lsp = {
    previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
    -- ...
    -- nested inside `setup.lsp`.
    finder = {
      previewer = function () return require('ningwang.utils.fzf-previewer-M') end,
    },
  },
}

You’re correct lsp.finder is the correct setting, you can also see the config path here:
https://github.com/ibhagwan/fzf-lua/blob/79c7c3480cc363b3d4ecdfcb8b56623d9decd570/lua/fzf-lua/providers/lsp.lua#L579


serviceworker.js & manifest.json not found

Gitea version (or commit ref):1.6.0
Git version:2.17.1
Operating system:ubuntu 18.04
Database (use [x]):

[ ] PostgreSQL
[x ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ x] No
[ ] Not relevant

Log gist:
https://gist.github.com/yarumair/090ea2332e8ef7f3cfa0412a783dbe0c

Description
Iam getting 404 both for  /manifest.json and /serviceworker.js.
I have setup gitea behind nginx proxy as:
server {
	listen 443 ssl;
	server_name xxx.xxx.xx;

	ssl_certificate /etc/letsencrypt/live/xxx.xxx.xx/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/xxx.xxx.xx/privkey.pem;

	client_max_body_size 0;

	location / {
		proxy_pass https://localhost:2052;
	}

	location ~ /\.ht {
			deny all;
	}

	access_log /var/log/nginx/xxx.xxx.xx.access.log;
	error_log /var/log/nginx/xxx.xxx.xx.error.log;
}

Following files/folders are placed here /var/lib/gitea/custom
robots.txt
public
templates
https

Following is the link for app.ini
https://gist.github.com/yarumair/74d4dfc14dac520f32903141b86d414d
No error at nginx level for this.

could you reproduce that on https://try.gitea.io

HI @lunny
Iam not sure i can do it. Since, i have done certain customization in app.ini and also using custom folder. Moreover iam running behind nginx as proxy. Not sure if this is possible to replicate on https://try.gitea.io.
On try.gitea.io both manifest.json and serviceworker.js are showing fine.
If you see my log there is one consistent error:
[...s/context/context.go:147 NotFoundOrServerError()] [E] GetRepositoryByOwnerAndName: repository does not exist [id: 0, uid: 0, owner_name: !api, name: 2.0]
which led me to believe that somehow Gitea is treating both the files as repository and searching for them.
So any pointers in right direction to debug are highly appreciated