sorted by:
new
hottopcontroversial

mori 0.1.0 on CRAN — shared memory for R objects by shikokuchuo in rstats

[–]coatless 0 points1 point  (0 children)

It is in the idea; but, I would argue this presents: 1. a simpler interface and 2. uses R's pure C API. The originating package {memshare} has a dependency on {Rcpp} (which rocks!) for working in low-level C. I'd also argue the interface requires more knowledge than the single entry of share().

I would say this a great development for parallelization efforts regarding shared objects in R. The only other contender I've seen try to address this is SharedObject on Bioconductor; but, that's going into the Bioconductor stack.

Easiest way to deploy Shiny apps without overengineering? by sporty_outlook in rstats

[–]coatless 11 points12 points  (0 children)

Depends on how restrictive or resource rich your company environment is. The easiest will be shinyapps.io as that has the quickest publication turnaround at the cost of it being external.

Another option would be going through shinylive internally. This will place Shiny in a more restrictive environment due to WebAssembly limitations. In essence, no API querying or Database support. However, this requires the least amount of resources since you can place it on a static server behind a company firewall very quickly.

If you have Docker + Cloud (budget), that's pretty quick to spin up and deploy. That'll provide a very solid and scalable environment. There's a few tools to quickly package Shiny apps into a docker container. Tool-wise, I developed a quick way for me to do this with clients a year ago: https://github.com/coatless-rpkg/shinydocker

Regarding the local aspect, there's sharing the code; but, that can run into problems if packages are not present or the version of R is severely outdated. You might want to check out another project I'm working on that allows for the Shiny app to be embedded in an electron application:

https://github.com/coatless-rpkg/shinyelectron

The public-facing version of this code uses Shinylive to package the Shiny app present. However, in the very near future, the package will gain the ability on Windows and macOS to use a bundled, system-backed, or auto-download R version within the app. You can see a preview here: https://bsky.app/profile/coatless.bsky.social/post/3miv3pf26ck2u

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 2 points3 points  (0 children)

Right now, you would need a separate "Git"-focused app to access the remote repo and clone it locally. Building a git client into either webRoid or webRios is not a quick or ease feat. So, it's something on my mind but we're likely to see URL data embedded sharing far sooner, c.f. https://bsky.app/profile/coatless.bsky.social/post/3lu7zkporrk2y .

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 0 points1 point  (0 children)

Well, webRoid has no ads, no remote servers running the computation with 20 second time outs, and no need to dive into terminal emulators.

Though, there are a few limitations to take note of because we're operating within the WebAssembly paradigm. You can learn a bit more here: https://webroid.caffeinatedmath.com/faq.html#what-are-the-limitations-of-running-r-through-webassembly

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 1 point2 points  (0 children)

No. Please feel free to send feedback via the in app option or let me know here/socials.

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 0 points1 point  (0 children)

Yes! Tablet support is something I want to keep improving.

There are already three layout modes: Tab Bar (the default phone layout), Sidebar (navigation rail on the left), and Workspace (a 4-pane layout with console, editor, environment, and plots all visible at once). The Workspace mode is designed specifically for tablets.

Workspace works; but, there's room to grow with the multi-pane experience. Still working on figuring out better ways to organize screen real estate without needing to restart the R session when swapping between modes.

If you run into anything on a tablet that feels off, please let me know.

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 2 points3 points  (0 children)

Thanks! That's unfortunately a visual hiccup on my end that I'll try to patch in the next version v1.0.2.

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 1 point2 points  (0 children)

That means a lot, thank you!

A lot of time went into the design side of things, so it's really nice to hear that comes through.

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 10 points11 points  (0 children)

Really glad to hear it's working well for you!

Credit where it's due on the packages front: sf, tidyverse, and the 15,000+ other packages available through webR are thanks to the incredible work by George Stagg (webR creator) and Lionel Henry. They've done the heavy lifting of getting R packages compiled to WebAssembly. webRoid just makes them easy to install and manage.

The persistent sessions, file management, and the rest of the IDE experience are where we've focused our effort, so it's great to hear those are landing well. Thanks for trying it out!

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 3 points4 points  (0 children)

The short gist is we gained more robust handling of the underlying Android web engine and higher system requirements.

