<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Python on AiSlackin</title><link>https://aislackin.com/tags/python/</link><description>Recent content in Python on AiSlackin</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 21 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://aislackin.com/tags/python/index.xml" rel="self" type="application/rss+xml"/><item><title>npu-monitor: a system tray that knows what hardware each box actually has</title><link>https://aislackin.com/posts/2026-08-21-npu-monitor-gpu-tray/</link><pubDate>Fri, 21 Aug 2026 00:00:00 +0000</pubDate><guid>https://aislackin.com/posts/2026-08-21-npu-monitor-gpu-tray/</guid><description>&lt;p&gt;Every multi-host monitoring tool I tried assumed homogeneous hardware: one GPU, maybe two, same on every machine. My LAN doesn&amp;rsquo;t work like that — one box has an AMD APU iGPU plus a Ryzen AI NPU, another has an AMD R9700 &lt;em&gt;and&lt;/em&gt; an NVIDIA RTX 5060 Ti. So &lt;code&gt;npu-monitor&lt;/code&gt; treats the device list as dynamic: each host reports its own real silicon and the tray renders whatever arrives.&lt;/p&gt;&#10;&lt;p&gt;The numbers come from the actual kernel interfaces, not screen-scraping: ROCm sysfs (&lt;code&gt;gpu_busy_percent&lt;/code&gt;) for AMD cards, &lt;code&gt;nvidia-smi&lt;/code&gt; for CUDA, &lt;code&gt;/proc/stat&lt;/code&gt; deltas for CPU, and a raw &lt;code&gt;DRM_IOCTL_AMDXDNA_GET_INFO&lt;/code&gt; ioctl against &lt;code&gt;/dev/accel/accel0&lt;/code&gt; — using the real 168-byte sensor struct from the kernel UAPI — for the NPU&amp;rsquo;s utilization columns.&lt;/p&gt;</description></item><item><title>csv2pg: CSV → PostgreSQL without the shell dance</title><link>https://aislackin.com/posts/2026-06-16-csv2pg/</link><pubDate>Tue, 16 Jun 2026 00:00:00 +0000</pubDate><guid>https://aislackin.com/posts/2026-06-16-csv2pg/</guid><description>&lt;p&gt;Most &amp;ldquo;import this CSV&amp;rdquo; advice ends with &lt;code&gt;psql&lt;/code&gt; invocations, &lt;code&gt;\copy&lt;/code&gt; meta-commands, and a schema you hand-write after eyeballing the data in a spreadsheet. I got tired of that ritual, so &lt;code&gt;csv2pg&lt;/code&gt; does the whole path in-process through psycopg3: analyze the file, infer the schema, create the table, stream the rows, verify the count, commit. No &lt;code&gt;psql&lt;/code&gt; binary involved anywhere.&lt;/p&gt;&#10;&lt;p&gt;The interesting part is the type inference. It samples up to 100 random rows per column to guess a candidate PostgreSQL type, then validates that guess against &lt;em&gt;every&lt;/em&gt; row in the file. If validation fails, the column widens to the next compatible type — up to five attempts — before falling back to &lt;code&gt;text&lt;/code&gt;. You get a tabulated summary plus a generated &lt;code&gt;.sql&lt;/code&gt; file before anything touches the database.&lt;/p&gt;</description></item></channel></rss>