B-logs by Prathamesh

Introducing Raphael: The Sardonic ADHD Advisor Inside Your Desktop HUD

2026-06-22T04:30:00+00:00

We’ve all been there. You sit down to write code or update a doc. You open a browser tab to check a reference, and twenty minutes later you’re deep in a Wikipedia rabbit hole reading about medieval trebuchet engineering.

Standard website blockers don’t work for engineers or power users — they’re too easy to disable, too rigid, and completely context-blind. Block Chrome and you lose everything: the critical docs page and the social media feed you were trying to avoid.

That’s why I built Raphael.

Raphael is a sardonically supportive ADHD cognitive advisor that integrates directly into your Linux desktop as a cockpit-style HUD. It watches your active workspace context, dynamically categorizes your behavior using an LLM pipeline, calls out focus slippages with ruthless wit, and locks your screen with interactive psychological challenges when you drift too far off track.

Core Architecture

Raphael splits its footprint between a lightweight desktop layer and a background analytics daemon.

QML HUD Frontend — A pair of frosted-glass overlay panels (leftQuotePanel, rightInsightPanel) pinned above your windows using KDE Plasma 6 (Qt Quick/QML). Streams live advisor observations, active telemetry, and your real-time Focus Efficiency Rating.

Flask Core Daemon — A zero-overhead background engine polling system state every few seconds. Parses active window properties, handles tracking triggers, serves a local analytics dashboard, and fires real-time classification requests against a Groq AI pipeline.

Key Features

Deep Window & Tab Dissection

Most focus trackers read process strings like google-chrome or vscodium and stop there. Raphael uses direct active window parsing (optimized for XWayland) to extract the exact browser tab title or current file path — stripping the application wrapper entirely. It knows the difference between github.com/pulls and an entertainment blog.

The Distraction Challenge

When the polling module detects you’ve lingered on an unapproved window past your threshold (default: 30 seconds), it overrides your layout with a focus interruption. Not a warning banner — a pop-up that forces you to textually justify your action:

“Explain exactly how this tab aids your immediate deployment target, or return to work.”

Session metrics don’t resume until you justify the context switch or close the window.

Dynamic Mid-Session Context Shifting

You don’t need to edit config files to change Raphael’s behavior mid-session. The integrated Chat Console accepts natural language updates on the fly:

“Remind me to stretch every 20 minutes.”
“From now on, ignore Spotify track changes.”
“Escalate the aggression matrix — I’m drifting.”

Project Structure

raphael/
├── run.sh                  # Environment setup and daemon launcher
├── daemon.log              # Main background log output
└── contents/
    ├── ui/
    │   ├── main.qml        # Core Plasma widget and control surface
    │   ├── ChatPanel.qml   # Chat shell for mid-session rule overrides
    │   └── daemon/
    │       ├── raphael_core_daemon.py   # Parser, Flask app, Groq wrapper
    │       └── dashboard.html           # Local analytics telemetry UI
    └── config/
        └── main.xml        # Preserved state schemas for the desktop layer

Under the Hood: QML Telemetry Sync

The HUD polls the Flask daemon on a tight loop and pushes live data directly into the overlay:

function syncNetworkPayload() {
    var xhr = new XMLHttpRequest();
    xhr.open(
        "GET",
        "http://127.0.0.1:5757/telemetry_v3?caring=" + caringLevel + "&ai_track=" + aiWindowTracking
    );
    xhr.onreadystatechange = function() {
        if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
            var res = JSON.parse(xhr.responseText);

            sharedState.currentQuote       = res.quote.text;
            sharedState.focusEfficiencyText = (res.efficiency * 100) + "% FOCUS";

            console.log("HUD Matrix Sync Complete // Status: " + res.status);
        }
    };
    xhr.send();
}

Web Telemetry Dashboard

The Flask daemon also hosts a full session dashboard at http://127.0.0.1:5757/dashboard, built with Chart.js:

Focus Timeline — Minute-by-minute view charting active focus against distractions.
Window Breakdown — Doughnut graph showing time distribution across file paths, browser tabs, and applications.
Session Goals — Checkable goal metrics generated at session start.