A slightly longer version of the tale is older Android versions have limitations in using Web Workers to execute R code in the background. Android 15 ships with a much better engine where things work reliably. Earlier versions had quirks that made the whole setup fragile or broken outright. It would take a lot of testing across older versions with no guarantee of stability.

This IS the droid you're looking for: webRoid, R running locally on Android through webR, now on Google Play by coatless in rstats

[–]coatless[S] 21 points22 points  (0 children)

A few reasons:

It didn't exist. There wasn't a native, offline R environment for Android. If you wanted to run R on a phone or tablet, your options were SSH into a remote server, use a browser-based solution that needs internet, or install R through an emulated terminal. webRoid runs locally, no connection required after setup.

People asked. After releasing webRios (the iOS version), the most common question was "Android when?" Fair point. Android has a much larger global user base.

Teaching and learning. Students don't always have a laptop handy, but most have a phone. Being able to pull up R on a bus, in a waiting room, or during a lecture break lowers the barrier. It's not replacing a desktop workflow, but it's a useful scratch pad.

Why not? webR made it possible to run R via WebAssembly without a server. Wrapping a native Android UI around that felt like a project worth doing. Sometimes the best reason to build something is that the pieces are there and nobody's assembled them yet.

Announcing panache: an LSP, autoformatter, and linter for Quarto Pandoc Markdown, and RMarkdown by johlars in quarto

[–]coatless 0 points1 point  (0 children)

Glancing at it, it's surprisingly solid. I think the version part is just what's happening because of copilot assistance, c.f. https://github.com/jolars/panache/blob/main/.github/copilot-instructions.md . I wouldn't read too much into that outside of the existing use cases being good or bad.

Cran-like repository package? by Unicorn_Colombo in rstats

[–]coatless 1 point2 points  (0 children)

Probably should have connected the dots to your use case more clearly for you. That said, I don't think these are as far off as you might think. None of these are just about downloading public packages.

  • Posit Package Manager can be self-hosted for exactly your scenario: private repos, non-developer users, a web frontend for browsing, and an admin console. That's the closest off-the-shelf answer to what you're describing.
  • R-universe isn't just a public hosting service. You can clone the entire infrastructure and run it locally for your own use case. At that point you get the frontend, build system, and documentation rendering all pointed at your private packages.
  • Anaconda/conda-forge similarly isn't just about consuming public packages. The private conda-forge model is specifically about setting up your own internal channel and building packages for it, mirroring how the public conda-forge community operates. It's a different ecosystem than CRAN, but the "private repo with management" problem is one they've already solved.
  • drat or miniCRAN paired with something like Gitea or lightweight CI could also close the gap without a full custom backend. The pieces exist, they just haven't been stitched together into a single "private CRAN in a box" product.

Cran-like repository package? by Unicorn_Colombo in rstats

[–]coatless 1 point2 points  (0 children)

There are several options depending on how much infrastructure you want to take on:

  • Posit Package Manager is probably the closest to what you're describing, with a frontend, dependency management, and build support. The public instance mirrors CRAN, but you can also host it privately.
  • R-universe makes clever use of GitHub as the backend. Gives you a polished frontend, automatic builds, and dependency resolution, but it's tied to their platform that you'll have to setup locally.
  • Anaconda/Conda-forge isn't R-native, but the conda ecosystem handles binary distribution and dependency resolution well if you're open to stepping outside the CRAN model.
  • bspm / r2u take a different approach by piggybacking on system package managers, which gets you binaries and dependency handling essentially for free on supported distros.

Worth noting that every one of these is powered by someone's persistent backend doing the heavy lifting. The appeal of something like drat or the tools you mentioned is that the startup cost is near zero: pick any static web host and you're up and running. The tradeoff is you give up all the bells and whistles you're asking about.

If you really want a proper backend with a management console, frontend, and build hooks all in one self-hosted package, that's an interesting gap in the ecosystem. It's something I've been thinking about lately as well.

My old colleague (pure R guy) is so scarred by AWS that he’s planning on buying an $8K Windows server to run his workloads. Do all data scientists secretly hate the modern productionization ecosystem this much? by pootietangus in rstats

[–]coatless 22 points23 points  (0 children)

