No network in rancher created container

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Install rancher
Provision a single node cluster (Debian 10 installed from official ISO, install docker using the script provided by get.docker.io)
Deploy a random container
Open a shell in the deployed container and try access the internet

Result:
There is no internet. DNS is not resolving and other kinds of traffic doesn't go through too.
Other details that may be helpful:

This is not related to #14863. DNS settings have been checked.
The cluster node is behind NAT while the rancher server has public IP. Tried to put the server and the cluster node in the same LAN too and the result is the same.
If I deploy the container with host networking then everything works.
Already tried restarting everything, reinstalling the cluster node and the rancher server, the result is the same.
If I provision the cluster node with RancherOS (other things are exactly the same), I can get network in the container.
There seems to be something wrong with Calico:

Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "b09079334b4cddd985d53d8259f0fa12be94fa2855fa682df235577529586724" network for pod "test-6d97969476-hf7l6": NetworkPlugin cni failed to set up pod "test-6d97969476-hf7l6_default" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/

(There is some discussion on Calico logs like this on the internet, but I can't extract any useful information on my problem out of these webpages, and I'm relatively new to the k8s world, so hope you don't mind me asking here.)

calico/node is exited and all its logs are:

2019-08-22 08:27:16.606 [INFO][8] startup.go 244: Early log level set to info
2019-08-22 08:27:16.607 [INFO][8] startup.go 260: Using NODENAME environment for node name
2019-08-22 08:27:16.607 [INFO][8] startup.go 272: Determined node name: li-generic-0
2019-08-22 08:27:16.624 [INFO][8] startup.go 304: Checking datastore connection
2019-08-22 08:27:16.637 [INFO][8] startup.go 328: Datastore connection verified
2019-08-22 08:27:16.637 [INFO][8] startup.go 92: Datastore is ready
2019-08-22 08:27:16.641 [INFO][8] customresource.go 217: Error getting resource Key=ClusterInformation(default) Name="default" Resource="ClusterInformations" Revision="" error=clusterinformations.crd.projectcalico.org "default" not found
2019-08-22 08:27:16.642 [INFO][8] customresource.go 100: Error getting resource Key=GlobalFelixConfig(name=CalicoVersion) Name="calicoversion" Resource="GlobalFelixConfigs" error=the server could not find the requested resource (get GlobalFelixConfigs.crd.projectcalico.org calicoversion)
2019-08-22 08:27:16.665 [INFO][8] startup.go 524: CALICO_IPV4POOL_NAT_OUTGOING is true (defaulted) through environment variable
2019-08-22 08:27:16.665 [INFO][8] startup.go 769: Ensure default IPv4 pool is created. IPIP mode:
2019-08-22 08:27:16.669 [INFO][8] k8s.go 453: Attempt to 'List' using kubernetes backend is not supported.
2019-08-22 08:27:16.682 [INFO][8] startup.go 779: Created default IPv4 pool (<IP_ADDRESS>/16) with NAT outgoing true. IPIP mode:
2019-08-22 08:27:16.682 [INFO][8] startup.go 518: FELIX_IPV6SUPPORT is false through environment variable
2019-08-22 08:27:16.682 [INFO][8] k8s.go 262: EnsuringInitialized - noop
2019-08-22 08:27:16.685 [INFO][8] customresource.go 217: Error getting resource Key=ClusterInformation(default) Name="default" Resource="ClusterInformations" Revision="" error=clusterinformations.crd.projectcalico.org "default" not found
2019-08-22 08:27:16.699 [INFO][8] customresource.go 217: Error getting resource Key=FelixConfiguration(default) Name="default" Resource="FelixConfigurations" Revision="" error=felixconfigurations.crd.projectcalico.org "default" not found
2019-08-22 08:27:16.708 [INFO][8] startup.go 169: Using node name: li-generic-0
2019-08-22 08:27:16.752 [INFO][21] allocate_ipip_addr.go 43: Kubernetes datastore driver handles IPIP allocation - no op
CALICO_NETWORKING_BACKEND is none - no BGP daemon running
Calico node started successfully

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.2.8
Installation option (single install/HA): single

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory): Hyper-V VM, Debian 10, 4 cores, 6GiB RAM
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.9", GitCommit:"3e4f6a92de5f259ef313ad876bb008897f6a98f0", GitTreeState:"clean", BuildDate:"2019-08-05T09:22:00Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.6", GitCommit:"96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:16Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:21:24 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:19:56 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Exactly the same here. I created a new Rancher host on a Debian 10 box and another fresh Debian 10 cluster node. Containers can't see one another, not even within the same namespace and they can't connect to the internet either.

If you want a hassle free experience, the recommendation is to use the OS's listed in our docs as described here: https://rancher.com/docs/rancher/v2.x/en/installation/requirements/
For Debian 10, it defaults to iptables-nft which breaks compatibility with legacy iptables. The quickest solution is to default to legacy using:
update-alternatives --set iptables /usr/sbin/iptables-legacy

A reboot is probably necessary to have everything take effect. I think compatibility for k8s/CNI is being worked on or is already added, possibly needs some flags to activate it vs auto detection.

Thanks @superseb that did the trick!

This is working for me. Thanks @superseb !


Lean unstable

The problem seems to have started with my recent changes to https://github.com/htzh/leanproved/blob/master/group_theory/hom.lean. Editing the file in emacs lean mode causes lean to generate uncaught exceptions after almost every key stroke. Editing the subgroup.lean file does not seem to have any problem.
I am still on a two days old version of Lean due to issue #591. My build was without tcmalloc and without -DBOOST using: cmake -D CMAKE_CXX_COMPILER=g++.exe -DCMAKE_INSTALL_PREFIX=/usr/local/ -G Ninja ../src. I am mostly up-to-date with regard to MSYS2

I cloned your repository and have been editing your files for several minutes without problems.
Recent changes modified the format of .olean files. So, this may be the source of the problem.
The tool linja is supposed to detect when the lean binary has been updated and recompile everything.
However, there is a problem with this feature (see issue #575). It is not clear to me where the problem is.
@soonhokong is investigating the problem.
So, in the meantime, please try to clean all object files in your project directory. You can use the following command:
linja clean

The linja script is located at <path-to-lean>/bin/linja. It is in the same directory of the lean binary.

Unfortunately that didn't work for me. The message from the VS JIT debugger says:
Unhandled exception at 0x00432EAD in lean.exe: 0xC0000005: Access violation reading location 0x00000020.

Not sure if that means anything.

I rolled back my hom.lean to e881d37abefaa6370276a3b9dabffa7522a5f606 and Lean stopped crashing. So at least on my part it is triggered by the changes in hom.leam. Due to the build issue my lean is on version e2c1dc92a8f85afd2470e9032d50b1b5b54b5776

I'm puzzled. I have a machine with msys2 in my office. I will try to reproduce the behavior on Monday.

I separated out the section where I thought was problematic. I used to have a class instantiated and included later in the section. I wasn't sure that was legal but Lean accepted it. Now I put it in the beginning of its own section and the crashing seemed to have stopped. It could be entirely a coincidence though.

Change is also on github.
diff --git a/group_theory/hom.lean b/group_theory/hom.lean
index 82aa5e0..d88d22c 100644
--- a/group_theory/hom.lean
+++ b/group_theory/hom.lean
@@ -52,6 +52,15 @@ theorem hom_map_mul_closed (Hom : is_hom f) (H : set A) : mul_closed_on H → mu
         ... = b1 * f a2 : {and.right Pa1}
         ... = b1 * b2 : {and.right Pa2},
         in_image Pa1a2 Pb1b2
+end^M
+section^M
+variables {A B : Type}^M
+variable [s1 : group A]^M
+variable [s2 : group B]^M
+include s1^M
+include s2^M
+variable f : A → B^M
+variable Hom : is_hom f^M

 variable {H : set A}
 variable [is_subgH : is_subgroup H]

Disregard the last two messages. It still crashes but maybe less severely. I will wait for the build issue to resolve and check out the latest version of Lean and see if that helps.

@htzh, could you try the latest build? I just pushed a fix for #591. I still need to figure out the reason why this patch fixes the problem but I confirmed that the fix itself is harmless so it's safe to be pushed to the blessed.
Let me check #575 this evening. I also only have my Windows machine at the lab. To avoid a problem like #575, I do the following:
cd lean/library
git -fxd
cd ../hott
git -fxd

The above steps clean up lean/library directory and lean/hott directory. After running them, go to your build directory and build it again (just make or ninja). I'm not sure that this helps your problem but I can confirm that this clears up any issues with #575.

I can confirm that the build goes through fine now. Thanks Soonho! I was
still able to crash Lean but the impression is that it is less frequent
now. I will report if I see a pattern. What does everyone use here? Linux?
I have a Linux vbox. I am a bit leery of running GUI out of it. I can try
emacs out in terminal mode and see how that goes.
On Sun, May 10, 2015 at 4:02 AM, Soonho Kong<EMAIL_ADDRESS>wrote:

@htzh https://github.com/htzh, could you try the latest build? I just
pushed a fix for #591 https://github.com/leanprover/lean/issues/591. I
still need to figure out the reason why this patch fixes the problem but I
confirmed that the fix itself is harmless so it's safe to be pushed to the
blessed.
Let me check #575 https://github.com/leanprover/lean/issues/575 this
evening. I also only have my Windows machine at the lab. To avoid a problem
like #575 https://github.com/leanprover/lean/issues/575, I do the
following:
cd lean/library
git -fxdcd ../hott
git -fxd
The above steps clean up lean/library directory and lean/hott directory.
After running them, go to your build directory and build it again (just
make or ninja). I'm not sure that this helps your problem but I can
confirm that this clears up any issues with #575
https://github.com/leanprover/lean/issues/575.
—
Reply to this email directly or view it on GitHub
https://github.com/leanprover/lean/issues/593#issuecomment-100624439.

I tried to build on my ArchLinux vbox. The build went smoothly. But there is apparently something wrong with the install script:
CMake Error at shell/cmake_install.cmake:36 (file):
  file INSTALL cannot find
  "/home/haitao/lean/build/shell/CMakeFiles/CMakeRelink.dir/lean".
Call Stack (most recent call first):
  cmake_install.cmake:90 (include)

FAILED: cd /home/haitao/lean/build && /usr/bin/cmake -P cmake_install.cmake
ninja: build stopped: subcommand failed.

I can use the non-installed directory for now.

@htzh Could you provide the sequence of commands you used?

What does everyone use here? Linux?

 Any suggestions?

@htzh, could you let us know 1) the version of Arch Linux that you're using, 2) cmake version? I can try to reproduce the problem in a fresh Arch Linux VM this evening.
I remember a student of @avigad is adding Lean to the Arch Linux package repository. Is it up-do-date?

