| use std::marker::PhantomData; | |
| pub enum TopK<I, E, K, F, const N: usize> { | |
| // this TopK has just been created and no data has been computed | |
| // this is the initial state | |
| Prepared { | |
| itr: I, | |
| f: F, | |
| _k: PhantomData<K>, | |
| }, |
| ; Replace the line marked 'TODO' with your solution, then compile by running: | |
| ; | |
| ; nasm aoc2021-day01a.nasm && chmod +x aoc2021-day01a | |
| ; | |
| ; to generate a static elf binary which should work on x86-64 linux. | |
| ; You can see what happens instruction-by-instruction with gdb, by running: | |
| ; | |
| ; gdb aoc2021-day01a | |
| ; | |
| ; and then using the gdb commands: |
(Phaiax - 2019/12/1 - CC_BY_SA 4.0)
Lately I was porting a software from tokio/futures-1.0 to async-await.
I somehow thought async-std was the successor of tokio and ported everything to async-std.
80% in, I noticed that my hyper dependency requires tokio and that it's not possible to replace tokio with async-std without also replacing hyper. Also, tokio and async-std try to solve the same problem. So I started a journey into the inners of the rust async story to find out if it is possible to use both tokio and async-std at the same time. (tl;dr: it is). I had heard of reactors and executors before, but there was much new stuff to discover.
| # Create a 10-Meg file | |
| $ dd if=/dev/zero of=foo bs=1024 count=10240 | |
| 10240+0 records in | |
| 10240+0 records out | |
| 10485760 bytes (10 MB) copied, 0.0142283 s, 737 MB/s | |
| # Check with ls = 10M | |
| $ ls -la foo | |
| -rw-rw-r-- 1 mina mina 10485760 Sep 11 15:32 foo |
| // Option 1: two dispatches, separated address modes and operations | |
| #define ABSOLUTE_X \ | |
| 0x1C: case 0x1D: case 0x1E: case 0x1F: \ | |
| case 0x3C: case 0x3D: case 0x3E: case 0x3F: \ | |
| case 0x5C: case 0x5D: case 0x5E: case 0x5F: \ | |
| case 0x7C: case 0x7D: case 0x7E: case 0x7F: \ | |
| case 0x9C: case 0x9D: \ | |
| case 0xBC: case 0xBD: \ | |
| case 0xDC: case 0xDD: case 0xDE: case 0xDF: \ |
| map = -> f { | |
| -> rf { | |
| -> acc, elem { | |
| rf[acc, f[elem]] | |
| } | |
| } | |
| } | |
| square = -> n { n**2 } | |
| add = -> acc, n { acc + n } |
When developing a program in Ruby, you may sometimes encounter a memory leak. For a while now, Ruby has a facility to gather information about what objects are laying around: ObjectSpace.
There are several approaches one can take to debug a leak. This discusses a time-based approach, where a full memory dump is generated every, say, 5 minutes, during a time that the memory leak is showing up. Afterwards, one can look at all the objects, and find out which ones are staying around, causing the
| require 'anima' | |
| require 'transproc' | |
| require 'virtus' | |
| require 'benchmark/ips' | |
| USERS = 1000.times.map { |i| { id: "#{i+1}", name: "User #{i+1}", age: "#{(i+1)*2}" } } | |
| module Mappings |
| # lets say this is the response we receive | |
| response = { | |
| "results" => { | |
| "total_count" => 15, | |
| "per_page" => 100, | |
| "companies" => [ | |
| { | |
| "company" => { | |
| "name" => "Foo Bar Ltd", | |
| "registered_address" => { ... }, |