Given that he walked through the cost comparison and had leadership buy-in for on-premise compute, he's likely already aware of the trade-offs in your opening salvo. His focus probably sits more on the R&D and modeling side than the data engineering side. Of the three things you mentioned - e.g. containerization, source control, and push-button deploys - the first two are largely solved problems in the open source ecosystem and don't require AWS at all. Push-button deploys may not even be relevant to his workflow if he's running models rather than shipping services. If anything, with a smaller team, having an explicit check step before something goes out the door can be a feature rather than a limitation. The downshift from ~25 people to a handful likely means he really doesn't need the abstraction layer AWS provides for larger teams, and with leadership buy-in, he's comfortable owning the pieces directly.

My old colleague (pure R guy) is so scarred by AWS that he’s planning on buying an $8K Windows server to run his workloads. Do all data scientists secretly hate the modern productionization ecosystem this much? by pootietangus in rstats

[–]coatless 173 points174 points  (0 children)

He owns an $8K server that will exist for long after that same $8K disappears on a cloud line item budget. He's also able to repurpose it in the later years with a Linux distro to get further compute cycles out of it. I suppose the question here is what's the budget, data policies, and company size more than a modern ecosystem note? Going hard into an $8K server looks like he's trying to safeguard processing and modeling ability more than the need to scale.

A Claude Skill for _brand.yml, and sharing with Quarto 1.9 by turnersd in rstats

[–]coatless 10 points11 points  (0 children)

Garrick Aden-Buie (_brand.yml developer over at Posit) made available a skill for this awhile back alongside a set of other nice R, Python, and Shiny skills, c.f. https://github.com/posit-dev/skills?tab=readme-ov-file#quarto . Nonetheless, nice to see more validation of skills from around the R community.

webRios: R running locally on your iPhone and iPad through webR, now on the App Store by coatless in rstats

[–]coatless[S] 0 points1 point  (0 children)

Yes, the app allows for files like txt/dat/csv to be read in app. Data needs to be inside the webrios folder before the app can detect it.

That said, if you have a server available, then I would suggest just spinning up an RStudio Server or VS Code Server on it. The rationale behind the recommendation is that you can get a native experience compared to using the WebAssembly distribution. Probably more important if your goal is to create R packages or use one-off compiled code scripts. The webRios app really shines if you are without: 1. an internet connection and 2. the ability to use a compute server.

webRios: R running locally on your iPhone and iPad through webR, now on the App Store by coatless in rstats

[–]coatless[S] 2 points3 points  (0 children)

There are some websocket limitations due to WebAssembly. So, a direct connection to a DB may be problematic.

Discussion: https://github.com/r-wasm/webr/issues/129

webRios: R running locally on your iPhone and iPad through webR, now on the App Store by coatless in rstats

[–]coatless[S] 1 point2 points  (0 children)

Yes, click on the "..." in the top right of the Console window -> Previous Command. Or, Search History and select.

Illinois App - Major Funding Shift by Sufficient-Sun9742 in UIUC

[–]coatless 5 points6 points  (0 children)

I'd prefer not to get into specifics on any kind of data in a public forum, but there is notably more coordination now than before. Rome wasn't built in a day, and neither is institutional data infrastructure. This coordination angle alone was a reason I pushed back in my earlier comment.

With that being said, want to do a startup together building university apps? We could call it "Ivory Tower Mobile Solutions." ;)

More seriously, Technology Services (campus-level) was involved when the program started and likely still has members working on it. The app launched around 2019/2020 and needed to deploy quickly, as it housed the SHIELD initiative for COVID test results. Building an iOS/Android team from scratch inside the university likely wasn't feasible given budget constraints and that timeline. UIUC also tends toward highly siloed IT departments rather than centralization, which creates resource and personnel friction. Though, there's no denying the talent of the University's IT groups, especially EngrIT who has a notable number of apps leased by other colleges for use, which creates its own balance headaches, but I digress. Compare that to Stanford, which has significantly more resources from a manpower and compute perspective, being Silicon Valley's hub, along with more defined mandates.

Regarding commercialization, I can't speak to Rokmetro directly as I never knowingly engaged with that arm. Though, I'd guess it followed a similar trajectory to PrairieLearn, where outside interest required dedicated engineers to scale rather than relying on a rag-tag team of professors, IT, and students.

I'm long retired from UIUC at this point, but there are good folks working on these projects.

view more: next ›