similar to: toolchains

Hello! Many years ago I have found some bugs are prevented build of libFLAC on some MinGW toolchains and I made my own patch to fix that. - The `_wutime64()` call may absent. For this case I using the `_wutime()` call as a fallback when _wutime64() is unavailable. - `_stricmp` and `_strnicmp` are also may fail. Therefore it's prefer to use `stricmp` and `strnicmp` (without `_` prefix) on

The MinGW-w64 project, whose toolchains we use for 64-bit Windows, have made some changes to their conventions *and* removed all the older binary builds from their site. The current toolchains are not suitable for use with R 2.11.x, and I've re-packaged an older version (which is) as http://www.stats.ox.ac.uk/pub/Rtools/oldWin64toolchain.zip The most critical change is to no longer have

Hi David, Thank you for your reply. In fact, my question originally came from the google native client. I thought that the bitcode can be shared among the different targets as it inherently is. Therefore, I used the clang to generate the bitcode to prove that my thought is right, and I supposed that the different bitcode caused from the different versions of libraries before. Thanks for the

On Jun 6, 2018, at 5:18 AM, Walter HILL <hill at ieee.org> wrote: > > Does anyone know of a relatively recent guide to getting this UPS > running on a newer version of OS X? I am aware that Apple have been > re-engineering their startup process so I expect that getting the driver > to work may be the least of my problems. > To be honest, I have not seen much demand for

I got my USB ups reporting on macOS, but it was quite a while ago, I’ll have to dig into how I did it.. I do remember is wasn’t simple.. ( actually is was long drawn out pain in the …. ) Maybe search for posts from me, I’ll check what I did on the weekend and get back to you.. Or, buy an APC.. as they will just appear in Energy Saver.. > On 6 Jun 2018, at 15:41, Charles Lepple

hello I maintain the gsl R package, and many users have recently reported that the package does not install from source under macosx 10.9 ("mavericks"). Users typically install the gnu GSL library and are able to compile and run a small "hello world" program which executes some of the Bessel functionality of the library; but under mavericks the configure script (which uses

Hi, I'm using clang to build my project as follows: $ clang++ -ccc-host-triple arm-none-linux-gnueabi --sysroot=/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc/ -o foo.o -emit-llvm -c foo.cpp $ clang++ -ccc-host-triple arm-none-linux-gnueabi --sysroot=/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc/ -o main.o -emit-llvm -c main.cpp $ llvm-link foo.o main.o -o

Kenia Kuo <kenkillerkuo at gmail.com> writes: [snip] > Currently, I tried the toolchains of ARM and PowerPC that have the > different versions of libraries, obviously the generated bitcode are > different. > So I wonder whether the version of library is the only reason why the > generated bitcode are different.

Hi Óscar, Thank you for your reply. It looks like the limitations are the platform's API and ABI (included the size of variable). So, if there are two platforms that have the same API, ABI but different ISAs, the bitcode can be shared. Can I say that? Thanks, Kenia Kuo 2012/9/25 Óscar Fuentes <ofv at wanadoo.es> > Kenia Kuo <kenkillerkuo at gmail.com> writes: > >

I am writing several webpages using the brew package and R2HTML. I would like to work off one script so I am using nested brew calls. The documentation for brew states that: "NOTE: brew calls can be nested and rely on placing a function named ?.brew.cat? in the environment in which it is passed. Each time brew is called, a check for the existence of this function is made. If it exists,

> We've taken the '.relr.dyn' section from Cary's prototype, and implemented a > custom encoding to compactly represent the list of offsets. We're calling the > new compressed section '.relrz.dyn' (for relocations-relative-compressed). I'd suggest just using .relr.dyn -- your encoding is straightforward enough that I'd just make that the standard

Dear all Is there an equivalent of "R CMD Sweave" for brew [1] documents? Something in the lines of "R CMD brew"? Can R be configured to parse brew documents from the commandline, without opening an interactive R session and issuing the following? require(brew) brew("featurefull.brew") I would like to set a LyX converter for brew documents, and for this I'd need

Dear R useRs, i have the following code to compute values needed for a contour plot ############################################################ "myContour" <- function(a, b, plist, veca, vecb, dim) { tmpb <- seq(0.5 * b, 1.5 * b, length=dim) tmpa <- seq(0.5 * a, 1.5 * a, length=dim) z <- matrix(0, nrow=dim, ncol=dim) for(i in 1:dim) { for(j in 1:dim)

> To be honest, I haven't experimented much with this, but I saw a normal shutdown/reboot when I just tried this from the command line (10.12): > > reboot ~ Mon Jun 12 08:36 > shutdown ~ Mon Jun 12 08:35 > clepple ttys007 Sun Jun 4 21:52 - shutdown (7+10:43) > However, the "-u" flag did not

Dear R-developers, As part of our package building process, we maintain internal CRAN-like repositories of our packages. This has worked pretty well, but we are running into issues with R 3.1 and OSX mavericks. Specifically, machines with osx mavericks seem to, by default, expect packages to be located under a 'mavericks' sub-directory, but this is not the location reported when

R.framework-Versions-Resources-library-grDevices-libs-cairo_20150120.tgz in http://sourceforge.net/projects/outmodedbonsai/files/R/ are dropped in replacement to the cairo.so's in the official R binaries (2.15.3, 3.0.3, 3.1.2). updated to cairo-1.12.18 and freetype-2.5.4. The official R binaries' were built with early freetype 2.4.x and cairo 1.11(?) and had a number of issues with some

brew implements a templating framework for mixing text and R code for report generation. brew template syntax is similar to PHP, Ruby's erb module, Java Server Pages, and Python's psp module. brew is written in R with no package dependencies, and it's not just for the web. It can be used as an alternative to Sweave in a limited context. See the brew-test-1.brew file in the

I just checked your package on a mavericks VM and it seems fine, so I wouldn't worry about it. Probably some configuration issue on the CRAN server, perhaps xquartz is outdated. Unfortunately there is no easy way anymore to check on Mavericks. Travis used to support it, but they have deprecated mavericks (along with Apple and homebrew). Hopefully CRAN will update to the current MacOS for the

MTS is a file extension for an AVCHD video clip format for high-definition video, s supporting 1080i (a high definition video format with 1080 horizontal scan lines, interlaced) and 720p (720 horizontal scan lines, progressive scan, rather than interlaced) in a relatively small file size. Recently more and more people have updated their Mac computer to Mac OS X 10.9 Mavericks, but video

Dear mac folks, I have started porting a large legacy toolset maintained in windows and heavily mpi laden so it can be used across platforms in R... so I am building a package out of it. On this note, I am noticing that almost all of the mpi dependent packages do not compile on the CRAN repositories.... with the basic issue that it appears it can not find mpi installed: configure: error: