search for: tre_regexecb

...>> ? Sun, 28 Jul 2024 20:02:21 -0400 >> Duncan Murdoch <murdoch.duncan at gmail.com> ?????: >> >>> gsub("^([0-9]{,5}).*","\\1","123456789") >>> [1] "123456" >> This is in TRE itself: for "^([0-9]{,1})" tre_regexecb returns {.rm_so >> = 0, .rm_eo = 1}, matching "1", but for "^([0-9]{,2})" and above it >> returns an off-by-one result, {.rm_so = 0, .rm_eo = 3}. >> >> Compiling with TRE_DEBUG, I see it parsed correctly: >> >> catenation, sub 0, 0 tags >&g...

...ul 2024 20:02:21 -0400 >>> Duncan Murdoch <murdoch.duncan at gmail.com> ?????: >>> >>>> gsub("^([0-9]{,5}).*","\\1","123456789") >>>> [1] "123456" >>> This is in TRE itself: for "^([0-9]{,1})" tre_regexecb returns {.rm_so >>> = 0, .rm_eo = 1}, matching "1", but for "^([0-9]{,2})" and above it >>> returns an off-by-one result, {.rm_so = 0, .rm_eo = 3}. >>> >>> Compiling with TRE_DEBUG, I see it parsed correctly: >>> >>> catenati...

On 2015-12-17 19:30, peter dalgaard wrote: > Presumably the file in question is one of > > Peter-Dalgaards-MacBook-Air:BUILD pd$ grep -r "^Package: tools" * > library/tools/DESCRIPTION:Package: tools > src/library/tools/DESCRIPTION:Package: tools > > so the first thing I'd do is to have a good look at those files and see if they got somehow corrupted. > >

On StackOverflow (here: https://stackoverflow.com/questions/78803652/why-does-gsub-in-r-match-one-character-too-many) there was a question about this result: > gsub("^([0-9]{,5}).*","\\1","123456789") [1] "123456" The OP expected "12345" as the result. Several points were raised: - The R docs don't mention the case of {,5} for the

...must contain the clue. Unfortunately not necessarily the matching one. My guess is that your TRE library is broken. The line should have matched the RE "regline" defined as tre_regcomp(&regline, "^[^:]+:[[:blank:]]*", REG_EXTENDED); ...and used here: if(tre_regexecb(&regline, line, 1, regmatch, 0) == 0) { but apparently does not. > Thanks for the assistance! > > Michael -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd....

...rtunately not necessarily the matching one. > > My guess is that your TRE library is broken. The line should have matched the RE "regline" defined as > > tre_regcomp(&regline, "^[^:]+:[[:blank:]]*", REG_EXTENDED); > ...and used here: > if(tre_regexecb(&regline, line, 1, regmatch, 0) == 0) { > > but apparently does not. > > > >> Thanks for the assistance! >> >> Michael > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederi...

...unately not necessarily the matching one. > > My guess is that your TRE library is broken. The line should have matched the RE "regline" defined as > > tre_regcomp(&regline, "^[^:]+:[[:blank:]]*", REG_EXTENDED); > ...and used here: > if(tre_regexecb(&regline, line, 1, regmatch, 0) == 0) { > > but apparently does not. int tre_regcomp(regex_t *preg, const char *regex, int cflags) { return tre_regncomp(preg, regex, regex ? strlen(regex) : 0, cflags); } The code is a bit too 'string busy' for me to be comfortable - so I took...