I am running emacs in a telnet (puTTY) into my vbox and now it is running fine. No crashing Lean. My MSYS2 version of Lean is pretty unusable right now on hom.lean. Amazingly emacs still works well in the terminal mode. However I am not very used to the terminal mode so I hope to get back to the gui soon when the Windows build is stable again.
@soonhokong I just updated vbox and archlinux (with pacman -Syu) so should be current.  cmake is at:
extra/cmake 3.2.2-1 [installed]

The install issue for Arch is very low priority for me. I am happy to run from the ~/lean/bin directory.

I am able to hobble along in a new section of hom.lean using my Windows emacs/lean and so far crash has not happened. So it appears it was somehow related to a particular section (the first section) of the file.

@htzh, I couldn't reproduce the error either. I downloaded an image of Arch Linux VM from osboxes.org. Then I did the following to install Lean:
pacman -S git cmake gcc gmp mpfr lua ninja python
git clone https:github.com/leanprover/lean
cmake -DCMAKE_CXX_COMPILER=c++ -DCMAKE_INSTALL_PREFIX=/usr/local -G Ninja ../src
ninja
sudo ninja install

Everything went well. FYI, it's 3.18.6-1-ARCH and has cmake-3.2.2.

@soonhokong , thanks for checking it out! I am okay with how it works for now. What I really want to know is if there is a simple way to run emacs in Windows while running Lean in vbox. I have set up a telnet server inside the vbox (only opens internally through vbox's internal network bridge feature). That is how I always used the vbox since its own terminal is no fun to use. Now in emacs we should be starting lean with some start-process cmd. If instead we can start-process a telnet (or anything that connects to a telnet port, which is just tcp) and has it run Lean inside the vbox I could be always using the Linux version of Lean instead of the Msys2 build. Do you think this is doable? Thanks a lot.

What I really want to know is if there is a simple way to run emacs in Windows while running Lean in vbox.

This is possible, but I don't think it's a good direction. We do have some Windows users and we will have more users, sooner or later. I think a natural direction is to fix the Unhandled exception problem so that you and other users can use Lean natively on Windows machines.
I will try to reproduce the problem on my Windows machine tomorrow.

@soonhokong I compiled lean using msys2. The whole library can be compiled without problems. I also managed to compile @htzh library without problems (using the command line):

However, when I open Emacs, nothing works. Every keystroke produces an error.
Here is error trace produced by linja.

Haito: do you get a similar error message?

@leodemoura I don't recall seeing the error trace, instead I got a window pop-up that says Lean has crashed and Windows would helpfully offer to start a JIT debugger since I have VS installed. My lean is compiled for release not debug so I couldn't see the symbol table to see what crashed.
The crashing was particular bad at the version of my file that I opened this issue with. I switched to Linux terminal mode for a while then I switched back to windows again. I was able to edit or interact with no crashing in a new third section at the end of file. I think I can still trigger crash if I merge the first two sections by cutting the the following (I just verified that the crash still does happen):
end
section
variables {A B : Type}
variable [s1 : group A]
variable [s2 : group B]
include s1
include s2
variable f : A → B
variable Hom : is_hom f

I compiled lean in release mode too. The error trace (in my previous message) is not produced by Lean, but linja. linja is a Python script (that invokes lean).
I removed the block you suggested, and I did not experience any crash on lean.
It seems I'm experiencing a different problem.
This is a tricky problem, could you please provide additional information?

Windows version (Vista, 7, 8, 8.1)? (I'm using Windows 8.1)
32 or 64 bits system? (I'm using 64 bits).
g++ version? (I'm using 4.9.1)

I'm also not using tcmalloc nor Boost.

I am using Windows 8.1 (auto updated to current). Windows is 64 bit but I use the 32 bit version of msys2/mingw-packages, so g++ is 32 bit generating 32 bit code.
$ g++ --version
g++.exe (Rev5, Built by MSYS2 project) 4.9.2

@leodemoura, I'll fix the python error this evening.
@htzh, was there any reason not to use 64-bit msys2 packages?

@soonhokong Not really. Just a hunch that most programs don't benefit much from being 64 bit other than making the image larger and pointers wider than needed. But if you think Lean can benefit from using 64 bit (maybe due to gmp or mpfr) or just for the benefit of having fewer variations it is not a problem to switch. I have both versions installed. It is just a question of which terminal I run in. I have more installed packages in 32 bit version but Lean has very few dependencies so that is not a problem. Do you prefer Python 3 as well?

@htzh, I would try the 64bit packages. Could you test that and let us know what you have?

Do you prefer Python 3 as well?

It should work on both Python2 and Python3.

I can build in 64 bit and it runs fine from the command line, but emacs does not work at all like @leodemoura said. Also Python 3 does not work for the build on mingw64, but Python 2 worked.
My error message in emacs says:
Suspicious state from syntax checker lean-checker: Checker lean-checker returned non-zero exit code 1, but no errors from output: [1/4] generating dep... \Users\haitao\proj\lean\proved\group_theory\flycheck_subgroup.d

The first python 3 failure came here, and then there are many cascading failures:
[353/354] cmd.exe /C "cd /D C:\alt\msys32\home\haitao\lean\hott && C:\alt\msys32\mingw64\bin\python3.4.exe C:/alt/msys32/home/haitao/lean/src/../bin/linja all tags"
[354/354] cmd.exe /C "cd /D C:\alt\msys32\home\haitao\lean\library && C:\alt\msys32\mingw64\bin\python3.4.exe C:/alt/msys32/home/haitao/lean/src/../bin/linja all tags"
FAILED: cmd.exe /C "cd /D C:\alt\msys32\home\haitao\lean\hott && C:\alt\msys32\mingw64\bin\python3.4.exe C:/alt/msys32/home/haitao/lean/src/../bin/linja all tags"

This is just FYI as I don't care which Python to use.

@htzh, thanks for the report. It's great to know that the use of 64-bit packages solved the build problem. I'll reproduce and fix the Python problem which @leodemoura originally reported.

@soonhokong just to be clear the build issue was solved since you fixed issue #591 and now both mingw32 and mingw64 build work (at least with python 2). Linja command line also works fine with both. The problem is when used with Emacs lean is unstable when built using mingw32 and not usable when built with mingw64 as reported.

@soonhokong sorry I didn't update you on #591 and when this issue started it was not fixed yet.

@soonhokong I did update the build issue earlier in this thread in response to your question https://github.com/leanprover/lean/issues/593#issuecomment-100656860 but I am sorry if you missed it. I should have cross-posted to #591.

@htzh, I think I got confused. So you don't have any problem in building/running Lean and the only problem is using it inside of emacs, right?
@htzh and @leodemoura, I can't reproduce the problem on my Windows machine. I can edit @htzh's hom.lean file on my emacs without a problem. Here are the versions of the components that I'm using:

GNU Emacs 24.4.1 (i686-pc-mingw32)
g++-4.9.2 (mingw-w64-x86_64)
python-2.7 (Windows native version), also worked with python-3.4 (Windows native version)

@leodemoura and @htzh, could you let me know the results of python --version and which python inside of eshell?

It is working for me now. It was a configuration problem. Everything works smoothly if I start emacs using bin/leanemacs.bat, and make sure my .emacs file does not mess the variables set in bin/leanemacs.bat.
I think a lot of the confusion is because linja does not terminate gracefully when it gets input that is not in the expected format.
Regarding this question

@htzh, I think I got confused. So you don't have any problem in building/running Lean and the only problem is using it inside of emacs, right?

I believe his previous problem was fixed after he used the 64-bit MSYS2 to compile Lean.

@soonhokong so there is a binary interface to Python? I see what is going on here, at least on my side: when I switched over to 64 bit built lean, I was still using 32 bit python in emacs. So I modded the the paths inside emacs now the 64 bit version no longer crashes. I will see if it is stable. This does not (yet) explain the 32 bit build instability.
My emacs is a standard windows native binary distro from GNU. mingw32 or 64  are not in my Windows PATH. They are set up automatically depending on which MSYS2 terminal I use. Emacs does not know about the existence of these and I have to put the correct path in site-start.el or init.el. So that is where the confusion comes from. @leodemoura  may have a similar problem.
Do you use system Python? Might be a good idea to pick the Python cmake found and used to build Lean and use that one inside Emacs as well. Could that configuration be built into cmake? You know people tend to have multiple versions of Python around. Some software even package their own Python.

This does not (yet) explain the 32 bit build instability.

BTW, it is not even clear to me whether 64-bit Windows + 32-bit MSYS2 is supposed to work.
This is not the standard way of building 32-bit binaries using MSYS2.
The MSYS2 website explicitly says one should use 64-bit MSYS2 with a 64-bit Windows.
Moreover, 64-bit MSYS2 can generate 32-bit binaries.

Reference for previous claim:
http://sourceforge.net/p/msys2/wiki/MSYS2 installation/

@htzh In the Lean website, we provide a zip file with the pre-compiled binaries for Windows.
http://leanprover.github.io/download/wininst.html

The zip file is updated everyday IF
1- There new commits
2- The compilation succeeds, and the binary passes all tests

@soonhokong @leodemoura just so we are on the same page, this is the sequence of event on my side:

There was a build problem #591
There is also an emacs crashing lean server problem, which is reported in this thread, config mingw32 build and python
build problem in 1 was fixed by the patch in #591, both mingw32 and mingw64 build now.
mingw32 build is unstable; mingw64 build crashed on my machine due to a misconfiguration of Python
mingw64 build appears to work once the correct Python is picked inside emacs

The MSYS2 website explicitly says one should use 64-bit MSYS2 with a 64-bit Windows.

I haven't had a problem with using the 32 bit msys2 and building apps using mingw32 before. Again there is a confusion of terminology: Msys2 comes in 32 bit and 64 bit flavors but that is just the shell. The toolchains and packages are separately installed as mingw32 or mingw64. So I don't think this is the cause of my problem. But I accept that my configuration is non-standard. I will happily use the mingw64 build of Lean if it is stable.

Just to be clear: mingw32 refers to mingw-w64-i686 packages, mingw64 refers to mingw-w64-x86_64 packages. MSYS2 itself depends on cygwin dll so packages with msys prefix are not windows native. mingw32 and mingw64 packages are windows native and they are used to build native apps.

@htzh,

@soonhokong so there is a binary interface to Python?

No. Lean's emacs-mode calls linja which is written in Python.

Do you use system Python?

I'm using the one that we can download from https://www.python.org/downloads/windows

@leodemoura,

I think a lot of the confusion is because linja does not terminate gracefully when it gets input that is not in the expected format.

I'll add code to handle corner cases in linja.

@htzh In the Lean website, we provide a zip file with the pre-compiled binaries for Windows.
http://leanprover.github.io/download/wininst.html

That would still require the matching of the correct Python right? That is if your binary distro is built for 64 bit then the system Python picked in emacs must also be the 64 bit version. You might want to make that clear on the website.

No. Lean's emacs-mode calls linja which is written in Python.

That is interesting! I am seeing dependence on which Python I use:

Python 3 does not build with mingw64 but Python 2 works.
mingw64 build crashes (in emacs) if using 32 bit Python but 64 bit Python works.

@htzh I'm confused... the MSYS2 website (http://sourceforge.net/p/msys2/wiki/MSYS2 installation/) provides two links 32-bit and 64-bit. It says one should use the 64-bit one for 64-bit Windows even if they want to build 32-bit binaries. Which one did you install?

So I don't think this is the cause of my problem. But I accept that my configuration is non-standard.

For me, this is the most probable explanation.
I don't have a 32-bit Windows machine to test, but I believe the 32-bit tool chain will work on a 32-bit Windows.
I have tested the 32-bit version on a Linux 32 bit VM, and did not find any problem. I tested 32-bit Lean using valgrind, and it did not report any problems in the Lean source code.
I see the following alternatives
1- use the pre-compiled Windows binaries from the Lean website
2- compile lean using the standard toolchain
I don't have the resources to support non standard configurations (e.g., 64-bit windows with 32-bit toolchain). If you want to do it, you will be very welcome, and I would be very grateful.

@htzh,

That would still require the matching of the correct Python right?

No. If there is any combination which does not work, it's a bug and I want to fix it. I just couldn't reproduce the previous one and it turned out that I was using the right combination.

Python 3 does not build with mingw64 but Python 2 works.
mingw64 build crashes (in emacs) if using 32 bit Python but 64 bit Python works.

I want to clarify the combinations which gave you problems. When we agree then I will reproduce them and fix them.

Native 64-bit Python3 + Lean built by using mingw64
Native 32-bit Python? + Lean built by using mingw64

Could you fill the 2nd item above? Also, please feel free to add extra items to the list.

@leodemoura I am fine with using the standard configuration. I am sorry to have caused what appears to be a wild goose chase. I will only report issues with the standard configuration from now on.
My problem appears to have been caused by using the mingw distributed Python (installed using pacman). I have switched to using Python distributed by python.org and the problem seems to have gone away with both mingw32 or mingw64 built Lean.

@htzh I'm confused... the MSYS2 website (http://sourceforge.net/p/msys2/wiki/MSYS2 installation/) provides two links 32-bit and 64-bit. It says one should use the 64-bit one for 64-bit Windows even if they want to build 32-bit binaries.

I have the 32 bit installer. The reason I don't believe it caused my problem is that the 32 bit here (if I remember correctly since I installed this long time ago and kept my system up-to-date using pacman) refers to the shell only, not the toolchain. There are 4 possible combinations: msys32/mingw32, msys32/mingw64, msys64/mingw32, msys64/mingw64. I have the first two combinations but toolchains are all native. I agree this is not the standard and from now on I will only report issues if it can be reproduced under msys64/mingw64 combination.

My problem appears to have been caused by using the mingw distributed Python (installed using pacman).

I think this is problematic. I just changed the instructions in https://github.com/leanprover/lean/commit/651345a89bb7df252cc60362a3fdb165a92810f0.

I have the first two combinations but toolchains are all native.

By this I mean that it does not matter whether you have msys32 or msys64 you are running the same gcc/g++ packages. There is only one mingw64 g++ binary distribution and you are running the same one whether you have msys2 32 bit or 64 bit installed. The difference is that under msys32 bash is 32 bit while under msys64 bash is 64 bit. This was what the MSYS2 website warned about. This only affect programs in /usr/bin which are not native. The choice here does not affect native programs under /mingw32 or /mingw64. But just to be absolutely sure, I have downloaded the 64 bit msys2 installer and will install a fresh copy of msys64/mingw64.

I have fresh started a new msys64/mingw64 to be on the safe side. It built Lean as expected. But lean.exe immediately crashed in Emacs. I also downloaded a binary distribution of lean from Lean website and it worked fine with Emacs. To find out why, I compared the DLL dependencies of the binary release and my own built lean:
# from Lean website
$ objdump.exe -x ~/w/proj/pkgs/lean-0.2.0-windows/bin/lean.exe |grep "DLL Name"
        DLL Name: libgmp-10.dll
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: libwinpthread-1.dll
        DLL Name: libgcc_s_seh-1.dll

$ objdump.exe -x /c/alt/msys64/usr/local/bin/lean.exe |grep "DLL Name"
        DLL Name: libgmp-10.dll
        DLL Name: lua53.dll
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: libwinpthread-1.dll
        DLL Name: libgcc_s_seh-1.dll
        DLL Name: libstdc++-6.dll

Note that the Lean built on my system has additional dependencies on lua53.dll and libstdc++-6.dll. It is surprising that the binary distribution of Lean also depends on many non-windows DLLs. In general there may be many versions of these DLLs lying around. For example on my system after I remove /mingw64/bin from PATH in a mingw64  shell I can still find the following:
$ which libgmp-10.dll
/c/alt/MinGHC-7.8.3/ghc-7.8.3/mingw/bin/libgmp-10.dll
$ which libwinpthread-1.dll
/c/alt/coq-bundle/bin/libwinpthread-1.dll

so the Lean binary distro was able to run without /mingw64/bin in the PATH, but my own binary crashes without it. I don't know why Windows does not show the traditional "DLL not found" message and instead just let Lean crash.
Anyway after I ensured in Emacs I have the right PATH setting:
           (setenv "PATH"
		   (concat "c:/alt/Python34" ";"
			   "c:/alt/msys64/mingw64/bin" ";"
			   (getenv "PATH")
			   ))
	   (setq exec-path
		 (append '("c:/alt/Python34"
			   "c:/alt/msys64/mingw64/bin")
			 exec-path))

now my own built binary also works with Emacs. This still does not explain everything but at least it seems reasonable enough so I won't pursue this matter further.

As it turns out this saga continues. As I perform the test of merging two sections https://github.com/leanprover/lean/issues/593#issuecomment-100985467 my own built Lean binary crashed again, but the binary from Lean site works. As I have made sure the environments are the same for the two, I am guessing the difference is due to DLLs bundled with the Lean binary distro: my own build depends on lua53.dll libstdc++-6.dll of my local mingw64 while Lean binary distro uses its own. As I said my build was with all fresh msys2 (64) and mingw64.

I can crash the binary distro from the website as well using the same cut test. It is not 100% reliable but it is fairly reliable. Okay so my own build and the binary distro behave about the same. The sad part is both crash.

I can crash the binary distro from the website as well using the same cut test. It is not 100% reliable but it is fairly reliable. Okay so my own build and the binary distro behave about the same. The sad part is both crash.

On my side, I downloaded the binary distro on a different machine, and edit your file for 30 min, I cut the block you pointed several times. I experienced no crash.
I started emacs using the leanemacs batch script in the binary distro.
Details:

I put the binary distro at C:\lean-0.2.0-windows
Python 2.7.8
Emacs <IP_ADDRESS>

Yesterday, you said the binary distro was working. What did it change? When did you start experiencing the crashes again?
Have you tried to compile Lean in debug mode?
Another experiment, in Emacs, go to the menu "Lean > Configuration". There are two check boxes: "Use flycheck (on-the-fly syntax check)" and "Show type at point".
First, disable "Show type at point", and try to reproduce the crash. If you have time, it would be useful to try other configurations.

Yesterday, you said the binary distro was working.

Sorry that was not clear. My build would not start at first but the binary distro would. That is when I thought it worked. Later on after more testing that turned out to be a premature judgement. There are so many possible combinations to check and it is triggered in the UI so I am sorry if some reports are not consistent.
I normally run emacs directly but I just tried leanemacs.bat from the binary distro as well. I tried starting it in a command prompt or from a mingw shell. I also removed my normal init.el. I tested Python 2.7.8 (32 bit) and Python 3.4.3 (64 bit). I tried turning off flycheck and type-at-point. I was still able to crash Lean.
If this is not reproducible by anyone else I can live with the current state since Emacs auto starts the Lean server after a crash. I am not equipped to debug UI issues. I will report again if I can find a non-UI based case or if the crashes happen so often as to be intolerable.

I tried turning off flycheck and type-at-point. I was still able to crash Lean.

@soonhokong I thought that Lean would not even be invoked when flycheck and type-at-point are disabled. Is that right?
@htzh When you say "crash Lean", I'm assuming you referring to lean.exe.

If this is not reproducible by anyone else I can live with the current state since Emacs auto starts the Lean server after a crash.

It seems the lean-sever process is the one crashing. This is not the process created by flycheck.
@soonhokong Do you think it is possible the lean-server process is "silently" crashing on our machines and being restarted? Do you generate a message whenever the lean-mode restarts the lean-server?

When you say "crash Lean", I'm assuming you referring to lean.exe.
Yes. It has always been a Windows popup with the standard message "lean.exe has stopped working A problem caused ......"

@soonhokong I thought that Lean would not even be invoked when flycheck and type-at-point are disabled. Is that right?

No. When we edit a Lean buffer, it sends changes to lean-server to synchronize.

@soonhokong Do you think it is possible the lean-server process is "silently" crashing on our machines and being restarted?

I'm not sure. It is possible. But, I guess you do also have Visual Studio installed, right? I don't understand why you don't get the VS debug pop-up while @htzh gets one.

Do you generate a message whenever the lean-mode restarts the lean-server?

Yes. See https://github.com/leanprover/lean/blob/master/src/emacs/lean-server.el#L241-L242 When we want to get a server process and failed to do so because a server process is not live. We force to restart it and log it to `Messages buffer.
@htzh, when you visit *Messages* buffer, do you see a string starting with "lean-server-get-process"?

I'm not sure. It is possible. But, I guess you do also have Visual Studio installed, right? I don't understand why you don't get the VS debug pop-up while @htzh gets one.

I believe there is a configuration in the registry to disable/enable this behavior.
This is probably disabled on my machine. I will try to find out.

when you visit Messages buffer, do you see a string starting with "lean-server-get-process"?

No I don't see the message but it seems to get restarted anyway since I can repeatedly trigger the same problem.

I pushed the hom.lean I tested on to github. It has one line difference (a comment) from the previous HEAD.

@htzh,
Could you provide a up-to-date list of combinations which you have problems? I wish to have the following information for each entry:

Lean binary: Download from the webpage / Built by yourself using mingw (if so g++ version with 32/64-bit info)
Python version : Native Windows / mingw ; 32-bit / 64 bit ; Python2 / Python3
Problem: In the build process / In Emacs

Of course, you don't have to provide a complete list. Just let us know couple of them. Some screenshot would be useful as well. Thank you.

@soonhokong
Problems are always in Emacs. No command line problems so far. Problems with both binary download and my own build (mingw 64, g++ 4.9.2) and Python 2.7.8 or 3.4.3 from python.org.
I tried an earlier version of my hom.lean 8c69a1caa34e6f3a70c6da8bb913ab1f610c66a5 I can reliably trigger the crash even easier by just pressing return after the "sorry" on line 31 (with the web download binary).

@htzh, thanks for the info. I'll check them this evening.

@htzh @soonhokong I managed to reproduce the crash. I believe it happens in all platforms, but we never noticed because lean-mode silently restarts the lean-server whenever it crashes.
In @htzh system, the VS debugger is automatically invoked when an application crashes. This is why it experienced the bug. On his Linux machine, lean-server is also probably crashing, but he doesn't see it.
The bug is in the lean-server, this is the tool used to provide typing information and auto-completion to Emacs. This is why we never managed to reproduce the crash using the command line tools.
Here is the "recipe" to reproduce the crash using the command line:
1- Clone https://github.com/htzh/leanproved
2- git checkout 8c69a1caa34e6f3a70c6da8bb913ab1f610c66a5
3- Go to directory leanproved/group_theory, and compile the whole project using linja
4- Create the file trace.input with the following content
VISIT hom.lean
WAIT
INSERT 32

REPLACE 31
lemma ker.has_one (Hom : is_hom f) : 1 ∈ ker f := sorry
WAIT

5- Execute
lean --server-trace trace.input

Then, we get the following output:
-- BEGINWAIT
-- ENDWAIT
-- BEGINWAIT
Segmentation fault (core dumped)

@leodemoura Glad you are able to reproduce. Thanks.

@htzh I found and fixed a problem in the lean-server background process. At least, the "recipe" in my previous message does not trigger the crash anymore.

Yes I can confirm that it no longer crashes at either reported trigger points. The bug appears to be fixed. I will report if I see other incidences of crashing.

@leodemoura, great! Thanks for solving the problem!!

I'm closing this issue, we can reopen it if we find other problems.

Yes I can confirm that it no longer crashes at either reported trigger points. The bug appears to be fixed. I will report if I see other incidences of crashing.

@htzh Thank you for insisting this issue was a bug. At several points, I doubted you, and I apologize for that. Without your persistence, this bug would probably remain there for a very long time.
Thanks!

@leodemoura Thanks for your gracious acknowledgement. At moments I doubted myself too. After getting bitten by some false starts I did spend a lot of time and effort trying out different combinations to double check what I reported. It is impressive how quickly you were able to fix it after you were able to reproduce the bug.


Where should I include the license notice ?

Hi, maybe stupid question but should the license notice be included in the source code of the project or added to emails sent with this template ?
Best regards,

"The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software."

The software in this case is an "Email template repository", not the email derivatives you create from it.
So if you fork the project, you should keep the MIT license in the source code repository only.

@webketje got it. thank you for taking the time to answer ;)


feat(resizer): Add support for maxWidth and maxHeight

This PR adds a new feature to the Node-Resizer to restrict the maximum Width and Height a node can be resized to.

Awesome thanks, so I'm going to close this PR.


add social media links to temp pombase2 front page

We will be doing some posting to coincide with conference start...

I've added a link to Twitter and to the Facebook page.  There's no fancy formatting yet but it's a start.

and pombelist
we will have a bit of a membership drive at the meeting...
good to have it in a prominent place
http://listserver.ebi.ac.uk/mailman/listinfo/pombelist
(we could do with a little icon for this!)

I've added the mailing list.  Tomorrow I'll dig up some little icons for the three links.

Tomorrow I'll dig up some little icons for the three links.

I've added icons.  Any suggestions about formatting or headers?

I think the text can be cut to
[bird icon] Twitter
[f icon] Facebook
[mail icon] Mailing list

I think the text can be cut to

I've done that.

Perhaps also:

Move the "contact curators" link down one row so that it is grouped with the other links
change the text to "contact"
use the mail icon with the "contact" link, and change the mailing list icon to something like this

or this,  quick mock-up...
maybe no text as it would be to small, but somthing to make it clearer its a mailing list about pombe...

Move the "contact curators" link down one row so that it is grouped with the other links
change the text to "contact"

I think the contact curators link should stay as it is, Its a bit different from the others....
But the other links can be just icons in a row as they are on the old front page.
Can add  linked in, google and Github (why not let users/funders see what we are doing/participate ...
WormBase  and GO use GitHub as their help desk now....).
Can we make "curation" a default pinned repository as this one is most the relevant for the community?

Github
we have nothing to hide except my typos....must try harder...

or this, quick mock-up...

It's quite tricky to make it clear when it's so small, but I've had a go.
I've also added icons and links for GitHub, Google+ and LinkedIn.

But the other links can be just icons in a row as they are on the old front page.

Done.

Can we make "curation" a default pinned repository as this one is most the relevant for the community?

That's done too.

But the other links can be just icons in a row as they are on the old front page.

I had never noticed those icons before.  Perhaps the could be a bit more prominent in PomBase v2?

I think this is done so I'm closing it.


Add multi clouds multi platform cost comparator

Abstract the workload to serverful and serverless, all clouds has these types of workloads


Improve the text at the top of the home page

Received the latest home page text from the product team.

ok


Do not use pkg.exports field

pkg.exports field does not work with tsconfig.moduleResolution === 'node'. Therefore, this field should not be used.

tsc can handle pkg.exports if moduleResolution === 'bundler' or moduleResolution === 'Node16'. And these days it is best practice to use either of these values instead of 'node'.
Given that, we may not need support for 'node'.


[BUG] Typer.style fails in Windows Powershell with colorama installed

Describe the bug
I tried to print red text in powershell on Windows. However, it just  printed with escape symbols instead. This is with colorama installed and if i manually initialize colorama the colors works as it should.
To Reproduce
Reporduce non-working version:
import typer
def main():
    print(typer.style("RED", fg=typer.colors.RED))
if __name__ == "__main__":
    typer.run(main)

Outputs:
RED

With manual colorma init:
import typer
import colorama
colorama.init()
def main():
    print(typer.style("RED", fg=typer.colors.RED))
if __name__ == "__main__":
    typer.run(main)

Ouputs, in red text:
RED

Expected behavior
As it in the documentation, https://typer.tiangolo.com/tutorial/printing/#color,  is stated that you don't have to manually initialize colorama I expected the first to work.
Environment

OS: Windows
Typer Version: 0.1.1
Python version: 3.7.2

So, for all the Colorama Windows magic to work you have to use typer.echo() instead of print(), like:
import typer
def main():
    typer.echo(typer.style("RED", fg=typer.colors.RED))
if __name__ == "__main__":
    typer.run(main)

Thank you! I must haves missed this.


Allow adding an index to a table created in the same migration

Allow the create_index operation to add an index to a table that was created by an operation earlier in the same migration.
The following migration would previously have failed to start:
{
  "name": "43_multiple_ops",
  "operations": [
    {
      "create_table": {
        "name": "players",
        "columns": [
          {
            "name": "id",
            "type": "serial",
            "pk": true
          },
          {
            "name": "name",
            "type": "varchar(255)",
            "check": {
              "name": "name_length_check",
              "constraint": "length(name) > 2"
            }
          }
        ]
      }
    },
    {
      "create_index": {
        "name": "idx_player_name",
        "table": "players",
        "columns": [
          "name"
        ]
      }
    }
  ]
}

As of this PR the migration can be started.
The above migration does not validate yet, but it can be started successfully with the --skip-validation flag to the start command.
Part of https://github.com/xataio/pgroll/issues/239

This can be closed now: https://github.com/xataio/pgroll/issues/203

This can be closed now: #203

I think we can't close it yet. The migration in the PR description still requires --skip-validation to work. Validating the migration is something still to be done.


Accepting suggestion/completion with tab is removing completion suffix

Description
Accepting suggestion/completion with tab is removing completion suffix.
Example
Given
| is cursor
const obj = {
	foo: 1,
	bar: 2,
	jar: 3,
};

for (const { foo, |bar } of obj) {
	console.log(foo, bar);
}

Typing in j and accepting completion jar results in jarbar in 1.85.1, now it results in jar (bar is removed).
Behavior in 1.85.1
https://github.com/microsoft/vscode/assets/16353531/2d6be151-fcaa-4381-be75-d28078424d92
New behavior
https://github.com/microsoft/vscode/assets/16353531/212a1696-9785-428b-bdae-54e2fdab9309
Info
Version: 1.86.0-insider
Commit: fb769554405bee9be16e21ceb0a496bd29126941
Date: 2024-01-09T10:06:54.001Z
Electron: 27.2.1
ElectronBuildId: 26149897
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 23.2.0
TS 5.3.2

Unsure if this is a bug and changed (the 2nd video has a different code sample) but debugging shows that insert and replace ranges are about replacing the current word.

Reproed with the same code:
https://github.com/microsoft/vscode/assets/16353531/0e9dbe8e-07ac-4446-a9fc-f8daf7b585dc
/*---------------------------------------------------------------------------------------------
 *  Copyright (c) Microsoft Corporation and GitHub. All rights reserved.
 *--------------------------------------------------------------------------------------------*/

const example = {
	foo: 1,
	bar: 2,
	jar: 3,
};

for (const { foo, |bar } of [example]) {
	console.log(foo, bar);
}

isn't this just a editor setting?
completion.replace vs insert or something

isn't this just a editor setting?
completion.replace vs insert or something

I copied my current settings in insiders to stable and still behavior was different between them.

This happens on an empty profile, and does not require actually accepting the suggestion (see my linked issue)


401 Unauthorized when streaming

I'm getting a 401 error, but only when using the StreamListener. Normal API calls work fine.
My Twitter account is set to the same timezone as my dev machine, and I still get 401 errors when I run my code on Heroku's servers. What gives? Is Tweepy still hitting v1 API endpoints?

I am having the same issue and troubleshooting for 2 days now. As you mentioned timezone is not the issue, and i've tried it with keys proven to work.

Same issue here. Unable to figure out.

I was able to figure out the issue after days of debugging. Turns out this is related with the way I read the keys from the property file. Somehow python inserted a subtle ' character to the beginning and end of the keys.
What lead me to the wrong direction is that this was not immediately obvious for some reason (caching mechanism?) on Twitter side.

Doesn't seem to be the case with me. Since Auth Handler object is getting instantiated. In my case too, normal api calls work fine. But Streaming doesnt.

I did manage to figure out the issue. Mine was indeed a timezone issue. I had change the timezone on my ubuntu machine but didnt sync ntp. Once I did that, everything started working fine. Thanks for your help though :) @theandrewchan If your issue is still unresolved, you might wanna give a try at this.

I had the same issue with an IOT device. Somehow the time-of-day on that system got offset by about 2h20min. When I set it back to the correct time (actually sync'd to ntp pool) it started to tweet again.

Same here, the time was off by 5 minutes and i got 401 errors.

been trying on and off for about a year... never once had it working

still the same

I switched to python-twitter, you may want to try that instead.

I'm unable to reproduce this, and this is likely just the response from Twitter rather than an issue with Tweepy. Can you provide a MCVE/SSCCE?
The description of a 401 error code from the API documentation:

HTTP authentication failed due to either:

Invalid basic auth credentials, or an invalid OAuth request.
Out-of-sync timestamp in your OAuth request (the response body will indicate this).
Too many incorrect passwords entered or other login rate limiting.

For more information, see https://developer.twitter.com/en/docs/tweets/filter-realtime/guides/connecting and https://developer.twitter.com/en/docs/basics/authentication/guides/authorizing-a-request.
Double check that your credentials are valid and that your system clock is in sync with NTP.

Hie, am also facing the same issue , i tried it on another machine and it worked but on my machine it its not working

I faced similar issue,my solution to get the output was:
a. check ntp- with system clocked using timedatectl and verify the timesyncd and system clock is synced
b. check the key format you entering
c. if using a third file do check it consist in the same file...common but i made that issue
check this is have issue with timedatectl:https://www.digitalocean.com/community/tutorials/how-to-set-up-time-synchronization-on-ubuntu-18-04

Anybody else getting this same error again? Currently running a tweet-streaming Python script on a GCP VM and getting 401s.
Batch, non-streaming API calls work fine. So auth is fine. And the script works when I run it from my local machine. So at this point my best guess is that it's a timing issue related to the VM. Does that sound plausible?

Anybody else getting this same error again? Currently running a tweet-streaming Python script on a GCP VM and getting 401s.
Batch, non-streaming API calls work fine. So auth is fine. And the script works when I run it from my local machine. So at this point my best guess is that it's a timing issue related to the VM. Does that sound plausible?


Fix default branch for GitHub Actions workflows

Just realized the default branch on #181 was not the correct one.
This PR fixes this.

D'oh! You know I noticed that the first time I looked through, but by the time I came back to it that slipped my mind. Good catch.


Add IpAddressType property to elbv2.

This was announced in:
https://aws.amazon.com/about-aws/whats-new/2017/04/aws-cloudformation-adds-support-for-amazon-cognito-ebs-elastic-volumes-and-updates-resource-coverage/

Thanks!


docs: move code outside of region tags required to run samples into r…

…egion tags
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

@nareshqlogic looks reasonable to me, although looks like you might have a linting issue locally and some sample test issues, to address the linting issue try:
rm -rf package-lock.json
rm -rf node_modules
npm i
npm run lint
npm run fix // if there are errors above.

Let me know if you need any help digging in to the linting issues.

I had run npm run fix, but must've not gotten it all.
Ooops was testing on my Dialogflow agent, which had a different response.

@bcoe, I'm not sure what the docs failure is.


Add support for a generic application-wide header and footer in the dashboard

Support generic application-wide header and footer in the dashboard

once header and footer is configured they will render on very page of the dashboard application
only SkillTree dashboard admins will be able to configure these items
add ability to input html for header, footer and associated styles on the Global Settings page (/settings)

design idea: have 3 input boxes: header that takes html, footer that takes html, css that applies to header and footer
design idea #2: 2 input boxes that will have inline styles

Consider creating new Navigation item on /settings page (especially if we go with three input boxes)
Validate that <script> tab is NOT supplied (both client and server)
Implement extensive Cypress Tests and applicable backend integration tests

mistakenly created in the wrong project


Gh 1524 timeline events participants

Summary
Timeline events for add/remove participants.
Service functions AddParticipantsand RemoveParticipants have change to trigger timeline events:

we keep already existent event type user_joinedleft if it's participate/leave run flow
we use participanmts_changed new timeline event when we add/remove users

RHS Timeline item has been refactored to handle more complex literals. summary/summarytitle for user_joinedleft moved from server to webapp (to be translatable and consistent).
Added several

added one

remnoved one

participate & leave

Ticket Link
Fixes https://github.com/mattermost/mattermost-plugin-playbooks/issues/1524
Checklist

[ ] Telemetry updated
[ ] Gated by experimental feature flag
[ ] Unit tests updated

Nice! 🎉 I left just a few non-blocking comments.

I forgot to push the last commit which cover some of your points. Will check the rest of them

Looks good visually but I think I spotted a bug. Whenever I add someone to a run, the timeline event shows as I joined the run.
bScreen.Recording.2022-11-02.at.2.47.37.PM.mov

You're right. I introduced an important error when I merged the simplification. Last minute change :(.
It's fixed now


QUIT on drop

Now the user should issue QUIT manually and I think that should be automated. I suggest implement Drop trait and issue quit on drop and probably make the function private.

I think this would be a great improvement, but why make the quit function private? It may be a good idea to leave it around if a user wants to manually quit.

If we leave it public then we should track if the user issued it already and that is one more field in FtpStream struct. But that is not really a big deal.

+1 to have imp Drop for FtpStream do the QUIT. However, this is a breaking change, so if we take this road there might be other breaking changes that may be worth doing. For instance I see that the return type of simple_retr is Result<Cursor<Vec>>, I would propose that we change it to Result<Vec> (the user can create the cursor if she wants to).

To add to this (perhaps a bit late), the purpose of making the quit function private is two-fold:

It's consistent with other rust types in the standard library.  Note the lack of a close() function on sockets or files.
It prevents the user from calling quit multiple times by accident.  Let the compiler handle the cleanup.  The borrow checker can handle this for you.

One last option would be to decorate quit() with a:
#[deprecated(
    since = "4.0.0",
    note = "This function is now a no-op.  quit is implicitly called on drop"
)]
pub fn quit(&mut self) {}

