Show HN: Easily visualize torch, Jax, tf, NumPy, etc. tensors https://ift.tt/anqfwJx

Show HN: Easily visualize torch, Jax, tf, NumPy, etc. tensors hey hn, wrote a python library for myself to visualize tensors. Makes learning and debugging deep learning code so much easier. Works seamlessly with colab/jupyter notebooks, and other python contexts. It's built on top of the graphics backend, chalk ( https://chalk-diagrams.github.io/ ). why? Understanding deep learning code is hard—especially when it's foreign, because it's hard to imagine tensor manipulations, e.g. `F.conv2d(x.unsqueeze(1), w.transpose(-1, -2)).squeeze().view(B, L, -1)` in your head. Printing shapes and tensor values only get me so far. tensordiagram lets me quickly diagram tensors. Other python libraries for creating tensor diagrams are either too physics and math focused, not notebook-friendly, limited to visualizing single tensors, and/or serve a wider purpose (so have a steep learning curve). https://ift.tt/kISOJeM October 28, 2025 at 03:00AM

Show HN: JSON Query https://ift.tt/KHCNSpc

Show HN: JSON Query I'm working on a tool that will probably involve querying JSON documents and I'm asking myself how to expose that functionality to my users. I like the power of `jq` and the fact that LLMs are proficient at it, but I find it right out impossible to come up with the right `jq` incantations myself. Has anyone here been in a similar situation? Which tool / language did you end up exposing to your users? https://ift.tt/mrc8wBK October 27, 2025 at 09:52PM

Show HN: MNML – Android Launcher (Open Testing Release) https://ift.tt/bEkwevz

Show HN: MNML – Android Launcher (Open Testing Release) Just got the first open testing release approved on google play store for a minimal android launcher i'm developing. I recently switched to a phone with an e-ink display and was missing features in current minimal launchers, so i decided to make my own. Would love to hear your opinion, improvements that could be made or features to change/add. Thanks! === Links === - https://ift.tt/g2RN5Tx - https://www.youtube.com/watch?v=6gcF9lSDBPY (video demo) === Current Features === - Multiple rows of apps - Material Font icons can be set as app names - When reducing or increasing apps you can re-order and select which apps to keep (this is missing from a lot of minimal launchers imo) - App shortcuts (long press on an app to show that app's own shortcut menu) - Backup your launcher settings with Export/Import - App drawer list (swipe up) - You can hide apps from the app list - You can uninstall apps from the app list - App rows can have their size individually set. === Planned features === - Background images or static colors - Show weather information - Screen time usage information - Possibly some limited widgets - google search bar on the bottom? - Notes on the main screen - App folders (so you can assign multiple apps to one slot) - App slot assignment other than apps - URL's - Files - Intents - Contacts - etc. - More gestures that you can assign actions to - 3 or 4 finger swipe - triple tap - pinch zoom - etc. - Find contacts and files in the app list - Localization October 28, 2025 at 12:50AM

Show HN: Helium Browser for Android with extensions support, based on Vanadium https://ift.tt/x5yfbVG

