search for: codereviews

Hi, I uploaded a patch for the "*Kind enum" rule to http://codereview.appspot.com/3402041 and attached it to this message too. Would you please take a look? Thanks, On Wed, Dec 1, 2010 at 9:19 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > Thanks, Chris and John.  Committed in r120689.  I'll try to add the > *Kind rule in a separate patch.  Cheers, > >

On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > Hi Chris, > > I've uploaded a new patch to http://codereview.appspot.com/3264041. > It's also attached to this message. This patch looks great to me, please apply, thanks! > I think I've addressed all your comments, except "when in doubt, an > enum should be a 'Kind'". I don't

On Dec 1, 2010, at 9:32 PM, Zhanyong Wan (λx.x x) wrote: > Hi, > > I uploaded a patch for the "*Kind enum" rule to > > http://codereview.appspot.com/3402041 > > and attached it to this message too. Would you please take a look? Thanks, Applied, thanks! After applying it, I went through and restructured the section for readability:

Hello Opus community, I'd like to ask you for advice and recommendations. WebRTC uses Opus, and I noticed https://webrtc-codereview.appspot.com/5549004 started referring to currently internal Opus headers. This is possible because for Chromium the Opus sources are just checked in, so any header can be #included. I detected this when trying to package Chromium for Linux distributions with

Here's a (more) proper patch for getting the tests to run on windows. With this only ~250 tests Unexpected Fail. I just need someone to make sure it doesn't break anything on other platforms. It feels kind of hacky, and I would appreciate any ideas on improvements. http://codereview.appspot.com/1657041/show - Michael Spencer

Thanks, Chris and John. Committed in r120689. I'll try to add the *Kind rule in a separate patch. Cheers, On Wed, Dec 1, 2010 at 5:18 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi Chris, >> >> I've uploaded a new patch to http://codereview.appspot.com/3264041. >> It's

Hi! Currently Clang "-g" flag emits full debug info, which is fine for debugging, but increases the binary size significantly. It may be useful to produce less debug info, that is still enough for collecting nice stack traces with file names and line numbers, but would introduce less overhead. Cary Coutant made a patch which does this for GCC (it didn't hit trunk yet) - reduces

On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > +llvmdev > > Thanks for the comments, Chris. > > On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: >> >>> Hi guys, >>> >>> Based on our discussion

Hi, all, Does Opus need celt_pitch_xcorr' s fixed point version for ARM aarch64 architecture? If yes, which version does Opus prefer: assembly or instrinsics? Thanks, Zhongwei -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the

Hi Chris, I've uploaded a new patch to http://codereview.appspot.com/3264041. It's also attached to this message. I think I've addressed all your comments, except "when in doubt, an enum should be a 'Kind'". I don't think I fully understand that point, and it strikes me as a bit ad hoc for the coding standards. Do we really want it? If you feel that's

Here''s my comments for the preliminary ZFS Crypto review. - Dan Webrev: http://cr.opensolaris.org/~darrenm/zfs-crypto-gate/webrev/ General comments: DEA-1 - SCCS keywords need to be removed DEA-2 - Copyright updated ------------------------------------------------------------------ usr/src/lib/libcryptoutil/common/keyfile.c pkcs11_read_data() This code in pkcs11_read_data() scares

On Apr 5, 2012, at 10:24 AM, Alexey Samsonov <samsonov at google.com> wrote: > Hi! > > Currently Clang "-g" flag emits full debug info, which is fine for debugging, but increases the binary size significantly. > It may be useful to produce less debug info, that is still enough for collecting nice stack traces with file names and line numbers, > but would introduce

On Thu, Apr 29, 2010 at 6:31 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Wed, Apr 28, 2010 at 10:48 AM, Yuri <yuri at tsoft.com> wrote: >> Jeffrey Yasskin wrote: >>> >>> We currently use two different techniques to get whole libraries >>> included into the .so. On Linux (gnu ld and gold), we pass >>> --whole-archive, while on

+llvmdev Thanks for the comments, Chris. On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi guys, >> >> Based on our discussion last week, I put together a new coding style >> rule regarding the naming of types/functions/variables.  I've uploaded >>

Hi Alex, Hi Weft-Users! I am looking for a tool for doing a qualitative analysis of mailing-list data. This means I have a *lot* of individual documents (the typical case: around 500-5000 emails), belonging to the same "super-document" (a mailing list). I have looked at several tools and I like that Weft is public domain and written in Ruby, so I want to figure out whether it

>> That makes four optional arguments to ExecutionEngine::create.  Do you >> mind if I go ahead and add an EngineBuilder? > > Please, thanks. This turned out to be somewhat involved and should probably be a separate patch. I started it, so I'll send it along later. The patch I'd like to submit now is attached and linked. http://codereview.appspot.com/90053/show Reid

Looks fine to me. Thanks. Can you commit it? Evan On Jul 6, 2009, at 4:28 PM, Reid Kleckner wrote: >>> That makes four optional arguments to ExecutionEngine::create. Do >>> you >>> mind if I go ahead and add an EngineBuilder? >> >> Please, thanks. > > This turned out to be somewhat involved and should probably be a > separate patch. I started

On Wed, Apr 28, 2010 at 10:48 AM, Yuri <yuri at tsoft.com> wrote: > Jeffrey Yasskin wrote: >> >> We currently use two different techniques to get whole libraries >> included into the .so. On Linux (gnu ld and gold), we pass >> --whole-archive, while on OSX we pass -all_load. Which ld does FreeBSD >> use? If you can rearrange tools/llvm-shlib/Makefile until it

I can't say anything about the logic as I don't know the testing framework, but in places where path separator conversion, python has specialized versions of its path handling for different platforms. os.path.normalize would convert all path separators to the platform default os.ntpath.normalize would convert all path separators to back-slashes os.posixpath.normalize would convert all

Hi Chris, I was reading the LLVM coding standards and noticed some typos & formatting nits. Please see http://codereview.appspot.com/3127041 for my proposed fix. Most of changes are local and cosmetic. The only bigger change I made is to group the sections about iostream and raw_ostream together, as they are logically related. I had to edit the text a little bit after the move, in order