Getting Started

Requirements: KDE Plasma 6.0+ and a valid Groq API key.

# Clone the repo
git clone https://github.com/prathameshrp/Raphael.git
cd Raphael

# Set your API key
export GROQ_API_KEY="your_api_key_here"

# Launch the daemon
chmod +x run.sh
./run.sh

After the daemon starts, add the Raphael Widget from your desktop panel’s widget picker.

To reload the Plasma shell after editing QML files (without interrupting the backend):

killall plasmashell && kstart plasmashell

Open Source

Raphael was built for those of us who need more than a stopwatch to stay on track. If you want to configure custom modules, tweak the AI persona rules, or extend the Wayland window reader — the repo is open.

👉 github.com/prathameshrp/Raphael

If Raphael has successfully guilted you back into finishing your codebase today, consider dropping a ⭐️.

Set Cover Meets Ant Colony: How We Optimized Multi-Store Delivery Routes

2025-10-10T04:30:00+00:00

Last semester I co-authored a paper on delivery route optimization that got published in the Journal of Robotics and Control. The core question: if a user’s cart has items spread across five different nearby stores, what’s the cheapest, fastest way to collect everything and deliver it?

This post is a deeper walkthrough of what we actually built and why we made the choices we did — more than what fits in a paper’s page limit.

The problem nobody talks about

Most delivery optimization research assumes a single warehouse. Real quick-commerce is messier: a user orders pasta, medicine, and phone cable. Those three items might be in three different stores within 2km. The system has to decide which stores to visit and in what order — and those are two fundamentally different problems stacked on top of each other.

We formalized this as two stages:

Store selection — find the minimal subset of stores that collectively stock every item in the cart
Route optimization — find the cheapest path through those stores to the delivery address

Stage 1 is a Set Cover Problem. Stage 2 is a Traveling Salesman Problem. Both are NP-hard. Great.

Stage 1: Modeling store selection as Set Cover

Given a set of required items I = {i₁, i₂, ..., iₘ} and nearby stores S = {s₁, s₂, ..., sₙ}, we build an availability matrix A where A[s][i] = 1 if store s stocks item i.

The goal is to find the smallest subset S* ⊆ S such that every item in I is covered by at least one store in S*, while also minimizing total travel cost.

We use a greedy set cover approach: start with an empty S*, iteratively add whichever store covers the most currently uncovered items, break ties by proximity to the delivery address.

Here’s the core of that logic:

JS Greedy Set Cover — store selection

// Greedy Set Cover
// items: array of item names
// stores: array of {name, stocks: Set of items, cost}

function greedySetCover(items, stores) {
  const required = new Set(items);
  const selected = [];
  let uncovered = new Set(items);

while (uncovered.size > 0) {
    // Pick store with best coverage/cost ratio
    let best = null, bestScore = -1;

for (const store of stores) {
      if (selected.includes(store)) continue;
      const covers = [...store.stocks].filter(i => uncovered.has(i)).length;
      if (covers === 0) continue;
      // Score: items covered per unit cost
      const score = covers / store.cost;
      if (score > bestScore) { bestScore = score; best = store; }
    }

if (!best) break; // shouldn't happen if stores cover all items
    selected.push(best);
    best.stocks.forEach(i => uncovered.delete(i));
    console.log(`Selected: ${best.name} → covers [${[...best.stocks].join(', ')}]`);
    console.log(`  Remaining uncovered: [${[...uncovered].join(', ')}]`);
  }

return selected;
}

const items = ['pasta', 'medicine', 'cable'];
const stores = [
  { name: 'QuickMart',   stocks: new Set(['pasta', 'cable']),    cost: 2 },
  { name: 'HealthPlus',  stocks: new Set(['medicine']),          cost: 3 },
  { name: 'MegaStore',   stocks: new Set(['pasta', 'medicine', 'cable']), cost: 8 },
  { name: 'LocalShop',   stocks: new Set(['pasta']),             cost: 1 },
];

