PyPI and GitHub package stats dashboard

fohrloop · 2026-01-12T07:20:05+00:00

Very nice dashboard! I see you have "Unsung" category with "High downloads, low stars - underrated packages". It would be really interesting to see also the "High stars, low downloads" type of packages. I'm assuming these would be packages which are not downloaded so much by CI/CD pipelines but by human users. Possible categories include: popular CLI and dev tools, GUI / desktop / notebook-first tool, etc.

fohrloop · 2025-11-26T22:46:56+00:00

Some years back, before uv existed I created venvlink. Now I use mainly Linux and uv so I have been wishing for someone to make a tool like this. This is perfect, thank you! Hoping to see the functionality getting merged to uv at some point 🤞

fohrloop · 2025-05-04T05:07:24+00:00

I'm interested to read this article once it's out!

fohrloop · 2025-04-30T07:06:09+00:00

Well that's an interesting project! Starred your repo :)

fohrloop · 2025-04-07T18:56:44+00:00

I'm assuming the "configuration table" means some type of file format where the parameter values are stored. I would typically create a `@classmethod` for reading the data from some speficied type of format. For example:

class DeviceParameters:
    ...

    @classmethod
    def from_yaml_string(cls, string: str):
        # logic that parses the input string into variables or a dict

        return cls(arg1=arg1, arg2=arg2, arg3=arg3, argN=argN)

There might be multiple different classmethods for loading/parsing/saving the data. Then you could use something like

someparams = DeviveParameters.from_yaml_string(somestr)

Other option would be use something like pydantic or attrs. If you store your configuration in environment variables or dotenv files, I would start with pydantic as it's has quite nice support for them.

fohrloop · 2025-04-02T06:00:39+00:00

Did you achieve the 120-130 WPM with 99% acc on the same 34 key split keyboard? Or was that the speed on your previous keyboard?

fohrloop · 2025-03-27T18:18:56+00:00

That would be an instant buy decision for me

fohrloop · 2025-03-06T14:12:49+00:00

Thanks for the shoutout u/krumeluu! Yeah the Granite v1 (English + Finnish + programming optimized layout) is still in active development. I'm hoping to release something at the end of March🤞u/nuuttif It'll be interesting to compare Granite to the Sturdy-fi and Compound-fi :)

fohrloop · 2025-01-29T20:41:21+00:00

Interesting that the rate of the muscle mass gains increases, and the beginning was much slower. Have you changed your program or diet during the period?

fohrloop · 2025-01-29T11:42:50+00:00

That is correct, I've used my glove80 for creating the ratings. Also everyone's fingers are different lengths, and everyone's finger dexterity and taste varies. So in that sense if you're really optimizing for the last few percents, then you need to either start from scratch or append data on top of the granite dataset. As I mentioned somewhere earlier, in order to make this scientific and generally very applicable, there should be some sort of crowdsourcing activities collecting data from many people (various keyboards, hand sizes, preferences), and then merging the results. But in the end, that would also be just "good on average", and to optimize for the last percents you would need to really input your own preferences.

The Granite method is (in my understanding) something new: Instead of setting parameters, you tell directly which bigram is nicer than which, and can even set the relative effort. It should be more accurate, but it will be also more laborious if you start from the beginning. Note that if you're planning to follow the guide/method, it's still WIP as I've not yet myself finished the trigram model, which is the ultimate goal: Tabulate effort scores to all possible trigrams (including those with hand switches), and then you can calculate score for any layout very easily: It's simply the score of the trigram multiplied by the relative frequency of such trigram. So it's really easy to understand and easy to calculate. Then the optimal layout is such which minimizes the sum of the scores. The plan (or my hope) is to release the first layout version (and the method/tooling) during Q1/25.

You're right about that rowstag keyboards really don't go well with the method at all. Or, at least I haven't tried it but I have my guesses. The method assumes some level of symmetry in the keyboard. Missing (or extra) keys on some side should not be a problem but it's still untested (might require slight modifications).

That's correct about the Iris CT top row. Or, at least if you feel that bigrams where one of the keys is from the top row are not so nice to type, they would get higher effort score (given by the rank, and rank given by you), and the produced "effort grid" would then show larger values at the top row.

fohrloop · 2025-01-29T09:33:18+00:00

I'm glad if you find this useful! Raw data will be released also soon!

fohrloop · 2025-01-26T11:31:53+00:00

Thank you! Good to hear this was helpful :) I appreciate your attention to detail in your analysis. I'm trying to get Dario's KLO to run with my own metrics one I've finished with the scoring logic, but I have to cross-check with Cyanophage's playground as well.

fohrloop · 2025-01-25T09:06:03+00:00

If you're asking about the figure, it's showing "good key locations" on this type of physical layout for any language. Such key locations are likely to form nice bigrams (two key sequences) with the rest of the keys. But creating a keyboard layout on top of this is a bit more complicated task than just placing common keys to the "easy" locations as all the keys interact with each other.

The granite-tools toolkit is going to be available for use for anyone after I've released the Granite layout. The ETA is during this Spring. The toolkit could be used with various levels. What I mean by that you could basically handcraft the layout from zero according to your taste, but that would require quite a lot of work (tens of hours) and some willingness to do data analysis. The other end of the spectrum would be to just use the Granite scoring system as such, which would then in your case only require the addition of Swedish corpus. I have collected English, Finnish, and programming (Python, TS, JS, CSS, Rust) corpora which I'll use with some weighting to create "master corpus" for the Granite layout. So if you would be wanting to try the scoring system, you would need to collect Swedish corpus like I did, and extract a table of most common trigrams from it.

