Um… what’s sessioncheck?

The thing about writing R packages that are not dplyr or ggplot2 is that, when the maintainer writes a blog post announcing an update to said package, the typical reaction from people who have the misfortune to encounter said blog post is to ask… “who the fuck are you bitch, what the fuck is this package, and why should I even care???”¹ And fair enough. Very few packages are famous and well known enough that the author can presume the reader knows what the hell any of this is about. So perhaps a brief recap is in order.

Back at the start of this year I wrote a blog post about this idea I had for a package that would assist beginner- and intermediate-level R users write their analysis scripts defensively, in a way that would hopefully stop them starting their scripts with the well-intentioned but utterly terrible rm(list=ls()) incantation. The idea behind deploying this strange and pointless piece of code at the top of the script is that – foolishly – people believe that clearing variables from the R global environment is a method of ensuring that their script will execute in a clean environment.

To anyone who has done the deep dive into the R inferno, this idea comes across as laughably foolish. It is an incantation to ward off evil spirits that has almost no power whatsoever to protect the wielder against the the eldritch horrors that live in the R session state.² Managing state is hard. Machines do strange things underneath the hood when you execute code, and there is almost no way you can truly protect yourself from the weirdness.

What you can do, however, is write your code in a way that scans the state of your R session and looks for hints that something might be amiss. Unless you’re the victim of a malicious attack against your machine (which I’m not going to even try to help you with), most of the things that “corrupt” your R session leave telltale signatures behind. Objects are left in the global environment. Unexpected packages have been attached. The session has been running for waaaaay longer than you think it should be. Etc. What sessioncheck does, at its core, is look for some of those telltale signs and warn the user loudly and obnoxiously that something is wrong.

There are various nuances underneath the hood, but the gist of it is this. Instead of opening your R script with rm(list=ls()), an incantation that fails silently and does more harm than good, you can use sessioncheck::sessioncheck() as the incantation, and it will annoy the fuck out of you until you fix whatever problem was making it whine at you:

sessioncheck::sessioncheck()

Warning: Session check results:
✖ Unexpected objects in global environment: blog_dir, cache_images, narrow, theme_custom, and 2 more
✔ No unexpected packages attached
✔ No unexpected environments attached

In my blog post session (which is most certainly not “clean” by any sense of the term), it detects that I’ve done something to the global environment, adding a bunch of variables that it wasn’t expecting to see if this were a truly clean session, and it whines about it in an annoying way. Indeed, it has some tools that allow you to make it even more annoying – if you call it with action = "error" the sessioncheck() function will throw an error if it detects anything it doesn’t like, and will prevent your script from doing anything.

That, of course, is the point: the true goal of sessioncheck::sessioncheck() is to annoy the shit out of the user until they clean up the R session. It doesn’t try to clean your R session for you, but it will piss you off over and over again until you do it yourself. The intent is very simple: mechanically cleaning a dirty session is very very hard. But restarting R is very easy. The purpose of the package is to annoy the user enough that they will restart R to run the script in a clean session rather than waste their time trying to figure out why their state is messed up.

Hopefully you get the idea. It is a package designed to be annoying. It is meant to force you to audit your own behaviour when you run an R script. Frankly, the package is an asshole.

Fine but why 0.2 anyway?

Okay, so now we all have some sense of what the package is about. What has changed in the new and thrilling “0.2 release” of the movie you weren’t watching anyway? Well, look, a lot of is is low-level bug fixes that you don’t care about: if you did care about such things you’d be reading the changelog. On top of that there are a few cute new features that make the output look prettier: by design the package cannot take any hard dependencies, but under the hood it’s secretly copied a few of the tricks built into cli, so it can crudely copy the gorgeous features built into cli… as long as you don’t push too hard. It’s a poor simulacrum, not the real thing. Nevertheless, you do get slightly pretter outputs in sessioncheck 0.2, which is rather nice to have. And there are a few subtle things that have been improved: you can now customise sessioncheck() to check the R working directory if you want. That wasn’t there before. But again, that’s tinkering at the edges.

The big new change, the one that deserves an actual blog post, is that sessioncheck now provides tools for recording and reporting the R session state. This shift pushes it a lot closer to well-trodden territory that is covered by packages like sessioninfo, which might come as a bit of a surprise. The sessioninfo package is already very, very good. It is maintained by Gábor Csárdi, and I trust him implicitly. I have been a Gábor Csárdi fangirl for a long time now. There is no version of Danielle that writes better code than Gábor. However, there are nuances… the goal of sessioninfo is slightly different to the goal of sessioncheck, and the things I need my package to report (in my specific industry context) are subtly different from what sessioninfo does. So……..

Yeah. Let’s talk nuance, babes…

Why include this extra information?

Now that I have tried my very best to openly disclose the potential risks in using sessionstate(), I should also talk about the potential benefits. Some of these I’ve already highlighted: in a regulatory environment we do need to know the hostname of the machine that executed the code, and personally I would go slightly further and say that the username is also important: knowing who executed the code is important for audit purposes. For much the same reason, the system time also matters, in case the file metadata gets corrupted but you still need to know when the script was executed.⁵

But there are other things you can gain from this more detailed audit log. One thing I am particularly fond of is the fact that it reports a hash for the RNG state. A common reason for scripts becoming subtly irreproducible on later re-run is that one of the packages upon which it relies has been updated in a way that alters how the RNG is called. Tracking this down is extremely difficult to do, and… well, sometimes that’s not the reason why an output changes. The advantage to explicitly including the RNG hash in the sessionstate() output is that if two runs of the same script produce the same RNG hash, you can feel pretty confident that any differences between the two aren’t due to hidden effects on the RNG state.⁶

Along similar lines, the sessionstate() output will capture some basic information about the state of an enclosing git repository. Technically, this is not part of the R session itself, but again useful for an audit log if you find yourself wanting or needing additional information about the surrounding environment at the time the script was executed. It’s not something I’d expect or want the existing tools to produce, but potentially valuable in the context for which sessionstate() is designed.

Redacting the output

As I mentioned, the design to sessionstate() reverses the priorities that implicitly underpin existing tools like session_info(). The primary goal is to create an audit trail; protecting privacy is a secondary goal. But that is not to say that privacy is ignored entirely. For example, one thing that sessionstate() absolutely does not attempt to capture are system environment variables, since sometimes those can contain genuine secrets that should not be included in an audit log.⁷ On top of that, the print() method for sessionstate objects allows the user to suppress printing of information that they’d prefer not to disclose. The most obvious example of this is the “machine” part of the output, since that is where the hostname and username get printed. You can suppress this like so:

print(
  sessioncheck::sessionstate(),
  machine = character(0),
  packages = c("package", "loaded_version"),
  globalenv_n = 3
)

─ Platform ─────────────────────────────────────────────────────────────────
• version             R version 4.6.1 (2026-06-24)
• os                  Ubuntu 24.04.4 LTS
• system              x86_64, linux-gnu
• ui                  non-interactive
• tz                  Australia/Sydney
• date                2026-09-16

─ Locale ───────────────────────────────────────────────────────────────────
• language            (unset)
• collate             en_US.UTF-8
• ctype               en_US.UTF-8