and move the actual implementation to Drop.  This would warn the users, but keep probably 90% of the existing code working.

To add to this (perhaps a bit late), the purpose of making the quit function private is two-fold:

It's consistent with other rust types in the standard library.  Note the lack of a close() function on sockets or files.
It prevents the user from calling quit multiple times by accident.  Let the compiler handle the cleanup.  The borrow checker can handle this for you.

One last option would be to decorate quit() with a:
#[deprecated(
    since = "4.0.0",
    note = "This function is now a no-op.  quit is implicitly called on drop"
)]
pub fn quit(&mut self) {}

and move the actual implementation to Drop.  This would warn the users, but keep probably 90% of the existing code working.


Nodes not removing when changing route if you interact with an input

Version
2.6.14
Reproduction link
https://codepen.io/edulavin/pen/LYyVMqO
Steps to reproduce
Open the codepen in debug mode and the performance monitor in Chrome Devtools
Write something in the input in Component 1
Click on the button to go to Component 2
Force the GC in the Chrome Devtools
Get back to Component 1
What is expected?
Nodes reduce to the previous value
What is actually happening?
Nodes count remains the same and if you go back to component 1 the node counts double in size. If you repeat the process the node count keeps rising

Can't reproduce

You have to open it in debug mode, otherwise the DOM Nodes counter doesn't work properly.

