search for: isroot

Hi. I'm not subscribed, so please Cc: me. This trivial patch fixes a typo that irritates me every time I boot.. --- linux-2.5.orig/net/bridge/br_stp.c 2004-07-19 14:43:44.000000000 +0300 +++ linux-2.5/net/bridge/br_stp.c 2004-07-19 14:53:15.000000000 +0300 @@ -299,7 +299,7 @@ int isroot = br_is_root_bridge(br); pr_info("%s: topology change detected, %s\n", br->dev->name, - isroot ? "propgating" : "sending tcn bpdu"); + isroot ? "propagating" : "sending tcn bpdu"); if (isroot) { br->topology_change = 1;

...code doesn't actually replace the two memory operations. It generates two MOVSDs and a SHUFPD just fine but it produces two extra MOVSD instructions. As far as I can understand things, the problem is that the two MOVSD instructions are generated by a recursive call to EmitResultCode. Thus isRoot is false and the result of the call to getTargetNode is not passed to ReplaceUses. Then when we pop back up and generate the SHUFPD we call SelectNodeTo which only transforms the immediate node (the vector_shuffle). It doesn't recurse to replace child nodes. I tried hacking tblgen to call...

...eave to LLVM to figure out. But if we change it so that the GC only sees pointers, then I'm dead in the water. As far as my suggestion of marking types go, you are right, it doesn't make sense for most types. It really only matters for structs and pointers. Imagine if structs had an "isRoot" flag that lived next to "isPacked", which makes the struct a distinct type. This would be written in IR as "gcroot { i1, float }" or something like that. The presence of this flag has the same effect as marking a pointer in the GC address space. Combine that with the abili...

...n't see why you would be "dead in the water" - because it could be made to work. > > As far as my suggestion of marking types go, you are right, it doesn't make > sense for most types. It really only matters for structs and pointers. > Imagine if structs had an "isRoot" flag that lived next to "isPacked", which > makes the struct a distinct type. This would be written in IR as "gcroot { > i1, float }" or something like that. The presence of this flag has the same > effect as marking a pointer in the GC address space. Combine that...

Currently, I load the RData file then ls() and str(). But loading the file takes too long if the file is big. Most of the time, I only interested what the variables are in the the file and the attributes of the variables (like if it is a data.frame, matrix, what are the colnames/rownames, etc.) I'm wondering if there is any facility in R to help me avoid loading the whole file.

On Mon, Mar 7, 2011 at 12:48 PM, Talin <viridia at gmail.com> wrote: > On Mon, Mar 7, 2011 at 10:58 AM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > >> Hi Talin, >> >> Sorry to interject - >> >> >>> For example, suppose I have a type "String or (float, float, float)" - >>> that is, a union of a string and a

...inter now, we no longer need the metadata argument to describe it's type." > >> As far as my suggestion of marking types go, you are right, it doesn't >> make sense for most types. It really only matters for structs and pointers. >> Imagine if structs had an "isRoot" flag that lived next to "isPacked", which >> makes the struct a distinct type. This would be written in IR as "gcroot { >> i1, float }" or something like that. The presence of this flag has the same >> effect as marking a pointer in the GC address space....

On Mon, 2008-10-20 at 11:49 -0500, David Greene wrote: > I tried hacking tblgen to call getTargetNode / ReplaceUses if any node in the > pattern has a chain by changing this line in tblgen: > > bool InputHasChain = isRoot && > NodeHasProperty(Pattern, SDNPHasChain, CGP); > > to call PatternHasProperty instead. This does cause tblgen to emit > getTargetNode / ReplaceUses instead of SelectNodeTo but ReplaceUses doesn't > know how to handle a complex pattern like this. It complai...

...nstructions which load and store from memory should have a chain, + // regardless of whether they happen to have an internal pattern saying so. + if (Pattern.getSrcPattern()->TreeHasProperty(SDNPHasChain, CGP) + && (II.mayLoad || II.mayStore)) + NodeHasChain = true; + bool isRoot = N == Pattern.getDstPattern(); // TreeHasOutGlue - True if this tree has glue.

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

The manual page says, that rcmd() is only to be used by root's processes. On other OSes (Solaris, AIX), trying to call rcmd() without being root simply fails. FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. Why? My understanding is, this is to make it harder for would-be attackers to

Hi Talin, I have some questions below. If these topics have already been discussed in earlier threads, kindly point me there. I'm aware of your GC proposal, but the rest is new to me. On Jul 1, 2011, at 11:05 AM, Talin wrote: > Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the frontend to generate very inefficient and

...: added 'login_shell' option to defaults XQuartz: Corrected copyright X.org Project -> X.org Foundation XQuartz: Fixed copy-paste error with login_shell commit XQuartz: Moved SetFrontProcess haco to set_front_process Rootless: RootlessEnsureFrame: Added check for !IsRoot XQuartz: Converted interface to nib 3.x format XQuartz: Added option for setting quartz-wm click-through preference XQuartz: Fixed layout of Applications->Customize menu XQuartz: Fixed EXTRA_DIST to include localization Fixed unescaped newline in EXTRA_DIST Ad...

So I've been using LLVM for about 4 years now, and I've posted a lot on this list about specific issues. What I would like to do is step back for a moment and give my "big picture" assessment of LLVM overall, particularly with respect to developing a "managed" language like Java / C# or my own language, Tart. Obviously, I feel that LLVM is the best choice out there,