msoloviev

I'm working on a text editor (https://github.com/blackhole89/autopen/) that continuously analyses the buffer with a local LLM to compute token surprisal and generate candidate completions starting from any point, and switch back and forth between different ones by walking a tree structure. This is pretty different from the usual way people interact with LLMs, and has lots of interesting applications - for example, if you are using them to translate and don't like a particular word choice, you can "dig through" top alternatives on the spot or even insert your own.

Applying the same approach to chain-of-thought reasoning gave me the feeling that I might be looking at a form of realistic UX for some sort of science-fiction neural AI augmentation - you can let the CoT run on and do its thing, but also interject at any point and insert a "thought" of your own, or go back and revise a thought you did not like, and then let it continue. Imagine such a stream hooked up with a two-way pipe into your phonological loop (https://www.sciencedirect.com/topics/psychology/phonological... - perhaps more attainable with existing tech).

I wonder how the "ring context" works under the hood. I have previously had (and recently messed around with again) a somewhat similar project designed for a more toy/exploratory setting (https://github.com/blackhole89/autopen - demo video at https://www.youtube.com/watch?v=1O1T2q2t7i4), and one of the main problems to address definitively is the question of how to manage your KV cache cleverly so you don't have to constantly perform too much expensive recomputation whenever the buffer undergoes local changes.

The solution I came up with involved maintaining a tree of tokens branching whenever an alternative next token was explored, with full LLM state snapshots at fixed depth intervals so that the buffer would only have to be "replayed" for a few tokens when something changed. I wonder if there are some mathematical properties of how the important parts of the state (really, the KV cache, which can be thought of as a partial precomputation of the operation that one LLM iteration performs on the context) work that could have made this more efficient, like to avoid saving full snapshots or perhaps to be able to prune the "oldest" tokens out of a state efficiently.

(edit: Georgi's comment that beat me by 3 minutes appears to be pointing at information that would go some way to answer my questions!)

Hah, +1 for HN users who attended that course in 2009 here. (I usually post on a pseudonymous account though.) I surely must know you, though I couldn't tell who you are from very briefly stalking your comments!

While we're reminiscing, I imagine you also took Concepts in Programming Languages in second year (https://www.cl.cam.ac.uk/teaching/1011/ConceptsPL/ ?), which (after a tour de force through all sorts of paradigms that were consigned to the fossil record for the time being) did advertise Scala pretty heavily. I found that course to be a true gem and haven't seen anything like it at any of the other universities I've passed through since then.

Yeah, the way Windows builds are made available at the moment is honestly pretty bad, and I should improve on that. There is the problem that you need to be logged in to download that particular type of CI artifact, and more generally that the archive is somewhat bloated because the build scripts have no notion of what parts of Gtk actually need to be bundled (and so they wind up including an excess of random icons and what-not).

I don't know if I want to reach what you would call the "general public" (at least not until the program is quite a bit more polished than it is now), but I'd certainly want to reach typical Linux-using HN posters who are interested in Markdown notetaking, and the circumstance that this subthread played out as it did implies I haven't yet done so.

Well, it's not exactly unsustainable - the Github CI continues producing those builds without me having to do anything for it (it in fact didn't break even once in the past year, compared to several breakages on the "backwards-compatible" Ubuntu 18.04 deb which happened whenever Github changed something about the package bundle available to that image). If someone reports a bug on Windows, I will look into it, and/or spend some time walking them through a workaround (since I do in fact have access to Windows setups). As I see it, in the most natural sense of support, I do have support for Windows, even though it is what I guess you would call Tier 2 support.

To nitpick a little, I also didn't say I don't think that those who care about licensing issues would use [the Windows build]; rather, I think that those who don't care about licensing issues and are on Windows would not use it, because there is a Windows-only product that is closed-source which I am unlikely to be able to compete with on that ground.

I'm not really advertising Mac support beyond having some files merged from people who did get it to work (https://github.com/blackhole89/notekit/blob/master/screensho...).

Thanks for the feedback! I can certainly try to improve the structure of the README, though I'm not sure if I agree with some of your points about giving more priority to non-Linux users. The thing is, at least in my eyes, Gtk generally feels terrible on platforms where it is not native (I would in fact even avoid using it in a Qt-based Linux desktop setup, just as I avoid Qt-based applications as far as possible in my Gtk-based one), and at any rate the ports are often lacking even in features (for instance, last I checked, Windows Gtk would not allow me to read tablet pressure information). If you are using Windows, and don't care for "free (speech and beer)", why would you even want to use anything other than OneNote? I'm somewhat wary of repeating the mistakes of Firefox (and GNOME) of snubbing a likely target demographic to court an unlikely one.

(Regarding Mac, I unfortunately don't have a Mac and neither does anyone who I know well enough to ask to borrow theirs, though someone did in fact contribute homebrew-based build scripts that supposedly work at some point. I just have no idea how to package the result to make it easy to install.)

I've been working on one (https://github.com/blackhole89/notekit) for a while now (which, unlike the aforementioned, also is not built on Chrome/Electron). Unfortunately it seems to be pretty hard to get the word out, or at least I haven't found any better strategy than to pounce, as I am doing now, whenever I see a HN thread about markdown editors (which invariably wind up having some comment thread lamenting the lack of WYSIWYG and/or non-Electron editors).

Thanks! I recommend using the repositories or the automated builds or compiling from source, as opposed to the tar.gz binary builds linked directly from the README, as those are somewhat badly out of date now. (I probably should update them at some point.)

I'm actually working on one (https://github.com/blackhole89/notekit). It's native (Gtk+/C++) rather than Electron, too.

> As soon as you wrap code in a function for reuse, the proximate call site no longer has anything to do with the widget ID.

That's a good point.

(a) hash the entire call stack (though that might produce false negatives, i.e. consider two UI elements that should be the same distinct?)?

(b) put the burden on the reusable function to mark itself as such by pushing/popping an identifier of its own call site on the ID stack?

> The real hack is implicit IDs, not the ID stack (which is just a way of implementing a hierarchical namespace like file system paths or URLs). The fact that implicit IDs just work 99% of the time and only require manual intervention 1% of the time is a false siren song into letting you believe a 100% solution is desirable (you have to consider the marginal cost of what it would entail).

Well, this is just the standard problem of library design, isn't it? You always have to figure out the appropriate tradeoff between supporting rare cases and making common ones easy. (Of course, you can often do both; in this case, you probably could both give "explicit ID" and "call site ID" versions of each UI element API.)

Yeah, I essentially copied imgui's ID stack approach for my experiments too. (I've been using imgui for some other projects to great success.) It still seems like a hack; I'm quite surprised that no programming language (I'm aware of) makes it possible to uniquely identify callsites like that. Maybe it hints at a more general blind spot/free real estate in PL design :)

