Re: [ESS] brms / cmdstanr crashes in emacs but not terminal
Hi Manuel, Thanks, different paths is a good idea. I'll take a look at those and experiment. Thank you! Josh On Fri, 26 May 2023 at 18:28, Manuel Teodoro wrote: > Hi Joshua, > > Here is an idea but I hope that somebody with more experience in Emacs can > chip in to the discussion. > > In my experience I have encountered a similar situation a couple of times: > when a process is available in the terminal but not in Emacs it is because > the path to the scripts and terminal commands is not known by emacs. Thus, > it can be possible that your package is trying to execute some commands > that are known by your terminal cmd.exe and if you tell Emacs what is the > path containing all those terminal commands, Emacs will be able to find it. > > Here are a couple of links that could possibly give you some ideas. As I > said, I am not really expert in the topic, plus I use emacs in Linux so, > I'm sorry if I can't help more. But for sure this will give you some > starting point. > > https://www.emacswiki.org/emacs/ExecPath > > https://emacs.stackexchange.com/questions/64081/how-to-get-the-path-from-the-shell > > Good luck! > Manuel T. > > On Fri, May 26, 2023 at 2:35 AM Joshua Wiley via ESS-help < > ess-help@r-project.org> wrote: > >> Hi All, >> >> I normally work in Emacs (28.2 build 2)) on Windows 11 pro as an admin >> user. >> Quite a few of my analyses these days use Stan (via cmdstanr and the brms >> package as example). >> I upgraded R to 4.3.0 and Stan. Now, I am quite reliably getting crashes >> where my R process terminates when using Stan. For those not familiar, >> Stan >> is in C++ and generates code which is then compiled into a custom C++ >> model >> for that Bayesian analysis. The compilation is fine, but when it starts >> sampling, I get this when I run via Emacs: >> >> ## Start sampling >> ## > > >> ## Process R finished at Fri May 26 10:32:05 2023 >> >> The reason I'm asking here and not just on Stan forums is that when I >> start >> a terminal (cmd.exe) and start R there and run the exact same code, it >> reliably finishes and does not crash. >> >> I also tried M-x shell in Emacs and running R through that and also get a >> crash. >> >> If anyone knows a solution that would be great but at this stage I'd love >> to hear even just ideas on _what_ the difference is? I guess in my head R >> through terminal and R through Emacs were the same and so I'm not sure >> where to even begin looking for causes. >> >> Many thanks, >> >> Josh >> >> [[alternative HTML version deleted]] >> >> __ >> ESS-help@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/ess-help >> > [[alternative HTML version deleted]] __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
[ESS] brms / cmdstanr crashes in emacs but not terminal
Hi All, I normally work in Emacs (28.2 build 2)) on Windows 11 pro as an admin user. Quite a few of my analyses these days use Stan (via cmdstanr and the brms package as example). I upgraded R to 4.3.0 and Stan. Now, I am quite reliably getting crashes where my R process terminates when using Stan. For those not familiar, Stan is in C++ and generates code which is then compiled into a custom C++ model for that Bayesian analysis. The compilation is fine, but when it starts sampling, I get this when I run via Emacs: ## Start sampling ## > > ## Process R finished at Fri May 26 10:32:05 2023 The reason I'm asking here and not just on Stan forums is that when I start a terminal (cmd.exe) and start R there and run the exact same code, it reliably finishes and does not crash. I also tried M-x shell in Emacs and running R through that and also get a crash. If anyone knows a solution that would be great but at this stage I'd love to hear even just ideas on _what_ the difference is? I guess in my head R through terminal and R through Emacs were the same and so I'm not sure where to even begin looking for causes. Many thanks, Josh [[alternative HTML version deleted]] __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] Advice on setting up ESS to edit and knit Rmarkdown files
Are the bugs something that could be helped if there was small funding for a student internship? If potentially useful, any of the ESS developers can contact me directly. On Thu, Sep 23, 2021 at 3:53 AM Martin Maechler via ESS-help < ess-help@r-project.org> wrote: > > Lionel Henry via ESS-help > > on Wed, 22 Sep 2021 15:15:42 +0200 writes: > > > We'd love to do a release but ESS is not in a good place > > right now. > > Definitely. The reason is that there have been too many bugs > introduced with the new features, so we could/should not > release. > > This has been the real reason for not releasing formally. > > In addition, another important goal for the release has been to > create an ESS+ "package" (not mainly an ELPA package, but also a > traditional tarball / zip file) which will contain > ESS plus relevant parts of polymode even though the latter is > only maintained by one of us; the use of both *and* correct > interplay between polymode and ESS is really crucial for parts > modern R using ESS, notably as we had decided to declare the ess > noweb-mode (for editing *.Rnw, i.e., Sweave & (tex-based) knitr) > as obsolete. > > > Recent versions of Emacs interrupt background > > commands (essential to completion and contextual help like > > eldoc) when the user starts typing, which causes hard to > > solve problems. > > > The dev branch is mostly working but not 100% > > correctly. Unfortunately none of us seem to have the time > > to work on ESS at the moment. > > > That said, while Martin, Vitalie and I notice issues here > > and there, we haven't had serious bug reports in a while, > > despite the dev branch being used by many Melpa users. So > > maybe releasing in the current state is better than nothing. > > Well... > It would be the first ESS release with serious (for some / in > some use case situaitons) known bugs .. > > > Best, Lionel > > > > On 9/22/21, Dirk Eddelbuettel via ESS-help > > wrote: > >> > >> On 20 September 2021 at 13:59, Sparapani, Rodney via > >> ESS-help wrote: | Generally, this stuff should just work > >> out-of-the-box. > >> > >> Understood. > >> > >> | And we are not a company like RStudio so this FOSS > >> setup works for us as | developers and hopefully it still > >> serves the users well. > >> > >> But legal structure has nothing to with 'calling a > >> release'. Which is done by authors (who should know the > >> code better than users) saying "yep what we have at HEAD > >> right now is good" and then cut a tarball. That is a > >> _marker_. Which some less-informed people like me can > >> take (and then ship downstream to Debian, and with that > >> Ubuntu etc). > >> > >> Without a marker, no shipment. Less ideal to me and > >> others. > >> > >> So pretty-please if someone would: could a release one of > >> these moons. It does not have to be frequent or regularly > >> schedule or anything. But maybe more often than once > >> every few years? Maybe when you sync with upstream Emacs > >> (assuming you do now)? > >> > >> Dirk > >> > >> -- > >> https://dirk.eddelbuettel.com | @eddelbuettel | > >> e...@debian.org > >> > >> __ > >> ESS-help@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/ess-help > >> > > > __ > > ESS-help@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/ess-help > > __ > ESS-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/ess-help > [[alternative HTML version deleted]] __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] Best Practice for building R packages
I'm not sure I could present, but very interested in watching. I manage a few packages and do it all in Emacs & ESS, but I don't think I take advantage of ESS well, other than its automatic ability to run roxygen2 examples, and syntax highlighting. Happy to read and edit wikis and provide input/feedback. On Fri, Oct 9, 2020 at 1:06 AM Dirk Eddelbuettel via ESS-help < ess-help@r-project.org> wrote: > > On 8 October 2020 at 13:17, Ahmadou Dicko wrote: > | I do agree with your suggestion. There is much more to ESS than I > | know and it would be great if we could pool our resources to improve > | further. > > On 8 October 2020 at 09:38, Tyler Smith via ESS-help wrote: > | I would also be interested in a webinar. > > Three, as they say, is a club -- so let's do this!! > > I am currently in a teaching term so a little tied up until year-end but > just > before I did about eight weeks with weekly short videos on 'tools, toys, > tips > and tricks' (mostly around the command-line). [1] > > Emacs is natural follow-up to this but there is _so much_ I wanted to cover > there that I am effectively overwhelmed and hence inactive. So let's turn > this upsite down and maybe _just_ focus on ESS. Shall we? We could / > should > just start with a wiki and hash out, say, half a dozen high-level topics > and > then take turns. Deal? > > Dirk > > [1] Blog posts under this tag: https://dirk.eddelbuettel.com/blog/code/t4/ > First post was > http://dirk.eddelbuettel.com/blog/2020/05/03#000_introducing_t4 > and YouTube content is here: > https://www.youtube.com/c/DirkEddelbuettel/videos > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > ESS-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/ess-help > [[alternative HTML version deleted]] __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
