joouha

Just noticed in the model's metadata:

> MiniLMv2 L6-H384 (30M params) progressively distilled L24→L12→L6 from RoBERTa-large-v8 teacher (neobert-v2 recipe, min_words=0). Byte-level BPE tokenizer. INT8 quantized.

Not GP, but I too was interested in this slopdetect-minilm-v3 model.

The model appears to be similar to MiniLM-L6 (384 dimension, 6 transformer layers) but uses RoBERTa/GPT-2 style embedding/tokenization (50265 vocab size), used for binary classification, and quantized to INT8.

My guess is that is was distilled from roberta-base, then fine-tuned on freely available pile like artem9k/ai-text-detection-pile or similar.

It's a nice model - I've just used it to create a browser extension which highlights text based on how likely it is to be LLM genereated.

Edit - a quick google search reveals ibm-granite/granite-embedding-30m-english with the same architecture: slap a binary classification head on, fine tune, job done.

This looks really nice in the screen-shots.

I'm working on what is effectively a fork of prompt_toolkit [1], which supports many modern terminal features I needed for euporie [2], such as terminal graphics, extra text styles, color palette detection, terminal clipboard, synchronized outputs, CSI-u, mouse pixel positioning, etc.

I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)

[1] https://github.com/joouha/euporie/tree/dev/packages/apptk

[2] https://github.com/joouha/euporie

tmux now supports sixel graphics, so you can use that instead if running euporie in tmux

> is there a way to swap the jupyter kernel within euphorie to something else more minimalist?

You can use euporie-console for a REPL-like terminal experience (still with rich outputs) if you don't want the full notebook experience.

You can also select the `local-python` kernel in euporie to run code using the local Python interpretor which runs euporie, instead of connecting to a Jupyter kernel.

> And when you run a project with ssh, there are ways to give access to other users with user:password if I may ask?

> I also wish to ask if there is a way to sign in to jupyter instance like that itself perhaps?

euporie-hub supports spawning notebook instances for connected users, but I haven't implemented collaborative editing like JupyterLab supports (yet). I believe that jpterm [1] might support this.

[1] https://github.com/davidbrochart/jpterm

Yes - you need to use the IJulia kernel: https://github.com/JuliaLang/IJulia.jl

You can absolutely run euporie in tmux. It's useful to do so when using long running notebooks over SSH, so you can disconnect and reconnect later.

I'm specifically interested in querying for support of particular glyphs (e.g. the symbols for legacy computing block), so applications can use a different fallback if it is know that a particular glyph cannot be rendered and will break the interface.

I agree that the addition of sending custom glyphs to the terminal is potentially problematic.

It's very interesting to learn about the newly proposed glyph protocol [1] in the linked blog post. I was bemoaning the lack of exactly this here about 6 months ago [2]!

[1] https://rapha.land/introducing-glyph-protocol-for-terminals/

[2] https://news.ycombinator.com/item?id=45805072

No evolution necessary! With my project, euporie [1], you can have use your data science notebooks with graphical image outputs, HTML, LaTeX, etc, all in the terminal.

[1] https://github.com/joouha/euporie

Maybe https://github.com/wesm/msgvault will do what you need?

Modshim does more than just wrap the external API of a package - it allows you to tweak something internal to the module while leaving its interface alone, without having to re-implement most of the package in order to re-bind new versions of objects.

There are a couple of example of this readme: (1) modifing the TextWrapper object but then use it through the textwrap library's wrap() function, and (2) modifing the requests Session object, but then just using the standard requests.get(). Without modshim (using standard monkey-patching) you would have to re-implement the wrap and get methods in order to bind the new TextWrapper / Session classes.

This sounds like an ideal use case for modshim [0]

One of its intended use cases is bridging contribution gaps: while contributing upstream is ideal, maintainers may be slow to merge contributions for various reasons. Forking in response creates a permanent schism and a significant maintenance burden for what might be a small change. Modshim would allow you to create a new Python package containing only the fixes for your bugbears, while automatically inheriting the rest from upstream httpx.