─ Matrix products ──────────────────────────────────────────────────────────
• BLAS                /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.12.0
• LAPACK              /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.12.0

─ Document products ────────────────────────────────────────────────────────
• pandoc              3.10
• quarto              1.10.18

─ Machine ──────────────────────────────────────────────────────────────────

─ Git ──────────────────────────────────────────────────────────────────────
• commit sha          e2f5bdcb4ed636ff8b9c237553cd3be2674c0a89
• dirty               TRUE

─ Timing ───────────────────────────────────────────────────────────────────
• captured at         2026-09-16 07:51:47 AEST
• session uptime      1.577 sec

─ RNG state ────────────────────────────────────────────────────────────────
• kind                Mersenne-Twister
• normal kind         Inversion
• sample kind         Rejection
• seed hash           bbd1d7bd48a494a1949e11f28b605dfb

─ Library paths [n = 4] ────────────────────────────────────────────────────
• /home/danielle/R/x86_64-pc-linux-gnu-library/4.6
• /usr/local/lib/R/site-library
• /usr/lib/R/site-library
• /usr/lib/R/library

─ Packages [n = 43] (attached + loaded via namespace) ──────────────────────
      package loaded_version
         base          4.6.1
          cli          3.6.6
     compiler          4.6.1
     datasets          4.6.1
       digest         0.6.39
        dplyr          1.2.1
     evaluate          1.0.5
       farver          2.1.2
      fastmap          1.2.0
           fs          2.1.0
     generics          0.1.4
      ggplot2          4.0.3
         glue          1.8.1
     graphics          4.6.1
    grDevices          4.6.1
         grid          4.6.1
       gtable          0.3.6
    htmltools          0.5.9
  htmlwidgets          1.6.4
     jsonlite          2.0.0
        knitr           1.51
    lifecycle          1.0.5
     magrittr          2.0.5
      methods          4.6.1
         otel          0.2.0
       pillar         1.11.1
    pkgconfig          2.0.3
           R6          2.6.1
 RColorBrewer          1.1-3
        rlang          1.3.0
    rmarkdown           2.32
    rprojroot          2.1.1
           S7          0.2.2
       scales          1.4.0
 sessioncheck          0.2.0
        stats          4.6.1
       tibble          3.3.1
   tidyselect          1.2.1
        tools          4.6.1
        utils          4.6.1
        vctrs          0.7.3
         xfun           0.60
         yaml         2.3.12

─ Global environment [n = 9] ───────────────────────────────────────────────
                name    class     size
               .main function 773.7 Kb
        theme_custom function  72.2 Kb
 .QuartoInlineRender function   3.6 Kb
 ... and 6 more (see x$globalenv)

─ Attached environments [n = 9] ────────────────────────────────────────────
              name    type
        .GlobalEnv   other
     package:stats package
  package:graphics package
 package:grDevices package
     package:utils package
  package:datasets package
   package:methods package
         Autoloads   other
      package:base package 

Here, the machine part of the output disappears entirely, leaving only a blank header. The packages part of the output is partially redacted, keeping only the package name and the version. The globalenv part of the output is limited also, showing only three variables rather than the default 10. Notice that this still leaks some potentially-private information: the libpaths are still shown, and that implicitly reveals the username.⁸ Under the hood, the sessionstate object still contains all the suppressed information for audit purposes: the only thing that is affected is the printed output. As a privacy-preserving mechanism is it is limited, so caution is again advised, but I think it’s still a useful feature for the package to provide.

Wrap up

For the purposes of a “oh hey there is a new version of this package” post, I think we’re good. There are other new features in the package: as mentioned earlier, sessioncheck 0.2 produces cleaner messages, fixes several mildy annoying but not very interesting bugs, and slightly extends the things you can check with the core sessioncheck() function. The new sessionstate() function is also accompanied by a compare_sessionstates() function that will show the differences between two session state snapshots, which I think is a handy feature to have.⁹

An anecdote

I’ll start the post with an anecdote to illustrate why I am making this claim. A few weeks ago I had to find a new GP. I’d been with the same practice for many years and was happy with them, but I’ve moved apartments and needed to find something closer to home. After a little research I discovered one extremely close to where I live, so I decided to make an appointment to get a prescription renewed. As with all medical practices, this one has a patient intake form. Because it is the 21st century, the form was online. Being a diligent person I started to fill it out. Within minutes I ran into a problem: just like the forthcoming ABS census, the clinic separates sex and gender on its forms. In fact, the wording on the questions was almost word-for-word identical to what the ABS now puts on the census:

• Question 1 (mandatory): What is your sex, as originally recorded on your birth certificate? Response options are limited to “male” and “female”.
• Question 2 (optional): How do you describe your gender? Several options were presented, including many that are appropriate for trans people.

There was also an optional question about pronouns, but it’s not relevant to the story.

As a middle-aged trans woman who transitioned over a decade ago, and who has a lot of professional experience with the collection of confidential medical data, psychological measurement, and a lot of direct personal experience with how organisations handle data that pertain to transgender people, I stared at these questions with a sense of utter dread. Everything in my professional and personal experience screamed at me that the correct thing to do here was to lie on the birth sex question^{4 5} and select “female”. But my conscientiousness overruled my better judgement and I did as I was asked. I selected “male”.

Within 24 hours, the medical practice had nonconsensually disclosed my transgender status to third parties who have absolutely no right to this information. This is of course a blatant violation of medical ethics, but those ethical standards don’t seem to apply to transgender people: our privacy does not get taken seriously, and I confess that I am rather bitter about it.

How did this happen? You might be tempted to think that it must have been malicious. Perhaps I had a bad doctor, one who does not take her professional responsibilities seriously. This is not what happened at all. What happened is something much, much worse: the underlying database that stores the intake data is configured incorrectly,⁶ and systems that interact with that database will leak transgender status by design. It is not a “one bad apple” problem: the entire infrastructure that underpins the “sex/gender” data collection is broken, and dangerously so.

Here’s the mechanics of how it happens. Internally, the database stores sex and gender as separate fields, mirroring the intake form: there is a sex field that records the birth sex information. It can have only two values, M or F. There is also a gender field that records the optional gender question, and it can have a wider range of values. When the GP logs into her software, the information displayed on her screen is the gender field. From her perspective, looking at this screen, there are no issues: the screen is not misgendering me, and it helpfully also shows her my pronouns. However, when she prints out a form for some blood work that I need to get done with a pathology lab, what gets printed is the sex field. In practice, doctors never actually look at those forms because they are so routine, so she did not notice.

This is where the breach happens. My GP does need to know my transgender status,⁷ because one of the things I talk to her about are the medications I take for my HRT. The pathology lab, on the other hand, does not need this information.^{8 9} It is a breach of confidentiality for a GP to disclose a patient’s transgender status to a third party, in exactly the same way that it would breach confidentiality to print sexual orientation on that form. But that’s exactly what happened. In everyday life, people rarely notice that I’m transgender, and I prefer it that way. I am not comfortable sharing this information with every person I happen to interact with: it is private data. If my doctor prints “male” on a form that I have to share with someone else, it outs me to that person without my consent.

