loadtxt VS rust-headless-chrome

It really depends on what part of Numpy you're using. You can easily leave Numpy's text parsing in the dust. And if you're doing element-wise operations on arrays, you can easily see 2-3x improvement with just numba.

Amdahl's Law will catch up with you really fast as you add threads with this strategy, but it's simple and is amenable to formats where you may have a delimiter in the middle of a record. For situations where you need maximum scaling and don't have the possibility of delimiters scattered into records, you can use the strategy I used to implement a faster numpy.loadtxt: https://github.com/saethlin/loadtxt/blob/master/src/inner.rs#L84 The general idea is that you divide the file among thread boundaries by splitting it on byte boundaries, then seeking from that byte offset to the end of the next record. This gets you non-interleaved sections so there's no duplicate parsing.

I'm using this to fill forms interactively and emulate a user. https://github.com/rust-headless-chrome/rust-headless-chrome

Afaict, it drives a stock Chromium instance. I'm not sure how Fidelity is detecting it, but they detect it even in normal headful mode. Idk if there's some JS that notices there's no mouse-move movements.

It's just not worth the headache. I despise bending over backwards for companies like this. But obviously I have no choice since they're my 401k plan facilitator.

Thanks, I was looking into that as well and got their example up and running. I also saw that chromiumoxide mentions rust-headless-chrome in its references section in the README, which is also updated recently, any differences between the two? Seems like chromiumoxide is async with code gen whereas rust-headless-chrome is not, is that right?

mdBook allows you to create book from markdown files. It's pretty much alike Gitbook but implemented in Rust. However, unlike Gitbook that supports using calibre for generating PDF, for a long time, mdBook doesn't support generating PDF files natively, and supporting that is also not in their roadmap. Existing plugins (backends) such as mdbook-latex that utilize Tectonic as well as pandoc solutions will generate a PDF page that doesn't unify with the existing mdBook generated HTML version. Considering these facts, I created a mdBook backend named mdbook-pdf for generating PDF based on headless chrome and Chrome DevTools Protocol Page.printToPDF.

There's https://github.com/stevepryde/thirtyfour for Selenium, and https://github.com/atroche/rust-headless-chrome for Chromium.

I published headless-chrome a few years ago, but I haven't cut a new release in almost two years now — despite the issues and pull requests piling up. I'm not relying on it for my work like I was previously, and I just don't have the spare energy to be a good maintainer.