const result = greedySetCover(items, stores);
console.log(`\nFinal stores to visit: ${result.map(s => s.name).join(' → ')}`);
console.log(`MegaStore covers everything but costs 8. Greedy picks the cheaper combination.`);

Notice how the greedy approach skips MegaStore (which covers everything, cost 8) in favor of QuickMart + HealthPlus (covers everything, cost 5). This is the classical approximation — it’s guaranteed to be within O(log n) of optimal, which is the best we can do for NP-hard problems with a polynomial algorithm.

Stage 2: Route optimization as TSP

Once we have S*, we need the shortest path through those stores to the delivery address. This is a Traveling Salesman Problem on a small graph (usually 2-5 nodes), so even brute force is fast.

The cost matrix captures inter-store distances plus the distance from each store to the delivery location d. We want to minimize:

minimize Σ Cost(sᵢ, sⱼ) for (sᵢ,sⱼ) ∈ route

For small |S*|, nearest-neighbor heuristic gets us close to optimal:

JS Nearest-Neighbor TSP — route optimization

// Nearest-Neighbor TSP heuristic
// nodes: array of {name, x, y}
// Returns visit order

function dist(a, b) {
  return Math.sqrt((a.x-b.x)**2 + (a.y-b.y)**2);
}

function nearestNeighborTSP(nodes, startName) {
  const unvisited = new Set(nodes.map(n => n.name));
  let current = nodes.find(n => n.name === startName);
  unvisited.delete(current.name);
  
  const route = [current];
  let totalCost = 0;

while (unvisited.size > 0) {
    let nearest = null, nearestDist = Infinity;
    for (const name of unvisited) {
      const node = nodes.find(n => n.name === name);
      const d = dist(current, node);
      if (d < nearestDist) { nearestDist = d; nearest = node; }
    }
    totalCost += nearestDist;
    route.push(nearest);
    unvisited.delete(nearest.name);
    current = nearest;
  }

// Return to depot
  totalCost += dist(current, nodes.find(n => n.name === startName));

console.log("Route: " + route.map(n => n.name).join(" → ") + " → depot");
  console.log(`Total cost: ${totalCost.toFixed(2)} units`);
  return { route, totalCost };
}

// Depot at origin, stores at various coordinates
const nodes = [
  { name: 'depot',      x: 0,  y: 0  },
  { name: 'QuickMart',  x: 3,  y: 4  },
  { name: 'HealthPlus', x: 7,  y: 2  },
  { name: 'Customer',   x: 5,  y: 7  },
];

nearestNeighborTSP(nodes, 'depot');

The Ant Colony Optimization approach

The classical two-stage method gives us a deterministic, predictable answer. But as the number of deliveries grows, it struggles — the greedy set cover can miss better combinations, and the TSP heuristic doesn’t adapt to constraints like traffic congestion or time windows.

ACO takes a completely different approach. It simulates a colony of ants, each building a route probabilistically. Ants that find better routes deposit more pheromone, biasing future ants toward those paths. Over hundreds of iterations, the colony converges on a near-optimal solution.

The key formula is the transition probability — how likely ant k is to move from city i to city j:

p_ij^k(t) = [τ_ij(t)]^α · [η_ij]^β  /  Σ [τ_ij(t)]^α · [η_ij]^β

Where τ_ij is pheromone on edge (i,j), η_ij = 1/distance is visibility, and α, β control the tradeoff between following pheromone vs. picking nearby nodes.

Pheromone evaporates over time (controlled by ρ) so bad paths don’t get permanently reinforced:

τ_ij(t+n) = ρ · τ_ij(t) + Δτ_ij(t)

Here’s a stripped-down simulation to show how pheromone reinforcement works:

JS ACO pheromone reinforcement — watch short paths win

// Pheromone update simulation — watch good paths get reinforced