When my GP printed out that form I spotted the issue immediately, because I knew exactly what was going to happen from the moment I filled out the intake form and was waiting for it. I pointed this out to her, and highlighted that it is a breach of privacy to print that information on the form but there wasn’t much she could do about it: once the “birth sex” field has been defined it is baked into the database, and every linked system will treat it as public data rather than private. My doctor is not transphobic. But the intake form and the IT infrastructure upon which her practice relies are transphobic by design.

I have seen this happen over and over again, across many different systems. The moment you separate sex and gender on the data collection instrument, it is more or less inevitable that your database will leak people’s transgender status and violate their privacy. I’ll talk more about why it happens, and the well-intentioned but misguided reasons why this situation came to pass, but before I dive into all that I want to emphasise the core point. If you take only one thing from this post, I would like it to be this:

You should never separate sex and gender on a form. Collecting information about people’s birth sex is dangerous for transgender people, and it is statistically and ethically irresponsible to collect it without an extremely good reason.

Databases almost always treat sex as quasi-public data: it’s not presumed to be sensitive or confidential information, and is very often shared with third parties with little consideration given to the privacy implications.¹⁰ This creates a serious problem: if you collect birth sex data as a mandatory item, you will very likely end up outing every transgender person in your data set. Indeed, forced outing of transgender people is the precise reason that other countries (notably the US and the UK) are pursuing the exact same policy: they are doing it to expose transgender people to dangerous situations. They are doing it out of malice;¹¹ Australia is doing the exact same thing out of stupidity.

Why did that happen?

The anecdote I just shared is just one instance, but it’s an experience that transgender people in Australia are starting to encounter more and more (e.g., here). Administrative systems all over the country are starting to create a distinct “birth sex” field in their databases,^{12 13} and they keep that field separate from the “gender” field. Almost every story I have heard is the same as mine: the database splits the two fields to support the “sex and gender” data collection, and then later on another subsystem queries the wrong field and shares someone’s trans status to a third party who should not have access to that information.

Given how severe the problem is (it has been a feature of almost every data storage system I’ve encountered that separates sex and gender),¹⁴ it’s worth asking how otherwise-competent people tried to do something trans-inclusive, and instead built a system that violates transgender people’s privacy on a mass scale.

I don’t know all of the history, but I know some of it. It is awkward for me to say it, but the blame largely lies with LGBTIQA+ advocacy organisations who don’t know enough about the practicalities of transgender data, academics who don’t understand the risks that transgender people face in the real world, and the ABS who – despite their many, many virtues – are thoroughly ill-equipped to handle the nuances of this issue.

During the process of designing the data collection standards that are now causing all these problems, a lot of people were consulted: the Australian public, statisticians, transgender people, social scientists, people who work with confidential data, etc. You know who wasn’t consulted? Australian transgender statisticians with specific expertise in social science and working with confidential medical data. They would be the optimal group to consult because they would have the most insight into how all the different aspects interact. But they weren’t, and in fairness I can understand the oversight. It’s a small demographic.

It’s entirely possible that I am the only person in it.¹⁵

The 2020 ABS standard

In my opinion, the root cause of the problem goes back to the 2020 ABS standards. Discussions and advocacy around these standards took place many years before they were finalised: I recall having a number of conversations with colleagues at UNSW about what should be included as far back as 2016. The standards themselves specify a 4-part data collection regimen, but for the purposes of the current post the key thing to recognise is that this is the place where the ABS formally asserted that it is best practice to separate sex from gender on data collection instruments.

These standards and this advice were designed with all the best of intentions. During the whole process leading up to it, I never encountered someone hostile to trans people.¹⁶ As terribly as it has played out on the ground for transgender people, that consultation process was not done with any malice. It was naivete and a lack of relevant competence, plain and simple.¹⁷

The failure happened because people who designed these standards never even considered what would happen when an ordinary GP equipped with an ordinary IT system tries to follow the ABS standard. The catastrophic data leakages that are happening everywhere in the country at the moment are a direct consequence of people implementing the ABS standards in situations where those standards are entirely inappropriate, and using IT infrastructure that isn’t fit for purpose when the sex/gender split exists in the data set.

It should have been foreseen, but almost nobody did foresee it. As it happens I was one of the few who did, but I cannot claim any special wisdom¹⁸ and in any case I was only very tangentially involved in the process. The only reason I saw it coming was that I was a statistician, programmer, and behavioural scientist transitioning within the academic system at the precise moment those conversations were taking place at UNSW.¹⁹ I’d had the horrible experience of watching as the IT infrastructure at UNSW turned out to be utterly incapable of preventing the data leakage from happening. It wasn’t designed to handle the existence of transgender staff members, and despite having all my HR records correctly updated it would leak my trans status everywhere because ancillary systems didn’t synchronise correctly.²⁰ My thinking was very simple: if an organisation as dedicated and well-resourced as UNSW is incapable of preventing data leakage relating to transgender status, it is an absolute certainty that smaller organisations will be even less capable. So I became very cautious on this topic, and my advice to people went down a very different path to what the ABS (and later, all the Australian medical agencies) went down. My advice was this:²¹

If you do not have a deep, mission-critical need to know the transgender status of every person who you interact with, the best practice is to never ask about birth sex in the first place.

If your database does not include birth sex or transgender status, systems that interact with that database cannot leak it. If you have ever taken a GDPR training course, you will already be aware of this as a fundamental principle. Do not collect data you do not need, and birth sex is almost never something you need.²²

Mission creep from medical agencies

Looking back at the 2020 ABS standards with some hindsight, I would have to say that while those standards are the root cause of the problem that trans people are now grappling with on the ground in 2026, the ABS isn’t most at fault here. The problem “went mainstream” once other organisations started to uncritically adopt the ABS standards, and promote them in contexts that go well beyond what the ABS itself does. The worst offenders, in my opinion, have been medical organisations. For example, medical research funding organisations like the NHMRC chose to treat the ABS standards as best practice guidelines for collecting sex/gender data, and – as far as I can see – failed to do their due diligence on this matter. I’ll quote the NHMRC directly here, because I want to emphasise how influential the ABS standards are outside the context of the data collected by the ABS itself:

We encourage use of the ABS 2020 Standard and associated guidance on data collection and analysis by researchers in all research projects, along with adherence to the Privacy Act 1988, as appropriate. The ABS 2020 Standard is designed to collect demographic information on the Variables and routine use of the Standard across research projects will enable consistent and comparable data to be collected.

This is terrible advice.²³ It is flat out wrong, and it was inappropriate for the NHMRC to make statements like this. The 4-question format laid out by the ABS standards is designed for the ABS to use, and its core purpose is to simultaneously collect as much information around sex, gender, orientation, and variation of sex characteristics as possible with a compact set of questions. This is almost never the correct approach for academic researchers to adopt in their typical research project. In psychology, for instance, you almost never need all four of these variables: usually you only want gender, and – at the risk of repetition – your study should not collect data beyond what it needs. Even in medical contexts, we rarely need all four variables. Given that those variables contain extremely private information and the data collection itself is intrusive,²⁴ it is a plain violation of ethics standards for human research²⁵ to cause unnecessary distress for your participants. The NHMRC statement is just wrong. It’s that simple.