(On the off chance you're curious, I just pushed some previously unpushed updates to that experiment I had sitting around, so now it has labels and text entry too. I guess the real test of the architecture would still be making an alternative "rendering backend" based on win32 widgets or something.)

Oh, yeah, the Stack Overflow post especially seems to talk about very similar problems to what I have been grappling with. Thanks for the pointer! The code is pretty opaque to me, though; it's been well over a decade since I've last had any interaction with the WINAPI programming style, Hungarian notation and all.

I wonder why he arrives at the conclusion that he needs a full-fledged DSL for what he is doing. I remember that at the time I was working on this, the impression I had was that a lot of my problems would go away if only there were some unique way to identify every distinct invocation of a function (so I could use data along the lines of "you are currently in the 3rd call of Button() in something.cpp"). __FILE__ and __LINE__ get close but don't disambiguate between multiple calls on the same line (and anyhow would need to be baked into the invocations with macro hackery).

Has anyone made a serious attempt at a intermediate-mode frontend to desktop GUI toolkits (as opposed to single-application ones that are rendered by some general-purpose accelerated graphics library)? I've experimented a little bit in the past (https://github.com/blackhole89/instagui/blob/master/main.cpp, whose implementation is based on something pretty close to my understanding of Elm's "virtual DOM" diffing; don't mind the kooky custom macro system), but wound up bumping into a lot of nasty little problems that made hacking on it not a lot of fun.

I actually like Ardour's GUI a lot (and am grateful that it uses Gtk: KDE never ran stably on a machine I owned, and I found that in Gtk-based environments, it is actually always the Qt applications that are inexplicably unstable). The main problem that prevents me from using it is that I keep running into show-stopping bugs in the backend: for instance, MIDI recording (including even "loopback" where I just recorded the output of another MIDI automation channel playing in Ardour itself) in 5.12 kept dropping note-on/-off events, and more critically, there is some persistent issue that results in ZynAddSubFX plugin settings getting corrupted through save-load cycles. I have confirmed that the latter is still around in 6.0, and the furthest I have gotten in pinning it down is the observation that the correct state seems to get saved in a plugins/<id>/state<n> folder, but this is not what gets loaded and loading and then saving again without doing anything else results in it creating a state<n+1> subfolder with the garbled state without state<n> being touched.

I haven't had any luck getting responses to bug reports, and anyhow it seems that ZynAddSubFX should be a sufficiently common plugin that if this bug were easy to reproduce, someone else would have stumbled upon it by now (and so it probably arises due to a weird interaction with something else that's particular to my setup).

