search for: substructures

https://bugzilla.samba.org/show_bug.cgi?id=9670 Summary: missing substructure within partial-dir causes files to be lost or overwritten Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: core AssignedTo: wayned at

Hi Spencer, I have seen your name on the web site, and perhaps you can help me with my R problem. I'm trying to use KernSur to put in evidence a substructure in a bidimensional plot. My problem is that, in order to get the density in the low density areas (in which the substructure is located) I should use different bandwidths. How I can do that? Also, I think that the best choice for my

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This

Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions,

Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions,

I've read in many places that R semantics are based on Scheme semantics. As a long-time Lisp user and implementor, I've tried to make this more precise, and this is what I've found so far. I've excluded trivial things that aren't basic semantic issues: support for arbitrary-precision integers; subscripting; general style; etc. I would appreciate corrections or additions from

Many of our pointers point into a structure where they could be considered as having the same base address. We use tbaa to indicate which ones could or could not alias because they are pointing into different substructures. This is exactly the sort of requirement that invoked the need for the restrict modifier in g++, c++0x etc. If I understand you correctly that cannot be expressed in llvm ir because it would be overridden by basicaa being conservative, overriding the explicit metadata. Is that true? It does make...

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

...3, "C::b2", metadata !3, "C::p", metadata !2} > where !3 is the struct node for "B", !2 is pointer type. > > Given a field access > struct B *bp = ...; > bp->a.x = 5; > we annotate it as B::a.x. In the case of multiple structures containing substructures, how are you differentiating? IE given struct A { struct B b; } struct C { struct B b; } How do you know the above struct B *bp =...; is B::b from C and not B::b from A? (I agree you can know in the case of direct aggregates, but I argue you have no way to know in the case of pointer arguments...

..., 2012 at 10:46 AM, Maurice Marks <maurice.marks at gmail.com>wrote: > Many of our pointers point into a structure where they could be considered > as having the same base address. We use tbaa to indicate which ones could > or could not alias because they are pointing into different substructures. > This is exactly the sort of requirement that invoked the need for the > restrict modifier in g++, c++0x etc. If I understand you correctly that > cannot be expressed in llvm ir because it would be overridden by basicaa > being conservative, overriding the explicit metadata. Is that t...

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

...3, "C::p", metadata !2} >> where !3 is the struct node for "B", !2 is pointer type. >> >> Given a field access >> struct B *bp = ...; >> bp->a.x = 5; >> we annotate it as B::a.x. > > In the case of multiple structures containing substructures, how are > you differentiating? > > IE given > > struct A { > struct B b; > } > struct C { > struct B b; > } > > How do you know the above struct B *bp =...; is B::b from C and not B::b from A? > > (I agree you can know in the case of direct aggregates,...

...!3, "C::p", metadata !2} >> where !3 is the struct node for "B", !2 is pointer type. >> >> Given a field access >> struct B *bp = ...; >> bp->a.x = 5; >> we annotate it as B::a.x. > In the case of multiple structures containing substructures, how are > you differentiating? > > IE given > > struct A { > struct B b; > } > struct C { > struct B b; > } > > How do you know the above struct B *bp =...; is B::b from C and not B::b from A? If I understand correct, the proposed graph is DAG, not tree, and it...

Based on discussions with John McCall We currently focus on field accesses of structs, more specifically, on fields that are scalars or structs. Fundamental rules from C11 -------------------------- An object shall have its stored value accessed only by an lvalue expression that has one of the following types: [footnote: The intent of this list is to specify those circumstances in which an

...is the struct node for "B", !2 is pointer type. >>>> >>>> Given a field access >>>> struct B *bp = ...; >>>> bp->a.x = 5; >>>> we annotate it as B::a.x. >>> >>> In the case of multiple structures containing substructures, how are >>> you differentiating? >>> >>> IE given >>> >>> struct A { >>> struct B b; >>> } >>> struct C { >>> struct B b; >>> } >>> >>> How do you know the above struct B *bp =...; is B::...