similar to: Bite-size project

On Mar 28, 2016 3:01 PM, "Olly Betts" <olly at survex.com> wrote: > That's where a new command needs to be hooked up, but in this case I'd > put the actual implementation into transform.cc alongside the > implementation of $transform - then it can share $transform's regex > cache (which avoids recompiling a regex if it's used multiple times, > either

On Mar 29, 2016 4:49 PM, "Olly Betts" <olly at survex.com> wrote: > > On Tue, Mar 29, 2016 at 11:41:02AM +0100, James Aylett wrote: > > It's probably helpful to create a ticket and claim it (and update the > > project ideas list to link to it), so other people don't try to work > > on it as well. (I have a feeling that it might have been among the

Hello, I think I've found a bug in the C function do_grep located in src/main/grep.c. It seems to affect both the latest revisions of R-2-13-branch and trunk when compiling R without optimizations and with it's own version of pcre located in src/extra, at least on ubuntu 10.04. According to the pcre_exec API (I presume the later versions), the ovecsize argument must be a multiple of 3 ,

free_last_match() frees the memory of the match passed as argument, so accessing it is not possible after free_last_match(). Since all we need is the return code, save it locally for later usage. --- common/mlpcre/pcre-c.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/mlpcre/pcre-c.c b/common/mlpcre/pcre-c.c index da982025f..0762a8341 100644 ---

Dear R-help, (This is the first time I tried compiling 1.6.x from source on WinNT4, so please bear with me...) I tried following the instruction in src/gnuwin32/INSTALL as closely as I could, but encounter the following errors at the make step. Can some kind soul please help? I'm using pcre-3.9 and MinGW-2.0.0-3. I checked and libRpcre.a _is_ in src/extra/pcre. TIA, Andy ... gcc

On Fri, Apr 08, 2016 at 09:57:16AM -0400, Richhiey Thomas wrote: > Sorry to take so much time on this. Was down with coursework because the > semester end is nearing. Not a problem -- that sort of thing is affecting a lot of people at the moment! > I used the latest development version which is 1.3.5 for this patch. > I have implemented the $match function and it works fine when I

On Tue, Mar 29, 2016 at 06:20:21AM +0100, Olly Betts wrote: > > Can I start with trying to implement this? > > Sure - there's really no need to ask permission to work on something. It's probably helpful to create a ticket and claim it (and update the project ideas list to link to it), so other people don't try to work on it as well. (I have a feeling that it might have

Stripped out the HAL support code and replaced with calls to udev. The remainder of the code to extract CPU details parses through the /proc/cpuinfo file since udev/sysfs will not return such information. Signed-off-by: Darryl L. Pierce <dpierce at redhat.com> --- configure.ac | 3 +- src/Makefile.am | 4 +- src/processors.cpp | 94

Since the daemon links to pcre and use regular expressions, and since the COMPILE_REGEXP macro doesn't depend on any aspects of the library-side code (eg. the guestfs_h handle etc), we can allow the daemon to use the COMPILE_REGEXP macro. Move the macro to "guestfs-internal-all.h" to permit this. --- src/guestfs-internal-all.h | 26 ++++++++++++++++++++++++++ src/guestfs-internal.h

The output of btrfs subvolume list has changed in F18 to include generation, which breaks the parsing in btrfs_subvolume_list. This change replaces sscanf with a more robust regular expression. The new regular expression should also handle the addition of future unexpected columns. Fixes RHBZ#903620 --- daemon/Makefile.am | 6 +++-- daemon/btrfs.c | 67

This class has been replaced by the ProcessorsAgent. Signed-off-by: Darryl L. Pierce <dpierce at redhat.com> --- src/Makefile.am | 4 - src/cpu.cpp | 216 ------------------------------------------------------- src/cpu.h | 111 ---------------------------- src/host.cpp | 24 ------ src/host.h | 3 - src/schema.xml | 16 ---- 6 files changed, 0 insertions(+),

Hi, I am currently pursuing my computing science bachelors degree at university of Alberta, Canada. My speciality lie in Information retrieval, machine learning and data mining. In order to get hands on experience with real world information retrieval systems, I would like to contribute to the Xapian project. I have been going through some of the project ideas in

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 11 ++++++++--- 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 15 ++++++++++++--- 4 files changed, 30 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

I am trying to compile R-2.4.1 in 64-bit on Solaris 10 running on AMD hardware. I am trying to do this with Sun Studio 11. My config.site looks like this: #! /bin/sh AR="/usr/ccs/bin/ar" TEX="/usr/local/teTeX/bin/i386-pc-solaris2.10/tex" LATEX="/usr/local/teTeX/bin/i386-pc-solaris2.10/latex" PDFTEX="/usr/local/teTeX/bin/i386-pc-solaris2.10/pdftex"

I am trying to compile R-2.4.1 in 64-bit on Solaris 10 running on AMD hardware. I am trying to do this with Sun Studio 11. My config.site looks like this: #! /bin/sh AR="/usr/ccs/bin/ar" TEX="/usr/local/teTeX/bin/i386-pc-solaris2.10/tex" LATEX="/usr/local/teTeX/bin/i386-pc-solaris2.10/latex" PDFTEX="/usr/local/teTeX/bin/i386-pc-solaris2.10/pdftex"

Str is a pretty ugly regexp module. Let's try to replace it with PCRE. This series of commits goes some small way towards that eventual goal. - - - I wonder if there was a deep reason why we had this? let unix2dos s = String.concat "\r\n" (Str.split_delim (Str.regexp_string "\n") s) I replaced it with what I think should be (nearly) equivalent: let unix2dos s =

Hey Richhiey, Most probably Xapian is used with CYGWIN in Windows and Windows Specific Code in Xapian is based on CYGWIN, However we would be able to help you out with this issue, if you could pastebin whole 'gnu-make' generated report. Regards, Abhishek On Sat, Jan 3, 2015 at 5:30 PM, <xapian-discuss-request at lists.xapian.org> wrote: > Send Xapian-discuss mailing list

We'd like to use PCRE instead of the awful Str module. However I don't necessarily want to pull in the extra dependency of ocaml-pcre, and in any case ocaml-pcre is rather difficult to use. This introduces very simplified and lightweight bindings for PCRE. They work rather like Str in that there is some global state (actually thread-local in this implementation) between the matching and