similar to: [LLVMdev] Re: LLVMdev Digest, Vol 2, Issue 30

MOre feedback inline ... Robert Mykland wrote: > Reid, > > Thanks for the detailed feedback. Sure .. devil's in the details :) > A value of zero now means zero literal for everything except labels, > right? Hmm. Not quite sure what you mean here. Zero values are used in quite a few places for various purposes. For example, the zlist will write a zero byte to terminate

Reid, Thanks for the detailed feedback. A value of zero now means zero literal for everything except labels, right? There is kind of a vague reference to this in the 1.0 -> 1.1 section I believe. You might want to make this clearer when talking about values in the body of the document. --> A comment on this: if a value of zero were never used for labels, that would make me happy,

At 09:37 PM 8/23/2004, you wrote: >On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > > At 06:43 PM 8/20/2004, Chris Lattner wrote: > > >I don't understand what you're getting at here. You can change char to > > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > > >understand how that would change anything to be more useful

At 05:09 PM 8/20/2004, you wrote: >On Fri, 20 Aug 2004, Reid Spencer wrote: > > > defined would be almost always stored in one byte instead of the present > > > usual two. > > > > So, if I get you correctly, you're advocating the creation of a > Type::CharTyID > > in the TypeID enumeration that is always written as a single byte? Note > that >

At 02:05 PM 8/20/2004, you wrote: >Robert Mykland wrote: >>Dear Chris and Reid: > >Hi Robert. > >>Some other random ideas I've had as I've been sifting through the new >>bytecode format. Please let me know what you think. >>1) ANSI C allows for char to default to unsigned char. This is I guess >>not how it normally is in GCC. If char defaulted

Dear Reid and Chris, I thought I should send this to the list in case anyone else is struggling to interpret bytecode files with the new docs. (1) First a bug I already mentioned to Reid. Unlike the other new module headers module 0x01 still uses the old 32-bit and 32-bit format instead of the new 5-bit and 27-bit format. Thus the first module in the file will be 0x00000001 followed by

Robert Mykland wrote: > Dear Chris and Reid: Hi Robert. > > Some other random ideas I've had as I've been sifting through the new > bytecode format. Please let me know what you think. > > 1) ANSI C allows for char to default to unsigned char. This is I guess > not how it normally is in GCC. If char defaulted to unsigned char > several things would be

At 06:43 PM 8/20/2004, Chris Lattner wrote: >On Fri, 20 Aug 2004, Robert Mykland wrote: > > >In any case, both signed and unsigned 8-bit constants can be written out > > >in a single byte. Again, do you think it's worth special casing this > > >though? Considering that we handle 8-bit strings specially already, there > > >are not a ton of 8-bit

I have written some programs in Common Lisp and I have been using SAS to pipe those programs to my lisp compiler in batch mode by using the %xlog and %xlst SAS commands. I wonder if there is in R a similar way to pipe commands to LISP so that all my work would be concentrated in R even when I have to call a LISP program? I have looked at the foreign library but this seems to adjust data types not

Dear Chris and Reid: Some other random ideas I've had as I've been sifting through the new bytecode format. Please let me know what you think. 1) ANSI C allows for char to default to unsigned char. This is I guess not how it normally is in GCC. If char defaulted to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > At 06:43 PM 8/20/2004, Chris Lattner wrote: > >I don't understand what you're getting at here. You can change char to > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > >understand how that would change anything to be more useful though. > > Well, in the old days, char strings were

On Fri, 20 Aug 2004, Reid Spencer wrote: > > defined would be almost always stored in one byte instead of the present > > usual two. > > So, if I get you correctly, you're advocating the creation of a Type::CharTyID > in the TypeID enumeration that is always written as a single byte? Note that > right now all ASCII values ( <128 ) will be written as a single byte for

The Wine development release 1.3.34 is now available. What's new in this release (see below for details): - Bytecode support in JavaScript. - Support for gradients in the DIB engine. - A number of Uniscribe improvements. - Fixes for DirectDraw mode switching. - A few more MSVC runtime functions. - Various bug fixes. The source is available from the following locations:

The Wine development release 1.3.35 is now available. What's new in this release (see below for details): - Triangular gradients and cosmetic wide pens support in the DIB engine. - All Wine dialogs can now be translated through po files. - Many more scripts added to UniScribe. - JScript using bytecode throughout now. - Several MSXML improvements. - Various bug fixes. The source

I get a similar error when I try to disassemble a bytecode file generated by llvm-gcc released for llvm 1.9. Do I need to upgrade to a new llvm-gcc? Ryan M. Lefever wrote: > I am trying to use llvm-ld but when I try to link several bytecode files > into a single bytecode file, it gives me the following error: > > llvm-ld -o benchmarks/bc-1.06/src/bc.c.bc

Kewl Beans! You're heading right where I need LLVM to go :) Details ... On Wed, 2003-11-12 at 07:22, John Criswell wrote: > Funny you should mention that; getting a C library compiled to LLVM > code is one of the tasks on my plate. :) Good. If I can help, please let me know. > You are correct that the LLVM assembly language cannot accept native > assembly instructions

I am trying to use llvm-ld but when I try to link several bytecode files into a single bytecode file, it gives me the following error: llvm-ld -o benchmarks/bc-1.06/src/bc.c.bc benchmarks/bc-1.06/src/bc.i.bc benchmarks/bc-1.06/src/execute.i.bc benchmarks/bc-1.06/src/getopt1.i.bc benchmarks/bc-1.06/src/getopt.i.bc benchmarks/bc-1.06/src/global.i.bc benchmarks/bc-1.06/src/load.i.bc

I was able to correct this problem by checking out the latest version of llvm-gcc4 from svn and compiling it from source. One note, in order to get llvm-gcc4 to compile, I had to add #include "llvm/Analysis/LoopPass.h" to gcc/llvm-backend.cpp Ryan M. Lefever wrote: > I get a similar error when I try to disassemble a bytecode file > generated by llvm-gcc released for llvm

> On Mar 11, 2018, at 3:32 PM, Neha Aggarwal <aggarwalneha2000 at gmail.com> wrote: > > Hello All, > I am facing a unique problem and am unable to find any help in R help pages > or online. I will appreciate your help for the following problem: > I have 2 data-frames, samples below and there is an expected output > > R Dataframe1: > C1 C2

Dear R-devel, utils::isS3stdGeneric tries to subset the body of the function it's fed, primitives don't like that because they don't have a body, identity doesn't like it either because it's body is a symbol. According to the doc, any function is a legal input. See below: identity #> function (x) #> x #> <bytecode: 0x0000000013d6da28> #> <environment: