joouha
Joined 5 years ago
Joined 5 years ago
> 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.
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.
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
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.
I agree that the addition of sending custom glyphs to the terminal is potentially problematic.
[1] https://rapha.land/introducing-glyph-protocol-for-terminals/
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.
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.
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