Displaying 8 results from an estimated 8 matches for "rentzsch".
2007 Jan 13
3
duplicate definition when inheriting classes
I thought the purpose of classes was that you could redefine types in
the subclasses. However I get "Duplicate definition" errors whenever I
attempt this. On a whim I tried the code from the documentation:
http://reductivelabs.com/projects/puppet/documentation/structures.html
---
Subclassing
The primary benefit of using subclasses instead of just including the
parent class is that
2011 Oct 20
6
maybe a year ago, but not today
sherwood said:
> If agreement is reached, then the group
> looks at variants 6,7,8,9 and inquires
> if they would like to join in this effort.
well, that kind of leveraged consensus would have
been the way to go about this process a year ago.
but not today.
> Has anyone collected a would-be canonical list
> of either the ambiguous cases in original MD,
>
2012 Nov 30
2
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
...an to stop using mach_override in
> asanin favor of OSX's native function interposition.
> So, we probably don't want to spend too much effort fixing mach_override.
>
> --kcc
Kostya,
Is the native function interposition that is being adopted based on...
https://github.com/rentzsch/mach_inject
? I assume that any method used will be transparent to the user and not require
manually setting DYLD_INSERT_LIBRARIES, correct?
Jack
>
> On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote:
>
> > Looks like this happens on...
2012 Nov 30
1
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
...> asanin favor of OSX's native function interposition.
>> So, we probably don't want to spend too much effort fixing mach_override.
>>
>> --kcc
>
> Kostya,
> Is the native function interposition that is being adopted based on...
>
> https://github.com/rentzsch/mach_inject
>
> ? I assume that any method used will be transparent to the user and not require
> manually setting DYLD_INSERT_LIBRARIES, correct?
> Jack
>
>>
>> On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote:
>>
>...
2007 Apr 03
11
RFC: Building a Development Process
Hi all,
I''m trying to work more on the development page[1], and I''m having
some trouble. It''s not really with the page per se, but rather with
trying to get a handle on Puppet''s development process.
Currently, my development work has focused on generally short-term
goals: Fixing known bugs, providing features that clients have paid
for, or providing
2007 Sep 04
16
REST/XMLRPC backward compatibility?
Hi all,
I''m in the throes of the REST conversion and I''m wondering: How
important is it to retain backward compatibility? The language will
clearly be consistent between the two, but it looks like it''s going
to be a heckuva lot more complicated to keep compatibility for all
network services (as in, for each of them, I''ll have to write a shell
that
2012 Nov 30
3
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Looks like this happens on x86_64 because the position of __cxa_throw
is too far from the allocated branch island (should be <2G). This can
be solved by allocating the branch islands somewhere near the text
segment (look for kIslandEnd in asan_mac.cc, this is currently
0x7fffffdf0000) or by patching the function with a longer instruction
sequence that stores the jump target in a register and
2012 Nov 30
0
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Just want to remind everyone that we plan to stop using mach_override in
asanin favor of OSX's native function interposition.
So, we probably don't want to spend too much effort fixing mach_override.
--kcc
On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote:
> Looks like this happens on x86_64 because the position of __cxa_throw
> is too far from