Can't reproduce

You have to open it in debug mode, otherwise the DOM Nodes counter doesn't work properly.


Set total number of batches in progress bar while testing

Now progress bar doesn't show total number of batches in test mode. This PR fixes it.

Yeah, here is a dummy example:
from time import sleep
import torch
from torch.utils.data import DataLoader, Dataset

import pytorch_lightning as pl

class DummyDataset(Dataset):
    def __init__(self):
        super().__init__()

    def __len__(self):
        return 10

    def __getitem__(self, idx):
        return torch.rand(1)

class CoolSystem(pl.LightningModule):
    def __init__(self):
        super(CoolSystem, self).__init__()

    def forward(self, x):
        return 0

    def training_step(self, batch, batch_nb):
        return {}

    def test_step(self, batch, batch_nb):
        sleep(1)
        return {}

    def test_end(self, outputs):
        return {}

    def configure_optimizers(self):
        return []

    @pl.data_loader
    def train_dataloader(self):
        return []

    @pl.data_loader
    def test_dataloader(self):
        return DataLoader(DummyDataset(), batch_size=1)

model = CoolSystem()
trainer = pl.Trainer(weights_summary=None, nb_sanity_val_steps=0)
trainer.test(model)

If you run this code with current master you will obtain the following output:
3it [00:03,  1.00s/it]
Whereas with this PR you will obtain:
30%|██████████████▋                                              | 3/10 [00:03<00:08,  1.00s/it]

