davidl wrote:
> 在 Wed, 03 Sep 2008 22:08:27 +0800，Alexander Panek <alexander.panek@brainsware.org> 写道:
> 
>> Denis Koroskin wrote:
>>> You already know that Google is making a buzz with their new Chrome browser.
>>> Go download and test it if you didn't do yet (www.google.com/chrome/, Windows only for now).
>>>  It is heavily multi-threaded and uses separate process for each window, each tab, each plugin etc. When one tab hags or a plugin crashes, nothing bad happens. The browser continues working as if nothing changes. It even has a built-in process manager, try opening youtube.com and killing a flash player plugin.
>>>  You can read the whole story at www.google.com/googlebooks/chrome/
>>>  This is an example of process-based designs implementation which is what D2 aims at, and it is clearly a success.
>>
>> It's funny, just a week ago or so Bartosz Milewski published a blog entry about how processes scale better than threads..
>>
>> I tried Chrome and I'm really impressed by how responsive it is. Also, the UI is kept very minimalistic, yet it doesn't lack any features. The website-application feature is also a very handy thing.
>>
>> Overall, I'd say Google Chrome is quite an impressive product. Would love having a D port. :P
> 
> Who will ever want to port a such big project? 437MB Source tarball(WTF, a browser bigger than OS source base)

I suppose you noticed the emoticon (":P") at the end of that sentence.


> Google goes the wrong way. It just extends the current web crap not reinvent something smarter.

Wrong or right, it doesn't extend anything. Google just happened to release a new, blazingly fast browser. I don't know in what way this can be attributed as "web crap" or similar. Do you have any better idea?

Alexander Panek wrote:
> davidl wrote:
>> 在 Wed, 03 Sep 2008 22:08:27 +0800，Alexander Panek <alexander.panek@brainsware.org> 写道:
>>> Overall, I'd say Google Chrome is quite an impressive product. Would love having a D port. :P
>>
>> Who will ever want to port a such big project? 437MB Source tarball(WTF, a browser bigger than OS source base)
> 
> I suppose you noticed the emoticon (":P") at the end of that sentence.

437MB?  I gotta go check that out (as in verify, not load my poor disk
with even more stuff).

>> Google goes the wrong way. It just extends the current web crap not reinvent something smarter.
> 
> Wrong or right, it doesn't extend anything. Google just happened to release a new, blazingly fast browser. I don't know in what way this can be attributed as "web crap" or similar. Do you have any better idea?

It's great for Google!  Now Mozilla can use the lessons learned from Chrome to make Firefox better!  Chrome is Google saying "we want a better browser.  So we made a proof of concept for you to both copy and improve upon."  I don't think Google is fixated upon webkit at all. They just wanted something quick and easy that they could pop into Chrome, which is mainly about the simplified interface, more survivable process-based design, and the much-faster JavaScript engine.

Because Chrome is Open-Source, I see no reason why the Mozilla team and the Chrome team cannot benefit from a little synergy as they learn from each other to build better browsers.  True, it's competition, but it's /Open-Source/ competition, the kind where everyone wins.

Chris R. Miller wrote:
> Alexander Panek wrote:
>> davidl wrote:
>>> 在 Wed, 03 Sep 2008 22:08:27 +0800，Alexander Panek <alexander.panek@brainsware.org> 写道:
>>>> Overall, I'd say Google Chrome is quite an impressive product. Would love having a D port. :P
>>> Who will ever want to port a such big project? 437MB Source tarball(WTF, a browser bigger than OS source base)
>> I suppose you noticed the emoticon (":P") at the end of that sentence.
> 
> 437MB?  I gotta go check that out (as in verify, not load my poor disk
> with even more stuff).

I ran, I checked, I became intrigued, so I downloaded and decompressed.

Firstly, it's 1.682 GB of raw sources.

Secondly, I ran an HDGraph scan of the tree to see where everything is.

