similar to: [PATCH] cube unfold distance

Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card processes these three floats? Does the card work with floats? Does (mesa? gallium? driver?) process these three input floats before it is sent to the card? Where is the code for it? If you say the floats are memory mapped as in exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would say from what I

Hi, I am attempting to modify LLVM to generate code for an architecture which is nearly identical to X86-64, but with a few minor differences. In particular, "call" must always have a register operand, and cannot have a memory operand. Any ideas on how I can express this rule? Thanks, - David -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Jun 8, 2010 at 2:05 PM, David Meyer <pdox at google.com> wrote: > Hi, > I am attempting to modify LLVM to generate code for an architecture which is > nearly identical to X86-64, but with a few minor differences. > In particular, "call" must always have a register operand, and cannot have a > memory operand. Any ideas on how I can express this rule? Just get

Hello All, I am trying to use the unfold function in RcmdrPlugin.survival library, which converts the survival data with time varying covariates to the counting process notation. The problem is somehow, the event indicator created is not correct. Below is the data, I am trying to convert: CASE TRT FAILTIME FAILCENS SEX AGE IGG0 IGG28 IGG42 IGG84 IGG364 26003 A 11.2033

Dear all, I am using the function ?unfold? from the ?RcmdrPlugin.survival? to convert my time-varying covariates dataset from wide to long. I managed to have it working for my data. However, the problem I have is that the observations after an event, won?t be dropped from the dataset. For example, see the dataframe below: the event occurs at 1.2 (event.time=1), but the 1.3 to 1.6 will remain in

On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <pdox at google.com> wrote: > Hi Eli, > I have tried this, but the resulting tool-chain was broken. > There are only two references to "CALL64m": the definition in > X86Instr64bit.td, and an entry in X86InstrInfo.cpp. > After commenting both out, compilation of a large application fails with: > llc: ScheduleDAG.cpp:462:

Hello, I used R a lot one year ago and now I am a bit rusty :) I have my raw data which correspond to the list of runtimes per minute (minute "1" "2" "3" in two database modes "sharding" and "query" and two workload types "query" and "refresh") and as a list of char arrays that looks like this: > str(data) List of 122 $ :

After removing CALL64m, the resulting DAG has a cycle that cannot be scheduled. I've attached a PDF of the DAG before instruction selection (-view-isel-dags), and after instruction select (-view-sched-dags). Notice how the flag/chain relationships between MOV64rm and CALL64r make it impossible to schedule. Here's the code being compiled: define ccc void @ArgsFree() nounwind { entry:

Hi Eli, I have tried this, but the resulting tool-chain was broken. There are only two references to "CALL64m": the definition in X86Instr64bit.td, and an entry in X86InstrInfo.cpp. After commenting both out, compilation of a large application fails with: llc: ScheduleDAG.cpp:462: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum]

Here are my patches to add edge + button functionality. I still feel that there is a problem with gconf, but I have just made it so that the edge button functionality works. I have included a patch for gconf to display AnyButton if it is set to 0. There is also a patch to make the edge size configurable because 1 pixel was too small and the mouse keeps slipping off when using it for the