search for: irreconcilably

Hi Kostya, So... a bunch of folks (not all CC'd - feel free to add anyone who seems relevant, I haven't gone back over the commits to check who's made what changes) have been making improvements to optimized code debug information - much of it around making sure sample profiles are accurate. This mostly entails removing debug locations from instructions that are moved between basic

Hi Folks, I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say

I am trying to build libguestfs version libguestfs-1.18.11 in my archlinux box i am getting this error: febootstrap: error: /lib appears as both directory and ordinary file (glibc, ntfs-3g) make[2]: *** [stamp-supermin] Error 1 make[2]: Leaving directory `/mnt/downloads/dnl/PKGBUILDs/kvm/libguestfs/src/libguestfs-1.18.11/appliance' make[1]: *** [all-recursive] Error 1 make[1]: Leaving

Jim Grosbach wrote: > Hi Ali, > > Thanks for bringing this up. You're definitely under very tight design > constraints from the hardware. I can certainly sympathize. Jim, First of all, thank you very much for understanding every detail of the problem at our hand and coming up with a solution that addresses every aspect of it. IMO, given the constraints, this is probably the best

As many of you know, when a piece of open-source software languishes with bugs for 3 years it's often forked Markdown.pl is licensed under the BSD license. (do `>tail -35 /path/to/Markdown.pl`) Has anyone thought of forking and maintaining Markdown.pl (hopefully with Gruber's blessing) to fix some of the known bugs? I'm not volunteering (I'd be horrible)... just seeing if

> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Folks, > > I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working

Hi Ali, Thanks for bringing this up. You're definitely under very tight design constraints from the hardware. I can certainly sympathize. I think two design elements are being conflated here, and it would be worthwhile splitting them out. For correctness, you need to make sure any routines called from an ISR don't clobber equivalent routines called from mainline code. For

Dear, is any way to change , the size of voice packets? I want to increase the quality by decreasing the size of each packets, because of bandwidth failure. ? thanks in advance Mani -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081110/c1b2ed9d/attachment.htm

Up front I apologize for the lengthy email. Since our patch was not accepted, Chris asked us to follow up with this issue on llvm-dev. For the sake of completeness, let me give a bit of background and the problems that we are facing. I tried to capture as much as possible here so Please do give us feedback. Don't take your stack for granted.... PIC16 has very poor pointer handling, hence

> On Jun 14, 2017, at 2:47 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 15 Jun 2017, at 6:50 AM, Louis Gerbarg <lgerbarg at apple.com <mailto:lgerbarg at apple.com>> wrote: >> >>> >>> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Extended thanks to the llvm community for feedback in advance, and especially thanks to Jim for laying out a solution that captures all aspects of the problems that we are facing. After some discussions with our team, we have decided to do the following, but to avoid further conflict with llvm standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

On 5 May 2016, at 12:14, Charles Davis via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The last sentence of the third paragraph bothers me: > >> In addition, violations of this code outside these spaces may affect >> a person's ability to participate within them. > ​This essentially gives the committee carte blanche to police our thoughts no matter where we

Hello everyone, This email is a continuation of a discussion started in October 2015, and continued in September 2016: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html As with those emails, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be