199.16 MB of hunspell dictionaries
147.46 MB of Chrome test data
228.31 MB of Chrome tools test data marked as a "reference build"
147.87 MB of webkit layout test results data
= 722.8 MB of non-code data

Therefore 1.682 GB - 722.8 MB = 959.2 MB total of source code

The Chrome source itself, minus the data and tools data, etc. is only 57.75 MB of source code for the browser itself.  The rest is third party libraries, such as Cygwin libraries and what looks to be the better part of 77 MB of a Perl interpreter and attached libraries, 158 MB of "icu38" library sources, etc.  It's really no wonder it's such a large download, since all you need to build the browser is MSVC 2005 and the Windows SDK.  Otherwise you don't need to go download any of the other things yourself.  So on closer inspection is does seem like a more appropriate level of data for a browser.

Looking at a few of the source files individually, it does appear that much of the code is reasonable, and that most of the data is just tools for unit tests, etc.

Just thought I'd share.

Denis Koroskin wrote:

> You can read the whole story at www.google.com/googlebooks/chrome/

On page 16 they mention "precise GC".

-manfred

-- 
If life is going to exist in this Universe, then the one thing it cannot afford to have is a sense of proportion. (Douglas Adams)

Manfred_Nowak wrote:
> Denis Koroskin wrote:
> 
>> You can read the whole story at www.google.com/googlebooks/chrome/
> 
> On page 16 they mention "precise GC".
> 
> -manfred
> 

Are you suggesting we should start talking about how this could be done in D ?

-Tomas

"Denis Koroskin" wrote
> You can read the whole story at www.google.com/googlebooks/chrome/

Hey, this comic is really awesome for explaining things!  The author did a great job.  Any artists out there that can explain the D benefits this way? I think that might go a long way for newb's.

-Steve

Steven Schveighoffer wrote:
> Hey, this comic is really awesome for explaining things!  The author did a great job.  Any artists out there that can explain the D benefits this way? I think that might go a long way for newb's.

That's certainly true! Though, they should've kept it a tad shorter. It was kind of getting boring at some point.

On Thu, Sep 4, 2008 at 10:14 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> "Denis Koroskin" wrote
>> You can read the whole story at www.google.com/googlebooks/chrome/
>
> Hey, this comic is really awesome for explaining things!  The author did a great job.  Any artists out there that can explain the D benefits this way? I think that might go a long way for newb's.
>
> -Steve

I was reading that comic thinking man this guy *must* have really studied those "understanding comics" books because he's using all the techniques just like they're described in that book.

Turns out the comic was done by Scott McCloud, who *is* the Understanding Comics books guy.

So looks like all we have to do is pay Scott McCloud large sums of cash and he will make us a nice comic for D too!

--bb

Tomas Lindquist Olsen wrote:
> Manfred_Nowak wrote:
>> Denis Koroskin wrote:
>>
>>> You can read the whole story at www.google.com/googlebooks/chrome/
>>
>> On page 16 they mention "precise GC".
>>
>> -manfred
>>
> 
> Are you suggesting we should start talking about how this could be done in D ?
> 
> -Tomas

It would require compiler support.

It would require emitting pointer maps for each stack frame and each object.

It's relatively straightforward. If you align pointers on word boundaries, you only have to store one bit per word; else, one bit per byte; so this is not a terribly large overhead (no more than a couple bytes for a typical function, probably).

It wouldn't be terribly fast, but it probably wouldn't be an extreme slowdown either, most likely.

Tomas Lindquist Olsen wrote:
> Manfred_Nowak wrote:
>> Denis Koroskin wrote:
>>
>>> You can read the whole story at www.google.com/googlebooks/chrome/
>>
>> On page 16 they mention "precise GC".
>>
>> -manfred
>>
> 
> Are you suggesting we should start talking about how this could be done in D ?
> 
> -Tomas

A major benefit of a precise GC is that you can turn it into a moving GC. Without a precise GC, you might change some random sequences of bytes to something else because it looks like a pointer to something you moved; not so with a precise GC.