Unfortunately, people do not look to me for advice on this topic. Instead academic medical researchers in Australia are being actively advised to use the ABS standards in their research. The NHMRC is the single most important body for funding medical research in this country, and academics take its advice very seriously. Those academics in turn train medical students, who then become doctors. Those doctors then join organisations like the AMA who write statements in support of the sex/gender split advocated by the ABS and the NHMRC, such as this:

The AMA supports the development of a NHMRC/MRFF joint statement on Sex, Gender, Variations of Sex Characteristics and Sexual Orientation in Health and Medical Research. The AMA would also like to see the adoption of the Statement by the wider research community.

In other words, the entire medical establishment in Australia has ended up treating the 2020 ABS standard as “the” correct way to measure sex and gender.²⁶ When the ABS created this standard in 2020, they did not merely lay the foundation for the questions that would eventually land in the 2026 census, they also set themselves up as the authority to define best-practice guidelines for other organisations, who have then gone on to badly misapply the ABS standards.²⁷

This is, of course, a recipe for disaster for trans people in a world where every IT system in existence treats sex as a static, public field. It was inevitable that this advocacy from the NHMRC and AMA would lead to privacy violations for transgender people. It was irresponsible behaviour from both organisations, and a gross misuse of ABS standards that were not designed for the purposes that medical organisations have tried to use them.²⁸

LGBTQIA+ advocacy requires data competency

Up to this point in the story, I’ve focused mostly on the role of medical, statistical, and scientific organisations. The ABS creates standards, partly in response to advice from academics, the NHMRC adopts and misapplies those standards in a medical context, and then the AMA pushes the same advice into places where doctors and other health practitioners will adopt it. That’s the “official” part of the story, because those are the organisations with the institutional authority to make the sex/gender split an accepted data collection standard.

But it is not the whole story, and those are not the only organisations who have mishandled this issue recently.²⁹ Because when the issue at hand relates to the lives of LGBTQIA+ people, the ABS, NHMRC, and AMA all take advice from LGBTQIA+ advocates. Organisations like ACON, Equality Australia, LGBTIQ Health Australia, and so on. What have these organisations had to say about the partial adoption of the 2020 ABS standard in the 2026 census? Here’s ACON praising the new census and giving credit to advocacy organisations:

This year’s Census is a historic milestone. For the first time, Australians aged 16 and over will be asked about their sexual orientation and gender identity, marking a significant moment in the recognition of LGBTQ+ communities in national statistics. This change came after years of advocacy from LGBTQ+ organisations who argued that access to this data would have an enormous impact on improving social cohesion and the health outcomes of LGBTQ+ communities.

Here’s Equality Australia being equally glowing:

“In 2027 we will finally have a more complete picture of who we are as a nation, including where LGBTQ+ adults live, what our jobs are, our health issues, where we go to school and what our families look like,” said Equality Australia CEO Anna Brown. “We still know so little about LGBTQ+ Australia because the 2021 Census failed to meaningfully count people of diverse sexualities and genders, and our families.”

Here’s LGBTQ Health Australia, again expressing their endorsement:

These updates are significant as the Census is one of Australia’s most important sources of population data. Governments, researchers, health services and community organisations use Census information to understand communities, identify needs and make decisions about policy, funding and services. For many LGBTQ+ people, these changes are not only about better data. They are about visibility and recognition in one of Australia’s most important national collections of population data.

Across the board, Australian LGBTQIA+ advocacy organisations have endorsed the new census questions specifically, with very little critical commentary.³⁰ Yet on the ground, if you talk to any transgender person who has had to interact with the medical system recently and who has encountered the same nightmarish experience I described in the opening anecdote, you will find that we are all extremely unhappy with the 2026 census.³¹ The addition of the optional gender identity question to the census had the side effect of forcing the ABS to reword the mandatory sex question to now explicitly request sex-at-birth,^{32 33} creating the exact problem I discussed in the opening anecdote when other organisations copy their methodology.³⁴ To put it bluntly, the new questions create an extremely intrusive privacy violation for transgender people. Somewhat disappointingly, LGBTIQA+ advocacy groups in Australia appear to have ignored this concern entirely.

As a consequence of all this, there is now a massive disconnect between what LGBTIQA+ advocacy groups are saying, and what transgender people are experiencing. But government agencies do not look to regular transgender people for advice: they go to ACON, Equality Australia, etc. Unfortunately, because those organisations are not really qualified to talk about the practicalities of data infrastructure as they pertain to the inadvertent leakage of transgender status, they give the wrong advice.

So here we are. Australia has ended up in the rather peculiar situation where data collection standards for trans people look strikingly similar to those used in the US and the UK. In all three countries, transgender people are now being forced to disclose birth sex information on a regular basis, often in situations where this is entirely inappropriate. In the US and the UK those policies were pushed by conservatives and opposed by LGBT advocacy organisations. In Australia, however, they have been pushed by progressives and encouraged by LGBT advocacy organisations. Unfortunately, the end result for trans people is exactly the same. The good intentions of the Australian organisations are irrelevant.³⁵ Our private data gets leaked to people who have no right to that information, and this happens very openly, and – as far as I have seen – without any consequences for the people responsible.

It is rather depressing.

Fixing the failure modes

My pessimism and depression regarding this issue notwithstanding, I would be remiss if I did not talk a little about possible solutions to the problem, and how organisations can handle data collection issues in those (rare) special cases where birth sex data is genuinely relevant. I am not a person who likes making strong recommendations, so I will be careful here, but I will make a genuine attempt. My advice is rather different depending on who you are.

• If you are the ABS. Setting aside some of the concerns around the format,³⁶ the 2020 standard is appropriate for your core purposes.³⁷ However, it has not been properly qualified: you need to make sure that organisations that do not have your same rigorous standards are not misled into thinking they should be using your data collection methodology. In contrast, the 2026 census is badly designed: transgender people will not answer the “birth sex” question honestly. We will lie, and with good cause. It was a mistake to create an asymmetry between the “sex” and “gender” questions, because many people will skip the optional question. That in turn means that downstream researchers will use the sex field rather than the gender field as covariates in their analyses. So transgender people will end up misclassified in almost every analysis. Most of us know this, because we all know how cisgender people respond to these questions. Lying is the best strategy for us. If you cannot make the full 4-question version mandatory (which of course is both politically impossible, and impractical on a mass scale), you should collapse the sex and gender questions to a single item, and do not force transgender people to humiliate ourselves on the census.³⁸ In brief: collecting data on the transgender population to guide policy is a laudable goal, but the census is the wrong instrument to use for it.³⁹ The topic is too sensitive, and there are some extremely negative side-effects of trying to do so in the way that the 2026 census does.

• If you are the NHMRC. With all due respect, I’d urge you to stop encouraging medical researchers to apply the ABS standards to data collection processes where it is not appropriate.^{40 41} Even in the medical context it is not common for the transgender status of participants to be relevant, in which case the distinction between sex and gender is not worth collecting data on. You are the premier organisation for funding medical research in this country, and other people are following your advice. With regard to the 2020 ABS standards the advice was the wrong call, and you have a professional obligation to make amends for the damage it has caused.