I have just realized that it is slightly more complicated. This PR only fixes the problem when .test(model) is called without .fit(). But if you call .test() after .fit(model) there again will be strange behavior. For example, run the following code:
from time import sleep
import torch
from torch.utils.data import DataLoader, Dataset

import pytorch_lightning as pl

class DummyDataset(Dataset):
    def __init__(self, n):
        super().__init__()
        self.n = n

    def __len__(self):
        return self.n

    def __getitem__(self, idx):
        return torch.rand(10)

class CoolSystem(pl.LightningModule):
    def __init__(self):
        super(CoolSystem, self).__init__()
        self.layer = torch.nn.Linear(10, 10)

    def forward(self, x):
        return self.layer(x)

    def training_step(self, batch, batch_nb):
        # REQUIRED
        sleep(1)
        return {'loss': torch.mean(self.forward(batch) ** 2)}

    def test_step(self, batch, batch_nb):
        # OPTIONAL
        sleep(1)
        return {}

    def test_end(self, outputs):
        # OPTIONAL
        return {}

    def configure_optimizers(self):
        # REQUIRED
        # can return multiple optimizers and learning_rate schedulers
        # (LBFGS it is automatically supported, no need for closure function)
        return [torch.optim.Adam(self.layer.parameters())]

    @pl.data_loader
    def train_dataloader(self):
        # REQUIRED
        return DataLoader(DummyDataset(10), batch_size=1)

    @pl.data_loader
    def test_dataloader(self):
        # OPTIONAL
        return DataLoader(DummyDataset(5), batch_size=1)

model = CoolSystem()
trainer = pl.Trainer(weights_summary=None, nb_sanity_val_steps=0, early_stop_callback=False,
                     check_val_every_n_epoch=100, max_nb_epochs=1)
trainer.fit(model)
trainer.test()

It will end with
15it [00:15,  1.01s/it, batch_nb=9, epoch=0, loss=0.107, v_nb=26]

We can reset the progress bar in that case too and it will show correct total number of iterations. But then this testing progress bar will show old postfixes from the training. So it seems that actually we should distinguish between train_progress_bar and test_progress_bar. In that sense it seems related to #420.