This looks like a more mature/different approach to the same thing I tried to do in a side project a while ago (https://github.com/blackhole89/macros), down to similar aesthetic choices. However, I pitch my project as a macro system rather than compile-time execution.

While here the metalanguage is itself a C++-lookalike, in my project I wound up with something that is perhaps better described as a weird TeX (which seems to be what happens naturally when your machine model is based on binding and substitution).

On one hand, C++ is surely more powerful/expressive and there is elegance to having the language and metalanguage use the same idiom. On the other, I feel like this might actually making Circle a bit more confusing to use at times, as it becomes less clear exactly when what parts of the code are executed, and you could even imagine a typo accidentally lifting a part of the code from runtime to compile time, resulting in mystifying bugs. (I am myself puzzled by the "serialize structs generically" example: does it imply that the template is specialised before the @meta for is executed?)

I made a fork of this that gives you some additional control over how links are treated - specifically, you can set it up different rules for what container to open a page in depending on what container it was opened from: https://addons.mozilla.org/en-US/firefox/addon/containers-wi...

The rationale is that you rarely want pages that you open from random Facebook posts or Reddit submissions, or pages that you arrive at by following more links from those, to have access to your Facebook or Reddit login information.

As I see it, the expectations I'd have towards a mobile note-taking tool (like Google Keep) are different enough that I think it should be a separate program. Folder structure would be fairly cumbersome to navigate on a cellphone, and few keyboards make it particularly easy to type the symbols that control Markdown styling; on the other hand, you'd probably really want solid support for shopping/TODO lists and the like, for which Google's tiling organisation paradigm seems very useful.

Submission statement: this is a Firefox extension I've been working on for a while, forked from Multi-Account Containers (which unfortunately seems to be very lightly maintained/not seeing much further development). Apart from some papercut solutions (based on personal opinions: the close-and-reopen mechanism to pick the right container for a tab seems to cause TST physical pain, so I tried to reduce the cases where it fires), it adds one big feature, which is container transition rules: rather than just setting a single default container for a website, you can say that you want to open it in a particular container X whenever it was opened (via a link, redirect, ...) from container Y.

This solves a common issue I was encountering when browsing, where I'd start out with some Facebook tab (dutifully containerised), click some links in the chat, follow some more links from the pages arrived at, and before long I'd have a subtree of 30+ tabs all being in the Facebook container while having absolutely no business seeing my Facebook cookies.

There's more documentation and some usage examples on the addon page. Of course, this is beta-quality software. I'd appreciate if you could try it out and give feedback and bug reports. Also, you should disable Multi-Account Containers before running this, since they both hook into the same events and I don't want to know what happens if they disagree over what container a page should go into.

See also the Reddit discussion, where I provide some more rationale: https://old.reddit.com/r/firefox/comments/abpssw/containers_...

I wrote a similar tool a while back which provides a more natural way to implement full-fledged programming language constructions such as loops (the example in the documentation here, which involves redefining a macro and explicit evaluation, feels a bit convoluted in comparison...), but is specifically tailored towards supporting C/C++: https://github.com/blackhole89/macros

I suppose the only strictly language-specific feature is the support for C string literals and it could otherwise also be made to run on top of different tokenisers.

m4 is surely more powerful still, but its syntax always struck me as somewhat jarring both on its own and in the context of any other language.

Submission statement: I have previously tried submitting it to not much avail, but the program has matured a lot since then. The repository includes a number of examples (in examples/) that are representative of the current version, such as an implementation of Restricted Boltzmann Machines (screenshot: https://raw.githubusercontent.com/blackhole89/graphicdepicti...). Apart from typesetting and layout work, the new ability to essentially associate arbitrary JavaScript objects with vertices and edges generally lends itself quite naturally to the local computation involved in many machine learning applications (as you can associate compute()-type functions with each vertex that read inputs and/or pass results to outputs).

Well, there's a README.md (that includes the screenshots) that Github displays under the repository listing, but I suppose there are sufficiently many files in the repository that not everyone would automatically be inclined to even scroll far enough down...

Visualising algorithms is an interesting angle I have largely neglected so far, since it's pretty different from the purpose I originally built the program for. I could try adding some more examples in the spirit of the sandpile model from the animated GIF, like pathfinding or selfish routing. Thanks for the suggestion!

I released a fairly major project (a research-oriented workbench for graph manipulation) in a state of comparitive usability: https://github.com/blackhole89/graphicdepictions

The main takeaway for me was that, unless you can tap into a preexisting pool of demand, grabbing people's attention is as hard and effort-consuming, if not more so, than actually solving a problem. One-on-one, I always had an easy time convincing people I knew that the program is useful for them, but simply throwing it out there and hoping someone would notice it was unexpectedly fruitless.

This is a tool that fell out of needing a quick way to test a variety of hypotheses regarding a problem that had a natural interpretation in terms of graphs for an academic project. I started it by plugging together bits and pieces of old gamedev projects because I was fed up with having to pore through textual representations and repeatedly write very similar code to make it at least slightly more palatable, but before long, it had grown into something sufficiently big and useful that I figured I might as well clean it up for an actual release.

A good representation of its current functionality is this short video of executing the sandpile model (https://en.wikipedia.org/wiki/Abelian_sandpile_model) on a graph: https://raw.githubusercontent.com/blackhole89/graphicdepicti...