• If you are running a clinical trial for a new drug with dense PK sampling, and you expect to have transgender participants. You are the rare exception. If your study design includes transgender people in the first place, it is because you have reason to think that the differences in metabolic processes for a transgender participant on HRT, a transgender participant not on HRT, and a cisgender participant might be important. You will need this data as a covariate for fitting your PPK model later on. However, if you’re skilled enough to have worked that out, you are also skilled enough to recognise that the 2020 ABS standard is not the correct way for you to collect that data. You will need to include specific questions about transgender status, not a generic “sex versus gender” instrument. You need to know concomitant medications like HRT, and you will want measurements of the relevant hormones. You also know that you have extremely strict rules around data confidentiality, and you will know that you cannot share the birth sex data to anyone except unblinded analysts working on the project. The ABS standards are not for you because you need something more sophisticated.

• If you are doing some other kind of research. Think very, very carefully about what measurements your study actually needs. Just because the ABS produced the 2020 standard and the NHMRC endorsed it does not mean your study should implement it. Collect the data that you need, and only the data that you need. In most cases, that won’t include birth sex because very few social, behavioural, or medical studies need it. Asking for gender will work just as well in the vast majority of cases. Indeed, there is virtue in being deliberately ambiguous here: psychological measurement is a different scientific problem to biological measurement, and there are peculiarities to it that need to be taken into account. Asking a single question that requests “sex/gender” and letting people interpret it however they like is fine, and potentially a methodologically superior approach to a forced sex-at-birth measurement instrument.⁴² More broadly, though, your data are not so precise that the subtle distinctions built into the ABS 2020 standard will affect your eventual p-value or the results you publish in academic journals.^{43 44} As George Box famously said about statistical models: “Since all models are wrong the scientist must be alert to what is importantly wrong. It is inappropriate to be concerned about mice when there are tigers abroad”. The same statement holds for measurement instruments: the sex/gender split is a mouse. The ethical concerns with being pointlessly cruel to your transgender participants, however, is a tiger. If your ethics committee were competent and paying attention to this issue, your study should properly be rejected if you unnecessarily collect birth sex data. Either way, though, you have a professional responsibility to not distress your participants. Drop the sex/gender split: you don’t need it.^{45 46}

• If you are a doctor or a hospital. Do not include birth sex questions on an intake form. The ABS standard is inappropriate here. Intake forms are not always as private as they need to be, and in particular you need to be aware that your own database will probably leak birth sex data (and hence transgender status) to unauthorised third parties. You are better off having a single, ambiguous sex/gender question on your intake form. If and when your transgender patients have decided that we trust you enough to disclose our status to you,⁴⁷ do not enter it in the sex field. It goes in private medical notes, because those notes do not get printed out on pathology forms or revealed to receptionists. You should treat birth sex with the same sensitivity that you would treat sexual orientation. If you believe it is unethical for a doctor to out their gay patients to strangers, you should show the same respect to your transgender patients. That means you must always treat birth sex as confidential data, in every context.

• If you are the Births, Deaths, and Marriages office. Actually, you’re doing great. More precisely, if you’re the South Australian BDM office, your current practices are almost perfect, as far as I can tell. Having updated my birth certificate sex/gender marker some time ago, the process was not as difficult as I feared, and the end result was surprisingly thoughtful. Legally recognised transgender people born in South Australia are issued two versions of our birth certificates, one with the marker change made explicit (useful for us when we have to prove we have transitioned) and one without it (useful when someone else asks to see the certificate and they have no business knowing our transgender status). Honestly, my main advice here would be very simple – the transgender status in your database should not be shared with any other organisations, including other government agencies. You are the official register for this kind of information: you should know that I am transgender. The tax office has no reason to know that.

• If you manage another kind of database with a sex/gender split. Be aware of the fact that the privacy implications change once this split has been implemented. In a database that contains only a single field (regardless of what it is labelled), it is likely that that sex/gender field contains those values that people felt willing to disclose. That value is private, but rarely highly sensitive.⁴⁸ Once the sex/gender split is in place, this changes. The sex category now becomes extremely sensitive information, and there are almost no situations in which its value should be disclosed to third parties. However, because your database almost certainly has legacy code and automated queries that predate the sex/gender split, the potential for data privacy breaches escalates dramatically the moment the split is introduced. Your task in this situation is to (a) push back against people wanting to implement the split if they do not have a good justification for doing so, and (b) investigate what queries are being made against the sex field in particular (but also the gender field) and check to see if they remain appropriate given the new data structure, as this is usually where the breaches occur.

• If you are ACON, Equality Australia, etc. Please spend less time lobbying the government and more time talking to regular transgender people. You’ve been advocating for a policy that is causing us a huge amount of distress, creating an administrative nightmare for us, and is leading to transgender people being outed by people who have foolishly listened to you. Separating sex and gender on data collection instruments is inherently bad practice in almost all situations, but the people who have been taking advice from you are not grasping the risks involved. Indeed, I worry that you might not understand the risks involved. Please be careful here, because there are serious downstream risks that attach to this advice.

• If you are just a regular person. Mind your own business. You do not need to know other people’s birth sex. Do not ask. It is very, very simple.

I hope some of this is useful.

Asserting boundaries

One of the things I found myself wanting to do at the outset, as a matter of self-care, is work out where my new boundaries would need to be set with regards to these tools. I’m no longer completely abstaining, but I don’t want them encroaching on literally everything I do. That’s not a technical issue so much as a personal one… if I don’t set clear boundaries for myself, it is inevitable that the cursed artifact will find a way to insert itself everywhere. Tool usage is infectious that way: the mere act of enabling Posit Assistant in my IDE is enough to make it feel convenient to use everywhere. I don’t want that for myself.

So, my first task was working out when I’m prepared to allow coding agents into my life. Some things are clearly “in scope” for this reluctant little experiment I’m running. Coding projects that I’ve started because of a work-induced need (e.g., emaxnls, erglm, and erplots) fall into that category. Even though they are all open source packages that I am writing and maintaining on my own time,⁴ they only exist in the first place because I need them professionally. And given that it is my professional working environment that creates the need for me to learn how to use coding assistants, these are fair game.

On the other end of the spectrum, other things are entirely out of scope. I tested out the idea of allowing agents to help me with writing on this blog and recoiled in absolute horror within minutes. My writing is personal. I have my own style, my own voice, my own train of thought that I follow when I write. The very moment that Posit Assistant started “helpfully” offering next-edit suggestions within this blog, I had a visceral urge to scream. I felt physically nauseous. The inline suggestions were worse than useless: not only were they completely off-track for what I was trying to write, they were intrusive, distracting, and they utterly broke my writing rhythm. It turns out that I literally cannot write when those vile things are enabled. So that’s a vehement no from me. Indeed, one of the first things I had to do once the assistant was enabled was set up the .vscode/settings.json file on this repo to block those suggestions.

They are truly awful, and oh my god I am glad they are now gone.

The other place that feels like a clear “no, absolutely not, never ever ever” decision is my generative art. It might seem counterintuitive given that it is 2026 and at this point most people think generative art is an AI thing, but that’s their problem not mine. I write art code emotionally. It isn’t software development, it isn’t data analysis, it is a personal and creative endeavour that is deeply tied to my emotional state. I’ve stopped trying to have opinions about whether AI can actually “do” art in the same sense a human does art — I simply don’t know the answer to that kind of question — but I do know that it can’t make my art. Asking Claude to help me make art is entirely incomprehensible to me. I don’t even understand the point. Art is something you do because it fulfils a personal expressive need. I can’t ask another human to do my art for me, and I can’t ask an AI to do it either. It wouldn’t be my art anymore if I did that. So I don’t.