function simulateACO(edges, iterations = 5) {
  // Initialize pheromone equally on all edges
  const pheromone = {};
  edges.forEach(e => { pheromone[e.id] = 1.0; });

const rho = 0.5;   // evaporation rate
  const Q   = 10;    // pheromone deposit constant

console.log("Initial pheromone:", JSON.stringify(pheromone));
  console.log("---");

for (let t = 1; t <= iterations; t++) {
    // Simulate: ants prefer shorter edges, deposit more pheromone there
    edges.forEach(e => {
      // Evaporate
      pheromone[e.id] *= (1 - rho);
      // Deposit: shorter distance → more ants use it → more pheromone
      const deposit = Q / e.distance;
      pheromone[e.id] += deposit;
    });

console.log(`Iteration ${t}:`);
    edges.forEach(e => {
      const bar = "█".repeat(Math.round(pheromone[e.id]));
      console.log(`  ${e.id.padEnd(20)} τ=${pheromone[e.id].toFixed(2)}  ${bar}`);
    });
    console.log("---");
  }

const best = edges.reduce((a,b) => pheromone[a.id] > pheromone[b.id] ? a : b);
  console.log(`Strongest pheromone trail: ${best.id} (distance ${best.distance})`);
}

const edges = [
  { id: "depot→QuickMart",  distance: 5  },
  { id: "depot→HealthPlus", distance: 10 },
  { id: "depot→Customer",   distance: 8  },
];

simulateACO(edges, 4);

Run this and watch: the shorter depot→QuickMart edge accumulates pheromone faster than the longer routes, even though all edges start equal. This emergent bias is what guides the colony toward good solutions without anyone explicitly programming “prefer short edges.”

Adding congestion as an independent parameter

One of the more interesting things we did was introduce traffic congestion as a weighted parameter on each node. We generated a synthetic heatmap where certain areas have high congestion levels, then ran both algorithms on it.

The result was surprising: in congested scenarios, the classical model actually beat ACO on cost. The classical model follows a fixed, mathematically computed path that sidesteps congested nodes by construction. ACO’s pheromone trails, built before congestion data is fully incorporated, can get “stuck” reinforcing paths that happen to run through congested zones.

This gave us the main practical finding of the paper:

JS Congestion-aware cost — why environment matters

// Simplified congestion-aware cost model
// Shows why algorithm choice depends on environment

const baseDistances = {
  'depot-A': 3, 'depot-B': 5, 'A-C': 4, 'B-C': 2, 'C-customer': 3
};

// High-congestion scenario: node B is in a traffic hotspot
const congestionMap = { A: 0.1, B: 0.9, C: 0.2, customer: 0.0 };

console.log("=== Classical route (avoids B): depot → A → C → customer ===");
const classicalCost = routeCost(
  ['depot','A','C','customer'], congestionMap, baseDistances
);

console.log(`\n=== ACO route (reinforced B as 'short'): depot → B → C → customer ===`);
const acoCost = routeCost(
  ['depot','B','C','customer'], congestionMap, baseDistances
);

console.log(`\nClassical cost: ${classicalCost.toFixed(1)}`);
console.log(`ACO cost:       ${acoCost.toFixed(1)}`);
console.log(classicalCost < acoCost
  ? "→ Classical wins here (congestion punishes ACO's pheromone trail)"
  : "→ ACO still wins despite congestion");

What the simulations showed

We ran both approaches on 100 simulated deliveries in Python and measured average delivery time and total cost at different scales.

The findings:

Classical (Set Cover + TSP)

Fast and exact for small delivery counts
Average delivery time increases steeply as volume grows
Wins on cost in high-congestion environments
No real-time adaptability

ACO

Consistently better average delivery time at high volumes
Cost scales more gracefully
Adapts dynamically via pheromone updates
Struggles above ~80 nodes when time window constraints are strict (ACO2 variant)

Neither approach dominates across all conditions. The paper concludes with a proposal for a hybrid model controlled by a parameter θ that selects the algorithm based on detected delivery environment — use classical for low-volume or high-congestion scenarios, ACO for large-scale or dynamic ones.

What I’d do differently

The congestion parameter was static — we baked it into the cost matrix before running either algorithm. A real system would need live traffic data updating the weights mid-route. That’s the natural next step: integrating a real-time traffic API and testing how ACO’s pheromone evaporation rate responds to sudden congestion spikes vs. how quickly a classical re-plan can compute a new optimal.

