similar to: [PATCH] always call FreeLibrary()

Full_Name: Venkatesh Mysore Version: R-1.7.0 OS: WindowsXP Submission from: (NULL) (216.165.110.10) While accessing Rproxy.dll repeatedly (using the code from the (D)COM example in the R website) causes a failure in the 24th iteration. R-1.6.2 does NOT give this error. This seems to be a memory management error, that might be linked to the huge leakage difference between R-1.7.0 and R-1.6.2

hi, I've some C++ code which try to load R.dll and execute some R command, then unload R.dll, yet it seems fail to unload it, so second time to call the function hangs since it is trying to Initialize R again(this is not allowed as documented). Anyone can tell me why, thanks. //the following is my c++ code, used in a Visual Studio 2012 Console Application #define ORAPI__cdecl

On 19.3.2013 15:49, JonY wrote: > On 3/19/2013 19:59, Janne Hyv?rinen wrote: >> On 18.3.2013 12:25, Erik de Castro Lopo wrote: >>> JonY wrote: >>> >>>> Before anyone does anything, see __wgetmainargs >>>> <http://msdn.microsoft.com/en-us/library/ff770599.aspx>. >>>> >>>> It can expand wildcards. Since it already

OK since this approach makes sense I'll shoot with my questions :) 1. Where should get_utf8_argv go and is the name of this function OK? Right now the function is inside llvm::sys::fs namespace because I need access to Windows.h, should I leave it there. 2. get_utf8_argv allocates new char** representing utf8 argv, should I deallocate this inside driver.cpp, use std::vector<std::string>

On Tue, Sep 20, 2011 at 4:15 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > OK since this approach makes sense I'll shoot with my questions :) > 1. Where should get_utf8_argv go and is the name of this function OK? Right > now the function is inside llvm::sys::fs namespace because I need access to > Windows.h, should I leave it there. I don't think it belongs

Here's a new patch that fixes all the issues mentioned before. Note that this isn't final, I didn't want to replace all calls to ::stat so that it's easier to review. I have only one more questions: 1. _wopen accepts _stat64i32 instead of stat structure. These two are exactly the same, the only difference is that stat uses time_t and _stat64i32 uses __time64_t (time_t is a

I think the assert you have for _stat64i32 is fine. It is a constant expression so should compile to nothing, and the chance of the definition changing is pretty much zero. LowercaseString appears to be used by ASM printers where the output is expected to be ASCII, and then some WIN32-conditioned code in FileManager.cpp. I hate to say it but you'll probably need to convert the UTF-8 paths to

I agree they are broken on all platforms. However, FileManager.cpp already contains an #if WIN32 conditional around the code calling LowercaseString, so you can use MultiByteToWideChar and CharLowerBuffW directly there, and not call the LowercaseString function. I don't think there are any other places where LowercaseString is called with non-ascii data, so you can punt on fixing it for now.

On 18.3.2013 12:25, Erik de Castro Lopo wrote: > JonY wrote: > >> Before anyone does anything, see __wgetmainargs >> <http://msdn.microsoft.com/en-us/library/ff770599.aspx>. >> >> It can expand wildcards. Since it already provides argc/argv/env, it is >> more a less a drop-in replacement for the main() arguments. > +1 > > Erik Alright, here's

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8 on success. This is the only way to set this flag to CP_UTF8. The programs continue to work

I have a problem with Lowercase and Uppercase functions. These are broken on all platforms, not only Window, so I can't just #ifdef and use CharLowerBuffW. I need a portable way to convert from UTF8 to UTF16. There is set of functions inside clang/Basic/ConvertUTF, but LLVM can't depend on this. What do I do? On Tue, Sep 27, 2011 at 5:09 AM, Bryce Cogswell <bryceco at yahoo.com>

I tried to do the conversion to lowercase inside GetFullPath by adding an additional bool parameter to this function. It's not perfect but seems much better than repeating the whole UTF8 to UTF16 and UTF16 to UTF8 conversion again. The problem I have is with access to CharLowerBuffW. I need Windows.h for this function but when I try to include it I get a bunch of errors because Language

You can use _iswupper and _towlower instead of CharLowerBuffW. They don't require windows.h and work with /Za. On Sep 30, 2011, at 12:24 AM, Nikola Smiljanic wrote: > I tried to do the conversion to lowercase inside GetFullPath by adding an additional bool parameter to this function. It's not perfect but seems much better than repeating the whole UTF8 to UTF16 and UTF16 to UTF8

towlower doesn't seem to work with my test string in Cyrillic. This function does locale-specific conversion, is this what we want? Here's the whole thing, with all the calls to ::stat replaced with llvm::sys::fs::Stat. On Fri, Sep 30, 2011 at 8:04 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > You can use _iswupper and _towlower instead of CharLowerBuffW. They don't

Locale-specific is not what we want, but I don't believe Windows exposes an alternative API that does what we want. (Does CharLower give a different answer than tolower?) However, looking over the FileManager code a little more I'm not even sure using the path is the best solution, it seems it would be better to use inode like the unix code does. Windows doesn't support inode (the

On 19.3.2013 19:13, LRN wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 19.03.2013 20:35, Janne Hyv?rinen wrote: >> On 19.3.2013 15:49, JonY wrote: >>> On 3/19/2013 19:59, Janne Hyv?rinen wrote: >>>> On 18.3.2013 12:25, Erik de Castro Lopo wrote: >>>>> JonY wrote: >>>>> >>>>>> Before anyone does

CharLowerW does the right thing. But I still need Windows.h to use it :) On Mon, Oct 3, 2011 at 8:43 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > Locale-specific is not what we want, but I don't believe Windows exposes an > alternative API that does what we want. (Does CharLower give a different > answer than tolower?) > > However, looking over the FileManager code

Trying to access R from Netlogo5 (using the NetLogo R-Extension), running the configuration validation tests in NetLogo5/extensions/r/Systemcheck.nlogo, I get several loadlibrary() errors ... in rJava Check2, > library(rJava); .path.package('rJava') Error : .onLoad failed in loadNamespace() for 'rJava', details: call: inDL(x, as.logical(local), as.logical(now), ...)

Dear R expert: I have the problems with calling R from Java on Windows XP_SP2/Eclipse3.1/JDK1.5 problems: Loading RInterpreter library Exception in thread "main" java.lang.UnsatisfiedLinkError: no RInterpreter in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at

On 06/25/2012 12:50 AM, Mihai Basa wrote: > Hello all, > > Is there a reason why the library location code in cindex py does not > use find_library() to locate libclang, like in the attached patch? > > Without it there were problems locating a versioned libclang.so.1 file > on Debian, for example. Hi Mihai, as this is a clang related question, I move your mail to the clang