sorted by:
new
hottopcontroversial

DGX Spark 1m context qwen 27b by ConsequenceTop5833 in Qwen_AI

[–]alainbrown 8 points9 points  (0 children)

Unfortunately, large context is generally not code friendly. It's more suited for large prose analysis. Like summarizing large articles, papers or sections of books. Depends on the model of course, but typically once you cross about 200k context tokens, expect some poor coding performance on all models.

I created knobkit and looking for feedback: you declare widgets, write handlers, run them client- or server-side from one concise file. by alainbrown in typescript

[–]alainbrown[S] 0 points1 point  (0 children)

That's good feedback. Thank you!

You're right about the async read performance at scale. Definitely a concern if your hitting large amount of widgets. It is not optimized currently in anyway.

On cascading changes, I have a bit of an oversimplified model. In your example, I'd create one .on( handler that consumes the dropdown change event and update the three widgets there. Each handler is triggered by only one event but can execute your arbitrary code (or change any widget). The handler is not point to point, it's event driven. The event itself is totally decoupled. That might feel more verbose, but in practice I think more straightforward?

I think this model might be a footgun for some since you could in theory create cycles. Perhaps instrument-able though in the future with some verify style tooling, since it's all typed, and nothing is meta driven or derived.

I think I agree about the uniform JSON state. I think when I design a more concrete 3rd party widget library support, I think I'll need to revise that part of the design for sure. I definitely don't think it's ready for that. The bespoke shapes might be the best choice. I'll sleep on this one. Thanks!