The paper’s code and simulation data are available if you want to dig into the Python implementation.

Building a Real-Time Virtual Try-On with MediaPipe and a Webcam

2025-04-08T04:30:00+00:00

Most virtual try-on demos you see online are either pre-recorded, server-heavy, or involve a 30-second upload cycle. I wanted something that felt instant — point a webcam at yourself, and a shirt just appears on you, live.

Here’s how it works and what I learned building it.

The architecture

The pipeline is split across two servers deliberately:

A Node.js/Express frontend server handles the webcam stream and serves the UI. Every 500ms it captures a frame from the browser, POSTs it as a JPEG, and replaces the output image with whatever comes back.
A Flask/Python backend does the actual computer vision — pose detection, clothing resize and placement, alpha compositing — and returns a processed JPEG.

Keeping them separate meant I could iterate on the CV logic without touching the frontend, and swap out the pose model without breaking the web layer.

Pose detection with MediaPipe

MediaPipe’s Pose solution gives you 33 body landmarks per frame. For draping a shirt, you only really need four of them: left shoulder, right shoulder, left hip, and right hip.

From those four points you can derive everything you need:

shoulder_distance = np.linalg.norm(np.array(left_shoulder) - np.array(right_shoulder))
shirt_width  = int(shoulder_distance * 1.5)
shirt_height = int(shoulder_hip_distance * 1.2)

The multipliers (1.5, 1.2) were tuned by feel — the shirt needs to be a bit wider than the shoulder span and slightly taller than the torso to look natural.

Alpha compositing

The clothing PNG has a transparency channel, so the overlay is a standard alpha blend per pixel:

alpha = resized_clothing[:, :, 3] / 255.0
frame[y1:y2, x1:x2, c] = (
    clothing[:, :, c] * alpha + frame[y1:y2, x1:x2, c] * (1.0 - alpha)
)

The trickier part is clamping the bounding box so the shirt doesn’t bleed outside the frame when you’re close to the camera edge — that’s what the crop_x1/y1 offset math handles.

What surprised me

MediaPipe is fast. Running pose detection on every frame at 500ms intervals felt seamless on a mid-range laptop. The bottleneck turned out to be the Node → Python round-trip over localhost HTTP, not the CV itself.

PNG alpha quality matters a lot. A clothing image with a clean, well-cut alpha channel looks convincing. A sloppy one with fringing makes the whole thing look broken regardless of how accurate your landmark math is.

What’s next

Right now it only supports one hardcoded shirt. The obvious next step is a clothing selector — a small gallery where you pick a PNG and the backend swaps the overlay. The pose pipeline doesn’t need to change at all for that.

The repo is open if you want to drop in your own clothing images and play with the multipliers.

👉 github.com/prathameshrp

cgPaint: Classic CG Algorithms, Pixel by Pixel

2024-12-02T04:30:00+00:00

For my computer graphics mini project I built a paint app where every primitive is implemented from scratch. No ctx.lineTo for lines. No ctx.arc for circles. Just the raw algorithms, plotting one pixel at a time.

The most useful part turned out to be the speed slider: slow an algorithm down to 100ms per step and you can watch Bresenham decide whether to step right or diagonally. That made the theory click in a way lecture notes didn’t.

DDA vs Bresenham: two ways to draw a line

DDA (Digital Differential Analyzer) is the intuitive approach — divide the total change in x and y by the number of steps, then increment:

JS DDA Line — try changing the endpoints

Bresenham eliminates the floating point entirely using an integer error term. At each step, the error tells you whether the next pixel should be directly right or diagonally up-right:

JS Bresenham Line — inspect the error term

Run both on the same line: they produce identical pixels. The difference shows up at scale — Bresenham avoids floating-point rounding that accumulates across millions of lines in a real renderer.

Bresenham’s circle: computing one octant, mirroring eight

