similar to: Bug: in 2.6.1

Full_Name: Gordon Lack Version: 2.2.0 OS: OSF1/Tur64 Submission from: (NULL) (193.128.25.20) R-2.2.0 fails to build on OSF1 systems. ..... make[4]: Leaving directory `..../R-2.2.0/src/library/tools/src Error in list.files(path, pattern, all.files, full.names, recursive) : invalid 'pattern' regular expression Execution halted make[3]: *** [all] Error 1 ..... I've tracked

Full_Name: Gordon Lack Version: 2.4.0 OS: OSF1 v5.1 Submission from: (NULL) (198.28.92.5) Changes to the bin/R front-end interlude script at 2.4.0 (cf: 2.2.0) have broken R on (Dec/Compaq/HP) OSF1. There are 3 occurrences of "${@}", but this is the incorrect syntax for adding $@, as on older Bourne shells this will add an empty (but present) parameter. The result is that the build

On 2009-02-27, at 19:58, Jon Harrop wrote: > On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: >> I agree this could be better. I think it would be prudent of you, >> being aware of this problem, to structure your compiler so as to >> limit >> the number of pieces of code which would be effected when you switch >> to a copying collector. > > I

On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: > I agree this could be better. I think it would be prudent of you, > being aware of this problem, to structure your compiler so as to limit > the number of pieces of code which would be effected when you switch > to a copying collector. I think that would make my VM a lot more complicated for no clear practical gain. >

On 2008-12-30, at 21:07, Ranjit Jhala wrote: > thanks Chris and Gordon for the fantasic infrastructure and ocaml > bindings and Erick for the prompt response! > > I'm looking to use LLVM to write program analyses for > C/C++ programs, but to use Ocaml to write the analyses. > I did see there were bindings for iterating over: > > * functions in a module

Is this just me???? Just installed 2.0.5a for testing. Copying files (using explorer) from NT to Samba-2.0.5a (Solaris2.6 *and* Irix6.5) fails to copy the date/time stamp correctly (1.9.18p7 is fine, from the same NT system). 24/06/1999 11:59 (on NT) => 25/06/1999 17:14 (Samba) 25/06/1999 17:00 (on NT) => 25/06/1999 17:09 (Samba) (Yes, that is one 24th and three 25ths of

hi*& ppl, what I see? smbstat shows this: veda uucp uucp 17012 vdv (193.168.6.84) Sun Dec 19 14:33:43 1999 squid-wate piv guest 19110 nlv (193.168.6.74) Mon Dec 20 08:51:18 1999 squid-nav paul wheel 19110 nlv (193.168.6.74) Mon Dec 20 08:51:42 1999 nlv nlv guest 19110 nlv (193.168.6.74) Mon Dec 20 09:11:31 1999

Gordon Messmer wrote: > On 11/09/2015 09:59 AM, John R Pierce wrote: >> On 11/9/2015 9:50 AM, Gordon Messmer wrote: >>> I don't see the distinction you're making. >> >> a incremental backup copies everything since the last incremental >> a differential copies everything since the last full. > > I guess that makes sense, but in backup systems based

On Feb 26, 2009, at 21:17, Jon Harrop wrote: > For example, the IR I am generating shares pointers read from the > heap even across function calls. That is built on the assumption > that the pointers are immutable and, therefore, that the GC is non- > moving. [...] > > If you wanted to add a copying GC to my VM you would probably > replace every lookup of the IR

There are two security advisories for people who run a writable rsync daemon. One affects only those with "use chroot = no" (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These

There are two security advisories for people who run a writable rsync daemon. One affects only those with "use chroot = no" (which is not a very safe combination in general), and one affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy. Included are simple config-change suggestions that should help you to avoid the security issues. These

On Sep 12, 2007, at 01:01, Gordon Henriksen wrote: > I'm authoring a C interface to the LLVM IR type system. Since this > is Really Quite Tedious, I would like to solicit opinions before I > get too far down any paths that seem offensive. I've attached the > header, where I've mapped a portion of Module and most of Type and > its subclasses. This is working, and

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in

Hello Josef, FYI build failure occured in fs/btrfs/ctree.h. CC fs/btrfs/super.o In file included from fs/btrfs/delayed-inode.h:30:0, from fs/btrfs/super.c:45: fs/btrfs/ctree.h:3235:1: error: expected identifier or ‘(’ before ‘<<’ token make[3]: *** [fs/btrfs/super.o] Error 1 make[2]: *** [fs/btrfs] Error 2 make[1]: *** [fs] Error 2 make[1]: Leaving directory ` make:

I have compiled R version 1.3.1 on a Linux system. No errors or warnings are reported. However, "make check" fails thus: ===== make[5]: Leaving directory `/proj/informatics-build/GML/R/R-1.3.1/src/library' running code in base-Ex.R ... ../../bin/R --vanilla < base-Ex.R > base-Ex.Rout make[4]: *** [base-Ex.Rout] Error 139 ===== The base-Ex.Rout being produced at this

On 2007-11-26, at 21:12, Jon Harrop wrote: > Provide a type enumerating the valid terminators and restrict the > last instruction in a block to be a terminator. Something like this: > > type terminator = [ `ret of llvalue | `br of llvalue ] > type instruction = > [ terminator > | `add of llvalue * llvalue > | `sub of llvalue * llvalue ] > type block

Full_Name: Gordon Lack Version: 2.4.0 OS: Redhat Linux AS2.1 Submission from: (NULL) (198.28.92.5) Not sure whether this is a configure issue or an R one. It's only a minor issue, so this is really just FYI. The code in configure checks for the version of makeinfo by splitting the version string into a major and minor component. The tests on these assume they are numeric. RHAS2.1 shipped

On Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > After some experimentation, I'd prefer the closed system. LLVM has some type > peculiarities like the commonality between CallInst and InvokeInst. I find > that the closed type system lets me express such constraints more naturally. > Expressing these constraints explicitly in the open

On Tue, 16 Jan 2007, Gordon Henriksen wrote: > The simplest solution is to avoid typedefs for array types. With > names of array types removed from the symbol table, llc will simply > output (for instance) 'l_structtype_s[3]' instead of the equivalent > 'l_fixarray_array3'. Very nice catch and approach. > A more ambitious fix would be to merge the

On Mon, May 12, 2008 at 9:50 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On May 12, 2008, at 12:00, Mahadevan R wrote: > > > 1) The MP dtor does a no-op (deletes self, but not the module it owns) > > That's not how the object works... Yes, I know ;-) I was hoping you could add a detach() or some such API for the MP...