Expecting a window handle relevant to the script to exist for the purpose of identifying a path seem to be orthogonal problems to me. But Andrew has indicated offlist that he has alternate code for other cases only uses this technique when appropriate.
I still feel this is too convoluted as a way to identify a path, but if he covers all cases then my opinion is just an opinion. On September 30, 2021 2:34:48 PM PDT, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: >On 30/09/2021 5:21 p.m., Jeff Newmiller wrote: >> What if you are on Windows but running R at the command prompt, or via >> cygwin, or in the console window of RStudio? >> >> This seems unstable to me. > >Sorry, too much context missing. What's unstable? > >Duncan Murdoch > >> >> On September 30, 2021 11:52:16 AM PDT, Andrew Simmons <akwsi...@gmail.com> >> wrote: >>> Hello, >>> >>> >>> I'm updating my package 'this.path' which is supposed to retrieve the >>> absolute path of the executing script when called. It's similar to 'here', >>> except that 'here' constructs paths relative to a project directory, >>> whereas 'this.path' constructs paths relative to script directories. I was >>> updating the section where I retrieve the executing script's path while >>> running from a script open in Rgui for Windows, and I needed >>> utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles >>> is a Windows only function, I >>> would imagine that 'utils' contains a similar line of code as above: >>> >>> >>> if (.Platform$OS.type == "windows") >>> getWindowsHandles <- function() ... >>> >>> >>> and then in the NAMESPACE: >>> >>> >>> if (.Platform$OS.type == "windows") >>> export(getWindowsHandles) >>> >>> >>> so I'd like to change my code to getWindowsHandles and import >>> getWindowsHandles from utils, but I can only do that on Windows, and so the >>> conditional importing should work for me. At no point does my function >>> mis-behave because of a attempting to use a function that isn't exported on >>> that platform, because within the function it only uses getWindowsHandles >>> if the OS is Windows. >>> >>> >>> On Thu, Sep 30, 2021 at 11:01 AM Mark Miller <mark.roman.mil...@gmail.com> >>> wrote: >>> >>>> Returning to the original question, if it's helpful: I'd like to know what >>>> constraints led to considering an export only available on Windows, and see >>>> if we can suggest some other designs. It'd be good to keep the user's >>>> mental model abstracted from the platform they're working on. There are >>>> often unavoidable differences due to platform, but usually they're handled >>>> with warnings and errors rather than selective exports. >>>> >>>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool < >>>> berryboessenk...@hotmail.com> wrote: >>>> >>>>> >>>>> One of the very best fortunes nominations! >>>>> >>>>> [...] >>>>> >>>>> I suspect something like >>>>> >>>>> if (stats::runif(1) > 0.5) export(someFunction) >>>>> >>>>> would work too, for a particularly frustrating experience for your >>>>> users. It would mean half the installs export the function, and half >>>>> don't. >>>>> >>>>> Duncan Murdoch >>>>> >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> ______________________________________________ >>>>> R-package-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>>> >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ______________________________________________ >>>> R-package-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>> >>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel