Using deno, git, virtualenv plugins
lyttle.zsh-theme:
PROMPT='%{$fg_bold[cyan]%}$(virtualenv_prompt_info)%}$(git_prompt_info) %c %{$fg_bold[white]%}%% %{$reset_color%}'
ZSH_THEME_GIT_PROMPT_PREFIX="("
ZSH_THEME_GIT_PROMPT_SUFFIX=")"
ZSH_THEME_GIT_PROMPT_DIRTY=""
| # Example of vegawidget with dynamic data and signal | |
| # | |
| # To use shiny_get_signal along with dynamic data (on R side), you have to use | |
| # shiny_set_data as well. This is because the binding of shiny_get_signal breaks | |
| # if you use normal reactive data (see other file in this folder). | |
| # | |
| # shiny_set_data work saround that problem and uses an elegant reactive solution | |
| # | |
| # based on: https://github.com/rhenkin/rsnippets/blob/main/vegawidget_shinygetsignal/app_working.R | |
| # |
Copyright (c) 2022 Ian Lyttle
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
These ideas based on GitHub Flow and are heavily influenced by Jenny Bryan and Hadley Wickham, through their R package {usethis}.
The term upstream refers to a remote that is the "canonical" repository for a project.
The term origin refers to a remote that is a fork of an upstream remote.
If you are one of the maintainers for a repository, you can push to the upstream remote.
| --- | |
| title: "Altair-reticulate" | |
| output: html_document | |
| --- | |
| ```{r load_packages} | |
| library(vegawidget) | |
| library(reticulate) | |
| ``` |
| # imports lubridate, emo, glue, purrr | |
| as_woodiac <- function(x) { | |
| is_dst <- lubridate::dst(as.POSIXct(x)) # pick up OS timzone | |
| x <- lubridate::as_date(x) | |
| date_2000 <- x | |
| lubridate::year(date_2000) <- 2000 | |
I see our project as a set of two transformations: one that changes a ggplot2 object into a ggspec, then another that changes a ggspec into a Vega-Lite spec.
The analogy may not be exact, but I see these transformations in terms of linear algebra, where a ggplot2 object is a vector in "ggplot" space, a ggspec is a vector in "ggspec" space, and a Vega-Lite spec is a vector in "Vega-Lite" space.
One of our goals is that "ggspec"-space should be a faithful representation of "ggplot2"-space. One way of doing this is to make sure that the "transformation-matrix" is as close to diagonal as we can make it. As Haley likes to point out, the ggplot2 object is a "list of 9"; therefore the "ggspec" object will have no more than 9 elements (maybe it will not have a "theme"?).
If we wanted to (and we don't want to), we could reproduce the ggplot2 object using the ggspec.
| # An .Renviron file helps keep you safe, by storing secrets in one place that | |
| # you can secure. | |
| # - to open *your* .Renviron file, usethis::edit_r_environ() | |
| # - please make sure that your .Renviron file ends with a newline, | |
| # or R will ignore it | |
| # - this is a minimal file, you will likely want to add your own "stuff" | |
| # - if you need to deal with a firewall, this is the place to define | |
| # your proxy variables | |
| # | |
| # More information: https://whattheyforgot.org/r-startup.html#renviron |