[chromium-dev] Re: dtrace and chromium?

[Miguel F Mascarenhas Sousa Filipe]

Hi,

What about a mix of:
- oprofile
- valgrind
- sysprof
- systemtap ? (on a RHEL 5 system)

I use the first two a lot, sysprof also looks promissing.

SystemTap, never used it, supposedly it can be used on rhel kernels to
perform tasks similar to what dtrace allows.

Kind Regards,


On Tue, Jan 13, 2009 at 4:57 PM, Evan Martin  wrote:
>
> This may be naive, but I expect what we have right now ought to be
> pretty close to working on Solaris anyway.  It might be quicker to
> just fix the few places it doesn't work.  (I wouldn't normally expect
> this of a Linux port of software in general, but we're also sharing
> all this code with OS X so it should be POSIX safe...)
>
> A friend of mine uses a VM with Solaris explicitly so he can use
> dtrace to analyze his Linux-based system software.
>
> On Tue, Jan 13, 2009 at 8:42 AM, DanKegel  wrote:
>>
>> I'm looking at Linux performance tools and checking
>> to see if there's a dtrace-shaped hole.
>> It might be fun to try running our linux app on Solaris
>> using BrandZ (their linux compatiblity environment).
>> Or, perhaps the code fairy will grant us a wish
>> and port it to Linux.  (Someone's trying; see
>> http://lwn.net/Articles/298685/
>> http://www.crisp.demon.co.uk/blog/ )
>>
>> I don't know how he's going about the kernel
>> part.  Presumably he's rewriting that from
>> scratch.  AFAIK, the license conflict between
>> the original dtrace code and linux only affects
>> kernel code, and the dtrace userspace code
>> can be used under its current license.
>> - Dan
>>
>> On Jan 12, 5:25 pm, Amanda Walker  wrote:
>>> I expect dtrace to be downright crucial once we get to performance
>>> measurement and improvement, especially in an execution environment
>>> that involves communication among multiple processes.  Apple ships
>>> both dtrace and a nice graphical frontend to it called "Instruments"
>>> as a part of the Xcode development environment.
>>>
>>> Is there a specific aspect you're interested in?
>>>
>>> --Amanda
>>>
>>> On Mon, Jan 12, 2009 at 7:27 PM, Dan Kegel  wrote:
>>>
>>> > Hey mac chrome developers,
>>> > how useful is / will dtrace be for chrome development on macosx?
>>> > (Beyond things like dtruss, I mean.)
>>> > Is it going to be important for tracking down performance
>>> > issues?
>>> > Thanks,
>>> > Dan
>>>
>>> --
>>> --Amanda
>> >
>>
>
> >
>



-- 
Miguel Sousa Filipe

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] 5 bugs, top 30% of crash reports in 2.0.157.2 (Dev channel release)

[Anthony LaForge]

Hey Team,

For the dev channel release: 2.0.157.2 our 5 top crashers are below w/ bugs.
 Please note that at this time only 2 out of 5 of the bugs are assigned.  If
you have some cycles to grab one of these please don't hesitate.


*Signature(s)**Bug**Percent Clients**Percent Reports**Column1**Status**Owner
**Area*NavigationController::DiscardNonCommittedEntries()-4D55B7(all
versions)6392  16.74%12.67% Untriaged---
BrowserBackendlinked_ptr::depart()-556B15(all versions)
6207  11.16%8.62%Problems reproducing, help from QA
AssignedjcampanBrowserUIRenderViewHostManager::UpdateRendererStateNavigate(NavigationEntry
const &)-5D2D85(all versions)   WebCore::RGBA32Buffer::setRGBA(unsigned
int *,unsigned char,unsigned char,unsigned char,unsigned char)-1AF79A4(all
versions)6307  3.22%3.17% Available---WebKit
WebCore::StringImpl::hash()-E02BA3(all versions)6315
 2.79%2.79% Available---WebKit-69CA16D3(all
versions)6306
 2.15%2.03% AssignedjcampanBrowserUI









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-dev] What is up with the test PreservedWindowPlacementIsLoaded?

[Jon]

While triaging the new Purify bugs I noticed that one test was showing up in
a lot of cases.  Here is the list:
http://code.google.com/p/chromium/issues/list?can=2&q=label:stable+label:purify+PreservedWindowPlacementIsLoaded