maybe think about moving from tqdm to enlighten
https://github.com/Rockhopper-Technologies/enlighten
the advantage is that the progress bar is not affected by mean-time messages
also see: https://pydigger.com/keyword/bar

maybe think about moving from tqdm to enlighten
https://github.com/Rockhopper-Technologies/enlighten
the advantage is that the progress bar is not affected by mean-time messages
also see: https://pydigger.com/keyword/bar

let’s keep it tqdm for now. we can consider this in a separate PR

should we just have the following bar setup?
train bar
val bar
test bar
each shown on top of each other depending on what's happening.

Yes, it sounds good. I like your idea that main train bar should have total number of batches (train + val) and that validation bar just pop ups as additional bar. And I just point out that test bar seems to be totally independent of the main train bar.


Update document to clarify pairs vs direction

[Enter feedback here]
I know that these are pairs and not the direction of replication; meaning ANF can replicate to East US -> East US2 and vice versa (for example). The way documentation reads can be confusing sometimes and gives an impression that it shows the direction of replication.
can you please add a note or clarifying statement pls?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: aa1995a6-8f18-c6ea-fff6-6c8f7b05d2f5
Version Independent ID: 8abbbb3f-2d03-1395-acea-197a6b2a7c7e
Content: Cross-region replication of Azure NetApp Files volumes
Content Source: articles/azure-netapp-files/cross-region-replication-introduction.md
Service: azure-netapp-files
GitHub Login: @b-hchen
Microsoft Alias: anfdocs

@ravkash -
The article already says that the replication is between the regions.

Azure NetApp Files volume replication is supported between various Azure regional pairs and non-standard pairs. Azure NetApp Files volume replication is currently available between the following regions:

We can add an additional statement for emphasis:
"You can replication Azure NetApp Files volumes from Regional Pair A to Regional Pair B, and vice versa."
cc:  @gvanteylingen

Fixed in https://github.com/MicrosoftDocs/azure-docs-pr/pull/189494
Posting by EOB 2/23/22 PST.
#please-close

yes, adding the emphasis would be great! I know it says "between" but I have got questions from many people over the last year about this and I think the addition would avoid some of those questions.


Save rooms joined in and rejoin on restart

It would be nice if there was an option to have the bot save the rooms it has joined.
Then it could rejoin those rooms on restart.
Example of how this could be configured:
Lita.configure do |config|
  config.robot.rooms = %w( list of rooms )
  # or
  config.robot.rooms = :persist
end

It would make managing the bot much easier than having to change config files and restart it.

Closing this in favor of #116, since more discussion has been happening there. Thank you for this issue – the feature will make it in sooner rather than later!


HTN-010: Implement Semantic Search

Allow functionality for searching plaintext and receiving clip timestamps

Fixed, works successfully to identify moments in videos


Google Calendar unable to trace "child" events after "child" time update

Steps to reproduce:

Create an event that starts on Monday at 1pm and it repeats daily
Edit the event from that series that is scheduled for Wednesday and set it to start at 2pm and select to update This and following events

Once updated events from Monday and Tuesday will have one recurringEventId while Wednesday and following will have another recurringEventId. Is there a way to track down events from Wednesday forward with the data like recurringEventId I have from the event from Monday and Tuesday?
Hope that makes sense.
Thanks in advance.

Hi @zendrax,
Have you taken a look at the support resources page for Calendar? Unfortunately, those of us who handle issues on this library are experts in the client libraries, but not necessarily on the specific APIs. For help with API usage, it's recommended you take a look at one of the available support resources, which are monitored both by community members with a lot of knowledge and by the people who build and maintain the Calendar API.
Best of luck!


Remove U256

Description
Removes the already deprecated U256 from the standard library, and any tests for it. Also modifies some tests that used it to use the u256 native type or no longer use the type.
Checklist

[ ] I have linked to any relevant issues.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book).
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
[ ] I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
[ ] I have requested a review from the relevant team or maintainers.

Should we remove it everywhere in the repo? I still see over 800 references to u256 when I search.

Should we remove it everywhere in the repo? I still see over 800 references to u256 when I search.

I believe i removed every reference of U256? If you meant the native type (u256, not U256) then thats the replacement for U256, no need to remove it.


mdbx.h: conflicting declaration of mode_t

In "mdbx.h", the declaration
typedef unsigned mode_t;
conflicts with the declaration of the same type in <sys/types.h>
typedef _mode_t mode_t;
The error was detected by GCC 7.1 (Mingw-w64) on Windows 7 - x64.
Changing the conflicting declaration to
typedef unsigned short mode_t;
seems to compile.

@zingchen , thanks for reporting.
I will fix this.
But I don't recommend use GCC/MinGW under Windows, since just not tested.

MinGW is fine, at least for (tiny) programs I've done. I use it as it integrates well with Code::Blocks, a mature IDE and lighter, faster than MSVC.

@zingchen, no problem. Just report a bugs, if ones.


I did the npm install and then run start but then shows this issue

can you send me the full ZodError?

sent to your email, ill show here as well

My guess is you are using the old config file. the zipcode section should be like this (example you are in zipcode 11111)
zipCode: ["11111"]

If that didn't fix, try to delete the config.yml and rename the example.config.yml back to config.yml and then fill in the data again


Stream search from prefix-based search to fuzzy-search

Changed the left side pannel stream list search algorithm from prefix-based to fuzzy search.
Fixes #16902
Testing plan:
Tested it with frontend tests and manually.
GIFs or screenshots:

Ohh I need this badly, thanks for implementing this. @Riken-Shah in case you didn't see it your PR now needs a rebase.

This would indeed be great!

@showell Can you please review this PR?

@zulipbot add "needs review"

Could you rebase this?

@Riken-Shah Since #22253 has been merged, do you think we can close this PR?

Hey Alya,
If our goal was only to implement fuzzy search at the level of "segments" (delineated by -, /, etc.) then we can close this, but if we want a more advanced fuzzy search (like general by typing gnrl) then we should keep it.

Hm, I don't think I'd expect, e.g., gnrl to find general, so let's close this one out. Thanks!


Modify DeregistrationNotify

Add query parameters to differentiate whether the type is implicit or explicit.

Related PRs:

https://github.com/free5gc/udm/pull/25

No need use queryParam, amf can determine to do implicit dereg by deregReason in DeregistrationDate.


Use passthrough for tls secret

/merge-when-ready delete-branch

OK, I will merge the pull request when it's ready, leave the commits as is when I merge it, and delete the branch after I've merged it.

I'm sorry but I failed delete the branch after merging the pull request.


anyone see anything wrong with using this useRailsContext custom hook?

Anyone see anything wrong with using the following to get the Rails Context via hooks for client rendered / non-single page apps?
import { useMemo } from 'react';

export const useRailsContextHtmlTag: any | undefined = () => {
  return useMemo(() => {
    try {
      return JSON.parse(
        document.getElementById('js-react-on-rails-context').innerHTML
      );
    } catch {}
  }, []);
};

@nratter We might need the next release if this is at the top level. Very soon!
I release a beta version today.

@nratter This is an interesting idea! BUT, this doesn't work for server-side rendering.
I could add this to the base JS library, or provide it as a doc example...
The new release requires this usage at the top level:
import React from 'react';

export default (props, railsContext) => {
  // Note wrap in a function to make this a React function component
  return () => (

      Your locale is {railsContext.i18nLocale}.

      Hello, {props.name}!

  );
};

@justin808 sounds good!

@nratter Please try out!
Gem version: 12.0.0.pre.beta.0 and npm version 12.0.0-beta.0 released!
https://www.npmjs.com/package/react-on-rails
https://rubygems.org/gems/react_on_rails


added plugin: Travel Guide

This pull request adds the Travel Guide plugin to the OMI ecosystem. (participant in Omi Hackathon)
Plugin details:
Name: Travel Guide
Type: Chat + Memory Prompt
Description: A travel advisor plugin that provides expert guidance on global destinations, trip planning, and budget travel with an adventurous and engaging communication style.
Changes made:

Added plugin JSON to community-plugins.json
Added plugin logo (travel-guide.jpg) to plugins/logos/

I've tested the plugin JSON for correct formatting and ensured the logo meets the required specifications.

Summary by CodeRabbit

New Features

Introduced the "Travel Guide" plugin, providing users with travel suggestions, trip planning, and budgeting assistance.
Engaging and adventurous tone in responses to inspire wanderlust.
Capabilities include conversational interactions and up-to-date travel information.

Bug Fixes

Removed the "Psychologist" plugin, eliminating its previous functionality.

lgtm @merouanezouaid 🥳 / looking fwd your show cases https://discord.gg/based-hardware-1192313062041067520


Colors for white areas

Thanks for this program!
I was wondering if the background of the main viewing area could also have color changes like the other elements. As you can see from the image the areas to the right of elements aren't colored like the rest of the backgrounds. And also the bottom panel "Description" (basically all the white areas).
Thanks.

Yep, in fact I added a new "Color Theme" setting with defaults for "Light" and "Dark" theme, with these colors by default.  I also redid the icons so they are transparent.

Wow! That looks great! You rock!! Thanks! =)


Support for data URIs

When using a data URI as a pageres source (data:text/html;base64,PGgxPkZPTzwvaDE+), pageres generates a white, empty image file.
Is it possible to get pageres to use data URIs? phatom has support for data uris afaik!

Probably just need to support data-URLs in our URL detection: https://github.com/sindresorhus/pageres-cli/blob/4301a0964f5e6f352299c44b4ad3f1d38d2c8db4/cli.js#L150
PR welcome :)


⚠ Bofrost.lu has degraded performance

In 87e1cad, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1581 ms

Resolved: Bofrost.lu performance has improved in 875fab9 after 10 minutes.


Order Book Price Label

.trade-list li>span {
width: 80px;
}
It currently has 70px and it appears like this

Insted it should appear like this

@dimarconicola this is probably on small screen sizes. It is fine on bigger screens.

Hey @aesthytik , I have a very common MacbookPro 13'' so it's a problem if even in my screen it doesn't appear right. Can you please take care of it?

done now!


feat(src): add new var $kong_request_id

See: https://konghq.atlassian.net/browse/KAG-2734

Given that the request ID is created for every request, it may make sense to replace the use of sprintf by a specialized hexadecimal serializer.  In my tests, this can reduce the time to generate the request ID string by 80%.  In the grand scheme of things, this may not be too much, but it would be an improvement that is cheap to make:
#include <stdlib.h>
#include <stdio.h>

