[chromium-dev] Chrome.exe Versioning
Is the zero versioned executable intentional?I mean, when you look at the properties for chrome.exe, it always has 0.0.0.0 as a version. Now, I know the executable is not always changing (f I understand correctly, most of the changes are in the DLL), so perhaps it should have its own versioning system, though I think the regular versioning system is sufficient. Or no one cares about it, anyway and that is why it is always 0.0.0.0. :) ☆PhistucK --~--~-~--~~~---~--~~ 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 chrome_exe to chrome, converting chrome.exe to gyp
This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like "test_shell (webkit\tools\test_shell\test_shell)", and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names "test_shell", "chrome", etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkus wrote: > Here's a quick example: > 1) Delete whole Debug directory > 2) gclient runhooks --force > 3) Set test_shell as startup project > 4) Hit F5 > Sample output of things that shouldn't be dependencies (mostly because > they're other executables) > sandbox (sandbox\sandbox) - Debug Win32 > chrome_dll - Debug Win32 > net_perftests - Debug Win32 > base_unittests - Debug Win32 > net_unittests - Debug Win32 > v8_shell - Debug Win32 > mini_installer - Debug Win32 > test_support_unit - Debug Win32 > test_support_ui - Debug Win32 > codesighs (third_party\codesighs\codesighs) - Debug Win32 > automated_ui_tests - Debug Win32 > memory_test - Debug Win32 > activex_test_control - Debug Win32 > > On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson > wrote: >> >> Andrew, can you give an example of something that built that shouldn't >> have for test_shell? Maybe we have some overspecified dependencies as well. >> >> -BradN >> >> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus >> wrote: >>> >>> I'll see if I can repro this again before filing a bug, but similar to >>> what Daniel and John reported, when I right click on test_shell and say >>> Build it builds the minimal set required to fully build+link test_shell.exe >>> However when I set test_shell as the start-up project and launch the >>> debugger, Visual Studio warns that every other project in chrome.sln must be >>> built before running (not true!). Is there a difference in build vs. runtime dependencies? >>> Andrew >>> >>> On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek wrote: > > > On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek > wrote: >> >> Yeah it happened to me before as well, I just figured I'd complain >> now.. Note another missing dependency is on crash_service.exe >> , npapi_layout_test_plugin, and npapi_test_plugin > > btw just to be clear, these are missing dependencies on ui_tests. > >> >> On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow >> wrote: >>> >>> I actually had this problem _before_ this change. Guess I should >>> have brought it up, but I figured it was just something funny on my >>> system. >>> >>> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek >>> wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx wrote: > > I notice that when I load chrome.sln and do a build, not all the > dependencies are built anymore. For instance, theme_dll isn't built > (not listed in the proj deps), is this expected? > > On Jun 18, 12:38 am, Steven Knight wrote: > > Okay, it looks like this change is sticking, at least until > > someone > > discovers Yet Another Unintended Side Effect. So heed the > > warnings in the > > previous message, quoted below. > > Git users on Linux: this requires an update to gyp to work > > properly, so > > make sure you "gclient sync" after you "git pull", or whatever >
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Additionally it seems like I'm getting no parallelism. I checked my visual studio settings and everything seems fine. Attached is a screenshot of how my CPU usage has looked for the entire processing of building test_shell (from chrome.sln). -- dean On Fri, Jun 19, 2009 at 12:10 PM, Dean McNamee wrote: > This also broke building from the command line. > > I usually never open Visual Studio as an IDE. I build on the command > line with something like: > > devenv chrome\\chrome.sln /Build release /Project test_shell > > It looks like project names like test_shell now have complicated names > like "test_shell (webkit\tools\test_shell\test_shell)", and I haven't > been able to manage supplying those on the command line. > > Is there a way we can get back our nice project names "test_shell", > "chrome", etc? > > On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkus wrote: >> Here's a quick example: >> 1) Delete whole Debug directory >> 2) gclient runhooks --force >> 3) Set test_shell as startup project >> 4) Hit F5 >> Sample output of things that shouldn't be dependencies (mostly because >> they're other executables) >> sandbox (sandbox\sandbox) - Debug Win32 >> chrome_dll - Debug Win32 >> net_perftests - Debug Win32 >> base_unittests - Debug Win32 >> net_unittests - Debug Win32 >> v8_shell - Debug Win32 >> mini_installer - Debug Win32 >> test_support_unit - Debug Win32 >> test_support_ui - Debug Win32 >> codesighs (third_party\codesighs\codesighs) - Debug Win32 >> automated_ui_tests - Debug Win32 >> memory_test - Debug Win32 >> activex_test_control - Debug Win32 >> >> On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson >> wrote: >>> >>> Andrew, can you give an example of something that built that shouldn't >>> have for test_shell? Maybe we have some overspecified dependencies as well. >>> >>> -BradN >>> >>> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus >>> wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight wrote: > > All-- > When you notice missing dependencies, pleased add them to the necessary > .gyp file(s)! One of the main reasons we've been trying to land all this > stuff is so that tracking down all these pieces isn't single-threaded > through one person (or two). If you're not comfortable making the change > yourself, then please file a bug so the dependency problems get tracked > and > fixed in an organized fashion. > Re: unnecessary rebuilds: please file bugs so they don't get lost. > Please include the target you were building, and the the libs/targets > that > were rebuilt unnecessarily. You don't have to be exhaustive about the > list, > it's more important here that at least some information gets collected and > doesn't languish on the ML or get dropped on the floor. > I'm working on a buildbot script that will test for missing dependencies > by building every target from scratch individually, and will then test for > unnecessary rebuilds by rebuilding each target after no updates. That's > been taking a back seat to just getting the conversion completed, but I've > accelerated my work on it as we wind down to the last few targets. > --SK > > On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek > wrote: >> >> >> On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek >> wrote: >>> >>> Yeah it happened to me before as well, I just figured I'd complain >>> now.. Note another missing dependency is on crash_service.exe >>> , npapi_layout_test_plugin, and npapi_test_plugin >> >> btw just to be clear, these are missing dependencies on ui_tests. >> >>> >>> On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow >>> wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek wrote: > > +1 this is affecting a lot of people. > > On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx > wrote: >> >> I notice that when I load chrome.sln and do a build, not all the >> dependencies are built anymore. For instance, theme_dll isn't built >> (not listed in the proj deps), is this expected? >> >> On Jun 18,
[chromium-dev] Running Cocoa in the renderer and bug 14609
http://crbug.com/14609 ... In the renderer we need to run Cocoa on a non-main thread. To pump windowserver events we need to pump on the main thread. And when we do so timers and notifications fire, screwing us over. I think the timers and notifications were not fired before, right? In the short term, I think that changing the run loop mode in which we pull events should fix things. I'm trying that out now. In the long term, I think this is yet another reminder about getting Cocoa out of the renderer... :) Avi --~--~-~--~~~---~--~~ 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: Running Cocoa in the renderer and bug 14609
On Fri, Jun 19, 2009 at 6:44 AM, Avi Drissman wrote: > In the long term, I think this is yet another reminder about getting Cocoa > out of the renderer... :) What do you use Cocoa in the renderer for? Does that include Core Graphics? Or is it just for widget rendering? --~--~-~--~~~---~--~~ 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: Running Cocoa in the renderer and bug 14609
Core Graphics is a level lower than Cocoa, and as the main way to draw on the Mac would be OK to use. I don't know what we use Cocoa for. I think widget rendering but I could be wrong. Avi On Fri, Jun 19, 2009 at 10:58 AM, Evan Martin wrote: > On Fri, Jun 19, 2009 at 6:44 AM, Avi Drissman wrote: > > In the long term, I think this is yet another reminder about getting > Cocoa > > out of the renderer... :) > > What do you use Cocoa in the renderer for? > Does that include Core Graphics? > Or is it just for widget rendering? > --~--~-~--~~~---~--~~ 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 chrome_exe to chrome, converting chrome.exe to gyp
[resend to chromium-dev from correct address; apologies if you get a dup.] I just landed a change (r18813) that may take care of a good number of the spurious rebuilds. Some of the .dll files are built as 'loadable_module' targets, which basically means they don't have any actual code (e.g. only resources) and no symbols to export, so the MS linker doesn't generate a .lib import library for them. However, gyp wasn't setting the necessary property (IgnoreImportLibrary) in the generated .vcproj file to inform Visual Studio that the project wouldn't generate a .lib, and dependent projects shouldn't expect a .lib. So it looks like VS would rebuild the loadable_module target trying to generate a .lib file that would never appear. I'm in the middle of a local rebuild cycle on my system to verify the behavior is actually fixed. (The CL also added 'theme_dll' as dependent target of 'chrome_dll', which would previously generate errors when the lack of the IgnoreImportLibrary property meant that chrome.dll would try to link against the nonexistent default.lib import library for themes.lib) If you still see unnecessary rebuilds after updating to r18813 or later, let me know what targets. There may be other contributing causes. --SK On Thu, Jun 18, 2009 at 4:30 PM, Andrew Scherkus wrote: > Here's a quick example: > 1) Delete whole Debug directory > 2) gclient runhooks --force > 3) Set test_shell as startup project > 4) Hit F5 > > Sample output of things that shouldn't be dependencies (mostly because > they're other executables) > sandbox (sandbox\sandbox) - Debug Win32 > chrome_dll - Debug Win32 > net_perftests - Debug Win32 > base_unittests - Debug Win32 > net_unittests - Debug Win32 > v8_shell - Debug Win32 > mini_installer - Debug Win32 > test_support_unit - Debug Win32 > test_support_ui - Debug Win32 > codesighs (third_party\codesighs\codesighs) - Debug Win32 > automated_ui_tests - Debug Win32 > memory_test - Debug Win32 > activex_test_control - Debug Win32 > > > On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson wrote: > >> Andrew, can you give an example of something that built that shouldn't >> have for test_shell? Maybe we have some overspecified dependencies as well. >> >> -BradN >> >> >> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus >> wrote: >> >>> I'll see if I can repro this again before filing a bug, but similar to >>> what Daniel and John reported, when I right click on test_shell and say >>> Build it builds the minimal set required to fully build+link test_shell.exe >>> However when I set test_shell as the start-up project and launch the >>> debugger, Visual Studio warns that every other project in chrome.sln must be >>> built before running (not true!). Is there a difference in build vs. >>> runtime dependencies? >>> >>> Andrew >>> >>> >>> On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight wrote: >>> All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek wrote: > > > On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek > wrote: > >> Yeah it happened to me before as well, I just figured I'd complain >> now.. Note another missing dependency is on crash_service.exe >> , npapi_layout_test_plugin, and npapi_test_plugin > > > btw just to be clear, these are missing dependencies on ui_tests. > > >> >> >> On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow wrote: >> >>> I actually had this problem _before_ this change. Guess I should >>> have brought it up, but I figured it was just something funny on my >>> system. >>> >>> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek >> > wrote: >>> +1 th
[chromium-dev] Conventions and patterns for multi-platform development
Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the "Engineering design documents" page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. Thanks! 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: V8 Generated Constructors
Ok, I see what you mean, but the macro in v8_proxy.h points to DOM_NODE_TYPES in v8_index.h, which includes VIDEO_HTMLELEMENT_TYPES (V), which conditionally defines V(HTMLAUDIOELEMENT, HTMLAudioElement) if video is enabled (which it is in webkit.gyp). So although that's not exactly the same as image, it looks like that binding does exist. Just because it's another layer away shouldn't mean the audio element isn't a node, correct? I did some more digging, and everything looks ok in HTMLElementFactory.cpp... I have no idea what I'm still missing. On Jun 18, 8:38 pm, Dimitri Glazkov wrote: > You're almost there. You also need to make sure to register it in > v8_proxy.cpp (look for Image as a pattern to follow). > > BTW, with gyp, dependencies in bindings are pretty robust. No need to > clobber anymore. > > :DG< > > > > On Thu, Jun 18, 2009 at 4:05 PM, kylep wrote: > > > Ok, so. So far I've created a new file > > V8HTMLAudioElementConstructor.cpp and modeled it off > > V8HTMLImageElementConstructor.cpp (changing all "image"s to "audio"s, > > plus modified V8CustomBinding.h and webkit.gyp. Change is here: > >http://codereview.chromium.org/132036 > > But I'm still getting "TypeError: Illegal constructor" when I try to > > call the audio constructor. Is there another hook I'm missing? > > > On Jun 16, 11:47 am, Dimitri Glazkov wrote: > >> A good place to start would be to look at existing *Constructor.cpp > >> files in WebCore/bindings/v8 and see how they are hooked in (like > >> Image constructor). Also, you have dimich and levin in close proximity > >> you who have added a V8 constructor or two in the past (I think). > > >> ;DG< > > >> On Mon, Jun 15, 2009 at 5:47 PM, Kyle Prete wrote: > >> > Hey I'm looking into these layout tests: > >> > LayoutTests/media/audio-constructor-src.html > >> > LayoutTests/media/audio-constructor.html > >> > LayoutTests/media/constructors.html > >> > and I need to know how constructors are generated. The failures all > >> > appear > >> > to be due to the Audio constructor, specifically: "TypeError: Illegal > >> > constructor" > >> > 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: Chrome.exe Versioning
2009/6/19 PhistucK > Is the zero versioned executable intentional?I mean, when you look at the > properties for chrome.exe, it always has 0.0.0.0 as a version. > Yes, that's intentional, to avoid having to patch the exe when it doesn't change. Not only would that make for bigger diffs it would cause more problems with firewalls and A/V programs. 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: V8 Generated Constructors
Since Audio object will be instantiated via JS, we need to add extra 2 lines to that huge switch statement in V8Proxy::GetTemplate: case V8ClassIndex::HTMLIMAGEELEMENT: desc->SetCallHandler(USE_CALLBACK(HTMLImageElementConstructor)); break; :DG< On Fri, Jun 19, 2009 at 10:05 AM, kylep wrote: > > Ok, I see what you mean, but the macro in v8_proxy.h points to > DOM_NODE_TYPES in v8_index.h, which includes VIDEO_HTMLELEMENT_TYPES > (V), which conditionally defines V(HTMLAUDIOELEMENT, > HTMLAudioElement) if video is enabled (which it is in webkit.gyp). So > although that's not exactly the same as image, it looks like that > binding does exist. Just because it's another layer away shouldn't > mean the audio element isn't a node, correct? I did some more digging, > and everything looks ok in HTMLElementFactory.cpp... I have no idea > what I'm still missing. > > On Jun 18, 8:38 pm, Dimitri Glazkov wrote: >> You're almost there. You also need to make sure to register it in >> v8_proxy.cpp (look for Image as a pattern to follow). >> >> BTW, with gyp, dependencies in bindings are pretty robust. No need to >> clobber anymore. >> >> :DG< >> >> >> >> On Thu, Jun 18, 2009 at 4:05 PM, kylep wrote: >> >> > Ok, so. So far I've created a new file >> > V8HTMLAudioElementConstructor.cpp and modeled it off >> > V8HTMLImageElementConstructor.cpp (changing all "image"s to "audio"s, >> > plus modified V8CustomBinding.h and webkit.gyp. Change is here: >> >http://codereview.chromium.org/132036 >> > But I'm still getting "TypeError: Illegal constructor" when I try to >> > call the audio constructor. Is there another hook I'm missing? >> >> > On Jun 16, 11:47 am, Dimitri Glazkov wrote: >> >> A good place to start would be to look at existing *Constructor.cpp >> >> files in WebCore/bindings/v8 and see how they are hooked in (like >> >> Image constructor). Also, you have dimich and levin in close proximity >> >> you who have added a V8 constructor or two in the past (I think). >> >> >> ;DG< >> >> >> On Mon, Jun 15, 2009 at 5:47 PM, Kyle Prete wrote: >> >> > Hey I'm looking into these layout tests: >> >> > LayoutTests/media/audio-constructor-src.html >> >> > LayoutTests/media/audio-constructor.html >> >> > LayoutTests/media/constructors.html >> >> > and I need to know how constructors are generated. The failures all >> >> > appear >> >> > to be due to the Audio constructor, specifically: "TypeError: Illegal >> >> > constructor" >> >> > 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] Using custom builds of chromium in a commercial setting
Hi folks, I'm currently investigating the possibility of using SSBs (Site Specific Browsers, another example is mozilla's Prism) to ship alongside a commercial web application, the application does not depend on the SSB in any way just makes it more acceptable to corporations who are opposed to updating to more recent web browsers. I've spent some time perusing the mailing list, and looking at the T's and C's that I can locate on the chromium website ( http://code.google.com/chromium/terms.html ). As far as I can tell the primary license and all 3rd party licenses are 'commecially friendly' and as long as the build of chromium doesn't mention Google or any of the associated trademarks then there should be no problem shipping a customised build of chromium on a cd alongside a commercial product. Can anyone confirm whether or not this is the case ? Many thanks - cj. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] IO Request Handing in Chromium
In http://dev.chromium.org/developers/design-documents/multi-process-resource-loading, all I/O in Render Process (WebKit code) is sent to Browser Process and Browser process is download the resource from the source. But what about Plugins (flash) which runs inside RenderProcess? How can those I/O requests being forward to Browser Process via chromium IPC mechanism? Flash plugins is closed source and it can make more than HTTP request. Flash can make RTMP request for video. How does IO in plugin being handled? 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: does chromium care about appcache manifests?
Developers would surely appreciate some kind of developer mode. Safari makes it nearly impossible to remove an appcache. Refreshing, emptying the cache nor resetting the browser helps in this. MobileSafari behaves about the same -- something like a notice with a force refresh option its developer mode would make debugging a lot easier. I'm not exactly sure what Firefox's behaviour is, but I remember it was somewhat better than Safari. The best way to develop using appcache seems to be by using uncachable references (e.g. timestamped) to every file in the appcache, which is quite tiresome. I'd suggest a 'force reload' option for the first implementation. A UI to show appcaches in some later stage would greatly easy debugging: appcaches are a 'black box' in current implementations. The only way to check that a browser is not reloading is by checking server logs, and even then you still can't be completely sure if it's regular browser caching or an appcache. On Wed, Jun 17, 2009 at 10:11 PM, Michael Nordman wrote: > Chromium has no behavior whatsoever yet... the feature is utterly > unimplemented thus far... but it will have identical behavior to > safari, iphone, andriod by virtue of the same code base performing > those behaviors... thats the plan at least, and I'm working on the > code now. > > Gears (i'm partly guilty of that) users have similar issues with the > gears system. Developing for 'offline' butts heads ( , > not buttheads :O) with standard operating procedures for web > development (put new stuff on server, hit reload, repeat as needed). > > I can think of at least some things that may help? > > * if the user-agent had a debugging level feature (in some debug/tools > menu) to blow away the current appcache. would that help? Or perhaps a > UI to show appcaches and a option to 'remove' one? > > The former could be provided without any spec changes and agreement > amoungst browser vendors. We're not far enough along with this > feature in chrome to be too concerned with UI yet... but I'll write > this down in my design doc. > > > On Wed, Jun 17, 2009 at 5:14 AM, Mark Janssen wrote: >> Hi Michael, >> >> It's been some time (I rarely read this address), but why I was asking >> is because I'm testing a web application for iPhone/Android. Safari >> does care about appcache manifest, but does so a bit too well: it's >> nearly impossible get it to reload a new version from the server (thus >> ignoring the appcache manifest). As you can imagine this is quite >> cumbersome during development, so I was wondering of Chromium has the >> same behaviour. >> >> Regards, >> Mark >> >> On Mon, Jun 1, 2009 at 11:54 PM, Michael Nordman wrote: >>> Hi, I'm assuming you and praseodym in #chromium IRC are one and the >>> same... if not, sorry for the spam. >>> >>> Yes, we do. >>> >>> At this point, there is no support for the feature in chromium, but >>> we're working towards that. The implementation in webcore has to be >>> refactored so that chromium can use it too... or chromium has to >>> implement this feature outside of webcore... we're pursuing the first >>> option at this time. >>> >>> https://bugs.webkit.org/show_bug.cgi?id=25436 >>> >>> Why do you ask? >>> >> > --~--~-~--~~~---~--~~ 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 TabRestoreUITest bug 1215881?
Pi, If you've tested this on a Vista lemme know.Plz check on WinRC6 coz
there might be
changes in the latest Vista RC; not to mention chrome version changes.
This looks like a k00l bug :P
On Thu, Jun 18, 2009 at 1:53 PM, pi wrote:
>
> Thank Nicolas for your clarify.
>
> Today I find the exception in
> AutocompleteEditViewWin::EraseTopOfSelection is caused by the rong
> compiler option of 2.0.172.28 official build.
>
> autocomplete_edit_view_win.cc:
>
> HDC BeginPaintIntercept(HWND hWnd, LPPAINTSTRUCT lpPaint) {
> BOOL EndPaintIntercept(HWND hWnd, const PAINTSTRUCT* lpPaint) {
>
> These two intercepting win32 API are not explicitly defined as
> __stdcall, and are wrongly compiled as __cdecl:
>
> chrome_1c3!`anonymous namespace'::BeginPaintIntercept:
> 021ea88f
> 021ea8b5 c3 ret
> 021ea8c4 c3 ret
>
> chrome_1c3!`anonymous namespace'::EndPaintIntercept:
> 021ea8c5
> 021ea8d7 c3 ret
> 021ea8e6 c3 ret
>
> This is harmless on windows XP, because the corrupted esp is restored
> by riched20!RichEditWndProc's leave instruction, and the corrupted esi/
> edi/ebx are restored by USER32!InternalCallWinProc.
>
> But it's a disaster on windows 2000, because the corrupted ebx (which
> keeps the AutocompleteEditViewWin this point in
> AutocompleteEditViewWin::OnPaint) is not restored by USER32!
> UserCallWinProc or by USER32!CallWindowProcAorW.
>
> Nicolas Sylvain wrote:
> > I filed this bug with this comment:--
> > TabRestoreUITest.RestoreToDifferentWindow fails on win2k debug. I
> disabled
> > it.
> >
> > This is not reproducible outside the buildbot environment.
> >
> > The problem seems to be that chrome cannot access a font. I was not able
> to
> > determine what the font was.
> > ---
> >
> > Later on I fixed it, but forgot to remove the comment.
> >
> > This bug was only for debug mode, it should not matter for release mode.
> >
> > Nicolas
> >
>
--
"take the red pill."
Akhil Wali
# http://code.google.com/
# http://aebpy.blogspot.com/
# http://twitter.com/darth10
# http://facebook.com/darth10
--~--~-~--~~~---~--~~
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: Conventions and patterns for multi-platform development
This is awesome! A great read and a good use of examples from our code. Is it worth being more explicit about using MVC to design a new component? Right now it's exemplified in the context of how to allocate memory for the various objects, but a concrete example (the TabStripModel is a good one) might be helpful too. On Fri, Jun 19, 2009 at 12:42 PM, Brett Wilson wrote: > > Our team has had somewhat of an ad-hoc approach to organizing code > that's different across platforms. In many cases our approach has been > quite good. In others, less so, and there have also been questions > about what the preferred method for writing a certain component in a > cross-platform way. > > Last night Ben and I wrote a document that tries to clarify this. It's > a combination of what we're doing now that works well, and what we > probably should be doing: > http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development > This is linked to from the "Engineering design documents" page. > > If you're starting a new component or reorganizing an existing one, > try to follow these guidelines. It can't possibly cover every case, so > you'll have to use your best judgement. > > Feedback from people who have done a lot of this stuff would be great. > Ideally it would be easy to follow and cover most cases for everybody. > > Thanks! > Brett > > > > -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Using custom builds of chromium in a commercial setting
I am not a lawyer, but that is the intent. (In some sense Google Chrome is just a commercial consumer of the code base as well. As I understand it, contributors retain copyright on their contributions, so it's not even the case that Google owns all the code that mentions Google in the copyright. See http://code.google.com/legal/individual-cla-v1.0.html ) BTW, Chromium in the "App Mode" is more or less an SSB. On Thu, Jun 18, 2009 at 3:45 AM, JavaJunky wrote: > > Hi folks, > > I'm currently investigating the possibility of using SSBs (Site > Specific Browsers, another example is mozilla's Prism) to ship > alongside a commercial web application, the application does not > depend on the SSB in any way just makes it more acceptable to > corporations who are opposed to updating to more recent web browsers. > > I've spent some time perusing the mailing list, and looking at the T's > and C's that I can locate on the chromium website ( > http://code.google.com/chromium/terms.html ). As far as I can tell > the primary license and all 3rd party licenses are 'commecially > friendly' and as long as the build of chromium doesn't mention Google > or any of the associated trademarks then there should be no problem > shipping a customised build of chromium on a cd alongside a > commercial product. > > Can anyone confirm whether or not this is the case ? > > Many thanks > > - cj. > > > > --~--~-~--~~~---~--~~ 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: V8 Generated Constructors
Ah! That did the trick; thanks. On Jun 19, 10:24 am, Dimitri Glazkov wrote: > Since Audio object will be instantiated via JS, we need to add extra 2 > lines to that huge switch statement in V8Proxy::GetTemplate: > > case V8ClassIndex::HTMLIMAGEELEMENT: > desc->SetCallHandler(USE_CALLBACK(HTMLImageElementConstructor)); > break; > > :DG< > > > > On Fri, Jun 19, 2009 at 10:05 AM, kylep wrote: > > > Ok, I see what you mean, but the macro in v8_proxy.h points to > > DOM_NODE_TYPES in v8_index.h, which includes VIDEO_HTMLELEMENT_TYPES > > (V), which conditionally defines V(HTMLAUDIOELEMENT, > > HTMLAudioElement) if video is enabled (which it is in webkit.gyp). So > > although that's not exactly the same as image, it looks like that > > binding does exist. Just because it's another layer away shouldn't > > mean the audio element isn't a node, correct? I did some more digging, > > and everything looks ok in HTMLElementFactory.cpp... I have no idea > > what I'm still missing. > > > On Jun 18, 8:38 pm, Dimitri Glazkov wrote: > >> You're almost there. You also need to make sure to register it in > >> v8_proxy.cpp (look for Image as a pattern to follow). > > >> BTW, with gyp, dependencies in bindings are pretty robust. No need to > >> clobber anymore. > > >> :DG< > > >> On Thu, Jun 18, 2009 at 4:05 PM, kylep wrote: > > >> > Ok, so. So far I've created a new file > >> > V8HTMLAudioElementConstructor.cpp and modeled it off > >> > V8HTMLImageElementConstructor.cpp (changing all "image"s to "audio"s, > >> > plus modified V8CustomBinding.h and webkit.gyp. Change is here: > >> >http://codereview.chromium.org/132036 > >> > But I'm still getting "TypeError: Illegal constructor" when I try to > >> > call the audio constructor. Is there another hook I'm missing? > > >> > On Jun 16, 11:47 am, Dimitri Glazkov wrote: > >> >> A good place to start would be to look at existing *Constructor.cpp > >> >> files in WebCore/bindings/v8 and see how they are hooked in (like > >> >> Image constructor). Also, you have dimich and levin in close proximity > >> >> you who have added a V8 constructor or two in the past (I think). > > >> >> ;DG< > > >> >> On Mon, Jun 15, 2009 at 5:47 PM, Kyle Prete wrote: > >> >> > Hey I'm looking into these layout tests: > >> >> > LayoutTests/media/audio-constructor-src.html > >> >> > LayoutTests/media/audio-constructor.html > >> >> > LayoutTests/media/constructors.html > >> >> > and I need to know how constructors are generated. The failures all > >> >> > appear > >> >> > to be due to the Audio constructor, specifically: "TypeError: Illegal > >> >> > constructor" > >> >> > 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: IO Request Handing in Chromium
On Thu, Jun 18, 2009 at 12:15 AM, n179911 wrote: > In > http://dev.chromium.org/developers/design-documents/multi-process-resource-loading, > all I/O in Render Process (WebKit code) is sent to Browser Process and > Browser process is download the resource from the source. > But what about Plugins (flash) which runs inside RenderProcess? How can > those I/O requests being forward to Browser Process via chromium IPC > mechanism? Plugins run in their own separate plugin process. > Flash plugins is closed source and it can make more than HTTP request. > Flash can make RTMP request for video. > How does IO in plugin being handled? Requests made through NPAPI get routed back through the browser's HTTP layer. Other requests go directly to the system, as plugin processes are not sandboxed. (In some sense, getting plugins out of the renderer process is a prerequisite for making renderer processes sandboxable.) --~--~-~--~~~---~--~~ 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 chrome_exe to chrome, converting chrome.exe to gyp
Just a heads-up, I imagine the various pages such as
http://dev.chromium.org/developers/how-tos/build-instructions-windows
will now need updating, I managed to do my first build of chrome last
night, and my second one this morning, until I read this post I
thought I was going insane
- cj.
On Jun 18, 8:38 am, Steven Knight wrote:
> Okay, it looks like this change is sticking, at least until someone
> discovers Yet Another Unintended Side Effect. So heed the warnings in the
> previous message, quoted below.
> Git users on Linux: this requires an update to gyp to work properly, so
> make sure you "gclient sync" after you "git pull", or whatever the right
> combination of commands is. If you see Python stack traces from gyp
> accompanied by complaints about looking up a "Dir as a File", make sure the
> tools/gyp subdirectory is at r521.
>
> --SK
>
> On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight wrote:
> > Heads up, again, dept.:
> > In the next in an ongoing series of attempts to convert chrome.exe to gyp,
> > I'm going to (try to) land two changes now that you should be aware of:
>
> > 1) convert the 'app' target in the chrome.gyp file to being named
> > 'chrome'. 2) actually convert the 'chrome_exe' project to using a
> > gyp-generated chrome.vcproj file, instead of the checked-in one.
>
> > When the first change lands, Mac developers will need to look for the new
> > 'chrome' target instead of 'app', and Linux developers who have been typing
> > 'hammer app' (or 'make app' if you're using the Makefile generator) will
> > need to type 'hammer chrome' ('make chrome'). The default behaviors of
> > building everything should be unaffected.
>
> > When the second change lands, Visual Studio users will need to use the
> > 'chrome' project, instead of the former 'chrome_exe' project. NOTE:
> > because the underlying .vcproj file will be completely different, any local
> > settings you've configured into the old 'chrome_exe' project will NOT be
> > transferred to the new 'chrome' project. You'll have to make a note of any
> > custom settings before updating and re-apply them to the new 'chrome'
> > project.
>
> > There's always the chance that one or both of these changes will have to be
> > reverted if unintended side effects pop up. I'll send out confirming email
> > with the final state of things.
>
> > --SK
>
>
--~--~-~--~~~---~--~~
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: IO Request Handing in Chromium
See http://dev.chromium.org/developers/design-documents/plugin-architecturefor some more details. TVL On Fri, Jun 19, 2009 at 1:51 PM, Evan Martin wrote: > > On Thu, Jun 18, 2009 at 12:15 AM, n179911 wrote: > > In > > > http://dev.chromium.org/developers/design-documents/multi-process-resource-loading > , > > all I/O in Render Process (WebKit code) is sent to Browser Process and > > Browser process is download the resource from the source. > > But what about Plugins (flash) which runs inside RenderProcess? How can > > those I/O requests being forward to Browser Process via chromium IPC > > mechanism? > > Plugins run in their own separate plugin process. > > > Flash plugins is closed source and it can make more than HTTP request. > > Flash can make RTMP request for video. > > How does IO in plugin being handled? > > Requests made through NPAPI get routed back through the browser's HTTP > layer. Other requests go directly to the system, as plugin processes > are not sandboxed. > > (In some sense, getting plugins out of the renderer process is a > prerequisite for making renderer processes sandboxable.) > > > > --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
You may also want to say something about TODO(port) and NOTIMPLEMENTED()s vs. bugs. Just some conventions & patterns I could think about. On Fri, Jun 19, 2009 at 18:42, Brett Wilson wrote: > Last night Ben and I wrote a document that tries to clarify this. It's > a combination of what we're doing now that works well, and what we > probably should be doing: > http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development > This is linked to from the "Engineering design documents" page. --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
This is a great overview! Thanks for writing this up. I wonder if it's worth giving some more guidance about when to use #ifdef vs. say splitting out a couple of methods into a platform-specific file. For example: "if you find yourself wrapping the entire body of a function in platform #ifdefs, that may be a sign that it's time to refactor that method into separate per-platform source files; if you find yourself doing so for several methods of a class, it may be time for a helper or delegate class that encapsulates the platform-specific behavior" (example: the platform delegate that let us unfork test_shell_main.cc)." My concern is that #ifdefs can be great for a "spot fix" here and there, but if they start growing, they can get unwieldy very quickly and obscure what code is actually getting run on any given platform. --Amanda On Fri, Jun 19, 2009 at 12:42 PM, Brett Wilson wrote: > > Our team has had somewhat of an ad-hoc approach to organizing code > that's different across platforms. In many cases our approach has been > quite good. In others, less so, and there have also been questions > about what the preferred method for writing a certain component in a > cross-platform way. > > Last night Ben and I wrote a document that tries to clarify this. It's > a combination of what we're doing now that works well, and what we > probably should be doing: > http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development > This is linked to from the "Engineering design documents" page. > > If you're starting a new component or reorganizing an existing one, > try to follow these guidelines. It can't possibly cover every case, so > you'll have to use your best judgement. > > Feedback from people who have done a lot of this stuff would be great. > Ideally it would be easy to follow and cover most cases for everybody. > > Thanks! > 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 9:42 AM, Brett Wilson wrote: > > Our team has had somewhat of an ad-hoc approach to organizing code > that's different across platforms. In many cases our approach has been > quite good. In others, less so, and there have also been questions > about what the preferred method for writing a certain component in a > cross-platform way. > > Last night Ben and I wrote a document that tries to clarify this. It's > a combination of what we're doing now that works well, and what we > probably should be doing: > > http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development > This is linked to from the "Engineering design documents" page. > > If you're starting a new component or reorganizing an existing one, > try to follow these guidelines. It can't possibly cover every case, so > you'll have to use your best judgement. > > Feedback from people who have done a lot of this stuff would be great. > Ideally it would be easy to follow and cover most cases for everybody. I have a feedback from someone who did not do a lot of this stuff. We should say that we prefer "#if defined(OS_WIN)" over "#ifdef OS_WIN". I always ask myself before doing it, and get confused by seeing the two used in our code base (and even in the same file, like canvas.h) Nicolas > > > Thanks! > 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain wrote: > We should say that we prefer "#if defined(OS_WIN)" over "#ifdef OS_WIN". > In general, you should always prefer "#if defined(FOO)" over "#ifdef FOO", e.g. because you can add "|| defined(BAR)" to the former later. 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 2:11 PM, Peter Kasting wrote: > On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain > wrote: >> >> We should say that we prefer "#if defined(OS_WIN)" over "#ifdef OS_WIN". > > In general, you should always prefer "#if defined(FOO)" over "#ifdef FOO", > e.g. because you can add "|| defined(BAR)" to the former later. > PK This is already documented in our Chromium coding style guide. Do we need to replicate it? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 11:15 AM, Mike Pinkerton wrote: > This is already documented in our Chromium coding style guide. Do we > need to replicate it? No, I was just mentioning that it was a broad principle, not restricted to cross-platform ifdefs. 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: Conventions and patterns for multi-platform development
On Fri, Jun 19, 2009 at 11:15 AM, Mike Pinkerton wrote: > On Fri, Jun 19, 2009 at 2:11 PM, Peter Kasting wrote: > > On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain > > > wrote: > >> > >> We should say that we prefer "#if defined(OS_WIN)" over "#ifdef > OS_WIN". > > > > In general, you should always prefer "#if defined(FOO)" over "#ifdef > FOO", > > e.g. because you can add "|| defined(BAR)" to the former later. > > PK > > This is already documented in our Chromium coding style guide. Do we > need to replicate it? Oops. It was not there when I look at the coding style a long time ago.. Nevermind! Thanks Nicolas > > > -- > Mike Pinkerton > Mac Weenie > pinker...@google.com > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Tagging WebKit bugs with [Chromium]
I think this is a really good idea, something Maciej has been doing for us in bugs.webkit.org: Anytime you create a WebKit bug that's specific to Chromium port, please add [Chromium] prefix to the bug title. :DG< --~--~-~--~~~---~--~~ 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: Tagging WebKit bugs with [Chromium]
On Fri, Jun 19, 2009 at 11:51 AM, Dimitri Glazkov wrote: > Anytime you create a WebKit bug that's specific to Chromium port, > please add [Chromium] prefix to the bug title. Note: DON'T do this is this is a cross-platform fix that happens to have been found by/affect Chromium. ONLY do this for fixes that are Chromium-specific, or you will delay your patch's review. 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] Icelandic dictionary for Chrome
I'm hoping to be able to add Icelandic spelling check to Chrome Before I invest a lot of time I have some quick questions/observations: I found an myspell/aspell dictionary for Open Office here: http://wiki.services.openoffice.org/wiki/Dictionaries#Icelandic_.28Iceland.29 and converted it to bdic format using the instructions here: http://dev.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries. When I replace a supported bdic with this one I can spell check mostly but seen errors such as: Run-Time Check Failure #2 - Stack around the variable 'candidate' was corrupted. (suggestmgr.cxx:680). Any pointers on where to start? I don't know if the dictionary/conversion are at fault or hunspell. Distribution: If I get this to more or less work - how would it possible to distribute it? I want of course the Language Selection UI to have Icelandic and support automatic download of the dictionary. Improvement: If I find issues with either hunspell or the dictionary itself should I work on it in the context of hunspell (which seems to be dormant from their dev mailing list) or what? For the curious more information on Icelandic is here: http://www.iceland.is/history-and-culture/Language/#Grammar Sverrir --~--~-~--~~~---~--~~ 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: Icelandic dictionary for Chrome
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Berg wrote: > I'm hoping to be able to add Icelandic spelling check to Chrome Before I > invest a lot of time I have some quick questions/observations: > I found an myspell/aspell dictionary for Open Office > here: http://wiki.services.openoffice.org/wiki/Dictionaries#Icelandic_.28Iceland.29 and converted > it to bdic format using the instructions > here: http://dev.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries. > When I replace a supported bdic with this one I can spell check mostly but > seen errors such as: > Run-Time Check Failure #2 - Stack around the variable 'candidate' was > corrupted. (suggestmgr.cxx:680). > Any pointers on where to start? I don't know if the dictionary/conversion > are at fault or hunspell. Yikes! I have no good input. Most of these bugs have been caused by the code reading the custom format or in its interaction with the rest of Hunspell. 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: Icelandic dictionary for Chrome
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Berg wrote: > Distribution: If I get this to more or less work - how would it possible to > distribute it? I want of course the Language Selection UI to have Icelandic > and support automatic download of the dictionary. Sounds like a question best brought up with a lawyer, just to be sure. > Improvement: If I find issues with either hunspell or the dictionary itself > should I work on it in the context of hunspell (which seems to be dormant > from their dev mailing list) or what? It's always polite to send stuff upstream first, but don't let that stop you from making fixes locally if the project has stopped. I'd expect the dictionary owners at least would welcome your changes. --~--~-~--~~~---~--~~ 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 chrome_exe to chrome, converting chrome.exe to gyp
Ok so I've tracked down the issue with 'test_shell' not working as a command line target.The issue is that folders in the solution hierarchy apparently cause an ambiguity so devenv doesn't know which one you're referring to, the test_shell folder or the test_shell project. So for instance base_unittests works as a target, but not base. Sigh. Simplest fix I can think of is add a slash to all the folder names. base/ test_shell/ etc. -BradN On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee wrote: > This also broke building from the command line. > > I usually never open Visual Studio as an IDE. I build on the command > line with something like: > > devenv chrome\\chrome.sln /Build release /Project test_shell > > It looks like project names like test_shell now have complicated names > like "test_shell (webkit\tools\test_shell\test_shell)", and I haven't > been able to manage supplying those on the command line. > > Is there a way we can get back our nice project names "test_shell", > "chrome", etc? > > On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkus > wrote: > > Here's a quick example: > > 1) Delete whole Debug directory > > 2) gclient runhooks --force > > 3) Set test_shell as startup project > > 4) Hit F5 > > Sample output of things that shouldn't be dependencies (mostly because > > they're other executables) > > sandbox (sandbox\sandbox) - Debug Win32 > > chrome_dll - Debug Win32 > > net_perftests - Debug Win32 > > base_unittests - Debug Win32 > > net_unittests - Debug Win32 > > v8_shell - Debug Win32 > > mini_installer - Debug Win32 > > test_support_unit - Debug Win32 > > test_support_ui - Debug Win32 > > codesighs (third_party\codesighs\codesighs) - Debug Win32 > > automated_ui_tests - Debug Win32 > > memory_test - Debug Win32 > > activex_test_control - Debug Win32 > > > > On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson > > wrote: > >> > >> Andrew, can you give an example of something that built that shouldn't > >> have for test_shell? Maybe we have some overspecified dependencies as > well. > >> > >> -BradN > >> > >> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus > > >> wrote: > >>> > >>> I'll see if I can repro this again before filing a bug, but similar to > >>> what Daniel and John reported, when I right click on test_shell and say > >>> Build it builds the minimal set required to fully build+link > test_shell.exe > >>> However when I set test_shell as the start-up project and launch the > >>> debugger, Visual Studio warns that every other project in chrome.sln > must be > >>> > built before running (not true!). Is there a difference in build vs. runtime > dependencies? > >>> Andrew > >>> > >>> On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight > wrote: > > All-- > When you notice missing dependencies, pleased add them to the > necessary > .gyp file(s)! One of the main reasons we've been trying to land all > this > stuff is so that tracking down all these pieces isn't single-threaded > through one person (or two). If you're not comfortable making the > change > yourself, then please file a bug so the dependency problems get > tracked and > fixed in an organized fashion. > Re: unnecessary rebuilds: please file bugs so they don't get lost. > Please include the target you were building, and the the libs/targets > that > were rebuilt unnecessarily. You don't have to be exhaustive about the > list, > it's more important here that at least some information gets collected > and > doesn't languish on the ML or get dropped on the floor. > I'm working on a buildbot script that will test for missing > dependencies > by building every target from scratch individually, and will then test > for > unnecessary rebuilds by rebuilding each target after no updates. > That's > been taking a back seat to just getting the conversion completed, but > I've > accelerated my work on it as we wind down to the last few targets. > --SK > > On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek > wrote: > > > > > > On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek > > > wrote: > >> > >> Yeah it happened to me before as well, I just figured I'd complain > >> now.. Note another missing dependency is on crash_service.exe > >> , npapi_layout_test_plugin, and npapi_test_plugin > > > > btw just to be clear, these are missing dependencies on ui_tests. > > > >> > >> On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow > >> wrote: > >>> > >>> I actually had this problem _before_ this change. Guess I should > >>> have brought it up, but I figured it was just something funny on my > system. > >>> > >>> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek < > j...@chromium.org> > >>> wrote: > > +1 this is affecting a lot of people. > > On Thu, Jun 18,
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Is building the folder expected behaviour, or something we should file with Microsoft? Could just be me but "Build " seems pretty unambiguous that I want to build a project and not a folder... Thanks for looking into the issue! Andrew On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson wrote: > Ok so I've tracked down the issue with 'test_shell' not working as a > command line target.The issue is that folders in the solution hierarchy > apparently cause an ambiguity so devenv doesn't know which one you're > referring to, the test_shell folder or the test_shell project. > So for instance base_unittests works as a target, but not base. Sigh. > > Simplest fix I can think of is add a slash to all the folder names. base/ > test_shell/ etc. > > -BradN > > On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee wrote: > >> This also broke building from the command line. >> >> I usually never open Visual Studio as an IDE. I build on the command >> line with something like: >> >> devenv chrome\\chrome.sln /Build release /Project test_shell >> >> It looks like project names like test_shell now have complicated names >> like "test_shell (webkit\tools\test_shell\test_shell)", and I haven't >> been able to manage supplying those on the command line. >> >> Is there a way we can get back our nice project names "test_shell", >> "chrome", etc? >> >> On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkus >> wrote: >> > Here's a quick example: >> > 1) Delete whole Debug directory >> > 2) gclient runhooks --force >> > 3) Set test_shell as startup project >> > 4) Hit F5 >> > Sample output of things that shouldn't be dependencies (mostly because >> > they're other executables) >> > sandbox (sandbox\sandbox) - Debug Win32 >> > chrome_dll - Debug Win32 >> > net_perftests - Debug Win32 >> > base_unittests - Debug Win32 >> > net_unittests - Debug Win32 >> > v8_shell - Debug Win32 >> > mini_installer - Debug Win32 >> > test_support_unit - Debug Win32 >> > test_support_ui - Debug Win32 >> > codesighs (third_party\codesighs\codesighs) - Debug Win32 >> > automated_ui_tests - Debug Win32 >> > memory_test - Debug Win32 >> > activex_test_control - Debug Win32 >> > >> > On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson >> > wrote: >> >> >> >> Andrew, can you give an example of something that built that shouldn't >> >> have for test_shell? Maybe we have some overspecified dependencies as >> well. >> >> >> >> -BradN >> >> >> >> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus < >> scher...@chromium.org> >> >> wrote: >> >>> >> >>> I'll see if I can repro this again before filing a bug, but similar to >> >>> what Daniel and John reported, when I right click on test_shell and >> say >> >>> Build it builds the minimal set required to fully build+link >> test_shell.exe >> >>> However when I set test_shell as the start-up project and launch the >> >>> debugger, Visual Studio warns that every other project in chrome.sln >> must be >> >>> >> built before running (not true!). Is there a difference in build vs. >> runtime dependencies? >> >>> Andrew >> >>> >> >>> On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight >> wrote: >> >> All-- >> When you notice missing dependencies, pleased add them to the >> necessary >> .gyp file(s)! One of the main reasons we've been trying to land all >> this >> stuff is so that tracking down all these pieces isn't single-threaded >> through one person (or two). If you're not comfortable making the >> change >> yourself, then please file a bug so the dependency problems get >> tracked and >> fixed in an organized fashion. >> Re: unnecessary rebuilds: please file bugs so they don't get lost. >> Please include the target you were building, and the the >> libs/targets that >> were rebuilt unnecessarily. You don't have to be exhaustive about >> the list, >> it's more important here that at least some information gets >> collected and >> doesn't languish on the ML or get dropped on the floor. >> I'm working on a buildbot script that will test for missing >> dependencies >> by building every target from scratch individually, and will then >> test for >> unnecessary rebuilds by rebuilding each target after no updates. >> That's >> been taking a back seat to just getting the conversion completed, but >> I've >> accelerated my work on it as we wind down to the last few targets. >> --SK >> >> On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek > > >> wrote: >> > >> > >> > On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek < >> j...@chromium.org> >> > wrote: >> >> >> >> Yeah it happened to me before as well, I just figured I'd complain >> >> now.. Note another missing dependency is on crash_service.exe >> >> , npapi_layout_test_plugin, and npapi_test_plugin >> > >> > btw just to be clear, these are missing dependencies on ui_tests
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
I wonder if it would suffice to reorder the project blocks:
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "test_shell",
"webkit\tools\test_shell", "{6CB66C51-6A84-2C9C-0561-7D059D26064E}"
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "test_shell",
"..\webkit\tools\test_shell\test_shell.vcproj",
"{FA39524D-3067-4141-888D-28A86C66F2B9}"
- nick
On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson wrote:
> Ok so I've tracked down the issue with 'test_shell' not working as a
> command line target.The issue is that folders in the solution hierarchy
> apparently cause an ambiguity so devenv doesn't know which one you're
> referring to, the test_shell folder or the test_shell project.
> So for instance base_unittests works as a target, but not base. Sigh.
>
> Simplest fix I can think of is add a slash to all the folder names. base/
> test_shell/ etc.
>
> -BradN
>
> On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee wrote:
>
>> This also broke building from the command line.
>>
>> I usually never open Visual Studio as an IDE. I build on the command
>> line with something like:
>>
>> devenv chrome\\chrome.sln /Build release /Project test_shell
>>
>> It looks like project names like test_shell now have complicated names
>> like "test_shell (webkit\tools\test_shell\test_shell)", and I haven't
>> been able to manage supplying those on the command line.
>>
>> Is there a way we can get back our nice project names "test_shell",
>> "chrome", etc?
>>
>> On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkus
>> wrote:
>> > Here's a quick example:
>> > 1) Delete whole Debug directory
>> > 2) gclient runhooks --force
>> > 3) Set test_shell as startup project
>> > 4) Hit F5
>> > Sample output of things that shouldn't be dependencies (mostly because
>> > they're other executables)
>> > sandbox (sandbox\sandbox) - Debug Win32
>> > chrome_dll - Debug Win32
>> > net_perftests - Debug Win32
>> > base_unittests - Debug Win32
>> > net_unittests - Debug Win32
>> > v8_shell - Debug Win32
>> > mini_installer - Debug Win32
>> > test_support_unit - Debug Win32
>> > test_support_ui - Debug Win32
>> > codesighs (third_party\codesighs\codesighs) - Debug Win32
>> > automated_ui_tests - Debug Win32
>> > memory_test - Debug Win32
>> > activex_test_control - Debug Win32
>> >
>> > On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson
>> > wrote:
>> >>
>> >> Andrew, can you give an example of something that built that shouldn't
>> >> have for test_shell? Maybe we have some overspecified dependencies as
>> well.
>> >>
>> >> -BradN
>> >>
>> >> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus <
>> scher...@chromium.org>
>> >> wrote:
>> >>>
>> >>> I'll see if I can repro this again before filing a bug, but similar to
>> >>> what Daniel and John reported, when I right click on test_shell and
>> say
>> >>> Build it builds the minimal set required to fully build+link
>> test_shell.exe
>> >>> However when I set test_shell as the start-up project and launch the
>> >>> debugger, Visual Studio warns that every other project in chrome.sln
>> must be
>> >>>
>> built before running (not true!). Is there a difference in build vs.
>> runtime dependencies?
>> >>> Andrew
>> >>>
>> >>> On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight
>> wrote:
>>
>> All--
>> When you notice missing dependencies, pleased add them to the
>> necessary
>> .gyp file(s)! One of the main reasons we've been trying to land all
>> this
>> stuff is so that tracking down all these pieces isn't single-threaded
>> through one person (or two). If you're not comfortable making the
>> change
>> yourself, then please file a bug so the dependency problems get
>> tracked and
>> fixed in an organized fashion.
>> Re: unnecessary rebuilds: please file bugs so they don't get lost.
>> Please include the target you were building, and the the
>> libs/targets that
>> were rebuilt unnecessarily. You don't have to be exhaustive about
>> the list,
>> it's more important here that at least some information gets
>> collected and
>> doesn't languish on the ML or get dropped on the floor.
>> I'm working on a buildbot script that will test for missing
>> dependencies
>> by building every target from scratch individually, and will then
>> test for
>> unnecessary rebuilds by rebuilding each target after no updates.
>> That's
>> been taking a back seat to just getting the conversion completed, but
>> I've
>> accelerated my work on it as we wind down to the last few targets.
>> --SK
>>
>> On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek > >
>> wrote:
>> >
>> >
>> > On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek <
>> j...@chromium.org>
>> > wrote:
>> >>
>> >> Yeah it happened to me before as well, I just figured I'd complain
>> >> now.. Note another missing dependency is on crash_service.exe
>> >> , npapi_lay
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
It doesn't seem to, am I missing something?-BradN
On Fri, Jun 19, 2009 at 3:06 PM, Nick Carter wrote:
> I wonder if it would suffice to reorder the project blocks:
> Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "test_shell",
> "webkit\tools\test_shell", "{6CB66C51-6A84-2C9C-0561-7D059D26064E}"
> Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "test_shell",
> "..\webkit\tools\test_shell\test_shell.vcproj",
> "{FA39524D-3067-4141-888D-28A86C66F2B9}"
>
> - nick
>
> On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson wrote:
>
>> Ok so I've tracked down the issue with 'test_shell' not working as a
>> command line target.The issue is that folders in the solution hierarchy
>> apparently cause an ambiguity so devenv doesn't know which one you're
>> referring to, the test_shell folder or the test_shell project.
>> So for instance base_unittests works as a target, but not base. Sigh.
>>
>> Simplest fix I can think of is add a slash to all the folder names. base/
>> test_shell/ etc.
>>
>> -BradN
>>
>> On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee wrote:
>>
>>> This also broke building from the command line.
>>>
>>> I usually never open Visual Studio as an IDE. I build on the command
>>> line with something like:
>>>
>>> devenv chrome\\chrome.sln /Build release /Project test_shell
>>>
>>> It looks like project names like test_shell now have complicated names
>>> like "test_shell (webkit\tools\test_shell\test_shell)", and I haven't
>>> been able to manage supplying those on the command line.
>>>
>>> Is there a way we can get back our nice project names "test_shell",
>>> "chrome", etc?
>>>
>>> On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkus
>>> wrote:
>>> > Here's a quick example:
>>> > 1) Delete whole Debug directory
>>> > 2) gclient runhooks --force
>>> > 3) Set test_shell as startup project
>>> > 4) Hit F5
>>> > Sample output of things that shouldn't be dependencies (mostly because
>>> > they're other executables)
>>> > sandbox (sandbox\sandbox) - Debug Win32
>>> > chrome_dll - Debug Win32
>>> > net_perftests - Debug Win32
>>> > base_unittests - Debug Win32
>>> > net_unittests - Debug Win32
>>> > v8_shell - Debug Win32
>>> > mini_installer - Debug Win32
>>> > test_support_unit - Debug Win32
>>> > test_support_ui - Debug Win32
>>> > codesighs (third_party\codesighs\codesighs) - Debug Win32
>>> > automated_ui_tests - Debug Win32
>>> > memory_test - Debug Win32
>>> > activex_test_control - Debug Win32
>>> >
>>> > On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson >> >
>>> > wrote:
>>> >>
>>> >> Andrew, can you give an example of something that built that shouldn't
>>> >> have for test_shell? Maybe we have some overspecified dependencies as
>>> well.
>>> >>
>>> >> -BradN
>>> >>
>>> >> On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus <
>>> scher...@chromium.org>
>>> >> wrote:
>>> >>>
>>> >>> I'll see if I can repro this again before filing a bug, but similar
>>> to
>>> >>> what Daniel and John reported, when I right click on test_shell and
>>> say
>>> >>> Build it builds the minimal set required to fully build+link
>>> test_shell.exe
>>> >>> However when I set test_shell as the start-up project and launch the
>>> >>> debugger, Visual Studio warns that every other project in chrome.sln
>>> must be
>>> >>>
>>> built before running (not true!). Is there a difference in build vs.
>>> runtime dependencies?
>>> >>> Andrew
>>> >>>
>>> >>> On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight
>>> wrote:
>>>
>>> All--
>>> When you notice missing dependencies, pleased add them to the
>>> necessary
>>> .gyp file(s)! One of the main reasons we've been trying to land all
>>> this
>>> stuff is so that tracking down all these pieces isn't
>>> single-threaded
>>> through one person (or two). If you're not comfortable making the
>>> change
>>> yourself, then please file a bug so the dependency problems get
>>> tracked and
>>> fixed in an organized fashion.
>>> Re: unnecessary rebuilds: please file bugs so they don't get lost.
>>> Please include the target you were building, and the the
>>> libs/targets that
>>> were rebuilt unnecessarily. You don't have to be exhaustive about
>>> the list,
>>> it's more important here that at least some information gets
>>> collected and
>>> doesn't languish on the ML or get dropped on the floor.
>>> I'm working on a buildbot script that will test for missing
>>> dependencies
>>> by building every target from scratch individually, and will then
>>> test for
>>> unnecessary rebuilds by rebuilding each target after no updates.
>>> That's
>>> been taking a back seat to just getting the conversion completed,
>>> but I've
>>> accelerated my work on it as we wind down to the last few targets.
>>> --SK
>>>
>>> On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek <
>>> j...@chromium.org>
>>> wrote:
>>> >
>>> >
>>> > O
[chromium-dev] Re: Gmock compilation errors on VS2008SP1
If you didn't see my other mail to chromium-dev, I'll be trying to whack the tr1 dependency next week. That should hopefully fix the issue you were having. Will update this thread again when the patch is committed. -Albert On Mon, Jun 15, 2009 at 9:11 AM, Albert J. Wong (王重傑) wrote: > > > On Mon, Jun 15, 2009 at 9:03 AM, nakro wrote: > >> >> Hi albret, >> >> projects that fail : >> gmockj >> gmockmain >> >> here is an example out from gmockmain >> >> C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : >> error C2065: '_Is_swap_move' : undeclared identifier >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple >> (504) : see reference to class template instantiation >> >> 'std::_Move_operation_category>' >> being compiled >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : >> error C2226: syntax error : unexpected type >> 'std::_Move_operation_category<_Value>::_Move_cat' >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : >> error C2947: expecting '>' to terminate template-argument-list, found >> '>' >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : >> error C2976: 'std::_If' : too few template arguments >> 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include >> \xutility(1018) : see declaration of 'std::_If' >> >> the solution on my machine is this >> to do HAS_TR1=0 (you have 1 by default) >> and to change >> >> gmock_port.h >> >> to include the boost version even on 2008, which initially your code >> goes to the path > > > That's a good workaround. Switching to the boost implementation would > almost certainly work for now. > > I'll attempt to reproduce and figure out a long term fix (including just > whacking the tr1 dependency out of gmock...started a discussion with > zhanyong about this last week). > > If it gets bad enough, we could consider changing over the VS2008 builds to > use boost as well, and then disable _HAS_TR1 as you described above, but > that'll require a full clobber from everyone due to precompiled header > issues. > > -Albert > > > >> >> >> but i must have something wrong with my machine if i am the only one >> who is having this >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