In between these extremes, though, there are grey areas that I have struggled with.

Packages like quartose and sessioncheck are only indirectly related to my work. They were inspired by problems I encountered in my work environment, but they aren’t as tightly linked to it as the packages I mentioned at the start. After some agonising about it, I decided I’m okay with using a coding agent to help me keep them up to date and take care of basic bug fixes. It’s not really a principled decision, but a pragmatic one: I have so little free time these days that I’ve had to acknowledge that a lot of those little bugs wouldn’t get fixed if I didn’t get some assistance, and I would genuinely like to keep those packages in good working order. So there’s some light AI use allowed there. If I had the spare capacity to do it without the agent’s assistant I would, but the reality is that I don’t.

A different kind of grey area arose when thinking about my learning statistics with R book. This one is hard to talk about, because it’s emotional for me. The book itself is very old. Most of the writing dates back to the 2010-2013 period, and I have a strong visceral need to leave that text more or less intact.⁵ The book is… look, it has its limitations, but it is what it is and it has a history I don’t want to mess with. But at the same time, the actual framework underneath it has been a disastrous mess for over a decade. I wrote it in LaTeX originally, with no code integration at all. It had a bookdown adaptation (courtesy of Emily Kothe) but that adaptation was always incomplete, and none of us have ever had the time to fix it. And… on top of that, there is one detail about the book that has caused me personal agony for years. Something I loathe deeply, but have never been able to do anything about. The book predates my transition, and the 0.6 version that has been live for what feels like an eternity just… sits there… misgendering me and deadnaming me to the entire world, a painful reminder of a past I don’t want to revisit. I’ve spent all this time feeling hurt about that, wanting desperately to disappear the book just to make it stop. But I couldn’t. The book has been in use all this time, and other people have been relying on it. It felt selfish for me to abruptly delete the whole thing, so I chose to leave it up and live with the pain.

As it turned out, though, fixing this problem was a very good use case for coding agents. It took me a long time to do — and I burned a lot of money on tokens because holding an entire 800 page book in chat is heavy lifting even for an AI — but Claude/Posit Assistant did a good job of rewriting the book in quarto, and fixing the deadname/misgender problem. It was actually healthy for me not to do the edits by hand. Seeing my deadname and the wrong pronouns in the text of the book makes me feel sick, and there is a kind of emotional distance you get by telling the agent to take care of the problem:⁶ to the dispassionate machine, renaming the author is no different to renaming variables in snake case (another minor tweak I did introduce), and I told it to do both of those things as part of a general minor tidying sweep.

I still cried a lot, but less than I would have done if I’d been forced to do the work myself. And so while using a coding agent for that task does cut against the spirit of what the book is about, I have no regrets on that front. The problem is solved, the book is still there, and I never have to look at the cursed text again. I’m glad the book has been valuable to other people, delighted that people still use it, but the author needs some distance from it and from that part of her life. Version 0.7 is now live, but please don’t expect to see a version 0.8 release anytime soon.

So… yes, boundaries. Boundaries are good to have. Moving on…

On writing code with a coding assistant

Being new to the experience, I’m hardly the right person to talk about what an AI coding agent can and can’t do. I’m a novice here. I’ve worked out how to write an AGENTS.md file and I’ve used agents to help with various projects, but compared to folks who have been doing this for years I am a long way behind. So I will not offer strong opinions here; instead I’ll say something about what it has felt like to me.

On writing actual words with a coding agent

So now we turn to the question of using a large language model to use actual language. Writing words about code, rather than writing the code itself. On this front, I feel much more pessimistic. The kindest thing I can think to say is that Claude is… okay at doing very bland report writing? If all you need an agent to do is provide a paraphrase of some numbers in a table, it can do that. Beyond that, I’ve found them disappointing. The package documentation they write is… okay, I guess? Claude can fill out a roxygen2 skeleton appropriately if you give it instructions on the level of detail required. I’ve still had to step in and fix weird leaks where it can’t seem to grasp that AGENTS.md is internal documentation only and you should not refer to it from the package documentation, but not too often. It knows what argument types a function takes, it understands the package structure, so it can write a servicable documentation entry. I guess.

But that’s as far as it goes. Beyond those limited cases where you deliberately want it to produce bland uninspiring text that does nothing more than rephrase the information contained elsewhere, my opinions on the quality of AI writing are uniformly negative. Even the task of writing a few paragraphs into the Learning statistics with R book was beyond it. Even with my careful prompting, even with literally 800 pages of text in the required style and pitched at the target audience, it simply could not do it. It was abysmally incompetent at the task: actually worse than my already-low expectations.

It wasn’t just that book either. When writing package vignettes, the only time it was ever capable of doing the task I had clearly instructed it to do was when I indicated it was okay to talk like a software engineer: it is simply incapable of understanding that the users of an R package have a different skill set to the developers of said package, and no matter what I told it to do it would fuck it up catastrophically. It would either ignore my instructions and start rambling about the intricacies of S3 method dispatch,¹² or it would go so far in the other direction that the writing sounded like the words of a condescending dick who can’t grasp that smart people sometimes have different knowledge to you. It is like… it can see that there is code in the repo, and therefore immediately decides to ignore all context and talk at me like the most annoying tech bro twat you ever met. Horrible stuff.

The only time I’ve seen it manage to do technical writing in an even half-decent way came from an open source project where we used the agent to help prepare extremely detailed plans for each document, complete with explicit instructions about voice and audience. Even then it fucked it up horribly the first time, and I had to explain the reasons why the first draft didn’t match the spec. It was only able to do a decent job after I’d painstakingly guided it through the process of creating one document that could serve as an example of how the spec should map onto the prose. At that point it was moderately capable of writing additional documents in a similar style, building off specs for those later documents. But that is an astonishing amount of scaffolding just to pull off the job of writing a half-competent professional technical document.

Honestly, I had no idea they were this bad at writing. Like, babe, you are a large language model. How in the everliving fuck in heaven are you so bad at language?

The blindingly obvious truth is that LLMs are much better at writing code than they are at writing words. If you can’t manage bland technical writing very well, you have zero chance in hell of understanding how to insert a queer footnote into the text.^{13 14} Admittedly, this limitation probably doesn’t pose any problems for a tech company or even a pharma company. Authorial voice is not part of the stock in trade for scientific or technical organisations, so it’s not really a dealbreaker in that sense. But letting Gemini have an attempt at writing in the style of this blog? To be vulnerable, profane, queer, and technically proficient all in one fell swoop? A virgo would not advise it.

The messiness of it all

