91–100 of 247 posts
Earlier quoted context omitted.
There you go folks: bsky-social-h3d4w-u6yn4 bsky-social-74bqi-vkmcq bsky-social-n3fdq-46nxz bsky-social-yippe-32vdr bsky-social-l2fbt-xnscx
Any more?
bsky-social-ge2mz-mfmpi
bsky-social-hykwa-x3ox4
bsky-social-gh4mt-2od6p
bsky-social-dejzy-mmcxf
edit: all gone :(
Earlier quoted context omitted.
Damn, they all gone.
There you go folks: bsky-social-h3d4w-u6yn4 bsky-social-74bqi-vkmcq bsky-social-n3fdq-46nxz bsky-social-yippe-32vdr bsky-social-l2fbt-xnscx
What do they mean by "Since SQLite does not support concurrent transactions" - it supports them, as long as you don't access the .db file through a file share (UNC, or NFS, etc) - https://www.sqlite.org/wal.html I've been using this to update/read db from multiple threads/processes on the same machine. You can also do snapshotting with the sqlite backup API, if you want consistent view, and to not hold on transaction…
> Writers merely append new content to the end of the WAL file. Because writers do nothing that would interfere with the actions of readers, writers and readers can run at the same time. However, since there is only one WAL file, there can only be one writer at a time. I think the OP meant that updates have to run sequentially.
I've got a bunch of invites if folks want them: bsky-social-etdu7-njigu bsky-social-2ktcs-uwoxg bsky-social-6f5nh-36gnq bsky-social-ciwro-3gzk5 bsky-social-y4h57-dxh3g
I've got a bunch of invites if folks want them: bsky-social-etdu7-njigu bsky-social-2ktcs-uwoxg bsky-social-6f5nh-36gnq bsky-social-ciwro-3gzk5 bsky-social-y4h57-dxh3g
I've got a bunch of invites if folks want them: bsky-social-etdu7-njigu bsky-social-2ktcs-uwoxg bsky-social-6f5nh-36gnq bsky-social-ciwro-3gzk5 bsky-social-y4h57-dxh3g
E: Happy to take one, if somebody happens to have a spare one left. Email is in my bio.
Cool, but maybe let people actually use your service before everyone forgets what it is?
They have over 1.8 million users currently, or do you mean PDSes specifically? Federation is in open beta on a test network, you can try it out today if you'd like.
Earlier quoted context omitted.
I prefer to have clear commits that tell a tidy story. For example: * Refactor function `foo` to accept a second parameter * Add function `bar` * Use `bar` and `foo` in component `Baz` to implement feature #X If you give me a commit history like this, I can easily validate that each step in your claimed process does what you describe. If you instead give me a messy history and ask me to read the diff, you might know…
In the context of Github PR you can’t leave reviews on commits other than what’s currently the tip commit of the pr branch so structuring this way is just wasted effort. What you should be doing is breaking down PRs more finely so that your unrelated refactors are all separate single-commit PRs. That ofc requires that your pr review round trip time is fast