similar to: [LLVMdev] RPM build failure on CentOS

Nice! This looks good to me but probably Chris or someone else should sign off on it. There were two minor warnings on Darwin: -- In file included from /Volumes/Data/Users/ddunbar/llvm/lib/Support/regexec.c:81: /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc: In function 'sbackref': /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc:665: warning: control reaches end of

On 2009-08-27 09:06, Daniel Dunbar wrote: > 2009/8/25 Török Edwin <edwintorok at gmail.com>: > >> On 2009-08-25 21:18, Daniel Dunbar wrote: >> >>> Woot! Thanks a bunch Edwin! >>> >>> Some comments on the patch: >>> -- >>> I'm not sure if it makes sense to import the man pages, if we only >>> expose Regex.h.

2009/8/25 Török Edwin <edwintorok at gmail.com>: > On 2009-08-25 21:18, Daniel Dunbar wrote: >> Woot! Thanks a bunch Edwin! >> >> Some comments on the patch: >> -- >> I'm not sure if it makes sense to import the man pages, if we only >> expose Regex.h. >> > > I'd like to keep re_format.7, it describes the format of the regex as >

Hi, In R 3.4.0, the "Pattern Matching and Replacement" documentation that describes regexec(), gregexpr(), etc. states that the "text" argument to regexec is a character vector, "or an object which can be coerced by as.character to a character vector": regexec(pattern, text, ignore.case = FALSE, perl = FALSE, fixed = FALSE, useBytes = FALSE)

On Sun, Aug 23, 2009 at 8:28 PM, Chris Lattner<clattner at apple.com> wrote: > > On Aug 23, 2009, at 5:50 PM, OvermindDL1 wrote: > >> On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> wrote: >>> >>> This is too heavy, and we don't need the extra features, and regexec >>> is well tested and much more standard. Unless there

On 2009-08-24 07:28, Chris Lattner wrote: > On Aug 23, 2009, at 9:01 PM, Daniel Berlin wrote: > >>> 2. Use POSIX regcomp facilities. This implies importing some >>> implementation of this interface, e.g., Windows. On Linux, BSD, etc. >>> we would try to use the platform version if available (and non- >>> buggy). >>> >> Don't

On Aug 23, 2009, at 5:50 PM, OvermindDL1 wrote: > On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> > wrote: >> This is too heavy, and we don't need the extra features, and regexec >> is well tested and much more standard. Unless there is an >> overwhelming > > 'regexec' I had never heard of, figured it was a library, turns

On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> wrote: > This is too heavy, and we don't need the extra features, and regexec > is well tested and much more standard. Unless there is an overwhelming 'regexec' I had never heard of, figured it was a library, turns out it is a function call on *nix systems, yea, that is very much not usable in any way

Hello, I've just updated to wine 0.9 and now I get following error when running diablo2: err:module:load_builtin_dll failed to load .so lib for builtin L"dbghelp.dll": /usr/lib/wine/dbghelp.dll.so: symbol regexec, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference err:module:import_dll Loading library dbghelp.dll (which is needed by

Under RSPython and rpy, the regexec C function is returning nonsensical results leading to segmentation faults. This is happening in some situations under R 1.4.1 and (more often?) under R 1.5.0 on my Solaris 8 box. R 1.4.1 was compiled with gcc 2.95.2, and I've tried 1.5.0 with both gcc 2.95.2 and gcc 3.0.3. The error appears to be exactly the same under both python tools and both

Hi Bill, This is a bug in regexec() and I will commit a fix. Thanks for the report, Michael On Tue, Oct 4, 2016 at 1:40 PM, William Dunlap <wdunlap at tibco.com> wrote: > I noticed a problem in the strcapture from R-devel (2016-09-27 r71386), when > the text contains a missing value and perl=TRUE. > > { > # NA in text input should map to row of NA's in output,

On Aug 23, 2009, at 9:01 PM, Daniel Berlin wrote: >> 2. Use POSIX regcomp facilities. This implies importing some >> implementation of this interface, e.g., Windows. On Linux, BSD, etc. >> we would try to use the platform version if available (and non- >> buggy). > > Don't do it. > They are ridiculous slow, and posix made some really dumb choices in >

On Sun, Aug 23, 2009 at 10:20 PM, Chris Lattner<clattner at apple.com> wrote: > On Aug 23, 2009, at 9:11 PM, OvermindDL1 wrote: >>> >>> Again, forget boost regex. :) >> >> What about std::regex? > > No, we have to build with c++'98 compilers. I think you're missing the > point here. We care about code size in llvm, and the best code size

On 2009-08-24 20:14, Chris Lattner wrote: > On Aug 23, 2009, at 11:59 PM, Török Edwin wrote: >> If LLVM is going to have an integrated regex library I suggest using it >> regardless if the platform has one. >> The LLVM integrated regex library will provide consistent behaviour and >> execution time, the system one will not. > > Hi Edwin, > > Can you propose

On Sun, Aug 23, 2009 at 3:29 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > On Sun, Aug 23, 2009 at 4:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: >> We would like to have access to some kind of regular expression >> library inside LLVM. For example, we need this to extend the FileCheck >> test case checking tool to support regular expressions.

Hi All, I have two small things that I would appreciate some help with: 1. Config/Alloca.h is now dead. Once configure and cmake support is removed, we can zap it. Can someone remove the cmake/autoconf stuff that pokes at Config/Alloca.h? 2. Daniel's regex email. I think the right answer is to just autodetect whether regcomp/regexec etc are available (his #2). Could someone add

Hey, Downloaded the release, used CMake to create solution... building mostly seems to be OK, except for a couple of compiler errors. warning C4090: 'function' : different 'const' qualifiers d:\companyone\external\llvm\source\llvm-2.7\lib\support\regengine.inc 188 error C2248: 'llvm::EquivalenceClasses<ElemTy>::ECValue::ECValue' : cannot access private member

It is also not catching the cases where the number of capture expressions does not match the number of entries in proto. I think all of the following should give an error about the mismatch. > strcapture("(.)(.)", c("ab", "cde", "fgh", "ij", "lm"), proto=list(A="",B="",C="")) A B C 1 a b cd 2 d

Chris Lattner <clattner at apple.com> writes: > 1. Config/Alloca.h is now dead. Once configure and cmake support is > removed, we can zap it. Can someone remove the cmake/autoconf stuff > that pokes at Config/Alloca.h? AFAIK, there is nothing specific for include/llvm/Config/alloca.h on the cmake build and it works fine after removing the file (checked on Linux x86_64).

On Sun, Aug 23, 2009 at 5:04 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Chris Lattner <clattner at apple.com> writes: > >> 1. Config/Alloca.h is now dead.  Once configure and cmake support is >> removed, we can zap it.  Can someone remove the cmake/autoconf stuff >> that pokes at Config/Alloca.h? > > AFAIK, there is nothing specific for