search for: data_table

I am new to R and new to time series modeling. I have a set of variables (var1, var2, var3, var4, var5) for which I have historical yearly data. I am trying to use this data to produce a prediction of var1, 3 years into the future. I have a few basic questions: 1) I am able to read in my data, and convert it to a time series format using 'ts.' data_ts <- ts(data, start = 1988, end =

From: Lyude Paul <lyude at redhat.com> There's been a TODO sitting in the kms_plane test suite for a while now as a placeholder for actually generating a reference CRC for plane-position-hole tests. This means we have never actually been verifying whether or not partially covering our hole with a hardware plane works displays properly, and have just simply been checking that the frame

Hi Good day. I am facing issue with creating a GlobalVariable. I already have an extern for that global in a header file to use it in the following way extern const void* DATA_TABLE[]; And with a LLVM PASS, I am trying to create this array with the same name and with initializer. So, I have following: GlobalVariable *gvar_data = new GlobalVariable( M, blockItems->getType(), true, GlobalValue::CommonLinkage, blockItems, "DATA_TABLE"); gvar_data->setAli...

Hi Ashi, > ld: illegal text-relocation to _data_table in table.o from foo in > use_table.o for architecture armv7 It looks like you're using iOS. I'm not familiar with the exact workings of that platform, but I think a similar message would occur in ELF-land. If iOS *is* comparable, your issue is that symbols in dynamically loaded objects...

...all if you swap the pop and the .long. Bernie, is it related to ARM pipeline? I'm interesting in this, is there any other additional information? On Fri, Mar 8, 2013 at 4:59 AM, Tim Northover <t.p.northover at gmail.com>wrote: > Hi Ashi, > > > ld: illegal text-relocation to _data_table in table.o from foo in > > use_table.o for architecture armv7 > > It looks like you're using iOS. I'm not familiar with the exact > workings of that platform, but I think a similar message would occur > in ELF-land. > > If iOS *is* comparable, your issue is that symb...

I have changed it to ExternalLinkage. Now, in LLVM IR, it looks like that: @DATA_TABLE = external global [0 x i8*], section "data_section", align 16 #0 @DATA_TABLE.1 = global [10 x i8*] [i8* inttoptr (i64 53415718 to i8*), i8* bitcast (void (%class.Hello*)* @_ZN5Hello5ptofnEv to i8*),...], section "data_section", align 16 #0 In my uses: %arrayidx = getelementptr...

Hello. I'm trying to understand how fastcall works. As far as I know, first two integer type arguments are passed in ecx and edx. I tested several test, but the result was different from what I expected #1 typedef struct _data_t { int d; } data_t; void __attribute__((fastcall)) test_suuu(data_t s, unsigned int a, unsigned int b, unsigned int c); unsigned int a is passed

...0 42.86 Aa 0 66.07 Aa 0 60.24 Aa 0 42.86 Qe 0 66.07 Qe 0 60.24 Qe 0 42.86 Cx 56 310.86 Cx 56 223.17 Cx 56 186.77 Tw 56 149.42 Tw 56 127.75 Tw 56 138.59 Aa 56 130.24 Aa 56 214.83 Aa 56 137.95 Qe 56 186.64 Qe 56 189.09 Qe 56 187.87 this is my script require(agricolae) file <- "A1.txt" data_table <- read.table(file, header=T, row.names=NULL) attach(data_table) anova <- aov(A1 ~ factor(Thesis)*factor(Days)) detach(data_table) first of all, I need to know if my script has conceptual errors secondly, I need to calculate HSD between Thesis:Days means I try with Tukey.test command from...

From: Lyude Paul <lyude at redhat.com> Signed-off-by: Lyude Paul <lyude at redhat.com> --- tests/kms_pipe_crc_basic.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c index d169b7bd..f121e27e 100644 --- a/tests/kms_pipe_crc_basic.c +++ b/tests/kms_pipe_crc_basic.c @@ -65,15 +65,14 @@ static void

From: Lyude Paul <lyude at redhat.com> We're finally getting CRC support in nouveau, so let's start testing this in igt as well! While the normal CRC capture tests are nice, there's a number of Nvidia-specific hardware characteristics that we need to test as well. The most important one is known as a "notifier context flip". Basically, Nvidia GPUs store generated CRCs

From: Lyude Paul <lyude at redhat.com> We're finally getting CRC support in nouveau, so let's start testing this in igt as well! While the normal CRC capture tests are nice, there's a number of Nvidia-specific hardware characteristics that we need to test as well. The most important one is known as a "notifier context flip". Basically, Nvidia GPUs store generated CRCs

From: Lyude Paul <lyude at redhat.com> We're finally getting CRC support in nouveau, so let's start testing this in igt as well! While the normal CRC capture tests are nice, there's a number of Nvidia-specific hardware characteristics that we need to test as well. The most important one is known as a "notifier context flip". Basically, Nvidia GPUs store generated CRCs

Hi I saw from the ChangeLog that [get|set]_client_data was removed from ComboBox for 0.4.0 because the methods weren''t working properly. TreeCtrl#get_item_data still seems to be there. I was wondering if someone who understood the issue could say if TreeItemData might also be afflicted with the same problems? I seem to be segfaulting quite a bit (actually, on TreeEvt#get_item), but it

From: Lyude Paul <lyude at redhat.com> We're finally getting CRC support in nouveau, so let's start testing this in igt as well! While the normal CRC capture tests are nice, there's a number of Nvidia-specific hardware characteristics that we need to test as well. The most important one is known as a "notifier context flip". Basically, Nvidia GPUs store generated CRCs

From: Lyude Paul <lyude at redhat.com> Nouveau has finally gotten CRC support, hooray! Well, it's under review at least: https://patchwork.freedesktop.org/series/74804/ (it has a cover letter, but nouveau's mailing list configuration has blocked the email so I'm waiting for a moderator to fix that) So, this series adds the relevant tests for it since nvidia's CRC

On Mon, 2020-09-28 at 17:36 -0400, Jeremy Cline wrote: > Hi, > > On Tue, Aug 18, 2020 at 05:00:51PM -0400, Lyude wrote: > > From: Lyude Paul <lyude at redhat.com> > > > > We're finally getting CRC support in nouveau, so let's start testing > > this in igt as well! While the normal CRC capture tests are nice, > > there's a number of

Hi, On Tue, Aug 18, 2020 at 05:00:51PM -0400, Lyude wrote: > From: Lyude Paul <lyude at redhat.com> > > We're finally getting CRC support in nouveau, so let's start testing > this in igt as well! While the normal CRC capture tests are nice, > there's a number of Nvidia-specific hardware characteristics that we > need to test as well. > > The most

From: Lyude Paul <lyude at redhat.com> (Just forwarding this to nouveau's ml, since I completely forgot to before) Nouveau has finally gotten CRC support, hooray! Well, it's under review at least: https://patchwork.freedesktop.org/series/74804/ (it has a cover letter, but nouveau's mailing list configuration has blocked the email so I'm waiting for a moderator to fix that)

From: Lyude Paul <lyude at redhat.com> Nouveau has finally gotten CRC support, and at this point that support has made its way upstream. Hooray! So, let's start adding some relevant tests for it since nvidia's CRC implementation has some rather interesting design choices that needed to be worked around. Lyude Paul (5): lib/igt_core: Fix igt_assert_fd() documentation

From: Lyude Paul <lyude at redhat.com> I ended up hitting some bugs when writing nouveau's CRC implementation due to incorrectly handling the situation where we disable CRCs on a pipe that already been disabled, which ended up causing some other vague igt issues when running certain tests in multi-mode. So, let's add a trivial test for this scenario while we're at it.