similar to: debugonce() functions are not considered as debugged

On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: [...] > Do you have a good use case when it would be useful to query/unset the > mark for debugonce? Well, I suppose the same use cases when it is useful to query/unset the other debug mark. To be more specific, in debug helpers for a tool that works with callbacks from a central event loop, it is

On 05/22/2018 06:07 PM, G?bor Cs?rdi wrote: > On Mon, May 21, 2018 at 5:01 PM Tomas Kalibera <tomas.kalibera at gmail.com> > wrote: > [...] >> Do you have a good use case when it would be useful to query/unset the >> mark for debugonce? > Well, I suppose the same use cases when it is useful to query/unset the > other debug > mark. I asked because the use cases

debug(fun) marks "fun" for debugging, it makes sure that whenever "fun" is called, the debugger is entered undebug(fun) removes this mark; it won't stop any current debugging of that function isdebugged(fun) tells whether this mark is set or not; it does not tell whether "fun" is currently running in a debugger/browser debugonce(func) adds a different mark to

This is kind of a dumb question: I know you can use isdebugged() to find out if a specific function is flagged for debugging, but is there a way to list all the functions that are flagged for debugging? Thanks, Andrew [[alternative HTML version deleted]]

Hi list, Is there a function that can let me know which functions are being debugged? I know I'm probably not doing a very good job of keeping track of things, but it does get messier when you dig into different layers of a function. I know there is "isdebugged", but it only works on one function at a time. Thanks! ...Tao [[alternative HTML version deleted]]

We have had some conversation within R core, lead by Duncan Murdoch and me, about a proposal to extend the current tracingState() functionality by something tentatively called debuggingState(). Duncan has allowed me to copy the previous conversation (after very minor editing): The following is quite technical and assumes you know more about R's debug()ing and trace()ing than an estimated

Hi, While audit our code, we found out a strange pattern in one of the LLVM headers and we were wondering if that was expected or if it should be fixed. Namely the problem looks like this: #ifndef NDEBUG // Define some variable. #endif assert(/*use this variable, i.e., outside of the ifndef NDEBUG scope*/); This happens in include/llvm/IR/ValueHandle.h for the variable Poisoned line 494

Hello all, Since I got no answer to my first mail, I suspect I did not formulate my question adequately, so I try again. In R, one can debug or trace a function 'foo' with debug(foo) or trace(foo), respectively. This leads to a special treatment of the function 'foo' until one enter undebug(foo) or untrace(foo). I would like to know if there is a convenient way to know at any

Dear R-devel, I don't think this is expected : foo <- function() "hello" trace2 <- function(fun) trace(fun, quote(print("!!!"))) base::fun # Object with tracing code, class "functionWithTrace" # Original definition: # function() "hello" # # ## (to see the tracing code, look at body(object)) `untrace()` has the same behavior. This is

Good point, I forgot to check the standard. Given the clang was failing I assumed the code was wrong x). I am guessing there is something weird with the project, because indeed, paragraph 7.2 of the standard says: The assert macro is redefined according to the current state of NDEBUG each time that <assert.h> is included. > On Oct 4, 2017, at 2:53 PM, Craig Topper <craig.topper at

But the main point is where arguments are mixed together: > debugonce(plot.default) > plot(x=1:10, y=, 'l') ... Browse[2]> missing(y) [1] FALSE Browse[2]> y [1] "l" Browse[2]> type [1] "p" I think that's what I fall over mostly: that named, empty arguments behave entirely different from omitting them (", ,") And I definitely agree we need

Please note that this is documented in ?trace. "fun" is matched to what, it is a _name_ of the function to be traced, which is traced in the top-level environment. I don't know why it was designed this way, but it is documented in detail, and hence the expected behavior. Debugging is often, and also in R, implemented in the core. Tracing is implemented on top without specific

Hi, > Committed a change for the cmake build that implements the option > LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is > Release. Thanks! I think it might be nice to make this a bit more consistent with Makefile.config. I'd suggest... - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS - have it default to OFF (so assertions are enabled) always -

Jay Foad <jay.foad at gmail.com> writes: >> Committed a change for the cmake build that implements the option >> LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is >> Release. > > Thanks! I think it might be nice to make this a bit more consistent > with Makefile.config. I'd suggest... > > - use LLVM_DISABLE_ASSERTIONS instead of

The replay gain code has dos line endings in CVS, which causes problems for the Sun compiler, among others. Attached is a patch for the lazy, but it's probably easier to fix locally and commit. -r

On Sat, Jun 04, 2005 at 08:00:45AM -0700, Ralph Giles wrote: > The replay gain code has dos line endings in CVS, which causes problems > for the Sun compiler, among others. Attached is a patch for the lazy, > but it's probably easier to fix locally and commit. Now with actual patch... -r -------------- next part -------------- Index:

Hi, I have not sent yet any bug-reports to llvm-dev but I am seeing this build-failure: ... [574/3685] Building CXX object lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/MetadataLoader.cpp.o FAILED: lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/MetadataLoader.cpp.o /usr/bin/g++-8 -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

Dear R-Users, It seems like once one invokes browser() inside a loop and steps through the body using 'n' any subsequent loop will be "intercepted" by debug() function. Here is exactly what I mean # fresh R session # run a loop that has browser() inside the body > for (i in seq(5)) { browser(); print(i) } for (i in seq(5)) { browser(); print(i) } Called from: NULL

Hi List, Please see the following simple example which illustrate the problem. I'm using R-2.5.0 in WinXP and R2HTML 1.58. Thanks, ....Tao #============="test.rnw" ================= <html> <body> <div> <h1 align=center>Report</h1> <p> <<echo=FALSE,results=html>>= print(y) print("\n") print(paste("(",

On Wed, Aug 29, 2018 at 9:29 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Wed, Aug 29, 2018 at 7:51 AM, Matthias Klose <doko at debian.org> wrote: >> On 28.08.2018 13:55, Sedat Dilek wrote: >>> On Tue, Aug 28, 2018 at 10:59 AM, Hans Wennborg <hans at chromium.org> wrote: >>>> On Tue, Aug 28, 2018 at 10:26 AM, Sedat Dilek via llvm-dev