void
hex_string(uint64_t num, char *s)
{
  static const char digits[513] =
    "000102030405060708090a0b0c0d0e0f"
    "101112131415161718191a1b1c1d1e1f"
    "202122232425262728292a2b2c2d2e2f"
    "303132333435363738393a3b3c3d3e3f"
    "404142434445464748494a4b4c4d4e4f"
    "505152535455565758595a5b5c5d5e5f"
    "606162636465666768696a6b6c6d6e6f"
    "707172737475767778797a7b7c7d7e7f"
    "808182838485868788898a8b8c8d8e8f"
    "909192939495969798999a9b9c9d9e9f"
    "a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
    "b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
    "c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
    "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
    "e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
    "f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";
  uint32_t x = (uint32_t)num;
  int i = 3;
  while (i >= 0) {
    int pos = (x & 0xFF) * 2;
    char ch = digits[pos];
    s[i * 2] = ch;

    ch = digits[pos + 1];
    s[i * 2 + 1] = ch;

    x >>= 8;
    i -= 1;
  }
}

int
main()
{
  char buf[37];
  for (int i = 0; i < 10000000; i++) {
#if FAST
    hex_string(rand(), buf);
    buf[8] = 'D';
    hex_string(rand(), buf+9);
    buf[17] = 'D';
    hex_string(rand(), buf+18);
    buf[26] = 'D';
    hex_string(rand(), buf+27);
    buf[35] = 'D';
    buf[36] = 0;
#else
    sprintf(buf, "%08xD%08xD%08xD%08xD", rand(), rand(), rand(), rand());
#endif
  }

  return 0;
}

The code looks good to me.

Have we seeded the ngx_random in other place? ngx_random calls libc random if I remember correctly and if we do not seed it, it will be seeded with 1 according to https://man7.org/linux/man-pages/man3/random.3.html.
If it has been seeded, the code looks good to me.

Here it is:
os/unix/ngx_process_cycle.c:    srandom(((unsigned) ngx_pid << 16) ^ tp->sec ^ tp->msec);
os/unix/ngx_posix_init.c:    srandom(((unsigned) ngx_pid << 16) ^ tp->sec ^ tp->msec);

I think almost all changes are good except the length of $kong_request_id.
Currently, we use 8 bytes as $kong_request_id, the collision chance is sqrt(pow(256, 8)) = 4,294,967,296 (uint32_t).
My concern is about the cloud scenario, if there is a large volunm of traffic, the $kong_request_id might replicate many times in a short of period.

Yes, it needs more discussion, Perhaps 24 bytes is a choice.

I think we can just do what the Nginx built-in $request_id did, using 16 bytes random data as $kong_request_id.

Of course, but if 8 bytes random data is enough we could get a little speed up.


Ingestion support for Databricks Workflows & Dashboards

Add support for ingesting Databricks' orchestration called workflows https://docs.databricks.com/en/workflows/index.html
Add support for ingesting Dashboards https://docs.databricks.com/en/sql/user/dashboards/index.html

.

.


Add npm install step to README

Thanks (and sorry about the delay) but this part is already In the readme after "basic usage" chapter.


Validate crs

Issue #, if available:
Description of changes:
This will verify if the following objects exist before creating a workload cluster

