search for: codereview

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....

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 think I fully understand that > point...

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: http://llvm.org/docs/CodingStandards.html#ll_naming -Chris > > On Wed, Dec 1, 2010...

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 using the system-provided Opus package....

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

...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 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 think I fully u...

...xtern variables, line number tables and inlined subroutine info by setting "-gmlt" ("minimum line table") or "-g1" flags. (See this patch at http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html or http://codereview.appspot.com/4440072). This patch is used in Google for about 2 years already. I get the following binary sizes of 483.xalancbmk benchmark from SPEC 2006 (clang from trunk vs. gcc 4.6.x with Google patches): 11026073 Xalan_base.clang_O0 45882529 Xalan_base.clang_O0_g 11079688 Xalan_base.gcc_O0 1643...

...anyong 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 >>> the patch to >>> >>> http://codereview.appspot.com/3264041 >>> >>> Please let me know what you think.  My idea is to start with something >>> non-controversial such that we can get the baseline committed soon. >>> We can then tweak the rule as needed later to cover more specific >>> scenarios...

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 real...

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

..., line number tables and inlined subroutine info > by setting "-gmlt" ("minimum line table") or "-g1" flags. > (See this patch at http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html > or http://codereview.appspot.com/4440072). This patch is used in Google for about 2 years already. > > I get the following binary sizes of 483.xalancbmk benchmark from SPEC 2006 (clang from trunk vs. gcc 4.6.x with Google patches): > 11026073 Xalan_base.clang_O0 > 45882529 Xalan_base.clang_O0_g > 110796...

...you can rearrange tools/llvm-shlib/Makefile until it works for >>> you and send us a patch, we can probably get it working for llvm-2.8. >>> >> >> >> ld on FreeBSD is from binutils. It takes --whole-archive option. > > Would you try the patch at > http://codereview.appspot.com/download/issue968046_1.diff? It should > make the BSDs fall into the same path as Linux, and since you use gnu > ld, that should work for you. Ping?

...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 >> the patch to >> >> http://codereview.appspot.com/3264041 >> >> Please let me know what you think.  My idea is to start with something >> non-controversial such that we can get the baseline committed soon. >> We can then tweak the rule as needed later to cover more specific >> scenarios.  Thanks, > >...

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

...ine::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 -------------- next part -------------- A non-text attachment was scrubbed... Name: issue90053_2001.diff Type: text/x-diff Size: 26719 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090706/6c790172/attachment.diff>

...nd 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 > <issue90053_2001.diff>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...ld does FreeBSD >> use? If you can rearrange tools/llvm-shlib/Makefile until it works for >> you and send us a patch, we can probably get it working for llvm-2.8. >> > > > ld on FreeBSD is from binutils. It takes --whole-archive option. Would you try the patch at http://codereview.appspot.com/download/issue968046_1.diff? It should make the BSDs fall into the same path as Linux, and since you use gnu ld, that should work for you. > But command > line needs to be changed: actual archive files should be supplied, not just > -lXXX. I believe that will fix the problem....

...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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100611/d388a5ad/attachment.html>

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 to reduce the repetition....