And so we come to the end of this little self-indulgent self-reflection, and my feelings remain as mixed as they ever were. None of my ethical concerns have gone away. It is hard to love a technology built on theft and exploitation, a tool whose primary purpose is to entrench inequality and concentrate power in the hands of a handful of the worst human beings on the planet. But that could be said of almost everything in the supply chain now. You won’t find a lot of ethical conduct when you start asking why the global economy depends rather heavily on who has control over the Strait of Hormuz either. We do not live in an ethical world. I don’t love that for any of us, but I am obligated to live with it. So, like everyone else, I pretend I can’t see the horror right in front of my face and use the grotesque technology anyway. It’s not noticeably different to what I was doing already. To be alive in the 21st century is to be complicit in atrocities.

But even with ethics set gently to the side,¹⁵ I cannot help but feel conflicted the tools.

In some regards they unambiguously work. I’ve been able to accomplish some tasks very quickly, and other tasks that I’d never have even found time to start. And when controlled carefully and deployed in a context-appropriate way, coding agents are genuinely competent at some types of tasks. They’ve let me get shit done that I wouldn’t have got done without them. A lot of things, to be honest. My token spend this month has been insane. But I suspect that’s a one-off. In my life I have left behind so many dangling threads and have so many unresolved traumas just laying around on github,¹⁶ and I have not enjoyed that feeling. It has been very mildly cathartic to burn tokens with the extravagance of a gilded age oil baron, and let the machine tie up those loose ends. I am uncomfortable with the manner in which it has been accomplished, but I will take it as a win and be grateful.

In other regards, the tools remain stunningly unfit for purpose. They can code moderately well, but they do not wordsmith with any skill. And yes, often you do not need writing skill to solve a practical problem. Often you can get away with the kind of blank, soulless prose that just feels like it was written by a wooden toy that wants to be a real boy one day. You can type a prompt into midjourney and get the kind of artwork that belongs in a stockbrokers foyer as a reminder of emptiness of existence. An LLM can do those things if you ask it to.

But usually that’s not what we want from words. It’s not what we want from art. It’s not easy to encapsulate the human connection we seek from other people in a SKILL.md file. LLMs work because the statistics of the environment encode so much about the world: any sufficiently powerful learning machine will capture those statistics and reproduce them usefully if you give it the opportunity. It makes them useful tools. But I’ve never fallen love with a man because his body had the statistical structure of Michelangelo’s David. I’ve never adored a writer because her sentences so perfectly reflect the long-range dependencies between words in a corpus. I don’t stand in a photo gallery trying to think up midjourney prompts to recreate the look and feel of the Christopher Street Pier in the 1970s. Art, words, and love. Those things aren’t part of the deal. And that’s okay. That’s not what the tool is for.

Honestly the whole thing feels like a mess.

The details

Yes, yes, Danielle. I already understand these principles, could you possibly speed up this exposition and say a little more about what the bloody thing actually does? Your verbiage is not as interesting as you think it is?

Fair point.

Okay, here’s basic design. The sessioncheck package exports a collection of specific “check” functions. Each of these functions inspects a single aspect to the R session and reports back to the user if any concerns are detected. At present, the following checkers are available:

• check_globalenv_objects()
• check_attached_packages()
• check_attached_environments()
• check_loaded_namespaces()
• check_sessiontime()
• check_required_options()
• check_required_locale()
• check_required_sysenv()

Each of these does pretty much what the function name suggests it does: check_globalenv_objects() looks at the global environment to see what objects it contains, check_attached_packages() takes a peek at the search path to find out what packages are attached, and so on. When the user calls sessioncheck(), some subset of these checks are performed, and the results are aggregated in a single message. You can customise exactly which checks are performed, and pass options to the specific checks if you want to whitelist certain packages or whatever. For instance, if I want the checks to ignore the variables that are always present in my blog posts I could do this:

sessioncheck::sessioncheck(
  action = "error",
  checks = c("globalenv_objects", "attached_packages", "attached_environments"),
  allow_globalenv_objects = c(
    "narrow", "wide", "very_wide", "cache_images", "blog_dir", "theme_custom",
    ".main", ".QuartoInlineRender", ".Random.seed"
  )
)

Clearly, this is quite a bit more detailed and frankly I would not want to write this code over and over again, but thankfully I don’t have to. The package supports a “sessioncheck” option that you can set in the .Rprofile if you want. So I could totally put this in my .Rprofile file:

options(
  sessioncheck = list(
    action = "error",
    checks = c("globalenv_objects", "attached_packages", "attached_environments"),
    allow_globalenv_objects = c(
      "narrow", "wide", "very_wide", "cache_images", "blog_dir", "theme_custom",
      ".main", ".QuartoInlineRender", ".Random.seed"
    )
  )
)

Having done so, the only thing I’d need to do is this:

sessioncheck::sessioncheck()

As an additional feature, sessioncheck() invisibly returns an object that is coercible to a data frame, so the user can easily get an overview of what the function actually checked, and whether or not the results of that check triggered an action:

as.data.frame(sessioncheck::sessioncheck())

         type              entity status
1   globalenv               .main  FALSE
2   globalenv .QuartoInlineRender  FALSE
3   globalenv        .Random.seed  FALSE
4   globalenv            blog_dir  FALSE
5   globalenv        cache_images  FALSE
6   globalenv              narrow  FALSE
7   globalenv        theme_custom  FALSE
8   globalenv           very_wide  FALSE
9   globalenv                wide  FALSE
10    package               stats  FALSE
11    package            graphics  FALSE
12    package           grDevices  FALSE
13    package               utils  FALSE
14    package            datasets  FALSE
15    package             methods  FALSE
16    package                base  FALSE
17 attachment          .GlobalEnv  FALSE
18 attachment       package:stats  FALSE
19 attachment    package:graphics  FALSE
20 attachment   package:grDevices  FALSE
21 attachment       package:utils  FALSE
22 attachment    package:datasets  FALSE
23 attachment     package:methods  FALSE
24 attachment           Autoloads  FALSE
25 attachment        package:base  FALSE

To my mind, that’s a handy diagnostic. You can look at this and see that three types of checks were performed (the type column). You can see exactly which aspects to the R session were detected by each check (the entity column). And you can also see whether that specific aspect triggered an action (the status column).

What’s the point, Danielle?

At this point, you (the presumed experienced R user who already knows all this stuff forwards and backwards) might be wondering exactly why I bothered to write all this extensibility into sessioncheck. After all, the package is deliberately pitched at novices. Novice R users aren’t going to understand the difference between a loaded namespace and an attached package, so why the hell does sessioncheck bother to build that nuance into the check functions? Simialrly, a novice isn’t going to know precisely what an .Rprofile does, so why do I support the use of the "sessioncheck" option?

In practice, I don’t really expect that a novice R user will understand any of these details. They won’t immediately find themselves customising the .Rprofile for each project, and they most certainly won’t immediately start thinking about how to handle hidden dot-prefixed variables like .Random.seed when they appear in the global environment. The distiction between namespaces and attached package environments won’t be apparent to them for a long time. Indeed, if a novice user knew those things they wouldn’t be a novice anymore. If you have the capacity to work with those things fluently, you already have the skills you need to graduate to proper project-oriented workflows or (gods forbid) targets.

But also… that’s the point.