Cluster
GitOpsConfig
VsphereMachineConfig
OIDCCOnfig
EKS Anywhere CRD

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mdsgabriel
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [mdsgabriel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: danbudris, mdsgabriel
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [danbudris,mdsgabriel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: danbudris, jiayiwang7, mdsgabriel
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [danbudris,jiayiwang7,mdsgabriel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


VS Code - automatic update sluggish

Since some days (or maybe 1-2 weeks now) auto updating the rust-analyzer plugin for VS Code is super sluggish.
Earlier it took maybe a few seconds to complete but since that time it already takes well over half an hour just for the simple download of the new update files. Oftentimes the download even gets stuck and I have to restart it.
Never had this problem with rust-analyzer before.

Is updating the extension slow, or downloading the new rust-analyzer binary? I assume the latter, since the extension is about 193 KB.
How fast is downloading from GitHub for you? Try getting a gz file from https://github.com/rust-analyzer/rust-analyzer/releases/tag/2021-01-11.

Is updating the extension slow, or downloading the new rust-analyzer binary? I assume the latter, since the extension is about 193 KB.
How fast is downloading from GitHub for you? Try getting a gz file from https://github.com/rust-analyzer/rust-analyzer/releases/tag/2021-01-11.

@Robbepop did you try that?

@Robbepop did you try that?

Hey sorry for not replying - I forgot.
Downloading files indeed seems to be a bit slower but not to the point I saw in rust-analyzer where most downloads (~80% of them in total) got completely stuck after ~10-30 minutes.
I resolved my issues (temporarily) by simply restarting the download after a minute when I see that it is slowing down instead of keeping up speed even though this means approx. 5-10 restarts per rust-analyzer update. A colleague of mine also reported that this works for them.

Hey sorry for not replying - I forgot.
Downloading files indeed seems to be a bit slower but not to the point I saw in rust-analyzer where most downloads (~80% of them in total) got completely stuck after ~10-30 minutes.
I resolved my issues (temporarily) by simply restarting the download after a minute when I see that it is slowing down instead of keeping up speed even though this means approx. 5-10 restarts per rust-analyzer update. A colleague of mine also reported that this works for them.

Can you test from a different network (e.g. at home)?

Can you test from a different network (e.g. at home)?

I am at home (home office). Tried over wifi and ethernet cable. Both equally slow. When a download (finally) is successful the whole update takes roughly 4-5 minutes.

I am at home (home office). Tried over wifi and ethernet cable. Both equally slow. When a download (finally) is successful the whole update takes roughly 4-5 minutes.

I can confirm, updating early in the week, is terribly slow and most of the times doesn't even make any progress.

I can confirm, updating early in the week, is terribly slow and most of the times doesn't even make any progress.

@Veetaha do you have any idea about this? The download and uncompression code hasn't changed lately, and neither did the Node version used by Code.

@Veetaha do you have any idea about this? The download and uncompression code hasn't changed lately, and neither did the Node version used by Code.

I do have exactly that same problem for about two weeks. How do I restart the download of the rust-analyzer binary?

I do have exactly that same problem for about two weeks. How do I restart the download of the rust-analyzer binary?

@FrankenApps you can download a release binary from
https://github.com/rust-analyzer/rust-analyzer/releases/tag/2021-01-18 and
copy it under the path from
https://rust-analyzer.github.io/manual.html#vs-code (look below the
screenshot).
You can download a gz file since they're smaller.

@FrankenApps you can download a release binary from
https://github.com/rust-analyzer/rust-analyzer/releases/tag/2021-01-18 and
copy it under the path from
https://rust-analyzer.github.io/manual.html#vs-code (look below the
screenshot).
You can download a gz file since they're smaller.

I've extracted our download code to https://github.com/lnicola/ra-dl-test, can you test it?

I've extracted our download code to https://github.com/lnicola/ra-dl-test, can you test it?

I have tested your download handler.
Never took more than 2-3 seconds on my network.
To test it, I downloaded rust-analyzer-linux multiple times without any problems on my macOS pc.
Even when the download is fast enough, so that it succeeds in VSCode, it is never even close as fast as it is with the node script.

I have tested your download handler.
Never took more than 2-3 seconds on my network.
To test it, I downloaded rust-analyzer-linux multiple times without any problems on my macOS pc.
Even when the download is fast enough, so that it succeeds in VSCode, it is never even close as fast as it is with the node script.

By never as slow, do you mean ten seconds instead of three, or minutes?
I think we send too many progress notification to Code, but that wouldn't explain this issue. Are you using some sort of proxy or VPN?

By never as slow, do you mean ten seconds instead of three, or minutes?
I think we send too many progress notification to Code, but that wouldn't explain this issue. Are you using some sort of proxy or VPN?

By not as slow I mean around 5 minutes. Basically the same timeframe as mentioned by @Robbepop.
I do not use a proxy or VPN.

By not as slow I mean around 5 minutes. Basically the same timeframe as mentioned by @Robbepop.
I do not use a proxy or VPN.

Which Code version are you using?
@Veetaha if you're still around and have any idea about this, it would be much appreciated.

Which Code version are you using?
@Veetaha if you're still around and have any idea about this, it would be much appreciated.

Filed #7415 to send fewer progress reports to Code, but I'm pretty sure it won't help here.

Hi @lnicola, sorry, I've been at very low availability lately, I can't promise anything about resolving this issue =(.
From what I see here I may conclude:

There are 3 people reporting slow download performance, so the chances of a transient network error coincidence are low
I don't see right away any changes to node-fetch version and our net.ts code that could cause this bug
vscode still uses the same nodejs.12 major version, so I doubt that there could be something happening in node's stdlib

I suppose we need more debug logs to diagnose what the anomalies are and what could potentially cause them because I (and probably @lnicola too) cannot reproduce this locally and deduce the core of the problem from this issue thread.
Some information that might be helpful in the context of this issue:

All extensions in vscode share the same process and nodejs runtime (thus, node's event loop is also shared)

Just for reference, downloads are working fine for me (the gzipped server binary is downloaded within ~5 seconds) though I use pretty crappy wifi and 100 Mbit internet.
Here are the specs from vscode info (I use vscode-insiders):

Specs
Version: 1.53.0-insider
Commit: 1a6eef3170be2a11751ee50d450328d458f7bfac
Date: 2021-01-15T05:14:07.888Z
Electron: 11.2.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.8.0-38-generic

Hi @lnicola, sorry, I've been at very low availability lately, I can't promise anything about resolving this issue =(.
From what I see here I may conclude:

There are 3 people reporting slow download performance, so the chances of a transient network error coincidence are low
I don't see right away any changes to node-fetch version and our net.ts code that could cause this bug
vscode still uses the same nodejs.12 major version, so I doubt that there could be something happening in node's stdlib

I suppose we need more debug logs to diagnose what the anomalies are and what could potentially cause them because I (and probably @lnicola too) cannot reproduce this locally and deduce the core of the problem from this issue thread.
Some information that might be helpful in the context of this issue:

All extensions in vscode share the same process and nodejs runtime (thus, node's event loop is also shared)

Just for reference, downloads are working fine for me (the gzipped server binary is downloaded within ~5 seconds) though I use pretty crappy wifi and 100 Mbit internet.
Here are the specs from vscode info (I use vscode-insiders):

Specs
Version: 1.53.0-insider
Commit: 1a6eef3170be2a11751ee50d450328d458f7bfac
Date: 2021-01-15T05:14:07.888Z
Electron: 11.2.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.8.0-38-generic

Thanks for chiming in and no worries of course. You do raise a good point about other extensions possibly interfering with this. Even other software on the computer (like an antivirus) could have an effect.
Another two differences are:

my test repo already has the fix in #7415 applied
I'm downloading the Linux binary, not the MacOS one (I don't know which platform @Robbepop is using)

And this apparently started after adding in support for Windows or MacOS ARM binaries (which did change the client code, but only a little).

though I use pretty crappy wifi and 100 Mbit internet

Nah, GitHub is still slow-ish even on a 1 Gbps connection.

Thanks for chiming in and no worries of course. You do raise a good point about other extensions possibly interfering with this. Even other software on the computer (like an antivirus) could have an effect.
Another two differences are:

my test repo already has the fix in #7415 applied
I'm downloading the Linux binary, not the MacOS one (I don't know which platform @Robbepop is using)

And this apparently started after adding in support for Windows or MacOS ARM binaries (which did change the client code, but only a little).

though I use pretty crappy wifi and 100 Mbit internet

Nah, GitHub is still slow-ish even on a 1 Gbps connection.

I don't know which platform @Robbepop is using

I am also using linux.
May off-topic but: Today I noticed that rust-analyzer VS Code plugin stopped automatically updates for me since 13 days already.
I cannot even manually choose from the versions and according to the rust-analyzer weekly there has been 2 updates since then. Any ideas? Maybe my config broke after I tried to fix the sluggish downloads speeds.

I don't know which platform @Robbepop is using

I am also using linux.
May off-topic but: Today I noticed that rust-analyzer VS Code plugin stopped automatically updates for me since 13 days already.
I cannot even manually choose from the versions and according to the rust-analyzer weekly there has been 2 updates since then. Any ideas? Maybe my config broke after I tried to fix the sluggish downloads speeds.

That happens when you have an incompatible (old) version of Code, but I don't remember us changing the minimum required version.

That happens when you have an incompatible (old) version of Code, but I don't remember us changing the minimum required version.

My version is 1.52.1 which seems to be from Nov 2020 but still newest there is at the moment.

My version is 1.52.1 which seems to be from Nov 2020 but still newest there is at the moment.

I just wanted to follow up and report that the latest updates worked fine for me.

I just wanted to follow up and report that the latest updates worked fine for me.

Yeah the original issue seems to be resolved for me. When I was downloading the outdated 0.2.449 multiple times to debug why I cannot have the newer one, the download speed was again within seconds.

Yeah the original issue seems to be resolved for me. When I was downloading the outdated 0.2.449 multiple times to debug why I cannot have the newer one, the download speed was again within seconds.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_0atow3zl38/clone/recipe/meta.yaml:23: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_0atow3zl38/clone/recipe/meta.yaml:36: missing_pip_check: For pypi packages, pip check should be present in the test commands
ERROR: /tmp/abs_0atow3zl38/clone/recipe/meta.yaml:54: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_0atow3zl38/clone/recipe/meta.yaml:54: missing_dev_url: The recipe is missing a dev_url
Errors were found


Can Anyone tell me how to solve the right corner message prompt problem?

Windows build number:
22H2
Your Distribution version:
no matter which version
Your WSL versions:
no matter which version
Steps to reproduce:
no matter which version,it is obvious that a IM disappear just because it wanted to show the message preview at the right corner but WSL GUI do not have a whole linux GUI interface.If I set the state of the chat to mute,it won't break suddenly when it received messages.
WSL logs:
No response
WSL dumps:
No response
Expected behavior:
No response
Actual behavior:
no matter which version,it is obvious that a IM disappear just because it wanted to show the message preview at the right corner but WSL GUI do not have a whole linux GUI interface.If I set the state of the chat to mute,it won't break suddenly when it received messages.

And it is obvious the WSLg Linux App have a window which is ONLY A WINDOW.IF I shake it left to right and right to left again and again,nothing would happen about other windows.


Add some new shapes

Except triangle, the rest are fine I guess. Let me know what do you think about that.😀

sounds great @MahirMahdi , do you wanna work on it ?

If someone else wants to work on it let them, and if it's still open after I'm done with my current projects I'll surely do it. 😀

sounds great @MahirMahdi , if there is no one before tomorrow than will just assign it to myself

Hi there,
I want to work on this issue.

@KlausMikhaelson  I wanna work on it.

@Vee339 sorry I just the repo, do you still wanna work on it or should I assign it to @mahfuztbt ?

@KlausMikhaelson  No problem, you can assign to @Vee339
thank you~

it's open for now if anyone want than just comment here once and than you can work on it !
Thank you !

Hey @Akhilbisht798 sure you can, just go through the code once, we are thinking to add new shapes in the game like currently it's a cube so we were thinking of adding some new shapes there, do let me know if you are facing any issue while working on it, Thank you !

Can you link me the code where you have declared the cube shape. That might help me. @KlausMikhaelson

I would love to work on this project. Saw an inconsistency in one of the card's sizes. I will also be adding animations to
the cards

Hey @ElizabethOgbee are you talking about the shapes ?
would love to see what you have in mind !, assigning it to you !
Thank you!


Real-time color change when color selection dialog is open.

This would apply to text etc.
Original request: https://www.boardgamegeek.com/thread/2680007/tim-feature-request

This was added as part of v.<IP_ADDRESS>-unstable.v.a1


Adminer installs but does not run.

Summary:
On develop
Install Adminer into your cloud
after install, run it
Result: "Failed to load resource: the server responded with a status of 503 ()"
I deleted the app and reinstalled and it worked.
It is possible there is something around first time cloud install after a deployment.
Checklist

[ ] I am running the latest version
[ ] I checked the documentation and found no answer
[ ] I checked to make sure that this issue has not already been filed
[ ] I'm reporting the issue to the correct repository (for multi-repository projects)
[ ] I have provided sufficient information for the team

Determined this was due to an OS level issue, which has been fixed


Invalid brod sasl configuration causes brod to crash

When the brod client is configured to use SASL PLAIN authentication but SSL is not enabled in the configuration brod client may crash. I would say that having SASL PLAIN authentication without SSL should be an invalid configuration or the connection should be promoted to SSL just by the fact that the client is configured to use SASL PLAIN authentication.

@alexandrejbr could you provide the crash log ?

@alexandrejbr was your kafka configured to use SASL_SSL listener instead of SASL_PLAINTEXT in your test ?
in brod_client_SUITE we have two SASL authentication test cases,
it connects to SASL_SSL listener in kafka with ssl options enabled in client config.
I have just tested with this below diff, and it works fine.
(changed to SASL_PLAINTEXT listener in kafka, removed ssl option from brod client config)
diff --git a/docker/docker-entrypoint.sh b/docker/docker-entrypoint.sh
index 924d766..85c3643 100755
--- a/docker/docker-entrypoint.sh
+++ b/docker/docker-entrypoint.sh
@@ -28,8 +28,8 @@ fi
 ipwithnetmask="$(ip -f inet addr show dev eth0 | awk '/inet / { print $2 }')"
 ipaddress="${ipwithnetmask%/*}"

-sed -r -i "s/^(advertised.listeners)=(.*)/\1=PLAINTEXT:\/\/$ipaddress:$PLAINTEXT_PORT,SSL:\/\/$ipaddress:$SSL_PORT,SASL_SSL:\/\/$ipaddress:$SASL_SSL_PORT/g" $prop_file
-sed -r -i "s/^(listeners)=(.*)/\1=PLAINTEXT:\/\/:$PLAINTEXT_PORT,SSL:\/\/:$SSL_PORT,SASL_SSL:\/\/:$SASL_SSL_PORT/g" $prop_file
+sed -r -i "s/^(advertised.listeners)=(.*)/\1=PLAINTEXT:\/\/$ipaddress:$PLAINTEXT_PORT,SSL:\/\/$ipaddress:$SSL_PORT,SASL_PLAINTEXT:\/\/$ipaddress:$SASL_SSL_PORT/g" $prop_file
+sed -r -i "s/^(listeners)=(.*)/\1=PLAINTEXT:\/\/:$PLAINTEXT_PORT,SSL:\/\/:$SSL_PORT,SASL_PLAINTEXT:\/\/:$SASL_SSL_PORT/g" $prop_file
 echo "sasl.enabled.mechanisms=PLAIN" >> $prop_file

 KAFKA_HEAP_OPTS="-Xmx1G -Xms1G -Djava.security.auth.login.config=/etc/kafka/jaas.conf" \
diff --git a/test/brod_client_SUITE.erl b/test/brod_client_SUITE.erl
index 9479146..b02aea3 100644
--- a/test/brod_client_SUITE.erl
+++ b/test/brod_client_SUITE.erl
@@ -271,8 +271,8 @@ t_sasl_plain_ssl({'end', Config}) ->
   brod:stop_client(t_sasl_plain_ssl),
   Config;
 t_sasl_plain_ssl(Config) when is_list(Config) ->
-  ClientConfig = [ {ssl, ssl_options()}
-                 , {get_metadata_timout_seconds, 10}
+  ClientConfig = [ %{ssl, ssl_options()}
+                   {get_metadata_timout_seconds, 10}
                  , {sasl, {plain, "alice", "alice-secret"}}
                  ],
   produce_and_consume_message(?HOSTS_SASL_SSL, t_sasl_plain_ssl, ClientConfig).
@@ -284,8 +284,8 @@ t_sasl_plain_file_ssl({'end', Config}) ->
   brod:stop_client(t_sasl_plain_file_ssl),
   Config;
 t_sasl_plain_file_ssl(Config) when is_list(Config) ->
-  ClientConfig = [ {ssl, ssl_options()}
-                 , {get_metadata_timout_seconds, 10}
+  ClientConfig = [ %{ssl, ssl_options()}
+                   {get_metadata_timout_seconds, 10}
                  , {sasl, {plain, "sasl-plain-user-pass-file"}}
                  ],
   produce_and_consume_message(?HOSTS_SASL_SSL, t_sasl_plain_ssl, ClientConfig).

It really relies on the client side to have everything configured correctly.
Before brod can connect to kafka, there is no way to tell if the remote port is a SSL port or PLAINTEXT port.
i.e. we can not just promote to SSL whenever we see SASL_PLAIN auth is configured,
because the remote port can be a PLAINTEXT port.
Not to mention that we often don't know how to promote without certificate files provided in ssl option


Add option --rebuild to azk shell

When using a Dockerfile as a base image, I would like to have a --rebuild option in azk shell command, like azk start --rebuild.

Pretty sure this is in now. The option works for me

Fixed in #221 PR.

I think this issue should be closed, like said in #221.

Are you sure @philss.
I'll close it.
Thank you for identifying it.

Something is wrong,
PR #221 adds --rebuild to start and restart, not in azk shell, as can be seen here: https://github.com/azukiapp/azk/blob/9bc9bdccb3dee8852053a3c9ba572e809aec8784/src/cmds/shell.js#L151-L163

@nuxlli sorry. I didn't notice that.

@philss no problem, none of us noticed this ;)

:sweat_smile:


Fixed #1801 : Can't install in VS 2019

Summary
Fixes #1801

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: J-kit sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.