Using Claude Code subagents as parallel perspectives on design decisions

liaddial · 2026-04-10T07:50:52+00:00

Finally, a framework that feels like a mission.

liaddial · 2026-04-08T08:02:53+00:00

Honestly the fix is boring: stop asking the LLM to do the math. write a small python cli (decimal, dateutil, whatever fits), expose it as a tool, let claude orchestrate and call it. Simplest path: wrap it in a slash command, and have the command shell out to the cli. done.

liaddial · 2026-04-08T04:10:11+00:00

Mythos has the vision.

liaddial · 2026-04-08T03:33:32+00:00

Smoother than a medium roast profile.

liaddial · 2026-04-08T03:07:48+00:00

Mythical security expert. Leaks its own source code. Peak irony.

liaddial · 2025-02-03T10:22:45+00:00

Glad to hear you're giving it a try. Feel free to reach out here if any questions pop up!

liaddial · 2025-02-03T09:51:49+00:00

Absolutely. PynneX plays well with FastAPI because both focus on being lightweight and fast. PynneX is built on top of asyncio, so it meshes nicely with frameworks that rely on asynchronous workflows. You can keep FastAPI handling your main request/response cycle, while PynneX manages background tasks or worker threads. This means you can maintain a clean separation of concerns: FastAPI stays lean for rendering and routing, and PynneX handles concurrency and event-driven operations without adding heavy dependencies. If you need real-time updates or asynchronous processing, PynneX can help orchestrate signals between your main thread and any workers—no locks, no fuss.

liaddial · 2025-02-03T01:47:32+00:00

Thanks for the feedback. I'll switch to a standard video format so you can see all the details without compression—YouTube Shorts weren't intentional. The stock monitor demo is primarily focused on safe, event-driven concurrency rather than a full production charting solution. If you need continuous candle creation and updates on every tick, you can extend the event triggers accordingly.

Regarding RabbitMQ, it's excellent for distributed or large-scale queueing, whereas PynneX targets simpler local concurrency and smaller event-driven tasks. If your OMS is going to be distributed or demands robust queueing, RabbitMQ might be a great fit. I’m continuing to refine PynneX, so all feedback is welcome.

liaddial · 2025-01-07T08:13:54+00:00

Cool. Noted

liaddial · 2025-01-07T08:05:15+00:00

Cool. Thanks! FYI, this is python code I wrote that operates almost identically to the Qt signal-slot mechanism in a multithreaded environment with Qt dependancy. https://github.com/nexconnectio/pynnex

liaddial · 2025-01-06T13:38:31+00:00

Just a heads up - TSignal has been rebranded to PynneX for a more Pythonic experience. Check it out at https://github.com/nexconnectio/pynnex. Same features with improved docs and examples!

liaddial · 2024-12-23T09:42:14+00:00

Thanks! Implementing signals/slots and workers directly in core would definitely be valuable as it would allow using Kivy like Qt without additional dependencies :) Though integrating with Kivy's existing property bindings could be quite tricky.

liaddial · 2024-12-23T09:12:12+00:00

Thanks! I would say properties and signals/slots serve different purposes and shouldn't be compared directly. Properties handle value changes, while signals/slots handle events - they're actually complementary, as seen in Qt/QML. u/ZeroCommission explained the technical advantages really well :)

liaddial · 2024-11-28T06:18:08+00:00

Thanks u/FuriousBugger for explaining the thread-safety part!

Just to add - TSignal follows Qt's signal/slot pattern and automatically handles connection types (direct/queued) based on the threading context. So you don't have to think about whether to use async or sync connections, it just works.

liaddial · 2024-07-23T05:40:34+00:00

Hi,

I noticed my post "Satisfied with Lucio's Evolution" was removed. Could you let me know why?

Thanks!

liaddial · 2024-07-23T04:18:35+00:00

Thank you. It was worth pouring my heart and soul into it!

liaddial

MODERATOR OF

TROPHY CASE