[chromium-dev] Re: SSLClientSocket, TCPClientSocket design choices on linux
>> Happily, Howard Chu recently posted a partial >> example of how to do the latter, >> http://groups.google.com/group/mozilla.dev.tech.crypto/msg/af4b5b6c71b70702 >> >> I think the next step might be for me to write an >> app demonstrating how to handle 500 >> simultanous ssl connections using nss and libevent. > > Above you wrote "epoll" but here you write "libevent". Do you have a > preference? > If you want libevent, might I suggest libev > (http://software.schmorp.de/pkg/libev.html)? It's based on libevent > but without the obnoxious advertising clause. But any extra library > dependency brings us again to the 64/32-bit library distribution > issues that have been super-annoying. libevent is licensed under the 3-clause BSD. I don't see the harmful 4th clause in either the main page or the explicit license file: http://monkey.org/~provos/libevent/ http://monkey.org/~provos/libevent/LICENSE -- Elliot --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Current line number from within a CALLBACK_FUNC_DECL?
[Resending and forwarding since google groups doesn't like my
google.com address:]
Feng (or another v8 expert):
Is there any way to get the current line number of an executing
javascript from within a C++ custom callback?
With JSC, you can get this information from the ExecState object with
exec->machine()->retrieveLastCaller(...), which pass back a bunch of
information about the calling context, including the line number of
the calling script, the url of the script file and the calling
function. I can't find any equivalent to get the line number from
within V8.
I need this piece of information for writing the callbacks for the
console functions. The current chrome build just has each
console.{debug,error,info,log} message say that it occurred on line 0.
My current patch to the webkit merge branch follows this precedent,
but I'm wondering if there's anything I can do so that we pass the
layout test which has the proper line numbers in it.
-- Elliot
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] LayoutTests results under Linux
The Linux team now has the entire LayoutTests running from start to
finish...and we don't do half bad for a first pass:
=> Tests we want to pass (10186):
4595 test cases (45.1%) Passed
5415 test cases (53.2%) Text diff mismatch
1820 test cases (17.9%) Simplified text diff mismatch
130 test cases (1.3%) Test timed out
24 test cases (0.2%) Test shell crashed
22 test cases (0.2%) No expected results found
=> All tests (10186):
4595 test cases (45.1%) Passed
5415 test cases (53.2%) Text diff mismatch
1820 test cases (17.9%) Simplified text diff mismatch
130 test cases (1.3%) Test timed out
24 test cases (0.2%) Test shell crashed
22 test cases (0.2%) No expected results found
(Note: Running the layout tests currently requires changelist 11455,
reapplying mmoss's revision 5567 which added lighthttpd binaries, and
commenting out some cygwin specific stuff in http_server.py,
specifically, the line "env['PATH'] = '%s;%s' %
(PathFromBase('third_party', 'cygwin', 'bin'), env['PATH'])". I'm
going to work on getting everything working out of trunk on an
unmodified build next.)
-- Elliot Glaysher
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
[chromium-dev] Re: The review tool
No, Dean is very much correct. "git cl upload" will upload your patch to the review server and will accept git-diff style arguments (including diffing against a sha1) or will build a patch going back to origin/trunk. It will also store the code review issue number and associate it with your current branch, allowing multiple uploads to the same code review issue. (git cl dcommit will also close your code review in addition to doing the associated git svn dcommit...) > Unless there is a new addition[...] git cl upload dates back to the very beginning of the git-cl tool. > Clearly you didn't even bother reading my e-mail (I know it was really > long and all) This was entirely unnecessary and inflammatory. -- Elliot On Thu, Dec 4, 2008 at 3:49 PM, Benjamin <[EMAIL PROTECTED]> wrote: > > Clearly you didn't even bother reading my e-mail (I know it was really > long and all) otherwise you would have noticed my one example of the > usage of my script. Here it is again: > > upload-git-patch sha1 > > Unless there is a new addition, last I checked you could not run > 'git-cl sha1' to upload a new patch for review. > > On Thu, Dec 4, 2008 at 3:40 PM, Dean McNamee <[EMAIL PROTECTED]> wrote: >> >> This is exactly what git-cl does. It's what we use, and probably the >> only thing we'll support if we ever "support" git. >> >> On Thu, Dec 4, 2008 at 4:50 PM, Benjamin <[EMAIL PROTECTED]> wrote: >>> >>> I have also written a tool that will upload a git patch. So this way >>> you can have as many branches as you want and commit whenever you want >>> and when you are ready you can just run >>> >>> upload-git-patch sha1 >>> >>> and it will upload that patch using the already committed description. >>> This allows for things like local git hooks, not having to wait on >>> reviews etc. >>> >>> http://github.com/icefox/chromium_tools/tree >>> >>> -Benjamin Meyer >>> >>> On Thu, Dec 4, 2008 at 7:14 AM, Dean McNamee <[EMAIL PROTECTED]> wrote: Several of us are already using git. Specifically the Linux developers are pretty much exclusively using git. There is an overview of how you might do it here: http://dev.chromium.org/developers/how-tos/using-git Small correction, we don't use gcl at all when using git, we have a replacement for uploading to Rietveld, called git-cl. On Thu, Dec 4, 2008 at 6:31 AM, Ben Goodger (Google) <[EMAIL PROTECTED]> wrote: > > It's possible to use git with our existing infrastructure before you > reach the commit to main-line gate. Evan has some scripts that make > using gcl easier. > > However we've not discussed converting wholesale seriously since our > infrastructure as a whole is tied to svn and it's not trivial (or > productive) for us to spend a lot of time on something that is mostly > working right now. > > -Ben > > On Wed, Dec 3, 2008 at 8:32 PM, Benjamin <[EMAIL PROTECTED]> wrote: >> >> Any thoughts on moving to git like the android webkit guys are? I >> have been using git on windows for about a month now and was expecting >> it to be absolutely horrible from what everyone said, but found it >> worked just fine and didn't find anything that got in my way. >> >> -Benjamin Meyer >> >> On Wed, Dec 3, 2008 at 12:25 AM, Ben Goodger (Google) <[EMAIL >> PROTECTED]> wrote: >>> >>> Google Code's review tool doesn't support flows that require review >>> before commit or our gcl changelist management script which are both >>> integral part of the Chromium project development flow. >>> >>> -Ben >>> >>> On Tue, Dec 2, 2008 at 8:50 PM, empriser <[EMAIL PROTECTED]> wrote: Hello, The current review tool has not search opinion, It is unconvinient. Why do not use the Google code's review tool ? Yours sincerely, Jack 2008-12-03 > >>> >>> > >>> >> >> > >> > > > > > >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test result scores don't match up?
I added support for making score.txt a few weeks ago. score.txt is generated by passing a file stream to the same function that outputs to the console instead of passing in stdout. Everything should be the same unless the printing code has side effects. -- Elliot On Fri, Dec 12, 2008 at 9:26 AM, Erik Kay wrote: > > On Fri, Dec 12, 2008 at 9:10 AM, Mike Pinkerton > wrote: >> I noticed today that the numbers in score.txt don't match the same >> results dumped to stdout at the end of running the layout tests. eg: > > How is score.txt generated? I recently made a change to > run_webkit_tests.py that prints out an additional number in the > summary (the total number of tests in the system, prior to any > filtering or skipping). It prints it out differently, but it's the > new first number that's printed out, so if the script that creates > score doesn't have a good pattern match, it would pick up the wrong > number. > > Erik > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] cpplint.py open sourced!
Background: For the last couple of months, there have been requests from external contributors for a style linting tool. I've just finish cleaning Google's cpplint.py up for public release. cpplint.py takes file names as input and returns file/line number pairs with error messages about style violations. By default it outputs in a format friendly to emacs compile-mode, but can output Visual Studio compatible errors with the "--output=vs7" option. See cpplint.py --help for more details. cpplint.py is not perfect as it is based on regular expressions--thus it won't catch everything and will have the occasional false positive. John is planning on integrating this directly with gcl, but if you want to run it right now, the python script is available at: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py For those who are interested, I've also released Google's indentation rules for emacs: http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Fwd: [chromium-dev] Re: Why do you use SCONS ?
> Usually Open Source projects use CMake Construction Tool Kit. Off the top of my head, KDE 4.x is the only project I know of that uses CMake, (which is different from the old unix make). >From your first email: > Usually, Open Source projects use Make. Very few open source projects use unix make exclusively because Makefiles aren't sufficiently powerful to do much of anything. Without massive, ugly hacks you can't get things like proper dependency checking. Most open source projects don't use make, but the full GNU autotools/autoconf/m4/libtool/make toolchain which automatically builds unix Makefiles from a set of simpler input scripts. Much has been written about autotools's shortcomings, so I'll just say that autotools is not a good solution, and for larger projects, it often isn't adequate. (See KDE's transition first to SCons, and then to CMake). Things get even worse when you throw windows support into the mix. There is a minority of projects which do use just unix make, but to be portable, they need to distribute a Makefile for each architecture/system combination, which is also not really acceptable. For example, Sleepycat libdb ships with about 50 Makefiles. This is not a solution that scales! make isn't really a good solution which is why there's been an endless procession of build systems to replace it and why each non-C language seems to have its own build system trying to replace or supplement make (OCaml has OMake, Haskell has hmake, perl has a module that spits out complex Makefiles, python has its own build system for modules and SCons, ruby has rake (among others), java has ant (among others), and there's jam (and a bunch of jam derivatives) in the C++ space). > Only www.scons.org has a comparison table .. but obviously it is'nt > fair. Really? I found both the feature list on the scons homepage and their dedicated comparisson page ( http://scons.org/wiki/SconsVsOtherBuildTools ) to be pretty fair, listing both the pros and the cons of each system. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Why do you use SCONS ?
> So, how do SCons improve the dependency checking and the > autoconfiguration? This is a totally different issue. When I'm talking about dependency checking, I'm talking about dependencies between files in the source. So let's say I change a header file, and three .cc files #include it. SCons will rebuild those three cc files automatically because scons has machinery to check what files a C++ file depends on by reading the actual source/header files (and allows you to write your own scanners for your own file types). Like Makefiles, you can manually specify dependencies in your SConscript if you want, but except for custom build steps, it's easier and more accurate to let scons figure all the dependency stuff out for you. The upside to this is that I almost never "make clean". I don't have to. SCons figures what needs rebuilding on its own so I don't get left with incomplete or corrupted builds. Since it's built into scons, it's not as fragile as "make depend" which I've seen break in some very weird ways... > I saw that some SConscript (see src/build/SConscript.main) uses pkg- > config to get rigth package configuration (for compilation, and > linking). > [...] I've gushed a bit about scons. Let's turn to the downsides: I would argue that SCons Achilles' heel would be it's checking of packages and properties of the host system. It's "./configure" equivalent is nowhere near as robust as autoconf, though I personally feel that the ease of use is a valid trade off. Also: speed. All the file scanning for dependencies slows scons down a bit. (Among other things). I think that it's overall a net time win compared to having weird crashes that go away with a full rebuild, but that's a personal opinion. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: linux: the views situation
On Thu, Jan 29, 2009 at 12:10 PM, Paweł Prażak wrote: > I'd really like to help you in some way, (unfortunately I don't have > years of experience in C++ :/ ) and I'd like to try play chromium > code, and try to make a Qt based test-shell, I know it's probably too > difficult for me to do it off hand, but I really would like to try. > So could you give me any hints on where to start? (I'm reading > documentation and code but it's huge and maybe it would be easier to > know where to start) I was thinking of merging somehow QtWebkit port > with chromium or something like that, and thy to run/port QtWebKit > simle demo/test browser. This will be difficult, but it may be possible: - You will need to port the message pump in base/. This means writing a version of what would happen if you were to call QApplication::exec(). Too much of our code requires our own custom message loop and some of the threading support it has. You might want to get this part down before anything else because I have vague memories of not being able to re-implement the main Qt runloop on one of my side projects. - You will need to modify all of the Qt widget rendering code to draw into a skia buffer. I don't know how difficult this is in Qt. Webkit renders the webpage into this buffer, along with native widgets for the form controls. (So add grabbing the Qt parts of webkit and forking them for Chromium). - The following files came up on a grep of the source tree for gtk and looked particularly relevant: -- base/clipboard_linux.cc -- chrome/common/gfx/chrome_font_gtk.cc -- webkit/glue/webcursor_gtk.cc -- webkit/glue/webkit_glue_gtk.cc -- webkit/tools/test_shell/test_shell_gtk.cc -- webkit/tools/test_shell/test_shell_main.cc -- webkit/tools/test_shell/test_webview_delegate_gtk.cc -- webkit/tools/test_shell/webwidget_host_gtk.cc Again, difficult, but if you can get the message pump working, probably doable. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts regarding exposing --single-process, in-process-plugins in release builds
+1. We absolutely should do this. -- Elliot On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek wrote: > I was looking at the second top crasher in 2.0.166.1, and it turned out that > these users are running with --in-process-plugins. This turns off the > sandbox and runs plugins in the renderer process. > So far we've exposed all the internal command line switches to all users, > but I'm wondering if that has outlived its usefulness. We don't test either > mode on chromebot, while in-process-plugins doesn't even have any tests. I > don't think spending much development time on these modes is worth the > opportunity cost. > The flip side is in the past they have been useful to have around, i.e. when > someone complains about a bug, we sometimes ask them to try these modes. > So I propose that we disable these flags in release builds, and if we want > to test on users, we can point them towards debug builds off the build > server. Obviously this is more work for them, but I think this avoids > distracting us with looking at modes that are only used by a minority of > users, and which we know are already broken. The bigger issue is why these > users used those modes. I think in the past we might have suggested it to > people if they had performance problems etc, but hopefully these are taken > care of by now, and if not, better to know it anyways by having these users > use the standard multi-process mode. > Any strong opposition to this? > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changing default compile for Chrome Linux build?
I have "CC=distcc gcc" and "CXX=distcc g++" in my bashrc file, so yes. -- Elliot On Wed, Apr 1, 2009 at 11:59 PM, QAH wrote: > > Hello everyone! I am building the source code of chrome for linux, and > I know that it uses gcc and g++. Since chrome is such a big build > though and I have 3 computers, I wanted to use distcc to allow all 3 > computers to compile chrome and make the build much faster. Is it > possible to change the compiler to distcc? Please let me know. > > Thanks > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebContents is dead, long live TabContents!
Congrts, Brett! -- Erg. On Fri, Apr 24, 2009 at 9:15 AM, Erik Kay wrote: > > woot! > > On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson wrote: >> >> I just moved the remaining methods from WebContents to TabContents. I >> kept the methods and data members the same, just merged the classes, >> so it should be easy to find what you're looking for (or to resolve >> conflicts if you have local changes to web_contents.cc). Hopefully >> this will make the complexity in this area much more manageable. >> >> We still have a shell class called WebContents (derived from >> TabContents) and references to it, which are temporary so I don't have >> to immediately change all references to it. It will hopefully soon go >> away. >> >> >> FAQ: Why did we do this? >> >> Chromium 1 used a variety of specialized tab contents types which we >> wrote native interfaces for. This included the history and downloads >> page. TabContents was the base class providing shared functionality >> and an external API, and there were a variety of subclasses for the >> different tab types. WebContents was the TabContents specialization >> for web pages. >> >> There were several problems with this. The original idea is that our >> native UI would be more awesome than a web page could ever be. But it >> turned out to be teh suck because a variety of things didn't work >> (find in page, printing, selection) and because we didn't end up doing >> anything fancy in there anyway. With native UI, we would have to write >> it again for every platform, which nobody was excited about doing. >> There were also very difficult bugs associated with switching tab >> contents types. For example, in Chromium 1, if you go to the history >> page, navigate to a regular web page, go back, then navigate to a >> different regular web page, you would see a flash of the first web >> page during the second transition. This was the tab contents types >> being switched between a HistoryContents and a previously-used >> WebContents. >> >> So now we only display web pages inside tabs. This makes the switching >> problem go away. Glen rewrote history and downloads we be special web >> pages with additional permissions, and I did a whole heckuva lof of >> refactoring to delete all the old TabContents switching. We still swap >> RenderViewHosts inside the TabContents when we need to switch >> processes. >> >> Brett >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: POSIX: EINTR correctness
On Fri, May 1, 2009 at 1:07 PM, Adam Barth wrote: > Wow, that's pretty deep magic. > >> And you can use it like: >> HANDLE_EINTR(close(fd)); > > Isn't it disaster if you say: > > HANDLE_EINTR(close(ret)); Yes. Regretfully, C doesn't have hygienic macros. It probably would be a good idea to change "ret" to a name less likely to conflict... -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: DLLs missing and DCHECKs in recent builds
I had to build under Windows for the first time in a month. I too can confirm this. -- Elliot On Wed, Jun 3, 2009 at 8:29 PM, Mohamed Mansour wrote: > Yup, I can confirm. I had to manually build theme_dll or it hits crazy > dchecks across the src. > -- Mohamed Mansour > > > On Wed, Jun 3, 2009 at 1:43 PM, Erik Kay wrote: >> >> I haven't seen anyone else mention this, but I also had to manually >> "rebuild" tcmalloc for my build to succeed, otherwise I'd get: >> LINK : fatal error LNK1181: cannot open input file >> 'E:\src\cr\src\chrome\Debug\obj\tcmalloc\libcmt.lib' >> Erik >> >> On Wed, Jun 3, 2009 at 10:23 AM, Glen Murphy wrote: >>> >>> To add to this - someone else running into this mentioned that they >>> needed to also build chrome_resources to get theme_dll to build. >>> >>> You'll also need to manually build crash_service if you're building >>> any of the tests. >>> >>> On Tue, Jun 2, 2009 at 9:19 PM, Glen Murphy wrote: >>> > I thought it was just me, but I just heard from someone else who hit >>> > this. It appears that a recent change causes a few things to not get >>> > built when you do a clean build, leading to DCHECKs when you try to >>> > run. I believe the GYP team is working on a fix, but in the meantime >>> > you can work around it by manually building chrome/theme_dll and >>> > chrome/app/locales/en-US. >>> > >>> > xox, >>> > Glen >>> > >>> >>> >> >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: New views::Menu API
I wasn't happy doing a direct port of the old Menu to GTK. This sounds a lot better. -- Elliot On Fri, Jun 5, 2009 at 12:34 AM, Ben Goodger (Google) wrote: > > As part of the TOOLKIT_VIEWS work some of the long time deficiencies > of the existing views::Menu API have come to a head. I think it may > finally be time to revisit this. > > The system of menu delegates, controllers, and such like are very > confusing. We have an API that on one hand provides a model-like > interface to a menu item provider, and on the other has methods for > adding menu items directly. It's not very coherent. The original > reason for this conflation was that some menus in Chrome are generated > by data (e.g. bookmarks menus), and some are known beforehand. It's > not impossible however to implement most of the fixed menus in terms > of a model interface... I looked into doing this late last year, but > it turned out there was one other reason for the simple "AddItem" > interface - the Windows system menu. It's not easily possible without > lots of gymnastics to populate this menu with a model interface, so > the views::Menu code which is designed to optionally wrap a system > HMENU retained this awkward interface. > > After some thought I think it would now be best to split off the > Windows system menu handling into something separate in the interests > of having an API that doesn't confuse everyone. > > To start with, I've begun to develop a new API for non-system menus. > I've sketched out a straw man API for a menu model and uploaded it > here: > > http://codereview.chromium.org/119237/patch/1001/1002 > > To make things simpler for fixed menus, an implementation of > Menu2Model would be provided called SimpleMenuModel which would offer > an interface similar to today's Menu API with functions like > AddItemWithLabel, AddSeparator, etc. > > Once this system works, the views::MenuButton would be re-done to use > this and automatically run the associated menu rather than delegating > this responsibility to the weird ViewMenuDelegate interface. > > My plan is to start working on the NativeMenu subclass of Menu2, then > work on transitioning the Page and Wrench menus over to it. This would > be done leaving the existing Menu class in place so conversion can be > done incrementally. Once all users are transitioned, Menu2 would be > renamed Menu. ChromeMenu would then be based on this system also, and > ultimately renamed ViewsMenu. > > Let me know if you think I'm missing anything. > > -Ben > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Build errors with VS2008SP1
Works for me. Synced yesterday. MSVS2005. -- Elliot On Fri, Jun 5, 2009 at 3:58 PM, nakro wrote: > > for chrome_dll.vcproj : > >>tcmalloc.lib(override_functions.obj) : error LNK2005: _malloc already defined >>in libcmt.lib(malloc.obj) > and many others related to libcmt . > > i really want to know if i am the only one getting this > because if so, this means something is very wrong with my config > (i did revert several times already and clobbered my build to no > avail) > > even a simple reply of "works for me" will help me in knowing where > the prob is > thanx > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Memory usage in chrome
On Sun, Jun 21, 2009 at 12:37 AM, n179911 wrote: > There is a test which compares memory usage among rendering engines > http://dotnetperls.com/chrome-memory > > From the site, it shows the maximum memory usage of Chrome is more > than Safari is > 2 times. >From TFA: "Google Chrome posted the highest maximum memory usage ***when all chrome.exe processes were summed***, reaching 1.18 gigabytes, while Firefox posted the lowest maximum memory levels of 327.65 megabytes." [Emphasis mine] Doing any memory test on a multi-process program where naive summation is used will yield inaccurate results. We wrote a blog post about this problem back when we launched in September: http://blog.chromium.org/2008/09/google-chrome-memory-usage-good-and-bad.html (I'm not claiming that Google Chrome uses the least memory; I'm just pointing out that the above experiment's methodology is invalid. Calculating actual memory consumption is really hard.) -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: What's the real reason of giving up Windows 2000 support?
On Tue, Jun 23, 2009 at 8:58 AM, Dan Kegel wrote: > p.s. And OS/2 is right out. And no Amiga port, either. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Memory usage in chrome
Could we stat at memory-model=hight and then change our memory model mid-flight if there are any large, non-chrome, memory hungry processes? -- Elliot On Wed, Jun 24, 2009 at 9:39 AM, Ian Fette wrote: > +1. Most people are not doing compiles, we're trying to say that people live > in the web and in their browser, and that their browser is the primary > application. For me at least, that is true. The browser is the app I use the > most -- the only other app I use regularly is an ssh client, which can > usually fit in memory or get swapped back in much quicker than Chrome. > > 2009/6/23 Peter Kasting >> >> FWIW, I strongly believe we should move the default to >> --memory-model=high. This is what pretty much every other app in the world >> does, and we mostly penalize ourselves when the OS aggressively swaps us out >> for a dumb reason (which yes, Windows does do). >> We have a lot of complaints of "I came back the next hour/day/whatever and >> everything was unresponsive". I don't think our current tradeoff is the >> right one. >> I know Mike wants to be a good citizen and feels like if the OS swapped >> you out it really needed that RAM, but in my own observations of my machine >> the OS swaps for retarded reasons and I gain nothing but headaches. >> PK >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: [webkit-dev] Important change for ports regarding FocusController
Will this let us solve http://crbug.com/1674 ? -- Elliot On Wed, Jul 1, 2009 at 11:53 AM, Peter Kasting wrote: > (Wanted to make sure the right people noticed this) > > -- Forwarded message -- > From: "David Hyatt" > Date: Jul 1, 2009 10:04 AM > Subject: [webkit-dev] Important change for ports regarding FocusController > To: "webkit-...@lists.webkit.org Development" > > In order to get focus memory for tabs working properly, we need a notion of > whether or not the underlying Page is focused. We need this since Web pages > should be able to shift around programmatic focus in background tabs and > have the new focused frame and focused node be remembered if you switch back > to that tab. > > Our current code was relying only on the window being active plus the frame > being focused to decide that it should draw focus rings and blink carets. > However this isn't good enough in the case described above. > > I have just added a new boolean to FocusController that indicates whether or > not the Page is focused. The Mac and Windows ports have been patched to > update the Page focused state properly (I hope). > > Other ports will need to call page->focusController()->setFocused(true) or > setFocused(false) now in order for everything to work properly. > > dave > (hy...@apple.com) > > ___ > webkit-dev mailing list > webkit-...@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Trac
If you're going to point people to the github mirror, could you do a fresh push there? -- Elliot On Thu, Jul 2, 2009 at 10:43 AM, Evan Martin wrote: > > On Thu, Jul 2, 2009 at 10:21 AM, Jeremy Orlow wrote: >> And no, I >> haven't tried git web yet. What's the URL? Is there anything major blocking it from being made external? > > The page people are referring to is cgit running on my desktop, so > yeah, hard to publish to the internet. > It wouldn't be hard to put something similar up on the machine hosting > git.chromium.org. I'm skeptical the git web interfaces are that > useful for us given that so much of our workflow involves svn revision > numbers. On the other hand, they are very fast. > > Here are some other (out of date) mirrors with different ways of viewing: > http://github.com/chromium/chromium/tree/trunk (custom software) > http://repo.or.cz/w/chromium.git (software used: gitweb) > > And here's cgit running on my website: > http://neugierig.org/software/git/?url=chromium/ > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Updating Rietveld by replying to codereview emails
This is the best news I've heard in the last week. Thank you, Thank you, Thank you. -- Elliot On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek wrote: > Just a heads up that you can now reply to code review emails and your reply > will show up on Rietveld. > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: applying Rietveld issue patches from the command-line
If you are using git-cl: git cl patch On Tue, Jul 7, 2009 at 4:46 PM, Marshall Greenblatt wrote: > Hi All, > > What is the best way to apply Rietveld issue patches from the command-line? > I've found WebKit's nifty "svn-apply" script that does 3-way diffs including > directory changes for patches in both svn and git syntax: > > http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/svn-apply > > Using a tool like this couldn't we add a "gclient apply" command with a > minimal amount of effort? > > gclient apply --issue= > > This command would download the unified diff for the specified issue from > Rietveld and apply it to the working copy using a script like svn-apply. > > - Marshall > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linking with custom fontconfig
On Wed, Jul 8, 2009 at 4:22 PM, Paweł Hajdan Jr. wrote: > It says "no symbols". :-/ > > Do you have an idea how can I get them? When you're building fontconfig, you're building it with no optimization and "-g" for debugging symbols, right? -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Clobber time?
I am landing a GRD change. You may need to clobber. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Reusing chromium code
Google testing and logging libraries are already separate projects: http://code.google.com/p/googletest/ http://code.google.com/p/googlemock/ http://code.google.com/p/google-glog/ A lot of the rest of stuff in base/ isn't, though. -- Elliot On Sun, Jul 19, 2009 at 6:46 AM, Igor Gatis wrote: > > Chromium has lots of interesting base APIs such as the ones found > under base/ and testing/. Is there any chance these two could be > available as a separate library? It would be great if I could use such > library in my own projects. > > Thanks, > -Gatis > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
+1 to this idea. Close the tree, only fixes can get in. -- Elliot On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegel wrote: > > Despite having had several valgrind/purify fixit weeks, > our bug tracker is still full of 'em. > > It might be a mistake to expect people to > get exicited about combing through a dusty > bug database. How about we tap in to the > adrenalin rush of a red tree instead? > > i.e. Next time we hold a valgrind fixit, > how about we just delete the non-upstream-bugs > suppressions files? The waterfall will turn > a lovely shade of red, and people will go into > action in their usual rapid way. > > (We'd still need to publicize it ahead of > time, and make sure people were set up > with valgrind properly, but that goes without saying.) > - Dan > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 10:25 AM, JT Olds wrote: > It's a shame this is what is left on the table, but hooray for git-svn! FYI: don't use git-svn. We have a dedicated git mirror that you can clone and fetch from. Much, much faster. http://code.google.com/p/chromium/wiki/UsingGit -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Creating a SkBitmap filled with one color
See what I do in GtkThemeProvider::LoadThemeBitmap: SkBitmap* bitmap = new SkBitmap; bitmap->setConfig(SkBitmap::kARGB__Config, kToolbarImageWidth, kToolbarImageHeight); bitmap->allocPixels(); bitmap->eraseRGB(color->red >> 8, color->green >> 8, color->blue >> 8); return bitmap; -- Elliot On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan Jr. wrote: > How do I create a SkBitmap of arbitrary size, filled with color of my choice > (on Linux)? > I'd need that for Linux extension shelf, and the Windows code for that seems > not easily portable to Linux. > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about PackageManager's queryIntentActivities() method
There is no class in the chrome codebase called "Intent" or
"PackageManager". Is this a chrome question?
On Wed, Sep 2, 2009 at 9:23 AM, hap 497 wrote:
>
> Hi,
>
> When I call PackageManager's queryIntentActivities() with this intent,
>
> Intent intent = new Intent(Intent.ACTION_SENDTO, Uri.parse("smsto:"));
> packageManager.queryIntentActivities(intent, 0);
>
> it returns 1 result.
>
> But when I do this:
> Intent intent = new Intent(Intent.ACTION_SENDTO);
> packageManager.queryIntentActivities(intent, 0);
>
> It returns 0 result.
>
> I am trying to query how many *all* activities registered for
> ACTION_SENDTO, instead of just send to smsto.
> So i expect the result to be at least 1.
>
> Anyone has any idea for this behavior?
>
> Thank you.
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: readability extension (experience writeup)
I saw Evan's extension and was inspired to try something even simpler.
pinboard.in is a delicious replacement and I was motivated to move
their bookmarklet into the page action area.
- Getting started was a bit difficult since I didn't know about
load-extension and "Load unpacked extension" didn't appear to work (on
linux). Was very confused. Figured out there were parsing errors in my
manifest. Might want to log those messages to chrome://extensions/
instead of just dumping them to the console.
- Listening to various tab events is a fairly low level API. Have you
considered a callback function that decides whether a certain URL
should be shown?
chrome.pageActions["bookmarks].shouldShowCallback(function(url) { /*
returns true to show action */ })
On second thought, maybe http://crbug.com/21729 is good enough and I'm
looking at the wrong solution to the pain point...
- tab.title (from chrome.tabs.get(...)) is undefined until after the
page has finished loading, which is a problem since I'm taking the
title and passing it to the bookmarking service. The title exists
somewhere; it's displayed in the on screen tab title at the time it
returns undefined to the callback.
-- Elliot
On Sat, Sep 12, 2009 at 7:02 PM, Evan Martin wrote:
>
> [resend, I think I screwed up the previous three tries]
> I wrote an extension that adds a page action to trigger Readability:
> http://lab.arc90.com/experiments/readability/
>
> It's basically just a glorified bookmarklet.
>
> Code is here:
> http://neugierig.org/software/git/?url=chrome-readability/
> Browse it here:
> http://neugierig.org/software/git/?url=chrome-readability/tree/
>
> I can't provide a .crx because I wasn't able to figure out how to
> build one, which I think means I can't actually install it. :~(
>
> Here's some feedback on the process. I know extensions are still
> under development, and that surely most if not all of these are
> already known bugs, and that others are probably my fault for doing it
> on Linux. I thought it would still be helpful to give an overview of
> points of confusion I ran into, in case any of these aren't yet known
> bugs.
>
> - Weight.
> This feels like a *lot* of code (content script, page action,
> background page, manifest, message ports) just to make a bookmarklet
> appear in the URL bar. I wonder if there's a place for a "simple"
> extension API for bookmarklet-y sorts of things?
>
> - Making my page action show up.
> It wasn't clear to me how to make my action just always show up.
> I think I may have done it wrong:
> http://neugierig.org/software/git/?url=chrome-readability/tree/background.html
> since it feels unreliable (sometimes it doesn't show).
>
> - The failure modes are confusing.
> Sometimes it prints to the console (when I've made a typo in my
> manifest); other times it prints to the error console of the extension
> (bugs in my background js); other times it prints to the page's error
> console (bugs in my content script). Many of those times there's no
> obvious way to map the error back to the line that is failing.
>
> - JS console.
> Do we really have no UI to get to the JS console? I had to open the
> developer tools, then guess that one of the icons at the bottom of
> the window would show me the messages.
>
> - The docs around content scripts communicating with the embedding
> page aren't too clear. See e.g.:
> http://code.google.com/chrome/extensions/content_scripts.html#messaging
> That section is mostly just a big example but for example nowhere is
> the postMessage API described. I'd prefer it to be laid out more
> like:
> - how to make each endpoint listen for messages
> - how to make each endpoint send a message
>
> - Doc organization.
> It would've been clearer to me if there is one more level of nesting.
> Sections like toolstrips, page actions are features with manifest
> edits as well as APIs, while sections like tabs and windows are just
> API references.
>
> - Building the .crx.
> strace -fo log chromium-browser --user-data-dir=/home/martine/test
> --pack-extension=`pwd`/readext
> --pack-extension-key=chrome-readability.pem
> Doesn't show it ever trying to create my .pem. Maybe it's not implemented,
> but it'd be nice if it at least complained in that case.
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] user feedback one month in
On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin wrote: > - CSS occasionally lost while browsing > My response: I think I've seen this too, but I had been assuming it's > site glitches. Does this ring any bells for anyone? I see this at least twice a day on my home connection. A site will load except for the corresponding CSS. There doesn't appear to be a pattern to it. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Problem with gyp every time v8 updates their branch
On Wed, Sep 23, 2009 at 1:25 PM, John Abd-El-Malek wrote: > I have to delete the v8 directory and run gclient sync again (or remove the > generated files). This is annoying, since it breaks syncing to all the > Windows developers (I don't think this happens on Mac and Linux). Actually, I have to nuke the v8/ directory every time they update under linux/scons, too. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Debugging glibc malloc "double free or corruption"
On Fri, Oct 2, 2009 at 7:32 AM, spotrh wrote: > I tried valgrind, but it gave up after 1000 errors. :/ Are you using our suppression files? (located in /tools/valgrind/memcheck/suppressions.txt) You'll hit the 1000 error limit easily if you don't. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: SVN Stable Tree Path for 3.0.195.25
The latest source is in trunk, not a specific release branch. -- Elliot On Tue, Oct 6, 2009 at 12:34 PM, Amit Kishnani wrote: > > Hey Guys, > > what is difference between these releases "3.0.190.2" & "3.0.195.25" > > i can get to "SVN" source tree to "read access" for code tree > "3.0.190.2" using the following svn repository url > > http://src.chromium.org/svn/releases/3.0.190.2/src/ > > i want to make sure i am getting the latest stable source tree , is > there a better svn url to get latest "3.0.195.25". please advise. > > Thanks, > Amit. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: my feelings on rebuilding v8bindings
This is the best rage comic ever. -- Elliot On Wed, Oct 14, 2009 at 10:40 AM, Evan Martin wrote: > See attachment. That is all. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
On Wed, Oct 28, 2009 at 9:20 AM, Evan Martin wrote: 3) Startup time is faster than calculator. >>> >>> I'm not sure if you're kidding. Do you mean Windows calculator? >> >> On my home linux box (Jaunty, reasonably fast), >> warm startup time of chrome is less >> than the warm startup time of gnome calculator. >> Strange but true. > > Yeah, that's why I was asking -- it wouldn't surprise me if we were > faster than the GNOME one. Without any numbers I'd blame the icon > theme stuff (Elliot found it can do a truly ludicrous number of disk > accesses on startup). Here's an experiment: Set Options > Personal Stuff > Use GTK+ Theme. Close chrome. Now try another warm start of chrome. Is it still faster than gnome calculator? If not, it's because you were using the classic chrome theme, which doesn't have to warm up GTK's *per process* icon cache. strace gnome-calculator and watch the output for reading directories and files with "icons" in them and be blown away by the amount of work done. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
On Wed, Oct 28, 2009 at 12:24 PM, Antoine Labour wrote: > For the UI bits, I'm willing to believe that GTK, which uses cairo, hence > XRender for rendering, is hardware accelerated and in any case pipelined in > another process (X), and so is faster than serialized, software rendered > Skia. How much is the impact ? I don't know, we're not talking a huge amount > of pixels, but still... Not only GTK mode. On linux, we upload (most of) the theme images to the X server so blitting the images is done server side and (hopefully) hardware accelerated. Off the top of my head, the tabstrip and the floating bookmark bar are the only pieces of the linux UI drawn with skia. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linting chrome/ in pre-submit checks
Chromium developers,
I have just submitted a PRESUBMIT.py for chrome/ which will run
cpplint.py on your change as part of the presubmit process. cpplint is
currently run at reduced strictness--cpplint run separately may
generate more errors[1]. Currently, it only runs it at (gcl/git cl)
upload time and only generates warnings. In the future, it should
error at commit time, but I want to put this through a trial period so
please pay attention to the warnings and yell and scream at me if
there are false positives. If I hear nothing, I'll enable errors at
commit time sometime next week.
I've also gone through chrome/ code and fixed most style errors.
Here's a few recurring problems to watch out for:
- There is supposed to be a space between (if|while|for) and the
opening parenthesis. There ISN'T supposed to be a space between a
function name and it's arguments.
- When declaring a class that inherits, the ':' should not just be
hanging on the previous line.
- On that note, please remember that "class x : public baseclass" and
"class x : baseclass" may both compile but have different meanings and
that you probably want the first.
- Remember that 'private:', 'public:' and 'protected:' should be
indented one space.
- Don't use tabs.
- Header guards should be of the form "CHROME_DIR_DIR_DIR_FILE_H_".
Header files require header guards; don't omit them. (Exception: the
"-message.h" headers which do multiple include trickery.)
- ';' shouldn't be used in empty loops. Use "{}" instead.
- If an else has a brace on one side, it should have it on both.
Time permitting, I also hope to have app/ , base/ , and maybe views/
lint clean with presubmit checks in the future. I also hope to make
the linter more strict in the future; this is just a starting point.
-- Elliot
[1] For the curious: currently, the presubmit process runs normal
chrome/ code through "--verbose=4" and unit test code through
"--verbose=5". In addition, there's a list of tests that we instruct
cpplint.py to not run due either to common false positives or style
violations that are really, really common.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Linting chrome/ in pre-submit checks
On Tue, Nov 17, 2009 at 11:29 AM, Peter Kasting wrote:
> There are some unittests where we have super-long bits which go over 80
> chars, and there are also some where the linter thinks our indenting is
> strange when we do something like:
> struct Foo { ... };
> Foo foo_cases[] = {
> {"a",
>"b",
>"c"},
> }
This construct is why I make cpplint run at a different verbosity
level for test code.
-- Elliot
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Linting chrome/ in pre-submit checks
On Tue, Nov 17, 2009 at 11:31 AM, Nico Weber wrote: > Is cpplint the thing that generates the "lint errors" column on codereview? > If so, it doesn't work very well for objective-c++ files (.mm) and .h files > that contain objc++ declarations. The PRESUBMIT.py file only runs on cc and h files and explicitly blacklists any file in the cocoa/ directory or any file that has "_mac.(cc|h)" or "*_mac_*" in its file name. -- Elliot -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] SQLite compression in history database.
I'm all for it. I vaguely remember people complaining about the size of our history files, and most of my history files are over 50M. -- Elliot On Tue, Nov 24, 2009 at 10:13 AM, Scott Hess wrote: > Long ago when developing fts1, I experimented with using zlib > compression as part of the implementation. It fell by the wayside > because it really didn't provide enough performance improvement (I > needed an order of magnitude, it didn't provide it), and because of > licensing issues (fts1/2/3 are part of core SQLite, which does not > include zlib). > > Chromium already has zlib, and I don't think there's any particular > reason not to hack our version of fts to support it. Looking at my > October history file, I get the following (numbers are in megabytes): > > ls -lh History\ Index\ 2009-10 > # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 > .../sqlite3 History\ Index\ 2009-10 > select > round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) > from pages_content; > # 34.9 > select > round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) > from pages_content; > # 12.29 > select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; > # 24.6 > select round(sum(length(compress(block)))/1024.0/1024.0,2) from > pages_segments; > # 14.3 > > pages_segments is the fts index. Since it is consulted very > frequently, I'd be slightly nervous about compressing it. > pages_content is the document data, which is hit after the index (or > when doing a lookup by document id), so compressing it shouldn't have > much performance impact. > > Does this seem like a win worth pursuing? > > -scott > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on "// NOLINT"?
If there are consistent patterns of NOLINT usage, I can suppress the whole error class. Also, the linter is only automatically run on chrome/ and app/, IIRC. -- Elliot On Wed, Dec 9, 2009 at 4:38 PM, Brett Wilson wrote: > On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek wrote: >> btw I searched the code, almost all the instances are in code from different >> repositories, like v8, gtest, gmock. I counted only 17 instances in >> Chrome's code. > > > Most of the Chrome NOLINTs look like the're around ifdefs, where the > ifdef code sometimes mean that a comma or a semicolon goes on the line > after the ifdef. We should be working to remove these anyway since the > ifdefs are super ugly, and I'm not sure the NOLINT comment actually > makes them worse. Some of these may not be practical or desirable to > remove, though. > > So I don't think I see a big problem with the way NOLINT is used in > Chrome. Looking through V8 I don't see a huge problem either. > > Some NOLINT calls weren't clear to me why the linter complained. I > suggest that NOLINT comments be documented. In some places they > already are. Then reviewers will know to argue when they see something > untoward, whereas just "// NOLINT" isn't alwasy clear about what the > problem is and whether they should complain. This will also make > NOLINTs more painful to add since you have to justify why you're > adding it, which will hopefully decrease its usage. > > Brett > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Problem in Hooking 'ExTextOut'
On Wed, Sep 15, 2010 at 10:04 AM, ZHOU Xiaobo wrote: > My question is: > what the sandbox does is just hooking a subset of the systemcall such > as 'OpenFile' 'CreateProcess' etc ? The effect is crashing the process on any syscall we don't whitelist. I don't know exactly how it works on Windows. I know that it's almost 17k sloc and does quite a bit of communication with the NT kernel which enforces the restrictions. (On Linux, our seccomp sandbox works by rewriting the binary in memory so each syscall callsite is rewritten as a read/write to a proxy that makes the security decision, and then telling the linux kernel to kill the process if it does any syscall other than read() and write().) There is no way to turn the sandbox off once it is on; this is an important part of chrome's security model. If a malicious website exploited a buffer overflow somewhere in the renderer, being able to tell the kernel to turn the sandbox off would kind of defeat the point, right? > what is the correct way to achieve my goal? (capture the word under > my cursor and translate it into Chinese.) You should be using a content script in an extension: http://code.google.com/chrome/extensions/content_scripts.html There are already content scripts that read text under the cursor (I specifically mentioned rikaikun on IRC when ), and either replacing the word or popping up a translation box (again, rikaikun) are trivial operations. In addition to being the correct thing to do, an extension would work on all platforms while trying to make a DLL would be Windows only. (You mentioned on IRC that you can't use an extension, though your phrasing suggested that was because you couldn't get the word under the cursor, which is wrong, you can. If you need to use a DLL because you already have a translation software already written in a compiled language or something, you don't really have any good options since you aren't going to be able to load a DLL into the process where text rendering is done.) -- Elliot -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
