similar to: R base packages

?library Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Mon, Oct 23, 2017 at 11:36 AM, Rene J Suarez-Soto < rene.j.suarez at gmail.com> wrote: > I installed R 3.4.2 (Windows) and noticed that 30 folders are under my

I checked after this question popped up on Stackoverflow: https://stackoverflow.com/questions/44785961/compile-pdf-in-rstudio-works-but-knit2pdf-does-not-work-in-r-or-rstudio On Windows, texi2pdf looks for the texify.exe of Miktex, but looks in a very wrong place: > Sys.which("texify") texify

Hi Duncan, I'm guessing I'll be able to look at this over the weekend/next week (probably closer to next week). It is on my list of things to do and I've just had a few other prior commitments that I have to finish first. Sorry for the delay. I'll chime in with a status update next week. Nathan -----Original Message----- From: R-devel [mailto:r-devel-bounces at r-project.org]

Hi, Duncan i have forwarded this thread to Nathan, who promised to look into it. Andrie On 17 Jun 2017 17:26, "Duncan Murdoch" <murdoch.duncan at gmail.com> wrote: > On 17/06/2017 9:13 AM, Ben Marwick wrote: > >> Hi Duncan, >> >> Thanks for your reply. Yes, it does seem to be specific to the CTYPE >> setting to Chinese on Windows. If I set it to

Dear dev team, I was sorry to see the announcement of Duncan about his retirement from maintaining the R Windows build and Rtools. Duncan, thank you incredibly much for your 15 years of devotion and your impressive contribution to the R community as a whole. Thinking about the future, I wondered whether there were plans for the succession of Duncan. Is it the intention to continue providing

I'd be curious to know what others think of Rich's patch. If it is acceptable, I can spend time that I was going to look at it this week on another bug. -----Original Message----- From: Rich Calaway Sent: Friday, June 23, 2017 6:34 PM To: Nathan Sosnovske <nsosnov at microsoft.com>; Duncan Murdoch <murdoch.duncan at gmail.com>; Andrie de Vries <apdevries at gmail.com>

I think that even though some Microsoft employees may have good intentions Microsoft as a company can not be trusted. There will be always a danger that they will try to create their own version of R which works only on Windows and that will become increasingly divergent from "other" R. We witnessed such (cursed in my opinion) attempts with their treatment of Java and Internet Explorer.

Thanks Andy, helpful as always! 1 is a possibility, but not ideal for us. Could you elaborate a little on 3? I don't really know what a jump stub is, but am guessing it's a kind of "alternative symbol" which would just act as a middle man to invoke the "real" symbol in the static library. If that's the case, I can think of a way to implement it for specific

Hey Bjorn, Were you able to figure this out or is it still broken for you? Our scenario is a little bit different, but I have a theory as to what may be going wrong. What linker are you using when you compile your project with clang-cl? I am wondering whether the version of the linker and/or the libraries that you are using is too old in comparison to the one used for the clang compilation.

First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced

Some time ago I posted here regarding a relocation overflow on Windows (among other things), but the issue disappeared and so the thread got left. I've started this new thread because a) I didn't want to necro the old one and b) it felt like its own. I've now encountered the issue again and am noting down all the information I can get about it whilst it's happening. The issues is

Hi All, I have a fix to this bug ( https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16454) and would like to submit a patch to the bug report on Bugzilla. I'd also like to start going through some of the other Windows-specific issues and start fixing those. The bug submission instructions indicate that I should ask here for a Bugzilla account. Is that still the correct procedure? Thanks!

Thanks for the link! There’s some code there that looks extremely relevant to say the least. > On 1 Oct 2015, at 19:00, Hayden Livingston <halivingston at gmail.com> wrote: > > Maybe looking at their code might help: > > https://github.com/dotnet/llilc/blob/dd12743f9cdb5418f1c39b2cd756da1e8396a922/lib/Jit/LLILCJit.cpp#L299 > > On Thu, Oct 1, 2015 at 10:45 AM, David

OK, so, if I understand, the tag is at 3.8.1, but there is no source drop available for download? Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Tuesday, July 5, 2016 4:12 PM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] llvm 3.8.1 Release Hi Del, Yes, the tag is for the latest stable release. It's

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated

It’s pretty intermittent at the moment…sometimes I get the relocation overflow issue, sometimes I get another issue about BSS sections having no contents. The source code to reproduce either is simple: #include <iostream> int main (int argc, char* argv[]) { } I’ve managed to reproduce the BSS section issue in clang consistently, and since that comes before terms of where it happens in

Cool, thanks for debugging this issue and letting us know. We have a few patches to fix this issue: - Introduce freeze in IR: https://reviews.llvm.org/D29011 - Lowering freeze: https://reviews.llvm.org/D29014 - Fix loop unswitch: https://reviews.llvm.org/D29015 Bonus patches to recover perf: - Be less conservative in loop unswitching: https://reviews.llvm.org/D29016 - Instcombine support

The best way to test on Windows would probably be creating a small virtual hard disk (via CreateVirtualDisk), mounting it, and writing to the mounted location. I believe the drive could even be mounted to an arbitrary location on the filesystem (instead of a drive letter) so that drive letter conflicts don't come into play. -----Original Message----- From: R-devel [mailto:r-devel-bounces at

Thanks for help! I think that sign extension is not involved here. PromoteIntegerResult is called since i32 is not a legal type in my target and the legalizer promotes operations with i32 result type to i64 operations. I think that SetPromotedInteger seems to be a common place for all promotions like SetExpandedInteger. Jonas, I would appreciate it if you can guide me about whether my

Oops, sorry for the spam. That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5 > On 5 Oct 2015, at 17:26, Joshua Gerrard <joshua.gerrard at roli.com> wrote: > > Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5 > >> On 5 Oct 2015, at 17:16, Joshua Gerrard <joshua.gerrard at roli.com> wrote: >>