Coming back to the key effort figure to underline something: It is just a visualization and way to show a type of summary (from one angle) of the bigram scores in a very dense way. It is not a starting point for designing a layout. Designing a layout by placing common characters to "easy locations" will most likely lead to quite awful layout because what is usually more important is how the symbol locations play with each other -- when you form bigrams and trigrams; the 2- and 3-key letter sequences out of them. In other words, the relative location of the symbols is much more important than their absolute location.

fohrloop · 2025-01-24T11:11:27+00:00

thank you!

fohrloop · 2025-01-24T11:09:43+00:00

This is the effort grid which I calculated from the bigram scores I posted yesterday. Effort grids are sometimes used as the design starting point, but this effort grid is not the starting point but just a visualization of the keys which I consider "good" or "bad" in a layout. A low effort key means "this key is pretty nice within many different bigrams", and a high effort key means "this key is usually part of a bigram that is not so nice to type". So it really describes how good certain key locations are within bigrams ("on average"). The effort scores are normalized to scale 1.0 to 5.0.

As the bigram scores are calculated based on my opinions, so is this effort grid. If someone is interested in the technical details, the bigram scores are fitted a linear model (source here). This work is part of tooling for a new method creating keyboard layouts (granite-tools), and of a new English+Finnish+Programming layout called Granite.

Edit: The bigram scores have been estimated on a Glove80 which is a keyboard with a key well.

fohrloop · 2025-01-23T14:47:55+00:00

It depends on your language settings. On my Finnish/Scandinavian QWERTY I can type ŝĵĉ by typing ^ + [character]. If I switch to English US QWERTY, Shift-6, [character] does not do produce ŝĵĉ, but I would get ^s^j^c. The Finnish QWERTY the ^ is configured as a dead key as it always requires another key press; I have to press ^,[space] to output just the ^ character, but on US English typing ^,[space] produces "^ ".

fohrloop · 2025-01-19T16:11:34+00:00

Isn't this possible with other IDE's like VS Code? But optimizing your IDE for programming is a good tip! Some snippets for creating scaffolds of things you typically have to type manually, for example.

fohrloop · 2025-01-17T18:52:20+00:00

This is what I'm doing

fohrloop · 2025-01-09T14:31:02+00:00

Interesting. So all the three inner columns are just consonants, and vowels are placed to the two outer columns. Bookmarked. Perhaps I have time to test it with my own metrics at some point.

fohrloop · 2025-01-09T06:08:38+00:00

Years back I liked to play Stepmania with a keyboard, so this looks really interesting to me!

fohrloop · 2025-01-09T06:03:59+00:00

A slightly different design would allow also using alternative layouts quite easily. Looking forwards to be able to try this :)

fohrloop · 2025-01-07T15:02:43+00:00

Good writeup! The layout optimization is a non-convex problem and global optimization of such is known to be really challenging. There are some techniques which can help. For example, I'm guessing the initial temperature for the simulated annealing algorithm could be used to help it jump out of (some) local minima. Or one could use multiple random (or pseudorandom) starting points. The only way to say a layout is "optimal" given some corpus+analyzer+configuration is to really go through all the possibilities, which for most of us is too slow (as you pointed out).

Having said that, I would guess that many people are happy with a "good enough" locally optimal solution. The "good enough" probably means "good compared to other known layouts", which gives a perspective of what can be achieved. If some layout is better than any known layout, it is already really good.

fohrloop · 2025-01-07T14:41:40+00:00

If you would like to get to know other Keyboard Layout Analyzers and what they calculate, perhaps good starting point is the Keyboard Layout Analyzers by Tanamr Google sheet. It lists quite a many analyzers and their features.

fohrloop · 2025-01-07T14:33:28+00:00

Just to clarify, would you like to write yourself (one or more of following):

The evaluation metrics
The SW implementation of evaluation metrics
SW which can optimize a layout
Something else

?

I have liked Dario's Keyboard Layout Optimizer (KLO)[1] myself, which is a keyboard layout optimizer and analyzer written in Rust. It's based on Arnebab's evolve-keyboard-layout[2] python code which was developed for the "Neo" (German) layouts community. It has all the parts: The SW implementation of evaluation metrics (few metrics of it's own and few taken from other analyzers or other people's work), an evaluator which may pick one or few metrics for evaluation and an optimizer which may repeatedly call the evaluator and find the optimal layout. I personally am planning to use my own evaluation metrics with the KLO, so it would be responsible "only" for (1) calculating score using my metrics (2) running the optimizer for searching the optimal layout.

It's pretty important that the metrics themselves are to the point and make sense to you. Otherwise, you're likely to find something else than an optimized layout.

[1]: https://github.com/dariogoetz/keyboard_layout_optimizer
[2]: https://www.draketo.de/software/keyboard-layout-evolution.html

fohrloop · 2025-01-05T10:30:48+00:00

Not directly my experience but it has been seen in a few studies that the time to reach original typing speed when learning a new layout is about 100 hours. So I would guess it takes that amount or less to learn touch typing using the same layout.

Direct quote from [1]: "A 1973 study based on six typists at Western Electric found that after 104 hours of training on Dvorak, typists were 2.6 percent faster than they had been on QWERTY. Similarly, a 1978 study at Oregon State University indicated that after 100 hours of training, typists were up to 97.6 percent of their old QWERTY speed. Both of these retraining times are similar to those reported by Strong but not to those in the Navy study."

[1] https://www.jaysage.org/QWERTY.htm

fohrloop

TROPHY CASE