Re: [chromium-dev] Re: Assertion failures on Mac OS are super slow
FYI: We have such suppression code in the tree which we use for the renderer process. For the browser process we allow the crash to reach Crash Reporter so that Chrome doesn't crash silently. see: DebugUtil::DisableOSCrashDumps() in base/debug_util_mac.cc Best regards, Jeremy On Tue, Nov 10, 2009 at 3:10 AM, Eric Seidel esei...@chromium.org wrote: ReportCrash is crawling for stacks and looking up symbol names. If your process is a debug build it has huge symbol tables. I don't know of any way to disable ReportCrash. However, you can add some code to your process to catch the offending symbols and exit instead. You can also run the process under the debugger, which will prevent ReportCrash from running. Others may know more. -eric On Mon, Nov 9, 2009 at 4:57 PM, Eric Roman ero...@chromium.org wrote: Whenever I hit a CHECK/DCHECK in the chrome unit tests on mac, after printing a backtrace (which btw lacks the symbol names), the process locks up and becomes un-killable! It won't respond to either SIGINT or SIGKILL. It looks like the villain is the ReportCrash process. As this is happening, ReportCrash happily chews up 100% CPU for about 5-10 minutes. I confirmed ReportCrash is the villain, since if I murder it as root then the unit-test is killed right away. I don't know what is going on with ReportCrash, but it is certainly very frustrating. Running fs_usage I notice that ReportCrash is repeatedly open/close/fstate the same *.a files under src/xcodebuild/Debug. So my guess is that ReportCrash is having a heart attack trying to symbolicate. Anyone know how to fix this? Can I disable ReportCrash if not? Thanks! /me is a mac n00b so please be gentle :) --~--~-~--~~~---~--~~ 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] [linux] page action extensions crashy on 4.0.237.0
You can disable the extensions easily by going to wrench extensions, and clicking the Disable link next to each item. - a On Mon, Nov 9, 2009 at 6:20 PM, Tony Chang t...@chromium.org wrote: If you don't run Chrome on Linux or you don't have any extensions installed, you can ignore this email. If you have any browser action extensions (like the buildbot extension or the gmail extension) installed on Linux Chrome, you may be experiencing frequent crashes when closing browser windows. A potential fix has been checked in, but until the next dev channel build is released, you can work around the crash by disabling the extension. This applies to any extension that puts a button in your browser toolbar. If you're curious: http://code.google.com/p/chromium/issues/detail?id=26751 tony --~--~-~--~~~---~--~~ 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] Re: [chromium-extensions] Re: Desktop Notifications
I did some quick spelunking with this feature this evening. It doesn't look like the integration with extensions is quite working yet. For one, when showing an HTML notification for a chrome-extension:// URL, it looks like the notification window ends up in a different process. This prevents chrome.extension.getBackgroundPage() from working, which how communication between notification windows and other extension views should work. I filed a few bugs on the integration between the two systems. You can find them all here: http://code.google.com/p/chromium/issues/list?q=Area:extensions+feature:notifications - a On Mon, Nov 9, 2009 at 10:09 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi John, To be more specific. We have logic in our background page that acts as a single entry point for several features, including opening site pages according to some user preferences and location. Any component that needs to open a page should do it through this entry point. We also have implemented an observer-like service, so that several parts of the application can react over several events. Use cases: * The notification contains a link or button that when clicked, the extension performs an action, ie. opening a custom link in a new tab, in a new window, etc... * The extension would want to update a notification's content(if visible) when some updated data is received via a remote API. Those are our specific use cases. Shared workers sound like what we need though. @Drew, Does near future include the 4.0 release? Let us know if you need help testing this. Thanks a lot! On Mon, Nov 9, 2009 at 10:33 PM, John Gregg john...@google.com wrote: Hi Marcos, It might help if you could describe (as specifically as you feel you can) the use-case you're hoping to realize, since changes to the spec should be driven by use-cases rather than just programming style. At present my concern is to make sure we remain flexible with the presentation of notifications rather than building in too many hooks before the feature has received a lot of use. But if there's an important use-case that the spec doesn't meet, that would be a place to start. As far as workarounds that wouldn't depend on changing the Notifications spec, you might look at shared workers, which are coming soon to Chromium as well (atwilson@ can provide details): it should be the case that both the notification page and the main creating script can communicate via the same shared worker. -John On Mon, Nov 9, 2009 at 11:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've managed to use the Notifications API from our extension, thanks to John Gregg's implementation. However we are missing a key feature for us, which is to be able to have some logic inside the notifications itself, so that we can communicate with the background script for several things. I understand the way of communicating this components is under discussion, but are there any tips or clues for us to base our work on? We've tried setting something like background to the Notification object and try accesing it from the inner javascript in the notification, with no luck, ince we can only reach up to a DOMWindow object. The same goes backwards, where onDisplay we were trying to call a method in the notifications internal javscript, but we can go deeper from the Notification object. Inside the DOMWindow from the notification we can go through chrome.[windows/tabs/extension] but any call to those APIs will throw an access denied error. Is there any workaround or something we can do in the short term to accomplish this type of communication? Maybe something like what content scripts do with ports. What are the proposals for this under discussion? Thanks for your help. Marcos On Thu, Nov 5, 2009 at 6:22 PM, Marcos Aruj marcos.a...@gmail.com wrote: Ok, done: http://www.crbug.com/26859 I attached a crx to the report that triggers the bug. Thanks! On Thu, Nov 5, 2009 at 5:19 PM, John Gregg john...@google.com wrote: Thanks for the bug report, I am currently working on getting Notifications working for extensions and I'm familiar with this issue, although I don't think there is a bug for it yet. If you would create one I can update it as I get the fix checked in (which will hopefully be tomorrow, I think it's a fairly easy fix). -John On Thu, Nov 5, 2009 at 6:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj
[chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
I've updated http://crbug.com/25959 with some comments. The suggestion was made to exclude the entire profile directory as a short-term solution, but that would mean not backing up the bookmarks and cookies. So for the immediate need (M4) what is more important: a) saving space in the Time Machine volume, or b) having a backup of bookmarks and cookies? On Nov 9, 7:40 pm, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM,mrossettiwrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Beginning with development
Hello, As you know, Chromium is a huge project, only checking out the code and compiling it is a very costly task. Some time ago I was browsing the Code, compiled it and also made some changes in order to patch some bug ( the one about drag dropping a items in Mac version ) Now I want to dive again into de code, but all my compiled code is outdated, so i need to update the code and recompile the full tree again. I still remember that compiling the full source code took my macbook around 2 hr and it replaced my calefactor for a while :). The question is if there is any way to take only the code that you want to work on and get the compiled libs of modules you don't want to modify. Say, i want to code in V8 module but i don't want to checkout the webkit one and spend half and hour building the library and its dependencies, or worse, recompile again the whole module when I sync the code to update the changes has been made. I would be perfect if you could have a precompiled version of everything and only build the module you want to solve a bug. I think than this approach would make the entry stages more affordable. Thanks. Roberto. -- 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] Re: Preventing Incremental Backup of History/Thumbnails
On Tue, Nov 10, 2009 at 08:14, mrossetti mrosse...@chromium.org wrote: I've updated http://crbug.com/25959 with some comments. The suggestion was made to exclude the entire profile directory as a short-term solution, but that would mean not backing up the bookmarks and cookies. So for the immediate need (M4) what is more important: a) saving space in the Time Machine volume, or b) having a backup of bookmarks and cookies? a is more important. On Nov 9, 7:40 pm, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM,mrossettiwrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens -- 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] Beginning with development
On Tue, Nov 10, 2009 at 9:13 AM, Roberto robj.pe...@gmail.com wrote: The question is if there is any way to take only the code that you want to work on and get the compiled libs of modules you don't want to modify. No. We have discussed this kind of thing in the past and I think in principle everyone can see the benefits. In practice, separating the dependencies in such a way as to make this happen, and keeping all the different module versions properly synced, becomes difficult when the entire source base moves so rapidly. We used to split off various subprojects like base into their own areas, and you could commit to one and then update the DEPS file to pull your changes into the mainline. This became horribly unwieldy, and that was a couple years ago when the number of committers was far smaller. PK -- 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] Beginning with development
Note however that you can build specific projects. When working on base or net for example, you can build just base_unittests and net_unittests. When working on webkity things, you can sometimes compile just the test_shell, and not chrome. -- 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] Simulating keyboard input
On Fri, Nov 6, 2009 at 8:16 AM, Simon Stewart simon.m.stew...@gmail.com wrote: I've noticed a difference between firefox and chrome, and was wondering whether it was deliberate. Generally, the way to resolve these issues is to also test Safari and IE. We almost always match Safari, so differences there are frequently bugs. If we match Safari but differ from IE/Firefox, then it's a WebKit bug. If we match Safari and Safari matches IE, then that is likely intentional. -- 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] Re: Preventing Incremental Backup of History/Thumbnails
I've verified with SQLite that journal files do NOT get the sync cookie. We could consider adding it to our SQLite, I suppose. It looks like there is room in the journal header for things like that. Not sure how often it comes up, but if it does come up it would be pretty devastating. -scott On Mon, Nov 9, 2009 at 6:40 PM, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM, mrossetti wrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens --~--~-~--~~~---~--~~ 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] Re: 437k files checked out for an official build
Note in Anthony's mail he said he was clobbering the build directory, not the checkout. I do not have very many files in my build directories: $ find Debug | wc -l 10499 $ find Release | wc -l 10290 I think this is not we have a lot of files because we do a lot of stuff but rather that something has gone horribly wrong. Anthony, did you happen to notice any large collections of files that were in the delete list? On Mon, Nov 9, 2009 at 6:41 PM, Thomas Van Lenten thoma...@chromium.org wrote: Right, but the builds need these files to run the tests to make sure the bits are good. The problem is some tests leave logs and such in the tree after running, if we could ensure nothing changes in the tree, we might be able to change the scripts to simply update. Or maybe we do the same gclient revert the trybots do to make sure it is a completely clean tree for the build. TVL On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow jor...@chromium.org wrote: This is related to the thread (last Friday?) about making a light weight checkout of Chromium the default. Btw a quick look indicates that 100k are Google specific files (hermetic build environment and such). 200k are layout tests. So that leaves only 150k filesprobably many of which are still test related. On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Was just clobbering a build directory this morning, and noticed it was deleting ~437 thousand files from a single Chrome official windows build directory, which took approximately 20-30 minutes to do a delete. Perhaps my view isn't oriented correctly, but this seems like a very high number of files. This isn't a high priority issue for the 4.0 timeframe, indeed may not be a high priority issue at all, but I'd like to turn it over to our developer community to see if anyone has any thoughts on the matter. So w/ that... Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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] Re: 437k files checked out for an official build
BTW, the trick I always use for deleting directories on Windows 'cause it's so slow is: mv dirname foo; rm -rf foo that way you can start your build or whatever again immediately, because the target directory is gone immediately. On Tue, Nov 10, 2009 at 10:39 AM, Evan Martin e...@chromium.org wrote: Note in Anthony's mail he said he was clobbering the build directory, not the checkout. I do not have very many files in my build directories: $ find Debug | wc -l 10499 $ find Release | wc -l 10290 I think this is not we have a lot of files because we do a lot of stuff but rather that something has gone horribly wrong. Anthony, did you happen to notice any large collections of files that were in the delete list? On Mon, Nov 9, 2009 at 6:41 PM, Thomas Van Lenten thoma...@chromium.org wrote: Right, but the builds need these files to run the tests to make sure the bits are good. The problem is some tests leave logs and such in the tree after running, if we could ensure nothing changes in the tree, we might be able to change the scripts to simply update. Or maybe we do the same gclient revert the trybots do to make sure it is a completely clean tree for the build. TVL On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow jor...@chromium.org wrote: This is related to the thread (last Friday?) about making a light weight checkout of Chromium the default. Btw a quick look indicates that 100k are Google specific files (hermetic build environment and such). 200k are layout tests. So that leaves only 150k filesprobably many of which are still test related. On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Was just clobbering a build directory this morning, and noticed it was deleting ~437 thousand files from a single Chrome official windows build directory, which took approximately 20-30 minutes to do a delete. Perhaps my view isn't oriented correctly, but this seems like a very high number of files. This isn't a high priority issue for the 4.0 timeframe, indeed may not be a high priority issue at all, but I'd like to turn it over to our developer community to see if anyone has any thoughts on the matter. So w/ that... Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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
[chromium-dev] Re: [gyp-developer] Coping with configurations differences in sources
On Mon, Nov 9, 2009 at 6:38 PM, Bradley Nelson bradnel...@google.com wrote: Currently they are porting base + app to 64-bit for windows. They only need a limited subset of functionality for nacl, so they have only made some source files 64-bit clean. They would like to simply disable the rest for 64-bit (at least for now). We are 64-bit clean on Linux; I would expect much of base is shared? My recollection is it only took Dean (and Joel?) a week or two to get us the rest of the way to 64-bit clean. -- 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] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Conceptually Chrome is a bunch of layers, from top to bottom 1) chrome+ui junk 2) multiprocess rendering 3) webkit API 4) webkit Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. We don't have a simple place to cut for that; however, since Chrome and test_shell are both just clients of the WebKit API, you could write your own client (like test_shell) and then copy the performant bits out of Chrome. It will require some work, but if it were easy then your job would be boring. :) -- 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] Re: test_shell performance is bad compared to Chromium
Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. Thanks for clarifying. I have had some time to think about what you guys have been saying, and I have decided to start out with kiosk mode. At some point in the future I will probably want to remove what I don't need. It will require some work, but if it were easy then your job would be boring. :) I'm getting used to not having a boring job. On Tue, Nov 10, 2009 at 7:26 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Conceptually Chrome is a bunch of layers, from top to bottom 1) chrome+ui junk 2) multiprocess rendering 3) webkit API 4) webkit Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. We don't have a simple place to cut for that; however, since Chrome and test_shell are both just clients of the WebKit API, you could write your own client (like test_shell) and then copy the performant bits out of Chrome. It will require some work, but if it were easy then your job would be boring. :) -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Local Storage directory moved as of rev 31584
*If you don't use extensions that use Local Storage or you only use the official Google Chrome builds, you can probably ignore this. (Local Storage was only enabled by default as of last Friday.)* As of svn rev 31584http://src.chromium.org/viewvc/chrome?view=revrevision=31584, local storage files are stored in Local Storage not localStorage (inside your profile directory). The change includes code that moves the directory from the former name to the latter. So if you're just using the official builds (or never running a newer build and then an older build), you needn't worry. But, if you're building your own version of Chromium, once you launch a newer build, it will migrate your data. Older builds will only look in the old location for it, so they will no longer have access to the localStorage data. And if you change a setting with that older build, the newer build won't see it since the migration is a one time only thing. If for some reason this is going to be a major problem for you, you can always symlink the one directory from the other. Sorry for any inconveniences this may cause. J -- 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] Re: 437k files checked out for an official build
In the case of the 437k, I'm nuking both the checkout and the build output. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Nov 10, 2009 at 10:45 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Tue, Nov 10, 2009 at 1:39 PM, Evan Martin e...@chromium.org wrote: Note in Anthony's mail he said he was clobbering the build directory, not the checkout. I do not have very many files in my build directories: $ find Debug | wc -l 10499 $ find Release | wc -l 10290 I think this is not we have a lot of files because we do a lot of stuff but rather that something has gone horribly wrong. Anthony, did you happen to notice any large collections of files that were in the delete list? Or did you mean you actually nuke the whole checkout and not just the build output directories? TVL On Mon, Nov 9, 2009 at 6:41 PM, Thomas Van Lenten thoma...@chromium.org wrote: Right, but the builds need these files to run the tests to make sure the bits are good. The problem is some tests leave logs and such in the tree after running, if we could ensure nothing changes in the tree, we might be able to change the scripts to simply update. Or maybe we do the same gclient revert the trybots do to make sure it is a completely clean tree for the build. TVL On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow jor...@chromium.org wrote: This is related to the thread (last Friday?) about making a light weight checkout of Chromium the default. Btw a quick look indicates that 100k are Google specific files (hermetic build environment and such). 200k are layout tests. So that leaves only 150k filesprobably many of which are still test related. On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Was just clobbering a build directory this morning, and noticed it was deleting ~437 thousand files from a single Chrome official windows build directory, which took approximately 20-30 minutes to do a delete. Perhaps my view isn't oriented correctly, but this seems like a very high number of files. This isn't a high priority issue for the 4.0 timeframe, indeed may not be a high priority issue at all, but I'd like to turn it over to our developer community to see if anyone has any thoughts on the matter. So w/ that... Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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] Re: 437k files checked out for an official build
Hey Evan, Aside from the total file count, I didn't really notice any specific areas of glaring bloat. Sounds like it might be worth further investigation. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Nov 10, 2009 at 10:39 AM, Evan Martin e...@chromium.org wrote: Note in Anthony's mail he said he was clobbering the build directory, not the checkout. I do not have very many files in my build directories: $ find Debug | wc -l 10499 $ find Release | wc -l 10290 I think this is not we have a lot of files because we do a lot of stuff but rather that something has gone horribly wrong. Anthony, did you happen to notice any large collections of files that were in the delete list? On Mon, Nov 9, 2009 at 6:41 PM, Thomas Van Lenten thoma...@chromium.org wrote: Right, but the builds need these files to run the tests to make sure the bits are good. The problem is some tests leave logs and such in the tree after running, if we could ensure nothing changes in the tree, we might be able to change the scripts to simply update. Or maybe we do the same gclient revert the trybots do to make sure it is a completely clean tree for the build. TVL On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow jor...@chromium.org wrote: This is related to the thread (last Friday?) about making a light weight checkout of Chromium the default. Btw a quick look indicates that 100k are Google specific files (hermetic build environment and such). 200k are layout tests. So that leaves only 150k filesprobably many of which are still test related. On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Was just clobbering a build directory this morning, and noticed it was deleting ~437 thousand files from a single Chrome official windows build directory, which took approximately 20-30 minutes to do a delete. Perhaps my view isn't oriented correctly, but this seems like a very high number of files. This isn't a high priority issue for the 4.0 timeframe, indeed may not be a high priority issue at all, but I'd like to turn it over to our developer community to see if anyone has any thoughts on the matter. So w/ that... Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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
[chromium-dev] A plan for i18n
We need to have basic i18n for extensions for the stable release, but our constraints are: a) Time is tight b) We should not slow down Chrome startup (eg by loading message catalogs early in startup) c) We should not do something that is incompatible with our eventual i18n vision Here is a proposal that I think meets these constraints: 1. Use the same message catalog layout we had before (_locales directory, one JSON catalog per locale, we find them by crawling the directory structure). This means we will be forward compatible. 2. Support i18n in text fields of the manifest (name, description, browser and page default titles, browser action default badge). These fields cannot be internationalized by developers any other way, so we need to support this at a minimum. 3. Support chrome.i18n.getMessage(). This allows developers to i18n the rest of their extension manually. Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. chrome.i18n.getMessage() is spec'd to be synchronous, which seems very useful. In order to support this, it means that we must load the message catalogs before the extension process is started. Thoughts? - a -- 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] A plan for i18n
On Tue, Nov 10, 2009 at 12:21 PM, Thomas Van Lenten thoma...@google.com wrote: Off list since I haven't really looked at extensions, so some of this might be obvious... Not a dumb question at all, so replying on-list :) On Tue, Nov 10, 2009 at 3:17 PM, Aaron Boodman a...@chromium.org wrote: We need to have basic i18n for extensions for the stable release, but our constraints are: a) Time is tight b) We should not slow down Chrome startup (eg by loading message catalogs early in startup) c) We should not do something that is incompatible with our eventual i18n vision Here is a proposal that I think meets these constraints: 1. Use the same message catalog layout we had before (_locales directory, one JSON catalog per locale, we find them by crawling the directory structure). This means we will be forward compatible. 2. Support i18n in text fields of the manifest (name, description, browser and page default titles, browser action default badge). These fields cannot be internationalized by developers any other way, so we need to support this at a minimum. 3. Support chrome.i18n.getMessage(). This allows developers to i18n the rest of their extension manually. Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. Where do extensions end up getting installed? ie-are they only in the profile directory or can they be installed machine wide? if machine wide, they you might not be able to write back into some places to update for a different locale. Worse, with Mac fast user switching, could two users have it active at the same time in different locales? Good point. We do allow machine-wide installation, but the way it works is that the extension ends up getting installed per-profile, on all profiles by default. So I think we are still good here. - a -- 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] Re: refactoring and git
On Fri, Nov 6, 2009 at 10:50 AM, Yaar Schnitman y...@chromium.org wrote:
Git is totally confusing my renames and new files. Take a look:
.../{WebSearchableFormData.h = WebElement.h} | 49 -
webkit/api/public/WebSearchableFormData.h | 4 +-
webkit/api/public/{WebNode.h = WebInputElement.h} | 51 --
webkit/api/public/WebNode.h | 39 ++--
...sswordAutocompleteListener.h = WebElement.cpp} | 33 ---
.../WebPasswordAutocompleteListener.h} | 14 ++-
.../api/src/{WebNode.cpp = WebInputElement.cpp} | 56 +--
webkit/api/src/WebNode.cpp | 14 +++
And I didn't even move or deleted the files that git thinks I renamed (e.g.
WebNode.h is alive and well).
Is there any way to fix that?
Will it actually create that mess in svn too
when I git cl dcommit? I did mess up git cl upload...
In general, yes. I don't know your particular problem but I agree
something looks messed up.
--
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] Beginning with development
As Phistuck said, modifying gclient config file and then skipping the changes of the modules that you're not working on seems a good solution to prevent continuous rebuildings of other modules. But this doesn't skip the first large build. I know that download already built modules isn't the best option but, for example, you could download the libs that buildbot builds (before linking in a single executable) and with these modules already built, satisfy the requeriments to build a single module on your own. I'm not talking about splitting the modules into different projects, but speed up the first stages of working in some module. On Tue, Nov 10, 2009 at 9:30 PM, Marc-Antoine Ruel mar...@google.comwrote: And you can use distcc. On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr phajdan...@gmail.com wrote: Note however that you can build specific projects. When working on base or net for example, you can build just base_unittests and net_unittests. When working on webkity things, you can sometimes compile just the test_shell, and not chrome. -- 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] Beginning with development
On Tue, Nov 10, 2009 at 2:31 PM, Roberto Perez robj.pe...@gmail.com wrote: As Phistuck said, modifying gclient config file and then skipping the changes of the modules that you're not working on seems a good solution to prevent continuous rebuildings of other modules. But this doesn't skip the first large build. I know that download already built modules isn't the best option but, for example, you could download the libs that buildbot builds (before linking in a single executable) and with these modules already built, satisfy the requeriments to build a single module on your own. I'm not talking about splitting the modules into different projects, but speed up the first stages of working in some module. It seems like that might be useful to some people. Maybe you could prototype such a tool? On Tue, Nov 10, 2009 at 9:30 PM, Marc-Antoine Ruel mar...@google.comwrote: And you can use distcc. On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr phajdan...@gmail.com wrote: Note however that you can build specific projects. When working on base or net for example, you can build just base_unittests and net_unittests. When working on webkity things, you can sometimes compile just the test_shell, and not chrome. -- 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 -- 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 2:31 PM, Erik Kay erik...@google.com wrote: To be clear what's (intentionally) omitted from this proposal: - localized resource fetching (transparently turning /foo/bar.gif into /_locales/jp/foo/bar.gif) - auto string substitution (l18n templating) I think what you've got is a good start for our initial release. The above omissions are going to be trickier to do without significant performance penalties, and I think we can add them later. This will mean that i18n will be more manual for developers with the initial release, but it should still perform well and should be forwards compatible. One minor thing you left out was getURL providing a way to generate a localized URL (ideally without stats). If we don't provide devs a way to construct URLs manually, then they won't have a good migration path for when we do implement localized resource fetching. One thing is that odd is that if we don't do fallback for getURL(), it will be inconsistent. The manifest and getMessage() API will localize using fallback, but getURL() won't. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Any chromium developer have a citibank account?
http://code.google.com/p/chromium/issues/detail?id=15876 is a report of a memory leak that happens if you're timed out while logged in to citicards.com and the tab is not in front. Can someone with an account there try to reproduce? 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 3:21 PM, Nebojša Ćirić c...@google.com wrote: One minor thing you left out was getURL providing a way to generate a localized URL (ideally without stats). If we don't provide devs a way to construct URLs manually, then they won't have a good migration path for when we do implement localized resource fetching. One thing is that odd is that if we don't do fallback for getURL(), it will be inconsistent. The manifest and getMessage() API will localize using fallback, but getURL() won't. We could let them build resource URL in the message catalog and get it using getMessage. JavaScript: ... getURL(chrome.i18n.getMessage(some_resource)); ... _locales/en/messages.json: ... some_resource : _locales/en/some_resource.jpg ... This approach would solve fallback problem too, since we would check all sublocales, without stating files. Developer would have to make sure the file actually exists. Yeah, I would rather something like this. Erik, I don't understand why you say this has no forward migration path. Wouldn't it just keep working if we introduced more clever APIs that automate more of this? At that point, the developer could choose to use the new APIs or keep doing it the old way. - a -- 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 3:24 PM, Nebojša Ćirić c...@google.com wrote: Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. We could generate all manifest.json files during the installation process and store them in respective locales: _locales/en/manifest.json _locales/es/manifest.json When user switches UI language, we would load correct manifest.json file and replace one in prefs. I think this would be cheaper (perf wise) than loading message catalogs when we detect UI language change, and then doing manifest localization on the fly (less files to load, less processing). I think it is OK to re-read the catalogs when the UI language changes. This is pretty infrequent. - a -- 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] Any chromium developer have a citibank account?
On Tue, Nov 10, 2009 at 3:11 PM, Dan Kegel d...@kegel.com wrote: http://code.google.com/p/chromium/issues/detail?id=15876 is a report of a memory leak that happens if you're timed out while logged in to citicards.com and the tab is not in front. Can someone with an account there try to reproduce? Thanks... I have an account there. I'll try. 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 3:31 PM, Aaron Boodman a...@chromium.org wrote: On Tue, Nov 10, 2009 at 3:24 PM, Nebojša Ćirić c...@google.com wrote: Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. We could generate all manifest.json files during the installation process and store them in respective locales: _locales/en/manifest.json _locales/es/manifest.json When user switches UI language, we would load correct manifest.json file and replace one in prefs. I think this would be cheaper (perf wise) than loading message catalogs when we detect UI language change, and then doing manifest localization on the fly (less files to load, less processing). I think it is OK to re-read the catalogs when the UI language changes. This is pretty infrequent. Ok, so it seems like the key people are all on board. This doesn't seem like a huge amount of work. I'll start creating some small bugs against the current state of the world. Cira, are you ready to start diving back into this, or are you still committed to beta blockers on the general product? - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] moderators for the list?
Hi all, Who are the moderators for this list? There was someone (djodoin) who has joined as a new member and apparently is waiting for his message to be sent, but I'm wondering if all of the likely moderators are on vacation or otherwise out ... -- Dirk -- 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] moderators for the list?
On Tue, Nov 10, 2009 at 7:09 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Who are the moderators for this list? There was someone (djodoin) who has joined as a new member and apparently is waiting for his message to be sent, but I'm wondering if all of the likely moderators are on vacation or otherwise out ... I believe you want Ian Fette. 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] How to compile Google Chrome with Visual C++ 2008 Express Edition
Hello, I just wanted to share with you all that I've succeeded in compiling Chrome using Visual C++ 2008 Express Edition and ATL 7.1 bundled with the Windows Driver Kit (WDK). I've wrote a blog post that gives the details of my recipe here: http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/ It would be nice if some Chrome developers could review the steps and see if it could be a valid setup to contribute to the project thus lowering the entry bar to develop on Windows OS. I also wonder if GYP could be made express edition aware? e.g. don't include solution folders in that case. Do not hesitate to make comments or suggestions. Thanks! -- Dominic. -- 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] Beginning with development
And you can use distcc. On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr phajdan...@gmail.com wrote: Note however that you can build specific projects. When working on base or net for example, you can build just base_unittests and net_unittests. When working on webkity things, you can sometimes compile just the test_shell, and not chrome. -- 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
[chromium-dev] Re: [gyp-developer] Coping with configurations differences in sources
We might build Chrome for 64-bit Windows in the future, but there are several reasons why we would like to avoid porting all Chrome code to 64-bit Windows now: - We are now in the process of porting Native Client code that is 64-bit clean on Linux to 64-bit Windows and it requires some effort. - We currently plan to use only a minimal subset of functionality in the 64-bit Windows binary, so we would like to keep that binary as small as possible Greg On Tue, Nov 10, 2009 at 10:41, Evan Martin e...@chromium.org wrote: On Mon, Nov 9, 2009 at 6:38 PM, Bradley Nelson bradnel...@google.com wrote: Currently they are porting base + app to 64-bit for windows. They only need a limited subset of functionality for nacl, so they have only made some source files 64-bit clean. They would like to simply disable the rest for 64-bit (at least for now). We are 64-bit clean on Linux; I would expect much of base is shared? My recollection is it only took Dean (and Joel?) a week or two to get us the rest of the way to 64-bit clean. -- 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: [chromium-extensions] Re: Desktop Notifications
I am trying to use the desktop notifications in an extension but I couldn't find a way to access any Chrome APIs inside a notification. Is there any way to do that? If not, is it possible to exchange messages for *indirect* access to the extension data like content scripts and their parent extension? Thanks. Raymond Lee On Nov 6, 8:22 am, Marcos Aruj marcos.a...@gmail.com wrote: Ok, done:http://www.crbug.com/26859 I attached a crx to the report that triggers the bug. Thanks! On Thu, Nov 5, 2009 at 5:19 PM, John Gregg john...@google.com wrote: Thanks for the bug report, I am currently working on getting Notifications working for extensions and I'm familiar with this issue, although I don't think there is a bug for it yet. If you would create one I can update it as I get the fix checked in (which will hopefully be tomorrow, I think it's a fairly easy fix). -John On Thu, Nov 5, 2009 at 6:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj marcos.a...@gmail.comwrote: Hi all, Quick question, how is the Notifications API going for the release of 4.0? Are there any news on this? Any sample code? Just wanted to know if we can rely on it now or if we should wait. Thanks! Marcos On Tue, Oct 20, 2009 at 11:04 AM, Darin Fisher da...@chromium.orgwrote: OK, that sounds reasonable to me. -Darin On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote: Not precisely embedding a TabContents; I'm drawing a custom toast using views and putting a RenderViewHost+RenderWidgetHostView in it. -John On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.orgwrote: Is this accomplished by embedding a TabContents in a custom drawn (using Views) toast? -Darin On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.orgwrote: To be clear - our priority is to support HTML notifications on all platforms *before* investigating support for native notification platforms (like Growl/libnotify). -atw On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.orgwrote: We're trying to come up with a way to display html notifications on these platforms, once we get the windows one checked in. (Likely code that we will have to write.) 2009/10/19 Evan Martin e...@chromium.org On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com wrote: The implementation of notifications is nearly complete for Windows chromium with the final pieces being reviewed right now. Hopefully it will be available on the dev channel very soon behind a command-line switch for developers to start using. If you have questions about the specifics of the API, let me know, I'm happy to answer them and/or provide more documentation. I had alluded to this before, but I don't still see a good answer: what is the plan on Mac/Linux when the API is called with HTML? -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- 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] moderators for the list?
Done. We're not on vacation (although I am in a different timezone), but in general we don't moderate every second. I go through in a batch daily, I think Mark Larson might moderate a bit more frequently, JonC was also helping out -- in general, if you want more frequent moderation, I'm happy to have help :) -Ian 2009/11/10 Peter Kasting pkast...@google.com On Tue, Nov 10, 2009 at 7:09 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Who are the moderators for this list? There was someone (djodoin) who has joined as a new member and apparently is waiting for his message to be sent, but I'm wondering if all of the likely moderators are on vacation or otherwise out ... I believe you want Ian Fette. PK -- 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] How to compile Google Chrome with Visual C++ 2008 Express Edition
On Mon, Nov 9, 2009 at 6:21 PM, Dominic Jodoin dominic.jod...@gmail.comwrote: It would be nice if some Chrome developers could review the steps and see if it could be a valid setup to contribute to the project thus lowering the entry bar to develop on Windows OS. What do you mean? Or to be more precise, what would considering your steps a valid setup to contribute concretely result in? PK -- 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] How to compile Google Chrome with Visual C++ 2008 Express Edition
On Tue, Nov 10, 2009 at 7:39 PM, Dominic Jodoin dominic.jod...@gmail.comwrote: I'm wondering if using a hacked ATL version 7.1 could lead to bugs given the product is built, I suppose, with ATL coming with Visual Studio 2005 or 2008 which is a different version. Possibly. But what I meant was that if the steps were to be approved, I thought they could be included on http://dev.chromium.org. I imagine that would depend on whether any of these instructions appear to violate any license agreements, copyrights, etc. I have no idea whether they do. PK -- 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] How to compile Google Chrome with Visual C++ 2008 Express Edition
Enabling contribution to Chrome on Windows without having to purchase any software is very welcome, good job :) I looked at the steps, and as I'm sure you're thinking, if these can be incorporated into the gyp sln generation that would be ideal. On Mon, Nov 9, 2009 at 6:21 PM, Dominic Jodoin dominic.jod...@gmail.comwrote: Hello, I just wanted to share with you all that I've succeeded in compiling Chrome using Visual C++ 2008 Express Edition and ATL 7.1 bundled with the Windows Driver Kit (WDK). I've wrote a blog post that gives the details of my recipe here: http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/ It would be nice if some Chrome developers could review the steps and see if it could be a valid setup to contribute to the project thus lowering the entry bar to develop on Windows OS. I also wonder if GYP could be made express edition aware? e.g. don't include solution folders in that case. Do not hesitate to make comments or suggestions. Thanks! -- Dominic. -- 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] How to compile Google Chrome with Visual C++ 2008 Express Edition
On Mon, Nov 9, 2009 at 6:21 PM, Dominic Jodoin dominic.jod...@gmail.com wrote: I just wanted to share with you all that I've succeeded in compiling Chrome using Visual C++ 2008 Express Edition and ATL 7.1 bundled with the Windows Driver Kit (WDK). I've wrote a blog post that gives the details of my recipe here: http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/ Awesome! It would be nice if some Chrome developers could review the steps and see if it could be a valid setup to contribute to the project thus lowering the entry bar to develop on Windows OS. Offhand it looks reasonable. I also wonder if GYP could be made express edition aware? e.g. don't include solution folders in that case. IIRC the plan was to slowly get rid of our use of ATL, then think about being express-edition-aware... so yeah, that sounds like something we'd like to do. Patches welcome :-) - Dan -- 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] Re: [chromium-extensions] Re: Desktop Notifications
Hey Aaron, thanks for your answer. Does this mean that extension and communication will be able to communicate between them without using Shared workers? Being able to do getBackgroundPage() from extension-created notifications would be awesome. We'll star those issues. On Tue, Nov 10, 2009 at 6:17 AM, Aaron Boodman a...@chromium.org wrote: I did some quick spelunking with this feature this evening. It doesn't look like the integration with extensions is quite working yet. For one, when showing an HTML notification for a chrome-extension:// URL, it looks like the notification window ends up in a different process. This prevents chrome.extension.getBackgroundPage() from working, which how communication between notification windows and other extension views should work. I filed a few bugs on the integration between the two systems. You can find them all here: http://code.google.com/p/chromium/issues/list?q=Area:extensions+feature:notifications - a On Mon, Nov 9, 2009 at 10:09 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi John, To be more specific. We have logic in our background page that acts as a single entry point for several features, including opening site pages according to some user preferences and location. Any component that needs to open a page should do it through this entry point. We also have implemented an observer-like service, so that several parts of the application can react over several events. Use cases: * The notification contains a link or button that when clicked, the extension performs an action, ie. opening a custom link in a new tab, in a new window, etc... * The extension would want to update a notification's content(if visible) when some updated data is received via a remote API. Those are our specific use cases. Shared workers sound like what we need though. @Drew, Does near future include the 4.0 release? Let us know if you need help testing this. Thanks a lot! On Mon, Nov 9, 2009 at 10:33 PM, John Gregg john...@google.com wrote: Hi Marcos, It might help if you could describe (as specifically as you feel you can) the use-case you're hoping to realize, since changes to the spec should be driven by use-cases rather than just programming style. At present my concern is to make sure we remain flexible with the presentation of notifications rather than building in too many hooks before the feature has received a lot of use. But if there's an important use-case that the spec doesn't meet, that would be a place to start. As far as workarounds that wouldn't depend on changing the Notifications spec, you might look at shared workers, which are coming soon to Chromium as well (atwilson@ can provide details): it should be the case that both the notification page and the main creating script can communicate via the same shared worker. -John On Mon, Nov 9, 2009 at 11:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've managed to use the Notifications API from our extension, thanks to John Gregg's implementation. However we are missing a key feature for us, which is to be able to have some logic inside the notifications itself, so that we can communicate with the background script for several things. I understand the way of communicating this components is under discussion, but are there any tips or clues for us to base our work on? We've tried setting something like background to the Notification object and try accesing it from the inner javascript in the notification, with no luck, ince we can only reach up to a DOMWindow object. The same goes backwards, where onDisplay we were trying to call a method in the notifications internal javscript, but we can go deeper from the Notification object. Inside the DOMWindow from the notification we can go through chrome.[windows/tabs/extension] but any call to those APIs will throw an access denied error. Is there any workaround or something we can do in the short term to accomplish this type of communication? Maybe something like what content scripts do with ports. What are the proposals for this under discussion? Thanks for your help. Marcos On Thu, Nov 5, 2009 at 6:22 PM, Marcos Aruj marcos.a...@gmail.com wrote: Ok, done: http://www.crbug.com/26859 I attached a crx to the report that triggers the bug. Thanks! On Thu, Nov 5, 2009 at 5:19 PM, John Gregg john...@google.com wrote: Thanks for the bug report, I am currently working on getting Notifications working for extensions and I'm familiar with this issue, although I don't think there is a bug for it yet. If you would create one I can update it as I get the fix checked in (which will hopefully be tomorrow, I think it's a fairly easy fix). -John On Thu, Nov 5, 2009 at 6:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have
Re: [chromium-dev] How to compile Google Chrome with Visual C++ 2008 Express Edition
This sounds great. I didn't know express chokes on folders. I'll investigate tomorrow and look into offering an option/autodetecting for gyp to emit a flat sln. -BradN On Tue, Nov 10, 2009 at 8:19 PM, Dan Kegel d...@kegel.com wrote: On Mon, Nov 9, 2009 at 6:21 PM, Dominic Jodoin dominic.jod...@gmail.com wrote: I just wanted to share with you all that I've succeeded in compiling Chrome using Visual C++ 2008 Express Edition and ATL 7.1 bundled with the Windows Driver Kit (WDK). I've wrote a blog post that gives the details of my recipe here: http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/ Awesome! It would be nice if some Chrome developers could review the steps and see if it could be a valid setup to contribute to the project thus lowering the entry bar to develop on Windows OS. Offhand it looks reasonable. I also wonder if GYP could be made express edition aware? e.g. don't include solution folders in that case. IIRC the plan was to slowly get rid of our use of ATL, then think about being express-edition-aware... so yeah, that sounds like something we'd like to do. Patches welcome :-) - Dan -- 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
[chromium-dev] Re: How to compile Google Chrome with Visual C++ 2008 Express Edition
Nice job. Thanks for doing this. Now the critic: Not too happy with the thunk generator: VirtualAlloc(0, sizeof(_stdcallthunk), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE) But I am too lazy right now to look at what does the VS2008 thunk logic looks right now. I would expect the page to be read-only once the thunk has been created. -- 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] How to compile Google Chrome with Visual C++ 2008 Express Edition
On Tue, Nov 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.com wrote: What do you mean? Or to be more precise, what would considering your steps a valid setup to contribute concretely result in? PK I'm wondering if using a hacked ATL version 7.1 could lead to bugs given the product is built, I suppose, with ATL coming with Visual Studio 2005 or 2008 which is a different version. But what I meant was that if the steps were to be approved, I thought they could be included on http://dev.chromium.org. -- Dominic. -- 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] Re: [chromium-extensions] Re: Desktop Notifications
On Tue, Nov 10, 2009 at 8:19 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hey Aaron, thanks for your answer. Does this mean that extension and communication will be able to communicate between them without using Shared workers? Yes, also, all the extension APIs, like chrome.tabs, chrome.bookmarks, etc should be available in the notification HTML page. Being able to do getBackgroundPage() from extension-created notifications would be awesome. We'll star those issues. Ok! -a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
