Dirk Eddelbuettel

website: https://dirk.eddelbuettel.com
github: https://github.com/eddelbuettel

Public Key

npub1klxw5thptxgffz6vjl7gjlahrna0dsgn2uqxzsl56nfpx6hgsmss4fa6s8

NIP-05 Address

Profile Code

nprofile1qqst0n829ms4nyy53dxf0lyf07m3e7hkcyf4wqrpg06df5sndt5gdcgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgdwaehxw309ahx7uewd3hkcrup20q

Publishing to

relay.primal.net

nos.lol

Author Public Key

npub1klxw5thptxgffz6vjl7gjlahrna0dsgn2uqxzsl56nfpx6hgsmss4fa6s8

Show more details

Last Notes

2025-12-31 20:07:40 CET

- reply

I am also a little non-plus'ed about the accrued time from forks. But the good news is that it should be ficticious money: for open source projects you usually do not get charged.

2025-11-06 00:15:32 CET

- reply

I really believe you have to have lived for a while with CRAN in "production" or other "downstream use cases" (and either at scale. ideally) to understand how this "everything at HEAD" monorepo works. The recent post by Julie T. (link below) expressed it well. People with different repo experiences cannot understand how we survive with #rstats. "Oh well" and _tant pis_.
https://jtibs.substack.com/p/if-all-the-world-were-a-monorepo

2025-09-15 21:52:11 CEST

- reply

Congratulations, you just reinvented the use case for Docker, a decade later. 😜

2024-09-12 17:21:00 CEST

- reply

You are extrapolating here and missing the forest for that one tree: you can use `data.table::rbindlist()` _on a list of data.frame objects_ and it will still glue them together faster than the alternatives _and_ it also offers you a data.frame as a return object.
What's not to like? 😉

2024-09-12 16:04:16 CEST

- reply

Take a look at `data.table::rbindlist()` which runs circles around alternatives and excels in all list-based, possibly `lapply((` et al drive iterative builds.