This reminded me of a prior discussion[0] on bulk data generation in SQLite with Rust (vs Python vs PyPy) which previously led me to trying out two different techniques using just SQLite[1]. The approach here is so similar I tried my prior solution on the slowest VPS I have access to (1 vCPU core 2.4GHz, 512Mi, $2.50/month from vultr):
sqlite> create table users (id blob primary key not null, created_at text not null, username text not null);
sqlite> create unique index idx_users_on_id on users(id);
sqlite> pragma journal_mode=wal;
sqlite> .load '/tmp/uuid.c.so'
sqlite> .timer on
sqlite> insert into users(id, created_at, username)
select uuid(), strftime('%Y-%m-%dT%H:%M:%fZ'), 'hello'
from generate_series limit 100000;
Run Time: real 1.159 user 0.572631 sys 0.442133
where the UUID extension comes from the SQLite authors[2] and generate_series is compiled into the SQLite CLI. It is possible further pragma-tweaking might eke out further performance but I feel like this representative of the no-optimization scenario I typically find myself in.
In the interest of finding where the bulk of the time is spent and on a hunch I tried swapping the UUID for plain auto-incrementing primary keys as well:
sqlite> insert into users(created_at, username) select strftime('%Y-%m-%dT%H:%M:%fZ'), 'hello' from generate_series limit 100000;
Run Time: real 0.142 user 0.068090 sys 0.025507
as well as explaining their behavior, albeit briefly:
> Extras union in the dependencies they define with the dependencies of the distribution they are attached to.
The resolution on . is explained by the pip documentation[1]:
> pip looks for packages in a number of places: on PyPI (if not disabled via --no-index), in the local filesystem, and in any additional repositories specified via --find-links or --index-url. There is no ordering in the locations that are searched. Rather they are all checked, and the “best” match for the requirements (in terms of version number - see PEP 440 for details) is selected.
ZFS has been on my list of things I should learn "some day" for a long time. I installed Fedora a while ago and ended up opted into Btrfs without really trying. I have been pleasantly surprised with it and have used it on 2 low-impact servers and 3 personal computers for about a year.
I don't tend to do anything very interesting to tax the filesystem so it is most important that things just work day to day and the less maintenance the better. I found a few use cases[0] for the copy-on-write abilities of Btrfs (built into systemd-nspawn) after switching but even that was a case where something I was previously doing was made instantly faster rather than working out a btrfs incantation.
I've recently been trying out a nifty backup tool[1] to try out a snapshot feature locally. This one did require two btrfs specific commands to restore a backup (`btrfs {send,receive}`). Once again though, this was an additional feature I decided to try out and not really required for my day to day. For me personally Btrfs has been easy to adopt because of how low-friction it has been to add and learn incrementally.
I use ZFS (4 x 2TB drivers in mirror mode = 4TB pool) for my backup system since 2014. I never had to "learn" anything ZFS related, the interface is fairly simple if you're familiar with CLI apps and the documentation for ZFS is crystal clear. The system overall is very easy to reason about. Works in a "set-and-forget" mode for me, every now and then I create, destroy or resize some volumes. I had to swap a broken HDD and re-silver once in 5 years it was two hours work IIRC.
The main drawback you have to keep in mind is that you cannot modify pool size. Every pool can have one or more volumes. For advanced features like ARC caching, I'm just using sensible defaults.
Also, keep in mind that ZFS need at least 8GB of RAM, possibly 16GB for up to 16TB of data.
As a specific example I routinely ran into forms that rendered like this (hidden scrollbars in three different browsers concealing content, though Safari rendered _just_ enough text that it might indicate there was more to see): https://nprescott.com/public/no-scroll-bars.png
In this specific case it is probably obvious enough that hey maybe I need to try scrolling randomly to find "baccalaureate" but the particular form that drove me to capture the above was littered with similar cases where it wasn't at all obvious. More than anything though the invisible scrollbars just meant I had to second guess every single form I ever submitted.
Ok, I haven’t thought of this inline case since I haven’t seen it in a while. But to be honest I’m not sure I would have noticed the scroll bars if those were full width elements. Personally I’d prefer some other visual indicator at the bottom of a cut off element or page.
I have tried with both python 2.7.18 and python 3.8.6 using Emacs 27.1 and the excerpt works without issue for me; I have no configuration (emacs -Q) beyond pointing org to my virtual environment and allowing python evaluation in org-babel:
There have been a few different fixes around the "last line" return value over the years[0][1] but I can't really remember something like your example not working for me personally.
The chromium bug ticketing system is all but unreadable to me. The OP ticket itself is closed and links to another instead, is there recent movement of note?
I know igalia[0] was working on this but I haven't been following the bug trackers directly. Their site and news section gives a better sense of the progress and includes small demonstrations with many of their updates.
Private collections based on what I've seen. Occasionally things come up for sale, this page dates to within the last few months for example: http://watrophy.com/files/lispm/lisp-sale.html
I wrote up a few of my own thoughts[0] on moving away from writing markdown to writing HTML directly. At this point I have a small bit of code to wrap things into an <article> tag include a <header>, <footer> with links to a home page and include some boilerplate like <meta> tags. I don't think I've sacrificed anything in terms of best practices and actually gained a few things in writing more semantic HTML which I think aid in assistive technologies[1]. I actually hope people will "view page source" on my pages anymore -- a big part of getting to where I am has been testing against alternative browsers like eww and w3m.
I've been writing HTML directly for my blog [1] for 20 years [2] and back around 2003 I started to be a bit more pedantic about the HTML I use, so I always (try to) close every tag. About five years ago I set up a gopher server [4] and use it to mirror my blog. I went the easy route and decided to use Lynx to convert the entries from HTML back to text, and ... it looks horrible. Now that the Gemini protocol [5] has stabilize, I've decided I should convert the HTML to text myself, and because I decided back in 2003 to close every tag, it's easy to do (after spending an evening cleaning up a few entries here and there---there are over 1,000 entries pre-2003 that need extensive cleanup though---sigh).
The optional tags make it easier to write, but make it far harder to mechanically process later if need be.
In the interest of finding where the bulk of the time is spent and on a hunch I tried swapping the UUID for plain auto-incrementing primary keys as well:
Clearly UUIDs are not free![0]: https://news.ycombinator.com/item?id=27872575
[1]: https://idle.nprescott.com/2021/bulk-data-generation-in-sqli...
[2]: https://sqlite.org/src/file/ext/misc/uuid.c