Displaying 20 results from an estimated 673 matches for "whoops".
Did you mean:
whops
2013 Mar 11
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...d work.
I haven't thought hard about it, but I believe it should wrok.
Note that again, neither works for pointers unless you can guarantee
you have the entire access path, which is hard:
union u {
struct A a;
struct B b;
};
int foo(struct A *a, struct B *b) {
....
}
void bar() {
union u whoops;
foo(&whoops.a, &whoops.b);
}
If you annotated foo with a partial access path, you may or may not
get the right answer.
You would think your type dag solves this, because you'll see they
share a supertype.
But it's actually worse than that:
file: bar.h
union u {
struct A a;
stru...
2000 Jul 28
0
whoops, revised patch for buildroot in 2.1.1p4
Whoops, missed a ./mkinstalldirs. Correct patch to Makefile.in is
attached.
--
Edward S. Marshall <emarshall at mercantec.com> UNIX Administrator
http://www.nyx.net/~emarshal/ Mercantec, Inc.
-------------- next part --------------
24c24
< CFLAG...
2012 Feb 01
0
Bug#658305: Whoops, fixed patch.
Whoops, that patch is obviously missing an extra line containing a fi
statement. Fixed version attached. And configurating is obviously not
english. :)
--
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenburg at mendix.com | www.mendix.com
-------------- next part ---...
2013 Mar 11
4
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
On Mar 11, 2013, at 2:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> On Mon, Mar 11, 2013 at 2:06 PM, Manman Ren <mren at apple.com> wrote:
>>
>> On Mar 11, 2013, at 1:17 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>>> On Mon, Mar 11, 2013 at 11:41 AM, Manman Ren <mren at apple.com> wrote:
>>>> Based on
2013 Mar 11
2
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...;
> Note that again, neither works for pointers unless you can guarantee
> you have the entire access path, which is hard:
>
> union u {
> struct A a;
> struct B b;
> };
>
> int foo(struct A *a, struct B *b) {
> ....
>
> }
>
> void bar() {
> union u whoops;
> foo(&whoops.a, &whoops.b);
> }
>
> If you annotated foo with a partial access path, you may or may not
> get the right answer.
> You would think your type dag solves this, because you'll see they
> share a supertype.
>
> But it's actually worse than t...
2005 Aug 19
2
Whoops! PHP does not have MySQL support
http://209.204.172.137:82/testphp.php
So, I will need to recompile PHP with MySQL (and Interbase), however I
do not want to "upset the appple cart" by bring in something that will
cause conflicts. Is there a step-by-step discussion on how to do this
for php 4.3.9?
Todd
--
Ariste Software
200 D Street Ext
Petaluma, CA 94952
(707) 773-4523
2010 Apr 23
0
Patch submission (whoops).
Greetings, and apologies for the braino leading to my first posting to
the general list. I'm reposting here, and changing how I attached the
files; they were hard to work with in the other post.
There's a coalescing group which is working to imitate Dirk's fine
translation of CRAN to APT, in the Fedora/Red-Hat flavored land.
One of the things we're trying to do is implement as
1999 Mar 28
0
whoops - ADMw0rm is old stuff
For all of us who don't regularly read the BUGTRAQ list and, like me
:-( , tend to forget: [mod: Like me :-( -- REW]
It has been pointed out, on a mail to BUGTRAQ, that the ADMw0rm is
pretty old stuff, already reported by CERT:
http://www.cert.org/advisories/CA-98.05.bind_problems.html
Searchable BUGTRAQ archives are available (also?) at
2013 Mar 12
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...unless you can guarantee
>> you have the entire access path, which is hard:
>>
>> union u {
>> struct A a;
>> struct B b;
>> };
>>
>> int foo(struct A *a, struct B *b) {
>> ....
>>
>> }
>>
>> void bar() {
>> union u whoops;
>> foo(&whoops.a, &whoops.b);
>> }
>>
>> If you annotated foo with a partial access path, you may or may not
>> get the right answer.
>> You would think your type dag solves this, because you'll see they
>> share a supertype.
>>
>>...
2005 Sep 07
1
Tracebacks with tryCatch() and withCallingHandlers()?
...ll sequence for the last uncaught
error, and not necessarily the last error."
(and it seems to be case for withCallingHandlers() too). Does anyone
know of a workaround for this? Is there a way to get the call stack
within the condition handler?
Example:
foo <- function() stop("whoops");
pre <- function() foo();
bar <- function() pre();
yo <- function(fcn=tryCatch) {
fcn(bar(),
error = function(ex) {
str(ex);
traceback(); # I would like to access the call stack here!
}
)
traceback();
}
Calling these gives:
> rm(.Traceback)...
2013 Mar 12
2
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...cess path, which is hard:
>>>
>>> union u {
>>> struct A a;
>>> struct B b;
>>> };
>>>
>>> int foo(struct A *a, struct B *b) {
>>> ....
>>>
>>> }
>>>
>>> void bar() {
>>> union u whoops;
>>> foo(&whoops.a, &whoops.b);
>>> }
>>>
>>> If you annotated foo with a partial access path, you may or may not
>>> get the right answer.
>>> You would think your type dag solves this, because you'll see they
>>> share a...
2010 Mar 04
0
ifthen() question -- whoops--ifelse()
OK, I got it figured out. I was not keying into a length greater than 1, so:
# I added this object and placed it into the iftelse statement:
lid <- sum(match(id, st[i], nomatch = 0))
out$var.g[i]<-ifelse(lid ==1, meta$var.g[id==st[i]],
aggs(g=g[id==st[i]],
n.1= n.1[id==st[i]],
n.2 = n.2[id==st[i]], cor)[2])
#full
2007 Mar 01
1
whoops, corrupted my filesystem
Hi all-
I corrupted my filesystem by not doing a RTFM first... I got an automated
email that the process monitoring the SMART data from my hard drive detected
a bad sector. Not thinking (or RTFMing), I did a fsck on my partition-
which is the main partition. Now it appears that I've ruined the
superblock.
I am running Fedora Core 6. I am booting off the Fedora Core 6 Rescue CD in
2013 Mar 12
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...gt;>> union u {
>>>> struct A a;
>>>> struct B b;
>>>> };
>>>>
>>>> int foo(struct A *a, struct B *b) {
>>>> ....
>>>>
>>>> }
>>>>
>>>> void bar() {
>>>> union u whoops;
>>>> foo(&whoops.a, &whoops.b);
>>>> }
>>>>
>>>> If you annotated foo with a partial access path, you may or may not
>>>> get the right answer.
>>>> You would think your type dag solves this, because you'll see the...
2013 Mar 13
3
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...ct A a;
>>>>> struct B b;
>>>>> };
>>>>>
>>>>> int foo(struct A *a, struct B *b) {
>>>>> ....
>>>>>
>>>>> }
>>>>>
>>>>> void bar() {
>>>>> union u whoops;
>>>>> foo(&whoops.a, &whoops.b);
>>>>> }
>>>>>
>>>>> If you annotated foo with a partial access path, you may or may not
>>>>> get the right answer.
>>>>> You would think your type dag solves this, b...
2013 Mar 13
0
[LLVMdev] PROPOSAL: struct-access-path aware TBAA
...ct B b;
>>>>>> };
>>>>>>
>>>>>> int foo(struct A *a, struct B *b) {
>>>>>> ....
>>>>>>
>>>>>> }
>>>>>>
>>>>>> void bar() {
>>>>>> union u whoops;
>>>>>> foo(&whoops.a, &whoops.b);
>>>>>> }
>>>>>>
>>>>>> If you annotated foo with a partial access path, you may or may not
>>>>>> get the right answer.
>>>>>> You would think your...
2010 Feb 11
3
[LLVMdev] Adding NonTemporal
...XCore backend by doing this:
if (Offset % 4 == 0) {
// We've managed to infer better alignment information than the load
// already has. Use an aligned load.
return DAG.getLoad(getPointerTy(), dl, Chain, BasePtr, NULL, 4,
false, false, 0);
}
Whoops! There's no alignment info being set here!
Is there any reason to keep these as default arguments? It invites silent
coding errors. I did this because I have to propagate the non-temporal
information through various phases of lowering and making these non-default
helps me catch missing cas...
2006 Mar 07
4
POSIX time zone codes
The manual entry for as.POSIX says this about time zone codes...
Usage
as.POSIXct(x, tz = "")
tz
A timezone specification to be used for the conversion...
but it fails to mention what these "specifications" are. So far, I
have tried...
as.POSIX(x, tz="UTC") ... works, gives UTC times
as.POSIX(x, tz="UTC") ... works, gives EST times
as.POSIX(x,
2019 Jun 17
2
[PATCH 08/25] memremap: move dev_pagemap callbacks into a separate structure
...x 219dd0a1cb08..a667d974155e 100644
> --- a/tools/testing/nvdimm/test/iomap.c
> +++ b/tools/testing/nvdimm/test/iomap.c
> @@ -106,11 +106,10 @@ EXPORT_SYMBOL(__wrap_devm_memremap);
>
> static void nfit_test_kill(void *_pgmap)
> {
> - struct dev_pagemap *pgmap = _pgmap;
Whoops, needed to keep this line to avoid:
tools/testing/nvdimm/test/iomap.c:109:11: error: ‘pgmap’ undeclared
(first use in this function); did you mean ‘_pgmap’?
2009 Sep 24
4
[LLVMdev] Headers (Was Re: help with llvm make system)
On Thu, Sep 24, 2009 at 1:54 PM, Jon H <hantheman12 at hotmail.com> wrote:
>>Whoops, sending it to to llvm list as well, freaking takes another ~70
>>seconds to do a reply to all instead of a reply to, headers still not
>>following standards of every other list I have ever been on...
>
> Stop whining about the headers. It's getting old.
It is also a rather m...