The whole idea behind sessioncheck is that it’s supposed to be scaffolding. A novice user can blndly use sessioncheck::sessioncheck() without thinking about the specifics, secure in the knowledge that it is strictly safer than doing the batshit rm(list=ls()) trick that gets passed around via folklore, but also it is extensible. The sessioncheck package has extra hooks (and documentation!) designed to guide novice users towards doing something even better than the defaults I’ve set. Eventually, if a user gets into the habit of thinking about what aspects of the session state need to be checked (and, ideally, disagreeing with my default choices!), they’ll find they’ve acquired all the skills they need to kick away the scaffold. They won’t need to use sessioncheck anymore because they’ll have discovered that there are more powerful tools they can use, and they’ll be ready to start learning them.

And so I come to the real point of the post…

I’m thinking of sending this package to CRAN, and I am thinking that once it’s there I will gently nudge people in my professional world towards using sessioncheck::sessioncheck() instead of rm(list=ls()). But… I don’t want to do this if there are any egregious flaws in my thinking, or if there are horrific bugs in the package that would actually make it worse than the – admittedly terrible – practice of using rm(list=ls()). So, dear reader, beloved R expert who reads my silly blog…

Is this sessioncheck package any good? Is it worth making this available on CRAN? If you have time to take a quick look at the documentation and/or code, I would welcome your thoughts, criticisms, and comments.

Because we are all in this together, and if there’s one thing we all care about it’s making sure that everyone can use R safely and freely, to solve whatever problems they personally care about.

And nobody wants to see another unnecessary laptop fire :)

Mapping the data

stadia_tile_url <- function(style = "stamen_toner", key = TRUE) {

  # URL template (without API key)
  base_url <- "https://tiles.stadiamaps.com/tiles"
  pattern  <- "{z}/{x}/{y}{r}.png"
  tile_url <- paste(base_url, style, pattern, sep = "/")
  if (!key) return(tile_url)

  # pull API key from private file
  api_key <- fs::path(runkeeper, ".Renviron") |> 
    brio::read_lines() |> 
    stringr::str_remove("^[^=]*=")

  #return the full URL template
  glue::glue("{tile_url}?api_key={api_key}")
}

# show URL template (without the API key)
stadia_tile_url(key = FALSE)

[1] "https://tiles.stadiamaps.com/tiles/stamen_toner/{z}/{x}/{y}{r}.png"

run_markers <- run |> 
  dplyr::mutate(
    n5min = as.numeric(floor(elapsed/5)), 
    new5min = n5min - dplyr::lag(n5min, default = 0)
  ) |> 
  dplyr::filter(new5min == 1) |> 
  dplyr::select(lat, lon, elapsed, distance) |> 
  dplyr::mutate(label = paste0(
    format(round(elapsed)), 
    ", ", 
    format(round(distance))
  )) 

run_markers

# A tibble: 6 × 5
    lat   lon elapsed        distance label            
  <dbl> <dbl> <drtn>                m <chr>            
1 -33.9  151.  5.016667 mins     711. " 5 mins,  711 m"
2 -33.9  151. 10.000000 mins    1488. "10 mins, 1488 m"
3 -33.9  151. 15.033333 mins    2270. "15 mins, 2270 m"
4 -33.9  151. 20.116667 mins    3028. "20 mins, 3028 m"
5 -33.9  151. 25.066667 mins    3865. "25 mins, 3865 m"
6 -33.9  151. 30.000000 mins    4617. "30 mins, 4617 m"

map <- leaflet::leaflet() |> 
  leaflet::addTiles(
    urlTemplate = stadia_tile_url(),
    options = leaflet::tileOptions(opacity = .5)
  ) |> 
  leaflet::addPolylines(
    data = run, 
    lat = ~lat, 
    lng = ~lon, 
    color = "red", 
    opacity = 0.5, 
    weight = 5
  ) |> 
  leaflet::addCircleMarkers(
    data = run_markers,
    lat = ~lat,
    lng = ~lon,
    label = ~label,
    color = "red", 
    opacity = 0.5, 
    radius = 5
  )

map

# paths to all csv files
csv_files <- fs::dir_ls(
  path = fs::path(runkeeper, "csv"), 
  recurse = TRUE, 
  type = "file"
)

# read everything into a single data frame
runs <- csv_files |> 
  purrr::map(\(file) {
    readr::read_csv(
      file = file,
      show_col_types = FALSE
    )   
  }) |> 
  dplyr::bind_rows()

# function that detects if a run is in sydney (in a lazy way)
near_sydney <- function(lat, lon, tol = 2) {
  if (abs(mean(lat) + 33.865) > tol) return(FALSE)
  if (abs(mean(lon) - 151.21) > tol) return(FALSE)
  TRUE
}

# append some handy information, and sort by run length; retain
# only those runs that are at least 2km (anything shorter than that
# usually indicates injury or some other extraneous factor)
runs_sydney <- runs |> 
  dplyr::mutate(
    sydney = near_sydney(lat, lon),
    run_len = dplyr::last(distance),
    .by = "id"
  ) |> 
  dplyr::filter(sydney == TRUE, run_len > 2000) |> 
  dplyr::arrange(run_len, id, time)

runs_sydney

# A tibble: 272,386 × 9
   id          time                  lat   lon   ele elapsed distance sydney
   <chr>       <dttm>              <dbl> <dbl> <dbl>   <dbl>    <dbl> <lgl> 
 1 2024-05-09… 2024-05-09 02:48:50 -33.9  151.  22.5   0         0    TRUE  
 2 2024-05-09… 2024-05-09 02:48:57 -33.9  151.  22.4   0.117     9.83 TRUE  
 3 2024-05-09… 2024-05-09 02:49:01 -33.9  151.  22.2   0.183    21.4  TRUE  
 4 2024-05-09… 2024-05-09 02:49:05 -33.9  151.  21.9   0.25     31.7  TRUE  
 5 2024-05-09… 2024-05-09 02:49:10 -33.9  151.  21.6   0.333    42.7  TRUE  
 6 2024-05-09… 2024-05-09 02:49:16 -33.9  151.  21.5   0.433    54.3  TRUE  
 7 2024-05-09… 2024-05-09 02:49:21 -33.9  151.  21.3   0.517    65.2  TRUE  
 8 2024-05-09… 2024-05-09 02:49:26 -33.9  151.  20.9   0.6      75.2  TRUE  
 9 2024-05-09… 2024-05-09 02:49:31 -33.9  151.  20.4   0.683    86.9  TRUE  
10 2024-05-09… 2024-05-09 02:49:37 -33.9  151.  19.7   0.783    98.6  TRUE  
# ℹ 272,376 more rows
# ℹ 1 more variable: run_len <dbl>

purrr::reduce(
  .x = runs_sydney |> 
    dplyr::group_by(run_len, id) |>
    dplyr::group_split(),
  .f = \(map, run) {
    map |> 
      leaflet::addPolylines(
      data = run, 
      lat = ~lat, 
      lng = ~lon, 
      color = ifelse(
        run$run_len[1] > 21000, 
        "#006699", 
        "#C76E00"
      ), 
      opacity = .6, 
      weight = 4
    )
  },
  .init = leaflet::leaflet() |> 
    leaflet::addTiles(
      urlTemplate = stadia_tile_url("stamen_watercolor"),
      options = leaflet::tileOptions(opacity = .3)
    )  
) |> 
  leaflet::setView(
    lat = -33.863, 
    lng = 151.235,
    zoom = 12
  )