It would be great if these fourteen failures were all somehow related.
 Several of the purify errors only occur in this one test.

Jon

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Why do you use SCONS ?

[Elliot Glaysher (Chromium)]

> So, how do SCons improve the dependency checking and the
> autoconfiguration?

This is a totally different issue.

When I'm talking about dependency checking, I'm talking about
dependencies between files in the source. So let's say I change a
header file, and three .cc files #include it. SCons will rebuild those
three cc files automatically because scons has machinery to check what
files a C++ file depends on by reading the actual source/header files
(and allows you to write your own scanners for your own file types).
Like Makefiles, you can manually specify dependencies in your
SConscript if you want, but except for custom build steps, it's easier
and more accurate to let scons figure all the dependency stuff out for
you.

The upside to this is that I almost never "make clean". I don't have
to. SCons figures what needs rebuilding on its own so I don't get left
with incomplete or corrupted builds. Since it's built into scons, it's
not as fragile as "make depend" which I've seen break in some very
weird ways...

> I saw that some SConscript (see src/build/SConscript.main) uses pkg-
> config to get rigth package configuration (for compilation, and
> linking).
> [...]

I've gushed a bit about scons. Let's turn to the downsides:

I would argue that SCons Achilles' heel would be it's checking of
packages and properties of the host system. It's "./configure"
equivalent is nowhere near as robust as autoconf, though I personally
feel that the ease of use is a valid trade off.

Also: speed. All the file scanning for dependencies slows scons down a
bit. (Among other things). I think that it's overall a net time win
compared to having weird crashes that go away with a full rebuild, but
that's a personal opinion.

-- Elliot

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

Re: Fwd: [chromium-dev] Re: Why do you use SCONS ?

[Adam Langley]

On Fri, Jan 16, 2009 at 2:44 PM, giamas  wrote:
> So, how do SCons improve the dependency checking and the
> autoconfiguration?

The dependency checking that we need is when a single file gets
changed. Visual Studio certainly gets it wrong all the time, but I've
rarely had a case where scons has gone wrong. This leads to faster
builds because one doesn't have to do full rebuilds as often.

> I respect the choiche of SCons, but I come from the usage of autotools/
> autoconf/m4/libtool/make.

So things can only get better? :)


AGL

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

Re: Fwd: [chromium-dev] Re: Why do you use SCONS ?

[giamas]

Thanks for you reply.
I still have some issue regarding "... proper dependency checking" of
SCons.

