Internet connection and DNS routing are broken from WSL2 instances, when some VPNs are active.
The root cause seems to be that WSL2 and the VPN use the same IP address block, and the VPN routing clobbers WSL2's network routing.
This problem is tracked in multiple microsoft/WSL issues including, but not limited to:
The following are appendices from Optics By Example, a comprehensive guide to optics from beginner to advanced! If you like the content below, there's plenty more where that came from; pick up the book!
| module Commands | |
| module Meeting | |
| AcceptSchema = Dry::Validation.Schema do | |
| required(:user_id).filled | |
| required(:status).value(eql?: :scheduled) | |
| end | |
| class Accept < Command | |
| def call | |
| return validate if validate.failure? |
| #!/usr/bin/env elixir | |
| defmodule Canvas do | |
| @behaviour :wx_object | |
| @title "Canvas Example" | |
| @size {600, 600} | |
| def start_link() do | |
| :wx_object.start_link(__MODULE__, [], []) |
| describe('Maths', () => { | |
| it('addition is commutative', () => { | |
| jsc.assertForall(jsc.integer, jsc.integer, (a, b) => a + b === b + a) | |
| // same as: | |
| assert(jsc.checkForall(jsc.integer, jsc.integer, (a, b) => a + b === b + a) === true) | |
| }) | |
| }) |
| const daggy = require('daggy') | |
| const Task = require('data.task') | |
| const _ = require('lodash') | |
| const kleisli_comp = (f, g) => x => f(x).chain(g) | |
| const compose = (f, g) => x => f(g(x)) | |
| const id = x => x | |
| //=============FREE============= | |
| const Free = daggy.taggedSum({Impure: ['x', 'f'], Pure: ['x']}) | |
| const {Impure, Pure} = Free |
| sudo apt-get install libncurses5-dev libgnome2-dev libgnomeui-dev \ | |
| libgtk2.0-dev libatk1.0-dev libbonoboui2-dev \ | |
| libcairo2-dev libx11-dev libxpm-dev libxt-dev python-dev \ | |
| ruby-dev python3-dev | |
| sudo apt-get remove vim vim-runtime vim-common | |
| ./configure --with-features=huge \ | |
| --enable-multibyte \ |
| /***************************************** | |
| /* DOM touch support module | |
| /*****************************************/ | |
| if (!window.CustomEvent) { | |
| window.CustomEvent = function (event, params) { | |
| params = params || { bubbles: false, cancelable: false, detail: undefined }; | |
| var evt = document.createEvent('CustomEvent'); | |
| evt.initCustomEvent(event, params.bubbles, params.cancelable, params.detail); | |
| return evt; | |
| }; |
My largest Sidekiq application had a memory leak and I was able to find and fix it in just few hours spent on analyzing Ruby's heap. In this post I'll show my profiling setup.
As you might know Ruby 2.1 introduced a few great changes to ObjectSpace, so now it's much easier to find a line of code that is allocating too many objects. Here is great post explaining how it's working.
I was too lazy to set up some seeding and run it locally, so I checked that test suite passes when profiling is enabled and pushed debugging to production. Production environment also suited me better since my jobs data can't be fully random generated.
So, in order to profile your worker, add this to your Sidekiq configuration:
if ENV["PROFILE"]