If you're building a CLI tool that can churn on large amounts of data for hours and you don't implement any kind of progress output, we won't become friends.
(And no, it refuses to work with stdin, else I would've just used pv and be done.)
@djh@tokudan I'm not exactly in a hurry (but it'd be nice to get some progress information nevertheless), and yeah, while I could be running this on an extract, I'd also like to know how it behaves when being fed the whole planet. 🤷♂️
So far, my preliminary verdict is "I need to find another way", but I want to test it first anyway.
@scy if you want to test another geocoder (assuming that is what you’re doing) i have a more space efficient version on my github and with progress output while it’s doing its thing 🙂 https://github.com/dunkelstern/osmgeocoder (implementation is mainly in postgres stored procedures with a small python shim to access it and throw stuff against) if you want to experiment and have questions feel free to ask. (No guarantees the thing works correctly in countries that have no street names like japan)
@dunkelstern Interesting, thanks for letting me know!
The thing is, I'm explicitly trying to avoid Postgres (not that I don't like it, I just try to keep the number of daemons low) and would want to use SQLite (or Spatialite) instead.
@scy Not sure about what top etc. report on Linux, but on macOS there are “total bytes read/written” statistics right in Activity Monitor. Surely there must be a similar thing?
@manawyrm Yeah the thing is, the default action for USR1 is to terminate, so I'm not risking sending this to that effing process now, 2 hours into however long it's gonna take…
Add comment