[0] https://github.com/joouha/modshim

Thanks for the bug report. It has been fixed in the latest version of euporie.

I use chafa extensively, and it really is the best tool for terminal graphics in my opinion.

I use it as a fallback option for terminals without proper terminal graphics support in my TUI Jupyter client, euporie.

There are Python bindings available: https://github.com/GuardKenzie/chafa.py

I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters.

This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.

I've tested it works from 3.9 to 3.14

It should in theory be possible to mount the new virtual package over the lower module - but I don't think works currently (I'll have to test this). Doing this would make modifications available globally like you describe.

Let me explain what inspired me to create modshim:

I've written a Jupyter client for the terminal (euporie), for which I've had to employ monkey-patching of various third-party packages to achieve my goals and avoid forking those packages. For example, I've added terminal graphics support & HTML/CSS rendering to prompt-toolkit (a Python TUI library), and I've changed aiohttp to not raise errors on non-200 http responses. These are things the upstream package maintainers do not want to maintain or will not implement, and likewise I do not want to maintain forks of these packages.

So far I've got away with monkey-patching, but recently I implemented a kernel for euporie which runs on the local interpreter (the same interpreter as the application itself). This means that my patches are exposed to the end user in a REPL, resulting in potentially unexpected behaviour for users when using certain 3rd party packages in Python through euporie. Modshim will allow me to keep my patched versions isolated from the end user.

Additionally, I would like to publish some of my patches to prompt_toolkit as a new package extending prompt_toolkit, as I think they would be useful to others building TUI applications. However, the changes required need to be deeply integrated to work, which would mean forking prompt_toolkit (something I'd like to avoid). modshim will make it possible for me to publish just my modifications.

Perhaps it's a somewhat niche use-case, and modshim is not something most Python users would ever need to use. I just thought it was something novel enough to be of interest to other HN users.

> messing around with import internals in python is extremely tricky to get right

This is true! modshim has been the most complicated thing I've written by some way!

Toy could try using euporie [1] to run Jupyter notebooks in the terminal

[1] https://github.com/joouha/euporie

I've just found that Mintty supports this

https://github.com/mintty/mintty/wiki/CtrlSeqs#overstrike

This would allow more complex shapes to be drawn by combining multiple glyphs, which would be useful for complex TUI applications (there are only a limited number of box-drawing characters available) Also, this could allow drawing more than two colours per terminal cell.

It's up to individual applications how they implement user input. All of this is entirely possible in modern terminal emulators - look at the micro text editor, for example.

I guess most shells (bash, zsh, etc.) keep things "traditional" for backwards compatibility reasons.

Do any terminals support overprinting? This could radically change what is possible in TUIs

This is a nice summary.

It would be good if there was more emphasis on graceful degradation in TUI libraries, such as falling back to ASCII art when terminal graphics are not supported.

> Some new TUI libraries, such as vaxis, are designed specifically to avoid using terminfo at all and exclusively use queries to determine feature capabilities.

I take this approach in euporie [1], having encountered the same issues with using terminfo as discussed. However, there were a few terminal features which I could not find a way to query - iTerm2 graphics support, for example.

[1] https://github.com/joouha/euporie

Euporie is the most complex TUI application I have built:

https://github.com/joouha/euporie

It consists of a TUI editor (and interactive REPL) for Jupyter notebooks, and supports displaying rich output in the terminal (images, LaTeX, HTML, interactive widgets, etc.).

You might be interested in https://github.com/fsspec/universal_pathlib

I wrote an HTML renderer [0] as part of euporie [1], which I'm planning on eventually spinning into a new terminal browser (but it needs a bit more work first).

There's no JS support, but a good chunk of CSS is implemented, and images are displayed using terminal graphics if your terminal supports it.

You can try it out by passing a URL to `euporie-notebook`.

[1] https://github.com/joouha/euporie/blob/dev/euporie/core/ft/h...

[0] https://github.com/joouha/euporie