I saw that some SConscript (see src/build/SConscript.main) uses pkg-
config to get rigth package configuration (for compilation, and
linking).
Moreover, current Chromium Source Tree has all the needed libraries
inside him (see src/thidr_party/*), and in this way we don't need to
check packages installed with the Linux Distribution.
So, how do SCons improve the dependency checking and the
autoconfiguration?

I respect the choiche of SCons, but I come from the usage of autotools/
autoconf/m4/libtool/make.

GM



On Jan 16, 9:34 pm, "Elliot Glaysher (Chromium)" 
wrote:
> > Usually Open Source projects use CMake Construction Tool Kit.
>
> Off the top of my head, KDE 4.x is the only project I know of that
> uses CMake, (which is different from the old unix make).
>
> From your first email:
>
> > Usually, Open Source projects use Make.
>
> Very few open source projects use unix make exclusively because
> Makefiles aren't sufficiently powerful to do much of anything. Without
> massive, ugly hacks you can't get things like proper dependency
> checking.
>
> Most open source projects don't use make, but the full GNU
> autotools/autoconf/m4/libtool/make toolchain which automatically
> builds unix Makefiles from a set of simpler input scripts. Much has
> been written about autotools's shortcomings, so I'll just say that
> autotools is not a good solution, and for larger projects, it often
> isn't adequate. (See KDE's transition first to SCons, and then to
> CMake). Things get even worse when you throw windows support into the
> mix.
>
> There is a minority of projects which do use just unix make, but to be
> portable, they need to distribute a Makefile for each
> architecture/system combination, which is also not really acceptable.
> For example, Sleepycat libdb ships with about 50 Makefiles. This is
> not a solution that scales!
>
> make isn't really a good solution which is why there's been an endless
> procession of build systems to replace it and why each non-C language
> seems to have its own build system trying to replace or supplement
> make (OCaml has OMake, Haskell has hmake, perl has a module that spits
> out complex Makefiles, python has its own build system for modules and
> SCons, ruby has rake (among others), java has ant (among others), and
> there's jam (and a bunch of jam derivatives) in the C++ space).
>
> > Onlywww.scons.orghas a comparison table .. but obviously it is'nt
> > fair.
>
> Really? I found both the feature list on the scons homepage and their
> dedicated comparisson page (http://scons.org/wiki/SconsVsOtherBuildTools) to 
> be pretty fair,
> listing both the pros and the cons of each system.
>
> -- Elliot
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: layout tests for printing

[Marc-Antoine Ruel]

No and that needs to be added. I think it should be something I should
focus on this quarter in fact. This obviously involves fixing
test_shell to be able to print.


On Fri, Jan 16, 2009 at 4:47 PM, Marshall Greenblatt
 wrote:
> Hi All,
>
> Do we currently have layout tests that specifically target printing output?
> If not, how feasible would it be to create them?  As an example of something
> currently broken for printing that a layout test might be able to catch: if
> you print a google search result page you'll notice that the baselines of
> bold and non-bold text don't line up.
>
> Regards,
> Marshall
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] layout tests for printing

[Marshall Greenblatt]

Hi All,

Do we currently have layout tests that specifically target printing output?
If not, how feasible would it be to create them?  As an example of something
currently broken for printing that a layout test might be able to catch: if
you print a google search result page you'll notice that the baselines of
bold and non-bold text don't line up.

Regards,
Marshall

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Stabilization Effort Daily Report

[Jon]

*Report for 2009-1-16*

We continue to make great progress on layout tests and we are ahead of pace
to finish by the end of the quarter.  Of course most of these early wins are
low-hanging fruit so we will eat into that lead as we move along but I have
to say that I love the look of this chart!


The Stability burndown chart got reset when a batch of un-reported Purify
bugs dropped in today.  To get those under control our bug squashing needs
to be at the rate of 6 a day for the next four weeks.  Many of these Purify
issues should be straightforward so I hope we can make up some ground
quickly.  I reset the blue line to reflect the required pace.

I still need an owner for this bug:

  Issue 5541 :
REGRESSION:
bad drop-shadow rendering


 *Layout Tests*

Since Monday we have resolved over 100 layout test failures!  That is more
than twice the pace we need to stay on target.  We also passed the 95% park
for tests we Want to Pass!  Fantastic!
  [image: All+Tests=77.5][image: Want+To+Pass=95.1]



[image: History of passing tests
%]
 Be sure to sign up at
http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJA&hl=en if you
are going to work on a layout test.  We don't want to step on each other's
toes.

All Tests is based on all available layout tests including those that we are
currently not trying to pass.  There are tests in this group which are known
to be bad or relate to future technologies.


Want to Pass is based on the tests that we need to be passing before we will
ship a revision of the browser.  Getting this number as high as possible is
the goal of the stabilization effort.  Some of these tests are failing due
to subtle changes that require the test to be re-baselined.



Crashers

Of the 24 crashers we have assigned to "stable" we have resolved 7.  That is
two more than yesterday.  We have been adding crashers to this list but I
have also been trying to weed out any that I can.


*Purify Bugs (Memory)*

We have resolved 20 of the 72 Purify issues.  There was a big batch of
Purify bugs that had not been entered into the bug tracker so if you look at
the chart you will see an explosion of issues.  Therefore I have reset the
blue line to take these into account.  There may be another 15 coming.


*Regressions*

We have resolved 18 of 28 regressions. We resolved one additional regression
since yesterday.


*Other bugs*

We have also resolved 21 of the 49 "other" bugs.


So our bug burndown chart looks like this:

   We have popped above the blue line but we are making great progress on
layout tests.  As long as we keep the red line below the blue line we are on
track for the bugs.  Keep in mind that this does not include the work on
Layout Tests.

You will find a lot more information about the Stabilization effort on the
Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why do you use SCONS ?

[Dan Kegel]

On Fri, Jan 16, 2009 at 12:34 PM, Elliot Glaysher (Chromium)
 wrote:
>> Usually Open Source projects use CMake Construction Tool Kit.
>
> Off the top of my head, KDE 4.x is the only project I know of that
> uses CMake, (which is different from the old unix make).

There are a few others; http://www.cmake.org/Wiki/CMake_Projects

I think scons was chosen simply because it's powerful
and flexible.  (I hate it, too, btw., but I respect what it can do,
and I don't hate it enough to rip it out.)

If somebody wanted to put together a CMake build for
Chromium that supported all three platforms well,
it would be fun to do a head-to-head comparison
to see how it compared in clarity and performance.
- Dan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

Fwd: [chromium-dev] Re: Why do you use SCONS ?

[Elliot Glaysher (Chromium)]

> Usually Open Source projects use CMake Construction Tool Kit.

Off the top of my head, KDE 4.x is the only project I know of that
uses CMake, (which is different from the old unix make).

>From your first email:
> Usually, Open Source projects use Make.

Very few open source projects use unix make exclusively because
Makefiles aren't sufficiently powerful to do much of anything. Without
massive, ugly hacks you can't get things like proper dependency
checking.

Most open source projects don't use make, but the full GNU
autotools/autoconf/m4/libtool/make toolchain which automatically
builds unix Makefiles from a set of simpler input scripts. Much has
been written about autotools's shortcomings, so I'll just say that
autotools is not a good solution, and for larger projects, it often
isn't adequate. (See KDE's transition first to SCons, and then to
CMake). Things get even worse when you throw windows support into the
mix.

There is a minority of projects which do use just unix make, but to be
portable, they need to distribute a Makefile for each
architecture/system combination, which is also not really acceptable.
For example, Sleepycat libdb ships with about 50 Makefiles. This is
not a solution that scales!

make isn't really a good solution which is why there's been an endless
procession of build systems to replace it and why each non-C language
seems to have its own build system trying to replace or supplement
make (OCaml has OMake, Haskell has hmake, perl has a module that spits
out complex Makefiles, python has its own build system for modules and
SCons, ruby has rake (among others), java has ant (among others), and
there's jam (and a bunch of jam derivatives) in the C++ space).

> Only www.scons.org has a comparison table .. but obviously it is'nt
> fair.

Really? I found both the feature list on the scons homepage and their
dedicated comparisson page (
http://scons.org/wiki/SconsVsOtherBuildTools ) to be pretty fair,
listing both the pros and the cons of each system.

-- Elliot

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why do you use SCONS ?

[giamas]

I wrote this page (http://code.google.com/p/chromium/wiki/
ChromiumSoftwareConstructionSystem)

Mybe my question is badly formed.

Usually Open Source projects use CMake Construction Tool Kit.
Chromium uses Scons. Why? What's the benefit?

I know that KDE 3.x has used SCONS, but KDE 4.x uses CMake.
So, why Chromium uses SCONS?

I didn't found any useful documentation on the web that compare Scons
and Make.
Only www.scons.org has a comparison table .. but obviously it is'nt
fair.

Thanks.
GM

On Jan 16, 6:54 pm, Marc-Antoine Ruel  wrote:
> http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSy...
>
> On Fri, Jan 16, 2009 at 12:28 PM, giamas  wrote:
>
> > I wonder about the usage of SCons.
> > Why do you decide to use SCons?
> > Usually, Open Source projects use Make.
> > Can anyone help me to understand.
> > GM
--~--~-~--~~~---~--~~
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: Qt now a possibility?

[robertknight]

> That's the situation between GTK and Qt these days.
> The OS underneath is the same, but running apps targeting one
> in an environment targeting the other in terms of user experience
> feels much like GTK apps feel on Windows.

It doesn't have to any more.  Qt 4.5 can use the current Gtk theme
and it will adjust the button order and other UI features to match the
current Gnome/GTK
settings.  I believe it can also use the native Gtk file dialog - if
not there are certainly
hooks that would permit it to be implemented.  Maybe not absolutely
perfect but
certainly nothing like Gtk on Windows.

Regards,
Robert.

On Jan 15, 7:04 pm, Evan Martin  wrote:
> On Thu, Jan 15, 2009 at 10:37 AM, cpu  wrote:
> > When Dean and Evan say that they don't mind reviewing patches for Qt
> > ports, what we are saying is that
> > we don't mind having two UI versions of Chromium on linux?
>
> > How would this work in the long term? UI tests times 2? you get to
> > choose what Chromium to install?
>
> I figured it would be unsupported.
>
> > If somebody asked me that they want to contribute a port of chrome on
> > Windows UI using MFC, I would say no. I just don't see the cost/
> > benefit.
>
> Here's an analogy.  Say I argued we should only target GTK because it
> runs on Windows just fine, so we'd be able to share UI test code
> between Windows and Mac.  You'd (hopefully) say it'd be terrible
> because it's non-native.
>
> That's the situation between GTK and Qt these days.  The OS underneath
> is the same, but running apps targeting one in an environment
> targeting the other in terms of user experience feels much like GTK
> apps feel on Windows.
>
> Unfortunately we don't have the resources to target both, but if
> someone else is willing to provide the patches I'm willing to review
> them.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why do you use SCONS ?

[Marc-Antoine Ruel]

http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem

On Fri, Jan 16, 2009 at 12:28 PM, giamas  wrote:
>
> I wonder about the usage of SCons.
> Why do you decide to use SCons?
> Usually, Open Source projects use Make.
> Can anyone help me to understand.
> GM
> >
>

--~--~-~--~~~---~--~~
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: Layout test and font stroking issue - help wanted

[Brett Wilson]

On Fri, Jan 16, 2009 at 9:32 AM, Sverrir Á. Berg  wrote:
> I'm running these tests:
> http://trac.webkit.org/export/39759/trunk/LayoutTests/fast/text/stroking-decorations.html
> http://trac.webkit.org/export/39759/trunk/LayoutTests/fast/text/stroking.html
> It seems that our font rendering path uses UniScribe/ScriptTextOut because
> of the accent (this means that the line containing the accented character is
> rendered incorrectly).  For other lines on the page we use paintSkiaText and
> that works fine (not using GDI because of the stroking).
> These tests run fine on webkit nightly because they end up
> using CGContextShowGlyphsWithAdvances which as far as I know not open
> source.
> Potential solutions:
> * Ignore.
> * Dynamically map è into è so we can use the skia rendering
> (along with other similar characters that are actually in use).
> * Implement complex rendering features on top of Uniscribe.
> Number two seems simple enough, number three scares me.

Number 3 is the right answer. You have to implement ScriptTextOut:
  http://msdn.microsoft.com/en-us/library/ms776504(VS.85).aspx
for Skia in the same way that skiaDrawText implements Windows'
DrawText funciton.

I don't think this function is that scary, but I'm not totally sure
about the details. You're given all of the glyphs and positions, so
hopefully it's not that hard. There might be some font fallback and
edge cases that won't work or will require extra code, but the initial
implementation should be reasonably straightforward.

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] Layout test and font stroking issue - help wanted

[Sverrir Á . Berg]

I'm running these tests:
http://trac.webkit.org/export/39759/trunk/LayoutTests/fast/text/stroking-decorations.html
http://trac.webkit.org/export/39759/trunk/LayoutTests/fast/text/stroking.html

It seems that our font rendering path uses UniScribe/ScriptTextOut because
of the accent (this means that the line containing the accented character is
rendered incorrectly).  For other lines on the page we use paintSkiaText and
that works fine (not using GDI because of the stroking).
These tests run fine on webkit nightly because they end up
using CGContextShowGlyphsWithAdvances which as far as I know not open
source.
Potential solutions:
* Ignore.
* Dynamically map è into è so we can use the skia rendering
(along with other similar characters that are actually in use).
* Implement complex rendering features on top of Uniscribe.

Number two seems simple enough, number three scares me.

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] Why do you use SCONS ?

[giamas]

I wonder about the usage of SCons.
Why do you decide to use SCons?
Usually, Open Source projects use Make.
Can anyone help me to understand.
GM
--~--~-~--~~~---~--~~
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: If you're feeling bored

[Dean McNamee]

On Fri, Jan 16, 2009 at 3:34 AM, Mohamed Mansour
 wrote:
> Hi,
> I would need some advice on how to do one static initializer when it is
> contained within the UI Thread. I want to try a simple example
> like: /src/chrome/browser/views/frame/browser_view.cc Can I get a
> confirmation whether what I am doing would be correct, and I have some
> questions that I am a bit confused (ok really confused, I don't want to
> submit a patch that I don't understand):
> This is one of the static initializers in browser_view.cc
>>
>> SkBitmap BrowserView::default_favicon_;
>
> And within the header file (browser_view.h) default_favicon_ is defined
> there as well:
>>
>> static SkBitmap* default_favicon_
>
> My first question, why is that done like that? Why do we have
> default_fav_icon_ defined in the class and header file? And why couldn't we
> just have it defined in the header file as this:
>>
>> SkBitmap* default_fav_icon_

This is how C++ works.  The problem is, you need to know where the
storage goes.  This pointer takes 4 bytes, and it needs to live
somewhere.  Which .o will it live in?  If it was only defined in the
header, there would be no way to really figure out where the storage
belongs.  This is how statics work (and I generally avoid class-level
statics unless really needed).  (There is an exception for static
integers and maybe other primitive types since their value can be
inlined, and needs no storage).

This is why it's also in the .cc, the one is the declaration, the
other is the definition.

>
> And if we want it as static to make it one instance, we could just add
> static at the beginning
> default_favicon_ is only initialized within the function InitClass (which is
> static) where it is being initialized like this:
>>
>> default_favicon_ = *rb.GetBitmapNamed();
>
>
> Since we wanted to ensure a singleton (unless I am mistaken), should we
> check if that variable is already initialized? From what I understand (mind
> you I am very new to c++, and am reading books that were recommended to me)

If it's singled threaded, who else would have initialized it?

>
> I would just delete the field declared in the class:
>>
>> void BrowserView::InitClass()
>
> And define it as a pointer in the header file:
>>
>> static SkBitmap* default_favicon_
>
> And within the init function I check if its valid and if it isn't I set it.
>>
>> if (default_favicon_)
>>   default_favicon_ = *rb.GetBitmapNamed();
>
> I have submitted two patches for remove static initializers but then deleted
> them because I "really" didn't understand what is going on. If anyone could
> shed some light, it would be highly appreciated! I am coming from a Java
> background if that would help.
>
> Thanks! And sorry for this long email.
>
>
> On Tue, Jan 13, 2009 at 12:50 PM, Dmitry Titov  wrote:
>>>
>>> They also contribute to launch time.  Generally speaking, the less
>>> code we have to execute during startup, the better it is for the user
>>> experience.
>>
>> This is especially important, because even though initialization is often
>> trivial, the page with the code for each initializer should be loaded from
>> disk into memory on startup. This paging often constitutes most of the app
>> startup time.
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: OSX 10.4 and PPC support?

[Mike Pinkerton]

The sandbox support isn't supported on 10.4. I know our linux brethren
are still debating sandboxing for their release, but I don't think
we'd want any Mac version to not have it.

On Thu, Jan 15, 2009 at 6:42 PM, Dean McNamee  wrote:
>
> On Fri, Jan 16, 2009 at 12:38 AM, Dan Kegel  wrote:
>>
>> On Thu, Jan 15, 2009 at 3:26 PM, Amanda Walker  wrote:
 Also, on a related note, are there also any plans for supporting the
 PPC architecture in the future?
>>>
>>> Not currently.  It would require, among other things, a PPC code
>>> generator for V8.  While this is not impossible, it's enough work that
>>> it's not part of our current plans.
>>
>> Wouldn't it be possible to fall back to the other
>> javascript engine on non-x86 platforms?
>
> No, not really.  Long story short, we have completely different binding 
> layers.
>
>>
>> >
>>
>
> >
>



-- 
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: stubbing out code

[Mike Pinkerton]

What I started doing over in the browser side is minimizing the ifdefs
with stub classes and functions. That way, the code is left mostly
unchanged and compiles as-is except you also have a record, in a
separate file called something like "temp_browser_scaffolding.h", that
lists every class that's been "mocked" this way. It's easy to see at a
glance what still needs filling in because it's still in that file.

The result has worked nicely, allowing browser_main() to compile with
only a small handful of idefs. This may not work with other files
bottom-up, it's clearly a top-down porting style.

On Thu, Jan 15, 2009 at 9:01 PM, Evan Martin  wrote:
>
> When you #ifdef around some code to make things temporarily link, but
> know that you'll need to bring that code (or its functional
> equivalent) back at some point, please mark those points carefully.  I
> fear that we'll eventually have everything building and linking
> together at some point and it'll crash and there will be 30,000 #ifdef
> OS_WIN where 20 of them were temporary hacks.
>
> Here's the pattern I use:
> #if defined(OS_WIN)
>  // code as before
> #else
>  // TODO(port): 
>  NOTIMPLEMENTED();  // so you get a run time error message rather
> than mystery crash
> #endif
>
> >
>



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