[Rd] ctrl-C aborts R when compiling package code with ICC+openMP
Hi all, I have some C++ code that I call from my package. In my main C++ loop, I check for user interrupts and return to the R shell after ensuring I've deallocated memory appropriately. This works fine when the code is compiled with gcc+openmp and with icc without openmp, but when I compile with icc and use openmp, the entire R session is immediately terminated when I hit ctrl-C. This happens even if I only have one thread and even if I set an openmp barrier just before checking for user interrupts. When the R session terminates unexpectedly, I usually just get "Aborted" before return to the bash prompt. Occasionally, though, I get this error: OMP: Error #15: Initializing libguide.so, but found libguide.so already initialized. OMP: Hint: This may cause performance degradation and correctness issues. Set environment variable KMP_DUPLICATE_LIB_OK=TRUE to ignore this problem and force the program to continue anyway. Please note that the use of KMP_DUPLICATE_LIB_OK is unsupported and using it may cause undefined behavior. For more information, please contact Intel(R) Premier Support. But KMP_DUPLICATE_LIB_OK=TRUE changes nothing. I had a look at: http://software.intel.com/en-us/articles/opm-abort-initializing-libguide40dll/ which suggests there may be a conflict between libguide40 and libiomp5md, but I can't find any loaded R packages that link against libiomp5md... Does anyone have any ideas? Many thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fwd: ctrl-C aborts R when compiling package code with ICC+openMP
I omitted to mention that when I set KMP_DUPLICATE_LIB_OK=TRUE and OMP_NUM_THREADS=1, I consistently get this error instead: OMP: Error #13: Assertion failure at kmp_csupport.c(465). OMP: Hint: Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/. Thanks, Ernest Begin forwarded message: > From: Ernest Turro > Date: 3 February 2010 20:49:42 GMT > To: r-devel List > Subject: [Rd] ctrl-C aborts R when compiling package code with ICC+openMP > x-mailer: Apple Mail (2.1077) > > Hi all, > > I have some C++ code that I call from my package. In my main C++ loop, I > check for user interrupts and return to the R shell after ensuring I've > deallocated memory appropriately. This works fine when the code is compiled > with gcc+openmp and with icc without openmp, but when I compile with icc and > use openmp, the entire R session is immediately terminated when I hit ctrl-C. > This happens even if I only have one thread and even if I set an openmp > barrier just before checking for user interrupts. > > When the R session terminates unexpectedly, I usually just get "Aborted" > before return to the bash prompt. Occasionally, though, I get this error: > > OMP: Error #15: Initializing libguide.so, but found libguide.so already > initialized. > OMP: Hint: This may cause performance degradation and correctness issues. Set > environment variable KMP_DUPLICATE_LIB_OK=TRUE to ignore this problem and > force the program to continue anyway. Please note that the use of > KMP_DUPLICATE_LIB_OK is unsupported and using it may cause undefined > behavior. For more information, please contact Intel(R) Premier Support. > > But KMP_DUPLICATE_LIB_OK=TRUE changes nothing. > > I had a look at: > http://software.intel.com/en-us/articles/opm-abort-initializing-libguide40dll/ > > which suggests there may be a conflict between libguide40 and libiomp5md, but > I can't find any loaded R packages that link against libiomp5md... > > Does anyone have any ideas? > > Many thanks, > > Ernest > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R/C++/memory leaks
Dear all, I have wrapped a C++ function in an R package. I allocate/deallocate memory using C++ 'new' and 'delete'. In order to allow user interrupts without memory leaks I've moved all the delete statements required after an interrupt to a separate C++ function freeMemory(), which is called using on.exit() just before the .C() call. I am concerned about the following. In square brackets you see R's total virtual memory use (VIRT in `top`): 1) Load library and data [178MB] (if I run gc(), then [122MB]) 2) Just before .C [223MB] 3) Just before freeing memory [325MB] 4) Just after freeing memory [288MB] 5) After running gc() [230MB] So although the freeMemory function works (frees 37MB), R ends up using 100MB more after the function call than before it. ls() only returns the data object so no new objects have been added to the workspace. Do any of you have any idea what could be eating this memory? Many thanks, Ernest PS: it is not practical to use R_alloc et al because C++ allocation/ deallocation involves constructors/destructors and because the C++ code is also compiled into a standalone binary (I would rather avoid maintaining two separate versions). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
On 25 Feb 2007, at 22:21, Ross Boylan wrote:
> On Sun, Feb 25, 2007 at 05:37:24PM +0000, Ernest Turro wrote:
>> Dear all,
>>
>> I have wrapped a C++ function in an R package. I allocate/deallocate
>> memory using C++ 'new' and 'delete'. In order to allow user
>> interrupts without memory leaks I've moved all the delete statements
>> required after an interrupt to a separate C++ function freeMemory(),
>> which is called using on.exit() just before the .C() call.
>
> Do you mean that you call on.exit() before the .C, and the call to
> on.exit() sets up the handler? Your last sentence sounds as if you
> invoke freeMemory() before the .C call.
>
" 'on.exit' records the expression given as its argument as needing
to be executed when the current function exits (either naturally
or as the result of an error)."
This means you call on.exit() somewhere at the top of the function.
You are guaranteed the expression you pass to on.exit() will be
executed before the function returns. So, even though you call on.exit
() before .C(), the expression you pass it will actually be called
after .C().
This means you can be sure that freeMemory() is called even if an
interrupt or other error occurs.
> Another approach is to associate your C objects with an R object, and
> have them cleaned up when the R object gets garbage collected.
> However, this requires switching to a .Call interface from the more
> straightforward .C interface.
>
> The finalizer call I used doesn't assure cleanup on exit. The optional
> argument to R_RegisterCFinalizerEx might provide such assurance, but I
> couldn't tell what it really does. Since all memory should
> be released by the OS, when the process ends, I wasn't so worried
> about that.
>
>
> Here's the pattern:
> // I needed R_NO_REMAP to avoid name collisions. You may not.
> #define R_NO_REMAP 1
> #include
> #include
>
> extern "C" {
> // returns an |ExternalPtr|
> SEXP makeManager(
> @);
>
>
> // user should not need to call
> // cleanup
> void finalizeManager(SEXP ptr);
>
> }
>
> SEXP makeManager(
> @){
> // stuff
>
> Manager* pmanager = new Manager(pd, pm.release(),
> *INTEGER(stepNumerator), *INTEGER(stepDenominator),
> (*INTEGER(isexact)) != 0);
>
> // one example didn't use |PROTECT()|
> SEXP ptr;
> Rf_protect(ptr = R_MakeExternalPtr(pmanager, R_NilValue,
> R_NilValue));
> R_RegisterCFinalizer(ptr, (R_CFinalizer_t) finalizeManager);
> Rf_unprotect(1);
> return ptr;
>
> }
>
> void finalizeManager(SEXP ptr){
> Manager *pmanager = static_cast(R_ExternalPtrAddr(ptr));
> delete pmanager;
> R_ClearExternalPtr(ptr);
> }
>
> I'd love to hear from those more knowledgeable about whether I did
> that right, and whether the FinalizerEx call can assure cleanup on
> exit.
>
> Make manager needes to be called from R like this
> mgr <- .Call("makeManager", args)
>
Since this is a standalone C++ program too, I'd rather use the R API
as little as possible... But I will look at your solution if I find
it is really necessary.. Thanks
>>
>> I am concerned about the following. In square brackets you see R's
>> total virtual memory use (VIRT in `top`):
>>
>> 1) Load library and data [178MB] (if I run gc(), then [122MB])
>> 2) Just before .C [223MB]
>> 3) Just before freeing memory [325MB]
> So you explicitly call your freeMemory() function?
This is called thanks to on.exit()
>> 4) Just after freeing memory [288MB]
> There are at least 3 possibilities:
> * your C++ code is leaking
The number of news and deletes are the same, and so is their
branching... I don't think it is this.
> * C++ memory is never really returned (Commonly, at least in C, the
> amount of memory allocated to the process never goes down, even if
> you do a free. This may depend on the OS and the specific calls the
> program makes.
OK, but the memory should be freed after the process completes, surely?
> * You did other stuff in R that's still around. After all you went
> up +45MB between 1 and 2; maybe it's not so odd you went up +65MB
> between 2 and 4.
Yep, I do stuff before .C and that accounts for the increase
before .C. But all the objects created before .C go out of scope by
4) and so, after gc(), we should be back to 122MB. As I mentioned, ls
() after 5) returns only the data loaded in 1).
>> 5) After running gc() [230MB]
>>
>> So although the freeMemory function works (frees 37MB), R ends up
>> using 100MB more after the functio
Re: [Rd] R/C++/memory leaks
On 26 Feb 2007, at 10:51, Hin-Tak Leung wrote: > Ernest Turro wrote: >> Dear all, >> I have wrapped a C++ function in an R package. I allocate/ >> deallocate memory using C++ 'new' and 'delete'. In order to allow >> user interrupts without memory leaks I've moved all the delete >> statements required after an interrupt to a separate C++ function >> freeMemory(), which is called using on.exit() just before the .C >> () call. >> I am concerned about the following. In square brackets you see >> R's total virtual memory use (VIRT in `top`): >> 1) Load library and data [178MB] (if I run gc(), then [122MB]) >> 2) Just before .C [223MB] >> 3) Just before freeing memory [325MB] >> 4) Just after freeing memory [288MB] >> 5) After running gc() [230MB] >> So although the freeMemory function works (frees 37MB), R ends up >> using 100MB more after the function call than before it. ls() >> only returns the data object so no new objects have been added to >> the workspace. >> Do any of you have any idea what could be eating this memory? >> Many thanks, >> Ernest >> PS: it is not practical to use R_alloc et al because C++ >> allocation/ deallocation involves constructors/destructors and >> because the C++ code is also compiled into a standalone binary (I >> would rather avoid maintaining two separate versions). >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > Read the help page of gc(). You need to run it with reset=TRUE for > the usage to drop back to original. i.e. gc(reset=TRUE). gc() on its > own doesn't quite do what you think it would do. > Thanks, but in this case it barely makes a difference.. :( __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
Thanks for your comments Ross. A couple more comments/queries below: On 26 Feb 2007, at 06:43, Ross Boylan wrote: > [details snipped] > > The use of the R api can be confined to a wrapper function. But I can > think of no reason that a change to the alternate approach I outlined > would solve the apparent leaking you describe. > I'm not sure I see how a wrapper function using the R API would suffice. Example: During heavy computation in the C++ function I need to allow interrupts from R. This means that R_CheckUserInterrupt needs to be called during the computation. Therefore, use of the R API can't be confined to just the wrapper function. In fact, I'm worried that some of the libraries I'm using are failing to release memory after interrupt and that that is the problem. I can't see what I could do about that... E.g. #include valarray foo; // I don't know 100% that the foo object hasn't allocated some memory. if the program is interrupted it wouldn't be released I find it's very unfortunate that R_CheckUserInterrupt doesn't return a value. If it did (e.g. if it returned true if an interrupt has occurred), I could just branch off somewhere, clean up properly and return to R. Any ideas on how this could be achieved? Thanks, E >> I am concerned about the following. In square brackets you see R's total virtual memory use (VIRT in `top`): 1) Load library and data [178MB] (if I run gc(), then [122MB]) 2) Just before .C [223MB] 3) Just before freeing memory [325MB] >>> So you explicitly call your freeMemory() function? >> >> This is called thanks to on.exit() >> 4) Just after freeing memory [288MB] >>> There are at least 3 possibilities: >>> * your C++ code is leaking >> >> The number of news and deletes are the same, and so is their >> branching... I don't think it is this. >> >>> * C++ memory is never really returned (Commonly, at least in C, the >>> amount of memory allocated to the process never goes down, even if >>> you do a free. This may depend on the OS and the specific calls >>> the >>> program makes. >> >> OK, but the memory should be freed after the process completes, >> surely? > > Most OS's I know will free memory when a process finishes, except for > shared memory. But is that relevant? I assume the process doesn't > complete until you exit R. Your puzzle seems to involve different > stages within the life of a single process. > >> >>> * You did other stuff in R that's still around. After all you >>> went >>> up +45MB between 1 and 2; maybe it's not so odd you went up +65MB >>> between 2 and 4. >> >> Yep, I do stuff before .C and that accounts for the increase >> before .C. But all the objects created before .C go out of scope by >> 4) and so, after gc(), we should be back to 122MB. As I mentioned, ls >> () after 5) returns only the data loaded in 1). > > In principle (and according to ?on.exit) the expression registered by > on.exit is evaluated when the relevant function is exited. In > principle garbage collection reclaims all unused space (though with no > guarantee of when). > > It may be that the practice is looser than the principle. For > example, > Python always nominally managed memory for you, but I think for > quite awhile it didn't really reclaim the memory (because garbage > collection didn't exist or had been turned off). > > >> 5) After running gc() [230MB] So although the freeMemory function works (frees 37MB), R ends up using 100MB more after the function call than before it. ls() only returns the data object so no new objects have been added to the workspace. Do any of you have any idea what could be eating this memory? Many thanks, Ernest PS: it is not practical to use R_alloc et al because C++ allocation/ deallocation involves constructors/destructors and because the C++ code is also compiled into a standalone binary (I would rather avoid maintaining two separate versions). >>> >>> I use regular C++ new's too (except for the external pointer that's >>> returned). However, you can override the operator new in C++ so >>> that >>> it uses your own allocator, e.g., R_alloc. I'm not sure about >>> all the >>> implications that might make that dangerous (e.g., can the memory be >>> garbage collected? can it be moved?). Overriding new is a bit >>> tricky >>> since there are several variants. In particular, there is one with >>> and one without an exception. Also, invdividual classes can define >>> their own new operators; if you have any, you'd need to change those >>> too. >>> >> >> That sounds rather dangerous! > At least tedious to get right. My statements weren't intended as a > recommendation of this approach; I was just pointing out R_alloc and > C++ allocation could probably be fit together. If your C++ program > isn't doing anything exotic with memory management t
Re: [Rd] R/C++/memory leaks
Hi Simon,
On 26 Feb 2007, at 16:58, Simon Urbanek wrote:
> Ernest,
>
> On Feb 25, 2007, at 12:37 PM, Ernest Turro wrote:
>
>> I have wrapped a C++ function in an R package. I allocate/
>> deallocate memory using C++ 'new' and 'delete'. In order to allow
>> user interrupts without memory leaks
>
> How do you allow for user interrupts? R doesn't allow interrupts
> while in .C/.Call on purpose,
void R_CheckUserInterrupt(void)
> so it's up to your code to handle interrupts properly. This also
> implies that you can use the regular methods for error recovery
> available in your language and handle the interrupt yourself by
> freeing the memory as needed, your code shouldn't return to R until
> it has cleaned everything up ...
How can I detect an interrupt from R inside the C/C++ code without
using the R API? SIGINTs don't get passed on if they come from within
R...
>
>
>> I've moved all the delete statements required after an interrupt
>> to a separate C++ function freeMemory(), which is called using
>> on.exit() just before the .C() call.
>>
>
> This sounds a bit dangerous - how can the separate function know
> about the previous call and the state it was in before the
> interrupt (save for hard-wiring everything into one instance)?
> Again, the crucial part is the interrupt handling in your code - it
> may fail to release some objects...
>
I have to declare variables for any allocated memory globally:
static int foo*;
extern "C"
void func(...) {
foo = new int[1024];
// heavy computation
// inside loop:
R_CheckUserInterrupt()
//end heavy computation
}
extern "C"
void freemem(...) {
delete [] foo;
}
in R:
func <- function() {
on.exit(.C("freemem"))
.C("func")
}
Cheers,
Ernest
> @Ross [see follow-up]: R_RegisterCFinalizerEx is called on R exit
> if desired (see arguments). However, I don't think this is relevant
> to the discussed issue as a process termination frees all its
> memory. Moreover I don't think Ernest wants to wrap all his classes
> to R objects - we're not talking about the GC here, it is supposed
> to be C++ internal issue.
>
> Cheers,
> Simon
>
>
>> I am concerned about the following. In square brackets you see R's
>> total virtual memory use (VIRT in `top`):
>>
>> 1) Load library and data [178MB] (if I run gc(), then [122MB])
>> 2) Just before .C [223MB]
>> 3) Just before freeing memory [325MB]
>> 4) Just after freeing memory [288MB]
>> 5) After running gc() [230MB]
>>
>> So although the freeMemory function works (frees 37MB), R ends up
>> using 100MB more after the function call than before it. ls() only
>> returns the data object so no new objects have been added to the
>> workspace.
>>
>> Do any of you have any idea what could be eating this memory?
>>
>> Many thanks,
>>
>> Ernest
>>
>> PS: it is not practical to use R_alloc et al because C++ allocation/
>> deallocation involves constructors/destructors and because the C++
>> code is also compiled into a standalone binary (I would rather avoid
>> maintaining two separate versions).
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
Hi Ross,
On 26 Feb 2007, at 22:34, Ross Boylan wrote:
> On Mon, 2007-02-26 at 16:08 +0000, Ernest Turro wrote:
>> Thanks for your comments Ross. A couple more comments/queries below:
>>
>> On 26 Feb 2007, at 06:43, Ross Boylan wrote:
>>
>>> [details snipped]
>>>
>>> The use of the R api can be confined to a wrapper function. But
>>> I can
>>> think of no reason that a change to the alternate approach I
>>> outlined
>>> would solve the apparent leaking you describe.
>>>
>>
>> I'm not sure I see how a wrapper function using the R API would
>> suffice. Example:
> It doesn't sound as if it would suffice. I was responding to your
> original remark that
>
>> Since this is a standalone C++ program too, I'd rather use the R API
>> as little as possible... But I will look at your solution if I find
>> it is really necessary.. Thanks
>
> I thought that was expressing a concern about using the alternate
> approach I outlined because it would use the R API. If you need to
> use
> that API for other reasons, you're still stuck with it :)
>>
>> During heavy computation in the C++ function I need to allow
>> interrupts from R. This means that R_CheckUserInterrupt needs to be
>> called during the computation. Therefore, use of the R API can't be
>> confined to just the wrapper function.
>>
>> In fact, I'm worried that some of the libraries I'm using are failing
>> to release memory after interrupt and that that is the problem. I
>> can't see what I could do about that... E.g.
>>
>> #include
>>
>> valarray foo; // I don't know 100% that the foo object hasn't
>> allocated some memory. if the program is interrupted it wouldn't be
>> released
> That's certainly possible, but you seem to be overlooking the
> possibility that all the code is releasing memory appropriately,
> but the
> process's memory footprint isn't going down correspondingly. In my
> experience that's fairly typical behavior.
>
OK, but does this still explain why the footprint keeps increasing
indefinitely when i do run, interrupt, run, interrupt, run,
interrupt..?
> In that case, depending on your point of view, you either don't have a
> problem or you have a hard problem. If you really want the memory
> released back to the system, it's a hard problem. If you don't
> care, as
> long as you have no leaks, all's well.
>
>>
>> I find it's very unfortunate that R_CheckUserInterrupt doesn't return
>> a value. If it did (e.g. if it returned true if an interrupt has
>> occurred), I could just branch off somewhere, clean up properly and
>> return to R.
>>
>> Any ideas on how this could be achieved?
> I can't tell from the info page what function gets called in R if
> there
> is an interrupt, but it sounds as you could do the following hack:
> The R interrupt handler gets a function that calls a C function of
> your
> devising. The C function sets a flag meaning "interrupt requested".
> Then in your main code, you periodically call R_CheckUserInterrupt.
> When it returns you check the flag; if it's set, you cleanup and exit.
> Ross
>
If this is feasible, it's by far the best solution.
in error.c:
void R_CheckUserInterrupt(void)
{
R_CheckStack();
/* This is the point where GUI systems need to do enough event
processing to determine whether there is a user interrupt event
pending. Need to be careful not to do too much event
processing though: if event handlers written in R are allowed
to run at this point then we end up with concurrent R
evaluations and that can cause problems until we have proper
concurrency support. LT */
#if ( defined(HAVE_AQUA) || defined(Win32) )
R_ProcessEvents();
#else
if (R_interrupts_pending)
onintr();
#endif /* Win32 */
}
Leaving aside the HAVE_AQUA and Win32 cases, I would like to write a
new function:
int R_CheckInterruptsPending(void)
{
R_CheckStack();
return R_interrupts_pending;
}
and then in my C++ code:
if(R_checkInterruptsPending) {
// clean up
// ...
R_CheckInterruptsPending();
}
R_CheckStack() is declared in R_ext/Utils.h but the variable
R_interrupts_pending isn't, so how could I access it? In other words,
how can I extend error.c .
Thanks,
E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
[snip]
Sorry. Small mistake fixed below:
>
> Leaving aside the HAVE_AQUA and Win32 cases, I would like to write
> a new function:
>
> int R_CheckInterruptsPending(void)
> {
> R_CheckStack();
> return R_interrupts_pending;
> }
>
> and then in my C++ code:
>
if(R_CheckInterruptsPending) {
// clean up
// ...
R_CheckUserInterrupt();
}
>
> R_CheckStack() is declared in R_ext/Utils.h but the variable
> R_interrupts_pending isn't, so how could I access it? In other
> words, how can I extend error.c .
>
>
> Thanks,
>
> E
>
>
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
On 27 Feb 2007, at 17:45, Luke Tierney wrote:
> On Tue, 27 Feb 2007, Ernest Turro wrote:
>
>> Hi Ross,
>>
>> On 26 Feb 2007, at 22:34, Ross Boylan wrote:
>>
>>> On Mon, 2007-02-26 at 16:08 +, Ernest Turro wrote:
>>>> Thanks for your comments Ross. A couple more comments/queries
>>>> below:
>>>>
>>>> On 26 Feb 2007, at 06:43, Ross Boylan wrote:
>>>>
>>>>> [details snipped]
>>>>>
>>>>> The use of the R api can be confined to a wrapper function. But
>>>>> I can
>>>>> think of no reason that a change to the alternate approach I
>>>>> outlined
>>>>> would solve the apparent leaking you describe.
>>>>>
>>>>
>>>> I'm not sure I see how a wrapper function using the R API would
>>>> suffice. Example:
>>> It doesn't sound as if it would suffice. I was responding to your
>>> original remark that
>>>
>>>> Since this is a standalone C++ program too, I'd rather use the R
>>>> API
>>>> as little as possible... But I will look at your solution if I find
>>>> it is really necessary.. Thanks
>>>
>>> I thought that was expressing a concern about using the alternate
>>> approach I outlined because it would use the R API. If you need to
>>> use
>>> that API for other reasons, you're still stuck with it :)
>>>>
>>>> During heavy computation in the C++ function I need to allow
>>>> interrupts from R. This means that R_CheckUserInterrupt needs to be
>>>> called during the computation. Therefore, use of the R API can't be
>>>> confined to just the wrapper function.
>>>>
>>>> In fact, I'm worried that some of the libraries I'm using are
>>>> failing
>>>> to release memory after interrupt and that that is the problem. I
>>>> can't see what I could do about that... E.g.
>>>>
>>>> #include
>>>>
>>>> valarray foo; // I don't know 100% that the foo object
>>>> hasn't
>>>> allocated some memory. if the program is interrupted it wouldn't be
>>>> released
>>> That's certainly possible, but you seem to be overlooking the
>>> possibility that all the code is releasing memory appropriately,
>>> but the
>>> process's memory footprint isn't going down correspondingly. In my
>>> experience that's fairly typical behavior.
>>>
>>
>> OK, but does this still explain why the footprint keeps increasing
>> indefinitely when i do run, interrupt, run, interrupt, run,
>> interrupt..?
>>
>>
>>> In that case, depending on your point of view, you either don't
>>> have a
>>> problem or you have a hard problem. If you really want the memory
>>> released back to the system, it's a hard problem. If you don't
>>> care, as
>>> long as you have no leaks, all's well.
>>>
>>>>
>>>> I find it's very unfortunate that R_CheckUserInterrupt doesn't
>>>> return
>>>> a value. If it did (e.g. if it returned true if an interrupt has
>>>> occurred), I could just branch off somewhere, clean up properly and
>>>> return to R.
>>>>
>>>> Any ideas on how this could be achieved?
>>> I can't tell from the info page what function gets called in R if
>>> there
>>> is an interrupt, but it sounds as you could do the following hack:
>>> The R interrupt handler gets a function that calls a C function of
>>> your
>>> devising. The C function sets a flag meaning "interrupt requested".
>>> Then in your main code, you periodically call R_CheckUserInterrupt.
>>> When it returns you check the flag; if it's set, you cleanup and
>>> exit.
>>> Ross
>>>
>>
>> If this is feasible, it's by far the best solution.
>>
>> in error.c:
>>
>> void R_CheckUserInterrupt(void)
>> {
>> R_CheckStack();
>> /* This is the point where GUI systems need to do enough event
>>processing to determine whether there is a user interrupt
>> event
>>pending. Need to be careful not to do too much event
>>processing though: if event handlers written in R are allowed
>>to run at this point then we end up with concurrent R
[Rd] Carriage returns and Sweave output
Dear all,
I have a code chunk in my Rnw file that, when executed, outputs
carriage return characters ('\r') to inform on the progress (e.g.
"sweep 4 of 1024\r"). But Sweave interprets this as a newline
character, and therefore I get countless pages of output in my
vignette where I only really want one line. Any ideas?
Thanks
E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
Hi Wolfgang,
the problem with results=hide is that it suppresses everything. I
just need Sweave to suppress strings ending in '\r'...
Best,
Ernest
On 19 Mar 2007, at 14:49, Wolfgang Huber wrote:
> Dear Ernest,
>
> this may not be exactly what you asked for, but how about setting
> "results=hide" in the options of your code chunk?
>
> Best wishes
> Wolfgang
>
> --
> Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
>
> Ernest Turro wrote:
>> Dear all,
>> I have a code chunk in my Rnw file that, when executed, outputs
>> carriage return characters ('\r') to inform on the progress (e.g.
>> "sweep 4 of 1024\r"). But Sweave interprets this as a newline
>> character, and therefore I get countless pages of output in my
>> vignette where I only really want one line. Any ideas?
>> Thanks
>> E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rinternals.h and undefined symbols
Hi, I'm trying to register my native routines using R_registerRoutines (...). I can compile the code, but the loader cannot resolve the symbol: undefined symbol: _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6 _ $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines U _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6 _ Why does it have this funny name? If I look at libR.so, I get an ordinary symbol name: $ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines 00032f80 T R_registerRoutines I get normal symbol names for R functions not in Rinternals.h and there is no problem there. For example: nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf U Rprintf $ nm ~/lib64/R/lib/libR.so | grep Rprintf 00129690 T Rprintf The shared library dependencies are also fine: $ ldd bgx.Rcheck/bgx/libs/bgx.so libR.so => /home/et04/lib64/R/lib/libR.so (0x002a95676000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x002a95a8) libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000) libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000) libRblas.so => /home/et04/lib64/R/lib/libRblas.so (0x002a96136000) libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000) libreadline.so.4 => /usr/lib64/libreadline.so.4 (0x002a96383000) libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x002a964bc000) libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000) /lib64/ld-linux-x86-64.so.2 (0x00552000) My LD_LIBRARY_PATH environmental variable is set appropriately. Any ideas? Thanks, E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinternals.h and undefined symbols
On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
> On 3/19/2007 5:23 PM, Ernest Turro wrote:
>> Hi,
>> I'm trying to register my native routines using R_registerRoutines
>> (...). I can compile the code, but the loader cannot resolve the
>> symbol:
>> undefined symbol:
>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3
>> _S6 _
>> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
>> U
>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3
>> _S6 _
>> Why does it have this funny name? If I look at libR.so, I get an
>> ordinary symbol name:
>
> That looks like C++ name mangling. Are you wrapping your
> declarations in
>
> extern "C" { }
>
> ?
Yeah, the routine is literally just:
extern "C"
void R_init_bgx(DllInfo *info) {
R_registerRoutines(info, cMethods,NULL,NULL,NULL);
}
with cMethods declared outside as a static const R_CMethodDef.
The two routines that I am registering are also wrapped in extern "C".
Ernest
>
> Duncan Murdoch
>
>
>> $ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines
>> 00032f80 T R_registerRoutines
>> I get normal symbol names for R functions not in Rinternals.h and
>> there is no problem there. For example:
>> nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf
>> U Rprintf
>> $ nm ~/lib64/R/lib/libR.so | grep Rprintf
>> 00129690 T Rprintf
>> The shared library dependencies are also fine:
>> $ ldd bgx.Rcheck/bgx/libs/bgx.so
>> libR.so => /home/et04/lib64/R/lib/libR.so
>> (0x002a95676000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6
>> (0x002a95a8)
>> libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000)
>> libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000)
>> libRblas.so => /home/et04/lib64/R/lib/libRblas.so
>> (0x002a96136000)
>> libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000)
>> libreadline.so.4 => /usr/lib64/libreadline.so.4
>> (0x002a96383000)
>> libncurses.so.5 => /usr/lib64/libncurses.so.5
>> (0x002a964bc000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000)
>> /lib64/ld-linux-x86-64.so.2 (0x00552000)
>> My LD_LIBRARY_PATH environmental variable is set appropriately.
>> Any ideas?
>> Thanks,
>> E
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinternals.h and undefined symbols
On 20 Mar 2007, at 00:18, Duncan Murdoch wrote:
> On 3/19/2007 7:41 PM, Ernest Turro wrote:
>> On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
>>> On 3/19/2007 5:23 PM, Ernest Turro wrote:
>>>> Hi,
>>>> I'm trying to register my native routines using
>>>> R_registerRoutines (...). I can compile the code, but the
>>>> loader cannot resolve the symbol:
>>>> undefined symbol:
>>>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDef
>>>> S3 _S6 _
>>>> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
>>>> U
>>>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDef
>>>> S3 _S6 _
>>>> Why does it have this funny name? If I look at libR.so, I get
>>>> an ordinary symbol name:
>>> That looks like C++ name mangling. Are you wrapping your
>>> declarations in
>>>
>>> extern "C" { }
>>>
>>> ?
>> Yeah, the routine is literally just:
>> extern "C"
>>void R_init_bgx(DllInfo *info) {
>> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>>}
>> with cMethods declared outside as a static const R_CMethodDef.
>
> I'm no C++ expert, but that looks like it declares R_init_bgx to be
> a "C" routine, but not R_registerRoutines (which is what the error
> was about). Its declaration is in Rdynload.h:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
> int R_registerRoutines(DllInfo *info, const R_CMethodDef * const
> croutines,
> const R_CallMethodDef * const callRoutines,
> const R_FortranMethodDef * const fortranRoutines,
>const R_ExternalMethodDef * const
> externalRoutines);
>
> Rboolean R_useDynamicSymbols(DllInfo *info, Rboolean value);
> #ifdef __cplusplus
> }
> #endif
>
> so maybe your compiler doesn't define __cplusplus, or you didn't
> include R_ext/Rdynload.h?
Thanks for the reply.
__cplusplus is defined and I do #include (after
all, it does compile)...
I've tried this on two different machines, so it's not a problem
specific to my setup either... ):
Ernest
>
> Duncan Murdoch
>
>
>> The two routines that I am registering are also wrapped in extern
>> "C".
>> Ernest
>>> Duncan Murdoch
>>>
>>>
>>>> $ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines
>>>> 00032f80 T R_registerRoutines
>>>> I get normal symbol names for R functions not in Rinternals.h
>>>> and there is no problem there. For example:
>>>> nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf
>>>> U Rprintf
>>>> $ nm ~/lib64/R/lib/libR.so | grep Rprintf
>>>> 00129690 T Rprintf
>>>> The shared library dependencies are also fine:
>>>> $ ldd bgx.Rcheck/bgx/libs/bgx.so
>>>> libR.so => /home/et04/lib64/R/lib/libR.so
>>>> (0x002a95676000)
>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6
>>>> (0x002a95a8)
>>>> libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7)
>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000)
>>>> libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000)
>>>> libRblas.so => /home/et04/lib64/R/lib/libRblas.so
>>>> (0x002a96136000)
>>>> libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000)
>>>> libreadline.so.4 => /usr/lib64/libreadline.so.4
>>>> (0x002a96383000)
>>>> libncurses.so.5 => /usr/lib64/libncurses.so.5
>>>> (0x002a964bc000)
>>>> libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000)
>>>> /lib64/ld-linux-x86-64.so.2 (0x00552000)
>>>> My LD_LIBRARY_PATH environmental variable is set appropriately.
>>>> Any ideas?
>>>> Thanks,
>>>> E
>>>> __
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinternals.h and undefined symbols
On 20 Mar 2007, at 00:50, Duncan Murdoch wrote:
> On 3/19/2007 8:41 PM, Ernest Turro wrote:
>> On 20 Mar 2007, at 00:18, Duncan Murdoch wrote:
>>> On 3/19/2007 7:41 PM, Ernest Turro wrote:
>>>> On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
>>>>> On 3/19/2007 5:23 PM, Ernest Turro wrote:
>>>>>> Hi,
>>>>>> I'm trying to register my native routines using
>>>>>> R_registerRoutines (...). I can compile the code, but the
>>>>>> loader cannot resolve the symbol:
>>>>>> undefined symbol:
>>>>>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
>>>>>> ef S3 _S6 _
>>>>>> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
>>>>>> U
>>>>>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
>>>>>> ef S3 _S6 _
>>>>>> Why does it have this funny name? If I look at libR.so, I get
>>>>>> an ordinary symbol name:
>>>>> That looks like C++ name mangling. Are you wrapping your
>>>>> declarations in
>>>>>
>>>>> extern "C" { }
>>>>>
>>>>> ?
>>>> Yeah, the routine is literally just:
>>>> extern "C"
>>>>void R_init_bgx(DllInfo *info) {
>>>> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>>>>}
>>>> with cMethods declared outside as a static const R_CMethodDef.
>>> I'm no C++ expert, but that looks like it declares R_init_bgx to
>>> be a "C" routine, but not R_registerRoutines (which is what the
>>> error was about). Its declaration is in Rdynload.h:
>>>
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>> int R_registerRoutines(DllInfo *info, const R_CMethodDef * const
>>> croutines,
>>>const R_CallMethodDef * const callRoutines,
>>>const R_FortranMethodDef * const fortranRoutines,
>>>const R_ExternalMethodDef * const
>>> externalRoutines);
>>>
>>> Rboolean R_useDynamicSymbols(DllInfo *info, Rboolean value);
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>>
>>> so maybe your compiler doesn't define __cplusplus, or you didn't
>>> include R_ext/Rdynload.h?
Duncan, you hit the nail on the head. Thanks so much.
If you download R-2.4.1.tar.gz from CRAN you will find that the
extern "C" is missing in Rdynload.h! I added it to my copy and my
code compiles now. I wonder why it's missing. Has this been fixed in
cvs?
Thanks,
Ernest
PS. you don't need the braces after extern "C"
>> Thanks for the reply.
>> __cplusplus is defined and I do #include
>> (after all, it does compile)...
>> I've tried this on two different machines, so it's not a problem
>> specific to my setup either... ):
>
> Here I'm just guessing: you don't wrap the whole function in
> extern "C", you just put extern "C" ahead of its header. That's not
> the usual way it's done, but I don't know C++ well enough to know
> if it matters. Nevertheless, I'd try
>
> extern "C" {
> void R_init_bgx(DllInfo *info) {
> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
> }
> }
>
> just to see if it helps.
>
> Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
On 20 Mar 2007, at 07:53, Martin Maechler wrote:
>>>>>> "Wolfi" == Wolfgang Huber <[EMAIL PROTECTED]>
>>>>>> on Mon, 19 Mar 2007 15:38:00 + writes:
>
>>> the problem with results=hide is that it suppresses everything. I
>>> just
>>> need Sweave to suppress strings ending in '\r'...
>
>
> Wolfi> Dear Ernest,
>
> Wolfi> IMHO it is good practice to make the printing of these
> progress reports
> Wolfi> ("sweep 4 of 1024\r") optional and produce them only if
> the user calls
> Wolfi> your function with, say, "verbose=TRUE",
>
> I strongly agree.
>
> Wolfi> and furthermore set the default value of the
> Wolfi> 'verbose' argument to "verbose=interactive()".
>
> or -- typically my choice -- to 'verbose = getOption("verbose")
>
> Martin Maechler, ETH Zurich
>
> Wolfi> Best wishes
> Wolfi> Wolfgang
>
> []
>
I agree that users should be free to choose the level of verbosity.
Here, I want to show the verbose output and print it onto the tex
file using Sweave to give users a good idea of what happens. What I
don't want is countless lines being printed because \r is being
interpreted as \n ...
Thanks,
Ernest
>>>> Ernest Turro wrote:
>>>>> Dear all,
>>>>> I have a code chunk in my Rnw file that, when executed, outputs
>>>>> carriage return characters ('\r') to inform on the progress (e.g.
>>>>> "sweep 4 of 1024\r"). But Sweave interprets this as a newline
>>>>> character, and therefore I get countless pages of output in my
>>>>> vignette where I only really want one line. Any ideas?
>>>>> Thanks
>>>>> E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] PKG_CFLAGS/CFLAGS and PKG_CXXFLAGS/CXXFLAGS
Why is it that R places CFLAGS after PKG_CFLAGS and not before when compiling a package (e.g. through R CMD build pkg)? This can be problematic if, for instance, you want to use -O3, but -O2 is in R_HOME/etc/Makeconf. If -O2 (in CFLAGS) appears after -O3 (in PKG_CFLAGS), you are left with what you didn't want: -O2. In R-exts, it says that "Flags which are set in file etc/Makeconf can be overridden by the environment variable MAKEFLAGS (at least for systems using GNU make), as in (Bourne shell syntax)" but this doesn't work if I set either MAKEFLAGS or CFLAGS/CXXFLAGS in my configure.ac script or package Makevars. Does anyone have any ideas on how to reliably override the default CFLAGS/CXXFLAGS given in Makeconf? Many thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
On 20 Mar 2007, at 13:24, Douglas Bates wrote:
> [snip]
> In cases like this capture.output() is your friend. Write one code
> chunk with results=hide,echo=FALSE that uses capture.output to trap
> the desired output as character strings then use string manipulation
> functions to do the desired replacement. A second code chunk with
> eval=FALSE shows the code that apparently produces the output and a
> third code chunk with echo=FALSE uses cat on the manipulated character
> strings with quote=FALSE to show what apparently was produced.
That is extremely helpful. Thanks very much Douglas.
Ernest
>
>> >>>> Ernest Turro wrote:
>> >>>>> Dear all,
>> >>>>> I have a code chunk in my Rnw file that, when executed, outputs
>> >>>>> carriage return characters ('\r') to inform on the progress
>> (e.g.
>> >>>>> "sweep 4 of 1024\r"). But Sweave interprets this as a newline
>> >>>>> character, and therefore I get countless pages of output in my
>> >>>>> vignette where I only really want one line. Any ideas?
>> >>>>> Thanks
>> >>>>> E
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PKG_CFLAGS/CFLAGS and PKG_CXXFLAGS/CXXFLAGS
On 20 Mar 2007, at 21:32, Kasper Daniel Hansen wrote: > > On Mar 20, 2007, at 7:58 PM, Ernest Turro wrote: > >> Why is it that R places CFLAGS after PKG_CFLAGS and not before when >> compiling a package (e.g. through R CMD build pkg)? This can be >> problematic if, for instance, you want to use -O3, but -O2 is in >> R_HOME/etc/Makeconf. If -O2 (in CFLAGS) appears after -O3 (in >> PKG_CFLAGS), you are left with what you didn't want: -O2. >> >> In R-exts, it says that "Flags which are set in file etc/Makeconf can >> be overridden by the environment variable MAKEFLAGS (at least for >> systems using GNU make), as in (Bourne shell syntax)" but this >> doesn't work if I set either MAKEFLAGS or CFLAGS/CXXFLAGS in my >> configure.ac script or package Makevars. > > In you example above you want to force the user to use a higher > optimization flag. But (s)he may have very valid reasons for not > doing so - and are you really sure that you are comfortable setting > -O3 on _all_ platforms? Also -O. is GCC specific so it does not > work for all compilers. My configure script checks for GCC before setting -O3 (and -ffast-math). > > If a user really wants a super fast R (s)he will (should) compile > it with -O3. I'm compiling a MCMC simulation package. It is very intensive and so - O3 should definitely be the default level on systems with GCC. > > Having said that, I think it is problematic that one cannot > _downgrade_ the optimization. I am maintaining a package including > an external library (outside of my control) which does not work > with -O2 on some platforms, due to alignment problems. > >> Does anyone have any ideas on how to reliably override the default >> CFLAGS/CXXFLAGS given in Makeconf? > > I was given the following code some while ago by Simon Urbanek: > > all: $(SHLIB) > > MYCXXFLAGS=-O0 > > %.o: %.cpp > $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< - > o $@ > > (this is for C++, I imagine the syntax is straightforward for C). > Put it in src/Makevars. Thanks very much. That does indeed allow me to place my flags _after_ the flags from R_HOME/etc/Makeconf. It would be nice, though, if the PKG_CXXFLAGS/PKG_CFLAGS were automatically placed _after_ CXXFLAGS/ CFLAGS by R... I vaguely recall the Windows version placing them in that order. Cheers, Ernest > > But as I said above, I think it is a bad idea to raise the > optimization level for all users. > > Kasper > >> Many thanks, >> >> Ernest >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-2.5.0 and unlink/wildcards
It seems unlink doesn't work with wildcards in 2.5.0. I've tried
R-2.5.0 under gnu/linux from source and the Mac binary from att
research. Example:
> dir()
[1] "bgx.Rnw" "bgx.pdf" "run.1"
> unlink("run.*",recursive=T)
> dir()
[1] "bgx.Rnw" "bgx.pdf" "run.1"
> unlink("run.1",recursive=T)
> dir()
[1] "bgx.Rnw" "bgx.pdf"
Cheers,
Ernest
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.5.0 and unlink/wildcards
Thanks, this now works.
I'd just like to mention that Sys.glob() wasn't necessary in 2.4.1
and this potential requirement should perhaps be mentioned in ?unlink.
Thanks
E
On 25 Apr 2007, at 12:38, Prof Brian Ripley wrote:
> This is shell-dependent on a Unix-alike, but Sys.glob() should
> work. So try
>
> unlink(Sys.glob("run.*"), recursive=TRUE)
>
>
> On Wed, 25 Apr 2007, Ernest Turro wrote:
>
>> It seems unlink doesn't work with wildcards in 2.5.0. I've tried
>> R-2.5.0 under gnu/linux from source and the Mac binary from att
>> research. Example:
>>
>> > dir()
>> [1] "bgx.Rnw" "bgx.pdf" "run.1"
>> > unlink("run.*",recursive=T)
>> > dir()
>> [1] "bgx.Rnw" "bgx.pdf" "run.1"
>> > unlink("run.1",recursive=T)
>> > dir()
>> [1] "bgx.Rnw" "bgx.pdf"
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] path autocompletion in 2.5.0
Hi,
R 2.5.0 isn't auto-completing paths properly as it used to. E.g.
suppose I have:
> dir("CEL/choe")
[1] "chipC-rep1.CEL" "chipC-rep2.CEL" "chipC-rep3.CEL" "chipS-rep1.CEL"
[5] "chipS-rep2.CEL" "chipS-rep3.CEL"
Now if I do:
ReadAffy("CEL/choe/ch # => ReadAffy("CEL/choe/chip
ReadAffy("CEL/choe/chipC # => ReadAffy("CEL/choe/chipC-rep
ReadAffy("CEL/choe/chipC-rep1 # Nothing happens.
in 2.4.1 that final line auto-completes properly to:
ReadAffy("CEL/choe/chipC-rep1.CEL"
Cheers,
Ernest
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] path autocompletion in 2.5.0
Apologies for missing that in NEWS.
Apart for auto-completion breaking for paths with '-', this sounds
very convenient.
E
On 26 Apr 2007, at 17:30, Prof Brian Ripley wrote:
> Did you actually look at the NEWS file?
>
> o The Unix-alike readline terminal interface now does
> command-completion for R objects, incorporating the
> functionality formerly in package 'rcompletion' by Deepayan
> Sarkar. This can be disabled by setting the environment
> variable R_COMPLETION=FALSE when starting R (e.g. in
> ~/.Renviron). (Note that when this is enabled, filename
> completion no longer works for file paths containing R
> operators such as '+' and '-'.)
>
> What 'properly' means is of course a matter of taste, but I am very
> surprised that you posted such a comment about something
> highlighted under USER-VISIBLE CHANGES as a configurable option.
>
> R-devel has an option to fine-tune this behaviour.
>
>
> On Thu, 26 Apr 2007, Ernest Turro wrote:
>
>> Hi,
>>
>> R 2.5.0 isn't auto-completing paths properly as it used to. E.g.
>> suppose I have:
>>
>> > dir("CEL/choe")
>> [1] "chipC-rep1.CEL" "chipC-rep2.CEL" "chipC-rep3.CEL" "chipS-
>> rep1.CEL"
>> [5] "chipS-rep2.CEL" "chipS-rep3.CEL"
>>
>> Now if I do:
>>
>> ReadAffy("CEL/choe/ch # => ReadAffy("CEL/choe/chip
>> ReadAffy("CEL/choe/chipC # => ReadAffy("CEL/choe/chipC-rep
>> ReadAffy("CEL/choe/chipC-rep1 # Nothing happens.
>>
>> in 2.4.1 that final line auto-completes properly to:
>>
>> ReadAffy("CEL/choe/chipC-rep1.CEL"
>>
>> Cheers,
>>
>> Ernest
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] file separator inconsistencies on windows?
tempdir() on windows returns the path using "\\" as file separator. But .Platform$file.sep returns "/". As a result, you get inconsistencies like: > file.path(tempdir(), "foo") [1] "C:\\WINDOWS\\Temp\\RtmpYEIXrb/foo" # Mix of \\ and / I'm not sure if this can cause problems but I thought I'd let you know just in case. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Overriding optimisation flags
Dear all, If one specifies, say, "PKG_CXXFLAGS= -O3" in a Makevars file, it will not make a difference to how the code is compiled if -O2 is specified in $R_HOME/etc/Makeconf. This is because PKG_CXXFLAGS is prepended to the corresponding flags in $R_HOME/etc/Makeconf instead of being appended and gcc only uses the last optimisation flag specified. As a result, one has to use targets in Makevars, which adds unnecessary complication to the whole process. Would it be possible to ensure PKG_CXXFLAGS & co. are appended instead of prepended to the default flags and, if not, is there an easier workaround than specifying targets? (targets are easy enough under unix, but seems a bit more complicated under windows...) Thanks! E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R, Macports and C++ streams
Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Cheers, Ernest Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 15:18, Kjell Konis wrote: I found this in Writing R Extensions: "Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (see Printing) for all I/O if at all possible." That is, use Rprintf() instead. The fact that your code works with one version of gcc and not another can probably be chalked up to coincidence. The doc warns that the output to stdout using iostreams may not appear on the console, there is no indication that doing this may crash R (and this has never happened to me before). Certainly, the use of file streams (fstreams) should work just fine. Ernest Kjell On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple-supplied gcc 4.2 instead of 4.0 ? Thanks, Ernest Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non-Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 17:58, Simon Urbanek wrote: On Jul 30, 2008, at 12:35 , Ernest Turro wrote: On 30 Jul 2008, at 15:18, Kjell Konis wrote: I found this in Writing R Extensions: "Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (see Printing) for all I/O if at all possible." That is, use Rprintf() instead. The fact that your code works with one version of gcc and not another can probably be chalked up to coincidence. The doc warns that the output to stdout using iostreams may not appear on the console, there is no indication that doing this may crash R (and this has never happened to me before). Certainly, the use of file streams (fstreams) should work just fine. FWIW I saw this problem when using mismatching compilers before (long time ago when we had to use FSF-built gcc because of bugs in Apple's gcc). Its likely cause is a combination of incompatible ABIs and libstdc++ mismatch. Note that Apple's gcc build script goes into great pains to not mess up system stdc++ because it's asking for trouble. Yes, this sounds like the most likely culprit. I guess, ultimately, Macports GCC maintainers should make sure their build script goes through the same hoops as Apple's to avoid this kind of mismatch problem with libstdc++. The best thing would be for the R port to depend on Apple-supplied gcc rather than the Macports gcc. Cheers Ernest Cheers, Simon Kjell On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 19:23, Simon Urbanek wrote: On Jul 30, 2008, at 13:16 , Ernest Turro wrote: On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. That is not exactly true - it uses whatever your gcc version is. You can use Apple's gcc 4.0 or 4.2, they both work. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. FYI it's part of Xcode 3.1 ... Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple- supplied gcc 4.2 instead of 4.0 ? I suspect you're confusing several separate issues here - the include paths for OMP have nothing to do with R, they are part of the gcc and as such added regardless of the include flags. Just try gcc-4.2 omp.c -o omp -fopenmp which specifies no include flags and works just fine. The real issue here is that Apple doesn't provide gcc-4.2 support for Tiger, so you cannot use 10.4 SDK unless you also install the corresponding libraries. Hence you have two choices: 1) install gcc-4.2 libraries in 10.4u SDK or 2) build for Leopard-only Thanks. I just realised that what was causing compilation to fail was the inclusion of the "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" flag. So now I have a package that compiles fine I think on most systems (I use the AC_OPENMP macro to check for openmp support, which it will generally not find on a Mac). Leopard users wishing to use openmp must: 1) install apple-supplied gcc 4.2 (e.g. via Xcode 3.1) 2) replace gcc and g++ by gcc-4.2 and g++4.2 respectively in Makeconf (or create appropriate symlinks) 3) remove all instances of "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" in Makeconf I have found this to work on my system. But is this the easiest solution for Mac users wishing to use openmp in the package - or can you think of a way of avoiding 3) ? Thanks for your help, Ernest As for 1) you can get just the SDK files for Tiger from http://r.research.att.com/tools/ (you'll need to symlink darwin8 directory to darwin9) As for 2) you can use the Leopard binaries from http://r.research.att.com/ Cheers, Simon Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non- Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 20:25, Simon Urbanek wrote: On Jul 30, 2008, at 15:13 , Ernest Turro wrote: On 30 Jul 2008, at 19:23, Simon Urbanek wrote: On Jul 30, 2008, at 13:16 , Ernest Turro wrote: On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. That is not exactly true - it uses whatever your gcc version is. You can use Apple's gcc 4.0 or 4.2, they both work. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. FYI it's part of Xcode 3.1 ... Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple-supplied gcc 4.2 instead of 4.0 ? I suspect you're confusing several separate issues here - the include paths for OMP have nothing to do with R, they are part of the gcc and as such added regardless of the include flags. Just try gcc-4.2 omp.c -o omp -fopenmp which specifies no include flags and works just fine. The real issue here is that Apple doesn't provide gcc-4.2 support for Tiger, so you cannot use 10.4 SDK unless you also install the corresponding libraries. Hence you have two choices: 1) install gcc-4.2 libraries in 10.4u SDK or 2) build for Leopard-only Thanks. I just realised that what was causing compilation to fail was the inclusion of the "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk" flag. Yes, as I told you. So now I have a package that compiles fine I think on most systems (I use the AC_OPENMP macro to check for openmp support, which it will generally not find on a Mac). Leopard users wishing to use openmp must: 1) install apple-supplied gcc 4.2 (e.g. via Xcode 3.1) 2) replace gcc and g++ by gcc-4.2 and g++4.2 respectively in Makeconf (or create appropriate symlinks) 3) remove all instances of "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk" in Makeconf I have found this to work on my system. But is this the easiest solution for Mac users wishing to use openmp in the package - or can you think of a way of avoiding 3) ? The easiest solution is 2) in my previous e-mail (it uses gcc-4.2 by default and targets Leopard) and that's what you're forcing with your patches anyway. Could you please clarify how you go about building packages for Leopard-only without using my patches? Thanks, Ernest Cheers, Simon As for 1) you can get just the SDK files for Tiger from http://r.research.att.com/tools/ (you'll need to symlink darwin8 directory to darwin9) As for 2) you can use the Leopard binaries from http://r.research.att.com/ Cheers, Simon Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non-Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand th
Re: [Rd] R, Macports and C++ streams
On 31 Jul 2008, at 10:29, Kjell Konis wrote:
Ernest,
Is it possible to provide a reproducible example of your crash?
Yes. R on macports depends on gcc43, which is causing the problems.
The best thing would be to make the port not depend on gcc43, and
instead depend on apple-supplied gcc (if this is possible).
Alternatively, the macports gcc43 build script should be fixed (e.g.
by looking at Apple's script, if available). Reproducible example:
Download and install gcc43 from Macports
cat - > foo.txt
Blah
Blah
^D
cat - > foo.cc
#include
#include
extern "C" {
void foo() {
char bar;
std::ifstream ifs("foo.txt");
std::ofstream ofs("foo2.txt");
ifs >> bar;
ofs << bar;
}
}
^D
cat - > foo.R
dyn.load("foo.so")
.C("foo")
^D
# Crash:
g++-mp-4.3 -shared -fPIC foo.cc -o foo.so
R --vanilla < foo.R
# Don't crash:
g++-4.2 -shared -fPIC foo.cc -o foo.so
R --vanilla < foo.R
Kjell
On Jul 30, 2008, at 6:32 PM, Ernest Turro wrote:
On 30 Jul 2008, at 15:46, Simon Urbanek wrote:
On Jul 30, 2008, at 9:45 , Ernest Turro wrote:
Dear all,
R on Macports relies on GCC 4.3 to build packages. I find that
packages with shared objects that use C++ streams crash R if
they're compiled using Macports' gcc43, but work fine if compiled
in exactly the same way using Apple-supplied GCC 4.2. Has anyone
here had the same issue/know what is causing this problem?
Using compilers from MacPorts and similar suites (Darwin ports, Fink
etc.) is strongly discouraged (and outright not supported by the
CRAN binary) since they have been known to be badly broken in the
past and when whenever tested so far they were incomplete and
incompatible. You have to re-compile R yourself with those tools
(and you're entirely on your own) if you really want to use them.
CRAN binaries work only with Apple's gcc branches, if you want to
use anything else, you have to follow the unix R instructions and
compile everything from sources.
Dear Kjell,
As you can see above, your R port on Macports appears to be broken
and
has a reputation of having been broken for a while. I for one have
experienced odd problems as described above. To avoid further issues
with unsuspecting Macports users, perhaps it would be good to pull
the
port from the repository until a decent level of reliability can be
provided ?
Cheers,
Ernest
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Including data in package for use by C functions
How should one go about including data files for use by some C function in an R package? The data subdirectory is for additional data files the package makes available for loading from R, not C, and including the files in some other directory is no good because non- standard directories are removed when building the package. Thanks, E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