Show HN: Helium Browser for Android with extensions support, based on Vanadium Been working on an experimental Chromium-based browser that brings 2 major features to your phone/tablet: 1. desktop-style extensions: natively install any extensions (like uBO) from the chrome web store, just toggle "desktop site" in the menu first. 2. privacy/security hardening: applies the full patch sets from Vanadium (with Helium's currently wip). Means you get both browsers' excellent privacy features, like Vanadium's webrtc IP policy option that protects your real IP by default, and security improvements such as JIT being disabled by default, all while being a reasonably efficient FOSS app that can be installed on any (modern) android. It's still in beta, and as I note in the README, it's not a replacement for the full OS-level security model you'd get from running the GrapheneOS Vanadium combo. However, goal was to combine privacy of Vanadium with the power of desktop extensions and Helium features, and make it accessible to a wider audience. (Passkeys from Bitwarden Mobile should also work straight away once merged in the list of FIDO2 privileged browsers) Build scripts are in the repo if you want to compile it yourself. You can find pre-built releases there too. Would love any feedback/support! https://ift.tt/FPVlNUa October 27, 2025 at 04:11AM

Show HN: The Legal Embedding Benchmark (MLEB) https://ift.tt/zi9KrXV

Show HN: The Legal Embedding Benchmark (MLEB) Hey HN, I'm excited to share the Massive Legal Embedding Benchmark (MLEB) — the first comprehensive benchmark for legal embedding models. Unlike previous legal retrieval datasets, MLEB was created by someone with actual domain expertise (I have a law degree and previously led the AI team at the Attorney-General's Department of Australia). I came up with MLEB while trying to train my own state-of-the-art legal embedding model. I found that there were no good benchmarks for legal information retrieval to evaluate my model on. That led me down a months-long process working alongside my brother to identify or, in many cases, build our own high-quality legal evaluation sets. The final product was 10 datasets spanning multiple jurisdictions (the US, UK, Australia, Singapore, and Ireland), document types (cases, laws, regulations, contracts, and textbooks), and problem types (retrieval, zero-shot classification, and QA), all of which have been vetted for quality, diversity, and utility. For a model to do well at MLEB, it needs to have both extensive legal domain knowledge and strong legal reasoning skills. That is deliberate — given just how important high-quality embeddings are to legal RAG (particularly for reducing hallucinations), we wanted our benchmark to correlate as strongly as possible with real-world usefulness. The dataset we are most proud of is called Australian Tax Guidance Retrieval. It pairs real-life tax questions posed by Australian taxpayers with relevant Australian Government guidance and policy documents. We constructed the dataset by sourcing questions from the Australian Taxation Office's community forum, where Australian taxpayers ask accountants and ATO officials their tax questions. We found that, in most cases, such questions can be answered by reference to government web pages that, for whatever reason, users were unable to find themselves. Accordingly, we manually went through a stratified sample of 112 challenging forum questions and extracted relevant portions of government guidance materials linked to by tax experts that we verified to be correct. What makes the dataset so valuable is that, unlike the vast majority of legal information retrieval evaluation sets currently available, it consists of genuinely challenging real-world user-created questions, rather than artificially constructed queries that, at times, diverge considerably from the types of tasks embedding models are actually used for. Australian Tax Guidance Retrieval is just one of several other evaluation sets that we painstakingly constructed ourselves simply because there weren't any other options. We've contributed everything, including the code used to evaluate models on MLEB, back to the open-source community. Our hope is that MLEB and the datasets within it will hold value long into the future so that others training legal information retrieval models won't have to detour into building their own "MTEB for law". If you'd like to head straight to the leaderboard instead of reading our full announcement, you can find it here: https://ift.tt/duy6TAP If you're interested in playing around with our model, which happens to be ranked first on MLEB as of 16 October 2025 at least, check out our docs: https://ift.tt/IWE1fZ2 https://ift.tt/hOWXJuz October 27, 2025 at 03:46AM

Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project) https://ift.tt/hoWER6B

Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project) Hi HN, I’m Dvir, a young developer. Last year, I got rejected after a job interview because I lacked some CPU knowledge. After that, I decided to deepen my understanding in the low level world and learn how things work under the hood. I decided to try and create an OS in C and ASM as a way to broaden my knowledge in this area. This took me on the most interesting ride, where I’ve learned about OS theory and low level programming on a whole new level. I’ve spent hours upon hours, blood and tears, reading different OS theory blogs, learning low level concepts, debugging, testing and working on this project. I started by reading University books and online blogs, while also watching videos. Some sources that helped me out were OSDev Wiki ( https://ift.tt/lZcGgPW ), OSTEP ( https://pages.cs.wisc.edu/~remzi/OSTEP ), open-source repositories like MellOS and LemonOS (more advanced), DoomGeneric, and some friends that have built an OS before. This part was the longest, but also the easiest. I felt like I understood the theory, but still could not connect it into actual code. Sitting down and starting to code was difficult, but I knew that was the next step I needed to take! I began by working on the bootloader, which is optional since you can use a pre-made one (I switched to GRUB later), but implementing it was mainly for learning purposes and to warm up on ASM. These were my steps after that: 1) I started implementing the VGA driver, which gave me the ability to display text. 2) Interrupts - IDT, ISR, IRQ, which signal to the CPU that a certain event occurred and needs handling (such as faults, hardware connected device actions, etc). 3) Keyboard driver, which enables me to display the same text I type on my keyboard. 4) PMM (Physical memory management) 5) Paging and virtual memory management 6) RTC driver - clock addition (which was, in my opinion, optional) 7) PIT driver - Ticks every certain amount of time, and also 8) FS (File System) and physical HDD drivers - for the HDD I chose PATA (HDD communication protocol) for simplicity (SATA is a newer but harder option as well). For the FS I chose EXT2 (The Second Extended FileSystem), which is a foundational linux FS structure introduced in 1993. This FS structure is not the simplest, but is very popular in hobby-OS, it is very supported, easy to set up and upgrade to newer EXT versions, it has a lot of materials online, compared to other options. This was probably the longest and largest feature I had worked on. 9) Syscall support. 10) Libc implementation. 11) Processing and scheduling for multiprocessing. 12) Here I also made a shell to test it all. At this point, I had a working shell, but later decided to go further and add a GUI! I was working on the FS (stage 8), when I heard about Hack Club’s Summer of Making (SoM). This was my first time practicing in HackClub, and I want to express my gratitude and share my enjoyment of participating in it. At first I just wanted to declare the OS as finished after completing the FS, and a bit of other drivers, but because of SoM my perspective was changed completely. Because of the competition, I started to think that I needed to ship a complete OS, with processing, GUI and the bare minimum ability to run Doom. I wanted to show the community in SoM how everything works. Then I worked on it for another 2 months, after finishing the shell, just because of SoM!, totalling my project to almost 7 months of work. At this time I added full GUI support, with dirty rectangles and double buffering, I made a GUI mouse driver, and even made a full Doom port! things I would've never even thought about without participating in SoM. This is my SoM project: https://ift.tt/JRslr58 . Every project has challenges, especially in such a low level project. I had to do a lot of debugging while working on this, and it is no easy task. I highly recommend using GDB which helped me debug so many of my problems, especially memory ones. The first major challenge I encountered was during the coding of processes - I realized that a lot of my paging code was completely wrong, poorly tested, and had to be reworked. During this time I was already in the competition and it was difficult keeping up with devlogs and new features while fixing old problems in a code I wrote a few months ago. Some more major problems occurred when trying to run Doom, and unlike the last problem, this was a disaster. I had random PFs and memory problems, one run could work while the next one wouldn’t, and the worst part is that it was only on the Doom, and not on processes I created myself. These issues took a lot of time to figure out. I began to question the Doom code itself, and even thought about giving up on the whole project. After a lot of time spent debugging, I fixed the issues. It was a combination of scheduling issues, Libc issues and the Qemu not having enough (wrongfully assuming 128MB for the whole OS was enough). Finally, I worked throughout all the difficulties, and shipped the project! In the end, the experience working on this project was amazing. I learned a lot, grew and improved as a developer, and I thank SoM for helping to increase my motivation and make the project memorable and unique like I never imagined it would be. The repo is at https://ift.tt/UXZramD . I’d love to discuss any aspect of this with you all in the comments! https://ift.tt/UXZramD October 27, 2025 at 02:13AM

Show HN: I Built DevTools for Blazor (Like React DevTools but for .NET) https://ift.tt/MyNbQFP

Show HN: I Built DevTools for Blazor (Like React DevTools but for .NET) Hi HN! I've been working on developer tools for Blazor that let you inspect Razor components in the browser, similar to React DevTools or Vue DevTools. The problem: Blazor is Microsoft's frontend framework that lets you write web UIs in C#. It's growing fast but lacks the debugging tools other frameworks have. When your component tree gets complex, you're stuck with Console.WriteLine debugging. What I built: A browser extension + NuGet package that: Shows the Razor component tree in your browser Maps DOM elements back to their source components Highlights components on hover Works with both Blazor Server and WASM How it works: The NuGet package creates shadow copies of your .razor files and injects invisible markers during compilation. These markers survive the Razor→HTML pipeline. The browser extension reads these markers to reconstruct the component tree. Current status: Beta - it works but has rough edges. Found some bugs when testing on larger production apps that I'm working through. All documented on GitHub. Technical challenges solved: Getting markers through the Razor compiler without breaking anything Working around CSS isolation that strips unknown attributes Making it work with both hosting models It's completely open source: https://ift.tt/A9TQNiZ Demo site where you can try it: https://ift.tt/trX0hvz Would love feedback, especially from anyone building production Blazor apps. What debugging pain points do you have that developer tools could solve? https://ift.tt/w3B6EHn October 26, 2025 at 10:04PM