A circle has 8-fold symmetry. Bresenham’s algorithm exploits this: compute one octant (45°), then mirror it to all eight positions simultaneously. For a radius of r, you only do ~r iterations to draw the full circle:

JS Bresenham Circle — 8-way symmetry

Scan-line polygon fill

Given an arbitrary polygon, the scan-line algorithm sweeps horizontal lines top to bottom. For each scan line it finds every edge intersection, sorts them, and fills between pairs. The tricky part is the edge table — you only activate edges whose yMin the current scan line has reached:

JS Scan-line fill — watch the sweep

function scanLineFill(polygon) {
  // Build edge table (skip horizontal edges)
  const edges = [];
  const n = polygon.length;
  for (let i = 0; i < n; i++) {
    const p1 = polygon[i], p2 = polygon[(i + 1) % n];
    if (p1.y === p2.y) continue;
    edges.push({
      yMin: Math.min(p1.y, p2.y),
      yMax: Math.max(p1.y, p2.y),
      xAtYMin: p1.y < p2.y ? p1.x : p2.x,
      slopeInv: (p2.x - p1.x) / (p2.y - p1.y),
    });
  }

const yMin = Math.min(...polygon.map(p => p.y));
  const yMax = Math.max(...polygon.map(p => p.y));

console.log("y  | active edges  | fill range");
  console.log("---|---------------|------------");

for (let y = yMin; y <= yMax; y++) {
    const xs = edges
      .filter(e => y >= e.yMin && y < e.yMax)
      .map(e => Math.round(e.xAtYMin + e.slopeInv * (y - e.yMin)))
      .sort((a, b) => a - b);

for (let i = 0; i < xs.length; i += 2) {
      const row = `y=${y}`.padEnd(3);
      const xPairs = `x=${xs[i]}..${xs[i+1]}`;
      const bar = "█".repeat(xs[i + 1] - xs[i] + 1);
      console.log(`${row}| ${xs.length} intersections | ${xPairs}  ${bar}`);
    }
  }
}

// A simple triangle
const triangle = [
  { x: 5, y: 0 },
  { x: 0, y: 8 },
  { x: 10, y: 8 },
];
scanLineFill(triangle);

The █ blocks in the output show the actual fill span per scan line. You can see the triangle widen as y increases.

2D transformations and why order matters

Translate, rotate, and scale are applied via the canvas transform stack. The important thing: the order you apply them changes the result. Rotate-then-translate is not the same as translate-then-rotate:

JS Transform order — rotate vs translate first

function applyTransform(point, ops) {
  let {x, y} = point;
  const log = [`start: (${x}, ${y})`];

for (const op of ops) {
    if (op.type === 'translate') {
      x += op.x; y += op.y;
      log.push(`translate(${op.x}, ${op.y}) → (${x.toFixed(1)}, ${y.toFixed(1)})`);
    } else if (op.type === 'rotate') {
      const cos = Math.cos(op.angle), sin = Math.sin(op.angle);
      [x, y] = [x*cos - y*sin, x*sin + y*cos];
      log.push(`rotate(${(op.angle * 180/Math.PI).toFixed(0)}°) → (${x.toFixed(1)}, ${y.toFixed(1)})`);
    } else if (op.type === 'scale') {
      x *= op.factor; y *= op.factor;
      log.push(`scale(${op.factor}) → (${x.toFixed(1)}, ${y.toFixed(1)})`);
    }
  }
  return log;
}

const point = { x: 10, y: 0 };
const angle = Math.PI / 2; // 90°

console.log("=== Rotate THEN Translate ===");
applyTransform(point, [
  { type: 'rotate', angle },
  { type: 'translate', x: 5, y: 0 },
]).forEach(l => console.log(l));

console.log("\n=== Translate THEN Rotate ===");
applyTransform(point, [
  { type: 'translate', x: 5, y: 0 },
  { type: 'rotate', angle },
]).forEach(l => console.log(l));

console.log("\nDifferent end points — order matters.");

In the actual app, each shape stores its own transform state and ctx.save()/ctx.restore() isolates it so one object’s rotation doesn’t bleed into the next.

👉 github.com/prathameshrp