Re: [webkit-dev] Leak in UIWebView?
On Apr 20, 2010, at 3:35 PM, Thomas Hauk wrote: > I've posted this question to devforums.apple.com as well as to Stack Overflow > (go to > http://stackoverflow.com/questions/2557964/uiwebview-leak-can-someone-confirm > to see it) and have not gotten any answer, so now I'm reaching out to > webkit-dev for some help. > > I am developing an iPhone application that contains embedded HTML resources. > The following code leaks memory only on the device (at least 75% of the time) > when I try to create a NSURLRequest for an HTML file in the application > bundle. My base SDK is 3.1.2 (also tried with 3.1.3), and I'm running this on > a first-gen iPod Touch running 3.1.3. This does not leak in the Simulator. If > I comment out the call to loadRequest: all is well. > > NSString* resourcePath = [[NSBundle mainBundle] resourcePath]; > NSString* filePath = [[resourcePath stringByAppendingPathComponent:@"html"] > stringByAppendingPathComponent:@"dummy.html"]; > NSURL* url = [[NSURL alloc] initFileURLWithPath:filePath]; > NSURLRequest* request = [NSURLRequest requestWithURL:url]; // leak! > [browserView loadRequest:request]; > [url release]; > > I can reproduce this leak in a freshly-generated Window-based or > Navigation-based project, with essentially only the above code plus the > addition of a UIWebView object in the generated xib. The stack trace for the > leak seems to be entirely within the "Apple" side of things. The HTML file > can be as simple as a file with the word "test" in it (i.e. it doesn't need > to be valid HTML). > > What am I doing wrong? Not filing this at http://bugreporter.apple.com :) Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Leak in UIWebView?
I've posted this question to devforums.apple.com as well as to Stack Overflow (go to http://stackoverflow.com/questions/2557964/uiwebview-leak-can-someone-confirm to see it) and have not gotten any answer, so now I'm reaching out to webkit-dev for some help. I am developing an iPhone application that contains embedded HTML resources. The following code leaks memory only on the device (at least 75% of the time) when I try to create a NSURLRequest for an HTML file in the application bundle. My base SDK is 3.1.2 (also tried with 3.1.3), and I'm running this on a first-gen iPod Touch running 3.1.3. This does not leak in the Simulator. If I comment out the call to loadRequest: all is well. NSString* resourcePath = [[NSBundle mainBundle] resourcePath]; NSString* filePath = [[resourcePath stringByAppendingPathComponent:@"html"] stringByAppendingPathComponent:@"dummy.html"]; NSURL* url = [[NSURL alloc] initFileURLWithPath:filePath]; NSURLRequest* request = [NSURLRequest requestWithURL:url]; // leak! [browserView loadRequest:request]; [url release]; I can reproduce this leak in a freshly-generated Window-based or Navigation-based project, with essentially only the above code plus the addition of a UIWebView object in the generated xib. The stack trace for the leak seems to be entirely within the "Apple" side of things. The HTML file can be as simple as a file with the word "test" in it (i.e. it doesn't need to be valid HTML). What am I doing wrong? -- Thomas Hauk Shaggy Frog Software www.shaggyfrog.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volcano
Currently in 1195 Oak st but it closes at 5pm. Eric suggested Cafe Abir on 1300 Fulton st. I have to go tomorrow afternoon to Sunnyvale for a meeting but in the morning I should be in the Cafe Abir :) I'm open to any suggestion anyway! Currently staying in Haight st around #800, I'd prefer to stay around if possible. Philippe On Tue, 2010-04-20 at 14:37 -0700, Evan Martin wrote: > I am down for a post-gathering SF hackathon. Name a cafe and time. :) > > On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand wrote: > > Hi, > > > > I'm stuck in SF until sunday, unless I can find a flight earlier... > > Hacking from a café there on some GTK fullscreen video support :) > > > > Philippe > > > > On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote: > >> I should have asked sooner... > >> > >> Are any folks stuck here after the WebKit conference due to the volcano? > >> > >> If so, drop me a line. I'd like to at least offer lunch and possibly > >> some in-person hack-time. > >> > >> -eric > >> ___ > >> webkit-dev mailing list > >> webkit-dev@lists.webkit.org > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > > > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volcano
I am down for a post-gathering SF hackathon. Name a cafe and time. :) On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand wrote: > Hi, > > I'm stuck in SF until sunday, unless I can find a flight earlier... > Hacking from a café there on some GTK fullscreen video support :) > > Philippe > > On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote: >> I should have asked sooner... >> >> Are any folks stuck here after the WebKit conference due to the volcano? >> >> If so, drop me a line. I'd like to at least offer lunch and possibly >> some in-person hack-time. >> >> -eric >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Volcano
Hi, I'm stuck in SF until sunday, unless I can find a flight earlier... Hacking from a café there on some GTK fullscreen video support :) Philippe On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote: > I should have asked sooner... > > Are any folks stuck here after the WebKit conference due to the volcano? > > If so, drop me a line. I'd like to at least offer lunch and possibly > some in-person hack-time. > > -eric > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Experimental new code reviews
At the risk of inspiring friendly competition, I've turned Andrew's demo into a patch: https://bugs.webkit.org/show_bug.cgi?id=37886 Adam On Tue, Apr 20, 2010 at 12:24 PM, Andrew Scherkus wrote: > Here's the prototype I made during the hackathon that simply uses a bunch of > Javascript to make it easier to type up comments: > http://ascherkus.appspot.com/bugzilla/index.html > I'm not a WebKit reviewer, but from what I gathered during the session > there's a lot of copying and pasting involved. I focused on trying to fix > that particular issue. > Double click a line to add a comment. Code context + comment gets appended > into the patch comment box. It's purely visual -- nothing gets persisted. > Andrew > On Mon, Apr 19, 2010 at 4:20 PM, Ojan Vafai wrote: >> >> I don't know if it's up anywhere. The other group's approach adds more >> directly upon the current review system. I don't think we need to choose one >> vs. another (at least not in the short term). Not that you were suggesting >> that. >> Ojan >> >> On Mon, Apr 19, 2010 at 4:06 PM, Adam Barth wrote: >>> >>> +scherkus >>> >>> On Mon, Apr 19, 2010 at 4:01 PM, Maciej Stachowiak wrote: >>> > >>> > I heard another group coded up a different approach to improving >>> > reviews - >>> > does anyone have a URL for that, so we can compare? >>> > Cheers, >>> > Maciej >>> > >>> > On Apr 19, 2010, at 3:35 PM, Ojan Vafai wrote: >>> > >>> > At the hackathon last Tuesday, a few of us put together mashup style >>> > rietveld integration with bugs.webkit.org. It currently requires a >>> > chrome >>> > extension. We'll integrate properly with bugzilla based on feedback if >>> > this >>> > seems to be a value add for the project. >>> > >>> > http://webkit-rietveld.googlecode.com/svn/trunk/chrome-extension/webkit-cr.crx >>> > You can try it out on the *last* attachment >>> > on https://bugs.webkit.org/show_bug.cgi?id=37531. >>> > You'll see another link next to each attachment labelled "Fancy >>> > Review". >>> > This loads a page much like the current review page, but >>> > with wkrietveld.appspot.com in the top frame (wkrietveld is our fork of >>> > rietveld). You can then make comments in rietveld. When you click the >>> > submit >>> > button, the comments are published *both* in Reitveld and >>> > to bugs.webkit.org. >>> > We do not intend to remove the old code review system for people who >>> > prefer >>> > to stick to that. >>> > >>> > Known issues: >>> > -Currently, only works with patches that are uploaded using >>> > "webkit-patch >>> > upload --fancy-review". >>> > -Due to using a chrome extension rather than a tighter integration, >>> > some >>> > things are a bit janky (e.g. the initial load). >>> > -Each time a patch is uploaded, it currently creates a new rietveld >>> > issue. >>> > Ojan ___ >>> > webkit-dev mailing list >>> > webkit-dev@lists.webkit.org >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> > >>> > ___ >>> > webkit-dev mailing list >>> > webkit-dev@lists.webkit.org >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> > >> > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Volcano
I should have asked sooner... Are any folks stuck here after the WebKit conference due to the volcano? If so, drop me a line. I'd like to at least offer lunch and possibly some in-person hack-time. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
On Apr 20, 2010, at 12:45 PM, Jeremy Orlow wrote:
Agreed. Can you give us a pointer to the email thread this decision
was made on?
Discussion was on the IETF hybi list (which is trying to standardize
the WebSocket protocol). I encourage anyone in the WebKit community
who is interested in WebSocket to join the hybi list: https://www.ietf.org/mailman/listinfo/hybi
On Tue, Apr 20, 2010 at 12:12 PM, Alex Russell
wrote:
Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.
In the case of WebSocket protocol, the hash doesn't need to be
cryptographically secure. Forging the hash is not a consideration. To
give a rough outline, the hash is used like this:
1) The browser sends a few pieces of information to the server
(including the Origin, a string specifically identifying the WebSocket
protocol, etc).
2) The server combines some of this info and computes a hash.
3) The hash is returned to the client, which verifies it.
Steps 2 and 3 are the ones that use MD5. The reason for this handshake
is to defend against cross-protocol attacks. The server responds with
information based on unique parts of the request, to avoid the
likelihood that a response from a non-WebSocket server won't
accidentally look like a valid handshake. A hash is used to reduce the
risk that a server that just echoes back pieces of the response may
look like a valid handshake respnse.
I don't believe a cryptographically secure hash is needed here, it
could have been something as simple as CRC-32, for example. I think
the reason to pick MD5 was that it's well known and widely available
as a library for many popular programming languages.
Regards,
Maciej
On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman
wrote:
> In webcore, should we use the same impl on all platforms rather
than use
> cryptdll on windows and md5.cc elsewhere?
> For chrome, I don't think we can have a dependency between
> WebKit/WebKit/chromium and /src/base/, and 'base' depending on
'webkit' also
> doesn't work. How can we avoid replicating the code? I guess having
> webcore's MD5 be platform specific could help us along those lines?
>
> On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak
wrote:
>>
>> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>>
>> I'm implementing new protocol of WebSocket
>> ( http://www.whatwg.org/specs/web-socket-protocol/ ).
>> Since it now requires MD5 in handshake, I wonder how I could add
MD5 in
>> WebCore. For now, there is no MD5 in WebCore. It is in
>> WebKitTools/DumpRenderTree to get message digest of image file.
>> I'm thinking to add new header file as WebCore/platform/MD5.h,
which
>> provides the following functions.
>> struct MD5_CTX;
>> void MD5_Init(MD5_CTX*);
>> void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
>> void MD5_Final(unsigned char hash[16], MD5_CTX*);
>> In Windows platform, it is implemented using "Cryptdll.dll". Is
it ok to
>> copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/
win/MD5.cpp,
>> or move?
>> In Mac platform, it is provided by
with
>> #define COMMON_DIGEST_FOR_OPENSSL ?
>> In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy
this in
>> WebCore/platform/chromium, or add dependency to base from WebCore?
>> How about other ports? is it ok to link openssl or some other
library?
>> (or use implementation used in chromium?)
>> I'm also wonder I need to put these functions in namespace WebCore.
>>
>> If you put this code in WebCore, it should go in the WebCore
namespace. I
>> think it would also be a good idea to turn the API into something
more
>> WebCore-ish, something like:
>> namespace WebCore {
>> class MD5 {
>> MD5(); // what was MD5_Init
>> addBytes(uint8_t* input, size_t length); // what was
MD5_Update ;
>> or maybe this should take a Vector?
>> Vector checksum(); // what was MD5_Final
>> };
>> }
>> (The key point being to match the coding style guidelines for
names, but
>> it also seems better to use a class here instead of a struct and
functions
>> that take a pointer to it.)
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.or
Re: [webkit-dev] MD5 in WebCore
On Apr 20, 2010, at 11:48 AM, Michael Nordman wrote:
In webcore, should we use the same impl on all platforms rather than
use cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between WebKit/
WebKit/chromium and /src/base/, and 'base' depending on 'webkit'
also doesn't work. How can we avoid replicating the code? I guess
having webcore's MD5 be platform specific could help us along those
lines?
I'd rather use a platform-independent MD5 implementation in WebCore if
possible.
Since the MD5 code itself has (presumably) minimal dependencies,
perhaps we could put it in WTF. I don't know if that would help
Chromium's dependency issues.
Regards,
Maciej
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak
wrote:
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket ( http://www.whatwg.org/specs/web-socket-protocol/
).
Since it now requires MD5 in handshake, I wonder how I could add
MD5 in WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h,
which provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using "Cryptdll.dll". Is
it ok to copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/
platform/win/MD5.cpp, or move?
In Mac platform, it is provided by
with #define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy
this in WebCore/platform/chromium, or add dependency to base from
WebCore?
How about other ports? is it ok to link openssl or some other
library? (or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore
namespace. I think it would also be a good idea to turn the API into
something more WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was
MD5_Update ; or maybe this should take a Vector?
Vector checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names,
but it also seems better to use a class here instead of a struct and
functions that take a pointer to it.)
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
Agreed. Can you give us a pointer to the email thread this decision was
made on?
On Tue, Apr 20, 2010 at 12:12 PM, Alex Russell wrote:
> Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
> a secure hash? New protocols should be avoiding it.
>
> On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman
> wrote:
> > In webcore, should we use the same impl on all platforms rather than use
> > cryptdll on windows and md5.cc elsewhere?
> > For chrome, I don't think we can have a dependency between
> > WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit'
> also
> > doesn't work. How can we avoid replicating the code? I guess having
> > webcore's MD5 be platform specific could help us along those lines?
> >
> > On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak
> wrote:
> >>
> >> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
> >>
> >> I'm implementing new protocol of WebSocket
> >> ( http://www.whatwg.org/specs/web-socket-protocol/ ).
> >> Since it now requires MD5 in handshake, I wonder how I could add MD5 in
> >> WebCore. For now, there is no MD5 in WebCore. It is in
> >> WebKitTools/DumpRenderTree to get message digest of image file.
> >> I'm thinking to add new header file as WebCore/platform/MD5.h, which
> >> provides the following functions.
> >> struct MD5_CTX;
> >> void MD5_Init(MD5_CTX*);
> >> void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
> >> void MD5_Final(unsigned char hash[16], MD5_CTX*);
> >> In Windows platform, it is implemented using "Cryptdll.dll". Is it ok
> to
> >> copy WebKitTools/DumpRenderTree/win/MD5.cpp to
> WebCore/platform/win/MD5.cpp,
> >> or move?
> >> In Mac platform, it is provided by with
> >> #define COMMON_DIGEST_FOR_OPENSSL ?
> >> In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this
> in
> >> WebCore/platform/chromium, or add dependency to base from WebCore?
> >> How about other ports? is it ok to link openssl or some other library?
> >> (or use implementation used in chromium?)
> >> I'm also wonder I need to put these functions in namespace WebCore.
> >>
> >> If you put this code in WebCore, it should go in the WebCore namespace.
> I
> >> think it would also be a good idea to turn the API into something more
> >> WebCore-ish, something like:
> >> namespace WebCore {
> >> class MD5 {
> >> MD5(); // what was MD5_Init
> >> addBytes(uint8_t* input, size_t length); // what was MD5_Update
> ;
> >> or maybe this should take a Vector?
> >> Vector checksum(); // what was MD5_Final
> >> };
> >> }
> >> (The key point being to match the coding style guidelines for names, but
> >> it also seems better to use a class here instead of a struct and
> functions
> >> that take a pointer to it.)
> >> Regards,
> >> Maciej
> >>
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Warning: expect commit-queue delays
The commit-queue [1] is up to 28 patches (20 bugs) due to the tree being red most of yesterday and all of last night. It's green now and landing things, but it will take it most of today to catch up. Anything time-sensitive that you need landed should be landed manually. [2] Sorry for the delay. I'll let you know when we're back to normal. -eric 1. You can see the list of bugs here: https://bugs.webkit.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=commit-queue%2B&order=Last+Changed 2. webkit-patch can help with manual landing: webkit-patch land-from-bug BUGNUMBER (--build and --test optional) or webkit-patch land (--build and --test optional) if you already have it in your tree. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.
On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman wrote:
> In webcore, should we use the same impl on all platforms rather than use
> cryptdll on windows and md5.cc elsewhere?
> For chrome, I don't think we can have a dependency between
> WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
> doesn't work. How can we avoid replicating the code? I guess having
> webcore's MD5 be platform specific could help us along those lines?
>
> On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak wrote:
>>
>> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>>
>> I'm implementing new protocol of WebSocket
>> ( http://www.whatwg.org/specs/web-socket-protocol/ ).
>> Since it now requires MD5 in handshake, I wonder how I could add MD5 in
>> WebCore. For now, there is no MD5 in WebCore. It is in
>> WebKitTools/DumpRenderTree to get message digest of image file.
>> I'm thinking to add new header file as WebCore/platform/MD5.h, which
>> provides the following functions.
>> struct MD5_CTX;
>> void MD5_Init(MD5_CTX*);
>> void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
>> void MD5_Final(unsigned char hash[16], MD5_CTX*);
>> In Windows platform, it is implemented using "Cryptdll.dll". Is it ok to
>> copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
>> or move?
>> In Mac platform, it is provided by with
>> #define COMMON_DIGEST_FOR_OPENSSL ?
>> In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
>> WebCore/platform/chromium, or add dependency to base from WebCore?
>> How about other ports? is it ok to link openssl or some other library?
>> (or use implementation used in chromium?)
>> I'm also wonder I need to put these functions in namespace WebCore.
>>
>> If you put this code in WebCore, it should go in the WebCore namespace. I
>> think it would also be a good idea to turn the API into something more
>> WebCore-ish, something like:
>> namespace WebCore {
>> class MD5 {
>> MD5(); // what was MD5_Init
>> addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
>> or maybe this should take a Vector?
>> Vector checksum(); // what was MD5_Final
>> };
>> }
>> (The key point being to match the coding style guidelines for names, but
>> it also seems better to use a class here instead of a struct and functions
>> that take a pointer to it.)
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak wrote:
>
> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>
> I'm implementing new protocol of WebSocket (
> http://www.whatwg.org/specs/web-socket-protocol/ ).
> Since it now requires MD5 in handshake, I wonder how I could add MD5 in
> WebCore. For now, there is no MD5 in WebCore. It is in
> WebKitTools/DumpRenderTree to get message digest of image file.
>
> I'm thinking to add new header file as WebCore/platform/MD5.h, which
> provides the following functions.
>
> struct MD5_CTX;
> void MD5_Init(MD5_CTX*);
> void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
> void MD5_Final(unsigned char hash[16], MD5_CTX*);
>
> In Windows platform, it is implemented using "Cryptdll.dll". Is it ok to
> copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
> or move?
> In Mac platform, it is provided by with
> #define COMMON_DIGEST_FOR_OPENSSL ?
> In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
> WebCore/platform/chromium, or add dependency to base from WebCore?
> How about other ports? is it ok to link openssl or some other library?
> (or use implementation used in chromium?)
>
> I'm also wonder I need to put these functions in namespace WebCore.
>
>
> If you put this code in WebCore, it should go in the WebCore namespace. I
> think it would also be a good idea to turn the API into something more
> WebCore-ish, something like:
>
> namespace WebCore {
>
> class MD5 {
> MD5(); // what was MD5_Init
> addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
> or maybe this should take a Vector?
> Vector checksum(); // what was MD5_Final
> };
> }
>
> (The key point being to match the coding style guidelines for names, but it
> also seems better to use a class here instead of a struct and functions that
> take a pointer to it.)
>
> Regards,
> Maciej
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Tue, Apr 20, 2010 at 10:48 AM, Stephan Assmus wrote: > In the Haiku port, I've temporarily made some useful BitmapImage methods > public, to iterate over all images contained in the object and find the one > with the size I want (in the browser code later on). Is there a better way > to do this? How do other browser projects handle this? Would a patch to make > some BitmapImage methods public have good chances of being accepted or is > there another vision? In Chromium, we use ImageSource instead of BitmapImage for this, because ImageSource already has public functions for everything you want (e.g. frameCount(), frameSizeAtIndex(), etc.), and thus no changes are needed. When we have some data blob that represents the favicon and we need to pick a good image (size) out of it, we just instantiate an ImageSource directly. Take a look at WebImage::fromData() in http://trac.webkit.org/browser/trunk/WebKit/chromium/src/WebImageSkia.cpp . PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting wrote: > AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio > to correctly understand dependencies itself so that incremental builds from > inside the IDE (which is where most Windows Chromium developers do their > builds) work correctly and are as fast as possible (e.g. the null build > should take close to zero time and not have to rerun steps or relink > executables). I have an other big project running with CMake, but I didn't see such a problem. When you declare the correct dependencies CMake does a nerly perfect job IMHO. No "rebuild time" when nothing changed and no outdated objectfiles. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer wrote: > Bradley Nelson: > > 1. Ability to incrementally transition on Windows. It took us about 6 > > months to switch fully to gyp. Previous attempts to move to scons had > > taken a long time and failed, due to the requirement to transition while > > in flight. For a substantial period of time, we had a hybrid of checked > in > > vcproj and gyp generated > CMake should be treated like a separate buildsystem like qmake or gyp > during a > possible switch. > The point was that we wanted to be able to switch over in a gradual fashion, not by constructing a complete, functional parallel build system and then "throwing the switch". If you take a look in the current vcprojs you can't understand them more > easy > than compared to CMake IMHO. > Anyway: How often do you look at these settings? I use the IDE only for > writing code and debugging. I do all my buildsystem changes directly in the > CMake files. If i see the source files in the IDE I'm already happy. Do you > have other requirements? > AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
Hi, Darin Adler wrote: > On Apr 15, 2010, at 3:41 PM, Aaron Boodman wrote: > > On Thu, Apr 15, 2010 at 3:25 PM, Maciej Stachowiak > wrote: > >> Well, it's hard to truly have consensus on adding feature without > knowing what it is. That being said, I at least would love to see a more > specific proposal for what we could do with . > > > > I want to support bigger icons for the tabs in Chromium. > > > > I'm not sure what the path is for fetching favicons today. > > To load an icon you call retainIconForPageURL and then later call > iconForPageURL once the icon is loaded. The iconForPageURL function takes an > IntSize. > > But if you look at IconRecord.cpp you will see that at the moment the size > isn’t yet used. Indeed. The method can return a BitmapImage instance, which may contain several bitmaps of different size. In the Haiku port, I've temporarily made some useful BitmapImage methods public, to iterate over all images contained in the object and find the one with the size I want (in the browser code later on). Is there a better way to do this? How do other browser projects handle this? Would a patch to make some BitmapImage methods public have good chances of being accepted or is there another vision? Best regards, -Stephan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake vs. Apple's build farm
On Apr 20, 2010, at 10:06 AM, Bradley Nelson wrote: > Would prebuilt checked-in binaries be an option? No. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake vs. Apple's build farm
Would prebuilt checked-in binaries be an option? Can cmake run out of an arbitrary directory? -BradN On Tue, Apr 20, 2010 at 5:25 AM, Bill Hoffman wrote: > On 4/20/2010 5:13 AM, Maciej Stachowiak wrote: > > 1) None of the Mac builders have CMake installed. >> 2) The organization that maintains the Mac builders is not willing to >> let teams use any build systems to build that do not come with the OS, >> or to install any custom binaries on the builders, because builds need >> to be reproducible. >> > So, long term is there a way for CMake to come with the OS? I mean gmake > is part of the OS, python seems to be OK, how does a tool get promoted to > such a level? > > > 3) CMake is not part of the standard Mac OS X install for any shipping >> version of Mac OS X. >> 4) LLVM compiles using a separate Makefile-based (and apparently >> autoconf and autogen based) build system in OS builds. >> 5) LLVM uses CMake to build on Windows. >> 6) The build organization is more willing to install custom tools on >> Windows builders. >> >> I think this rules out using CMake to build the mac port. Even if we got >> it set up, we'd need to maintain some kind of parallel build system for >> production builds via the build farm, which would negate the benefit. It >> might be possible to use CMake for Apple's Windows port, but if we >> switch away from native project formats at all, ideally we'd like to >> switch both ports to the same build system. >> > I am wondering if you could include the sources to CMake inside the source > tree for the Mac build farms. CMake really only depends on the C++ > compiler, and that is part of the OS. You could use CMake's bootstrap > script to build it. Then run that CMake to generate the build. I could > help you create a lean CMake that would only build the features used for the > build of WebKit. > > >> Since gyp does not require any special software to be installed merely >> to build, it seems like a more plausible option at the moment. >> >> > Note: this is not to hate on CMake, I just don't want to end up in a >> position where we have to maintain two parallel build systems for the >> Mac port, or fight with other organizations about the operation of the >> build farm. Requiring CMake to be installed at build time seems like a >> showstopper from that point of view. >> >> So, rather than install one program, Apple would rather have one of its > developers maintain a forked build system. I would of course like to see > this change. I would think it would be possible to change this. I suppose > if enough tools that Apple uses move to CMake, it would become OK. Anyway, > what do think about building CMake with the project? > > -Bill > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview
I'd really like to see this on bugs.webkit.org with a proper patch splitting out the CMake portion. I understand that this is primarily motivated by your desire to see EFL port build, rather than to solve the build system problem, but this *DOES* add a new build system to the tree. I think we have to see if we can get the Apple showstopper cleared up. I think installing CMake sources and getting Bill's help to create a streamlined CMake binary is a great idea. Adam On Tuesday 20 April 2010 08:29:55 am Gustavo Sverzut Barbieri wrote: > On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer > > wrote: > > Hi, > > > > Gustavo Sverzut Barbieri: > >> Find attached 2 patches. > >> > >> ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that > >> implements CMake support for WebKit-EFL and also adds the missing > >> patches to make it compile (but runs with some bugs, needs updating to > >> some api changes). Apply it if you want to compile the port (also get > >> EFL from svn, see http://svn.enlightenment.org/) > >> > >> ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single > >> CMakeLists.txt and support *.cmake modules > >> > >> Please take a look if you are interested in CMake for WebKit-EFL. > >> > >> If you know CMake already, review it and send comments. My team just > >> started with CMake some days ago. > > > > Can you please post the patch at bugs.webkit.org. > > will do as soon as we get the ".pc" generated and installed, otherwise > the external programs cannot know how to link to it. > > > Maybe you can split it into a CMake and a "other stuff" part. (Was it > > already before you merged it?) > > It is already, the patch is at > http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch > > > I'd like to give you some feedback at the bug comments. The CMake file > > should be split into different projects for example. > > Hum... I saw everywhere that it was common to split in multiple > directories, particularly for JavaScriptCore and WebCore. But given > that I wanted to keep it simple, I forced it to be one single file to > make merge into SVN easier. I was also worried about the propagation > of settings and flags to the sub-folders. But yes, I notice that it > will make easier to use INCLUDE_DIRECTORIES() as we'd just have one > target per directory. > > Our primary goal is not to join into the recent GYP x CMAKE > discussion, but we need our EFL port fully landed to avoid the > overhead we're doing now. We were using the GTK autotools, as we were > more familiar with it, but given it is slow and messy, the GTK guys > did not want to merge our patches right away, requesting a cleanup of > existing code first. We did part of the cleanup and CMake in parallel, > but CMake worked out quite nice and we don't plan to use GTK's > autotools anymore (but we did send the cleanup we achieved until now). >That is to say that making it simple to be merged is our first aim. > > One more thing I'd like to kindly ask you is if you can also post > patches to the CMake files. This is because our team is already > suffering to match the latest WeKit changes (we have already a huge > queue waiting to be merged, and now patches have to be rebased and so > on). So the more help, the better! :-) > > BR, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview
On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer wrote: > Hi, > > Gustavo Sverzut Barbieri: >> Find attached 2 patches. >> >> ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that >> implements CMake support for WebKit-EFL and also adds the missing >> patches to make it compile (but runs with some bugs, needs updating to >> some api changes). Apply it if you want to compile the port (also get >> EFL from svn, see http://svn.enlightenment.org/) >> >> ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single >> CMakeLists.txt and support *.cmake modules >> >> Please take a look if you are interested in CMake for WebKit-EFL. >> >> If you know CMake already, review it and send comments. My team just >> started with CMake some days ago. > > Can you please post the patch at bugs.webkit.org. will do as soon as we get the ".pc" generated and installed, otherwise the external programs cannot know how to link to it. > Maybe you can split it into a CMake and a "other stuff" part. (Was it already > before you merged it?) It is already, the patch is at http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch > I'd like to give you some feedback at the bug comments. The CMake file should > be split into different projects for example. Hum... I saw everywhere that it was common to split in multiple directories, particularly for JavaScriptCore and WebCore. But given that I wanted to keep it simple, I forced it to be one single file to make merge into SVN easier. I was also worried about the propagation of settings and flags to the sub-folders. But yes, I notice that it will make easier to use INCLUDE_DIRECTORIES() as we'd just have one target per directory. Our primary goal is not to join into the recent GYP x CMAKE discussion, but we need our EFL port fully landed to avoid the overhead we're doing now. We were using the GTK autotools, as we were more familiar with it, but given it is slow and messy, the GTK guys did not want to merge our patches right away, requesting a cleanup of existing code first. We did part of the cleanup and CMake in parallel, but CMake worked out quite nice and we don't plan to use GTK's autotools anymore (but we did send the cleanup we achieved until now). That is to say that making it simple to be merged is our first aim. One more thing I'd like to kindly ask you is if you can also post patches to the CMake files. This is because our team is already suffering to match the latest WeKit changes (we have already a huge queue waiting to be merged, and now patches have to be rebased and so on). So the more help, the better! :-) BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake vs. Apple's build farm
On 4/20/2010 5:13 AM, Maciej Stachowiak wrote: 1) None of the Mac builders have CMake installed. 2) The organization that maintains the Mac builders is not willing to let teams use any build systems to build that do not come with the OS, or to install any custom binaries on the builders, because builds need to be reproducible. So, long term is there a way for CMake to come with the OS? I mean gmake is part of the OS, python seems to be OK, how does a tool get promoted to such a level? 3) CMake is not part of the standard Mac OS X install for any shipping version of Mac OS X. 4) LLVM compiles using a separate Makefile-based (and apparently autoconf and autogen based) build system in OS builds. 5) LLVM uses CMake to build on Windows. 6) The build organization is more willing to install custom tools on Windows builders. I think this rules out using CMake to build the mac port. Even if we got it set up, we'd need to maintain some kind of parallel build system for production builds via the build farm, which would negate the benefit. It might be possible to use CMake for Apple's Windows port, but if we switch away from native project formats at all, ideally we'd like to switch both ports to the same build system. I am wondering if you could include the sources to CMake inside the source tree for the Mac build farms. CMake really only depends on the C++ compiler, and that is part of the OS. You could use CMake's bootstrap script to build it. Then run that CMake to generate the build. I could help you create a lean CMake that would only build the features used for the build of WebKit. Since gyp does not require any special software to be installed merely to build, it seems like a more plausible option at the moment. Note: this is not to hate on CMake, I just don't want to end up in a position where we have to maintain two parallel build systems for the Mac port, or fight with other organizations about the operation of the build farm. Requiring CMake to be installed at build time seems like a showstopper from that point of view. So, rather than install one program, Apple would rather have one of its developers maintain a forked build system. I would of course like to see this change. I would think it would be possible to change this. I suppose if enough tools that Apple uses move to CMake, it would become OK. Anyway, what do think about building CMake with the project? -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket ( http://www.whatwg.org/specs/web-socket-protocol/
).
Since it now requires MD5 in handshake, I wonder how I could add MD5
in WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using "Cryptdll.dll". Is it
ok to copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/
platform/win/MD5.cpp, or move?
In Mac platform, it is provided by
with #define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy
this in WebCore/platform/chromium, or add dependency to base from
WebCore?
How about other ports? is it ok to link openssl or some other
library? (or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore
namespace. I think it would also be a good idea to turn the API into
something more WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was
MD5_Update ; or maybe this should take a Vector?
Vector checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names,
but it also seems better to use a class here instead of a struct and
functions that take a pointer to it.)
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MD5 in WebCore
I'm implementing new protocol of WebSocket (
http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using "Cryptdll.dll". Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library? (or
use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
Thanks in advance,
ukai
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where are bench-alloc-reatained.js and ~-nonretaned.js?
We investigating in multithreading possibilities. In connection with the GC I try to organize the mark phase into a parallel thread. The idea is to have 2 heap, serve allocations from the active one, while marking the other. When the active is full, swap them. Currently, it is in a non stable and non complete state, and it is not 100% that it will be ever complete. On 04/19/2010 11:08 PM, Geoffrey Garen wrote: > Hi Balazs. > > I just checked in those two tests to JavaScriptCore/tests/perf. > > What kind of GC hacking are you doing? > > Geoff > > On Apr 19, 2010, at 5:44 AM, Balazs Kelemen wrote: > > >> Hi folks! >> >> I am doing some hacking around the GC, and want to test and benchmark it. >> In GC related changes I see results of these two benchmarks, but I do >> not find them in the tree. >> Are those living in the tree? If not, I think it would be useful to >> check-in them. >> >> Balazs Kelemen >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where are bench-alloc-reatained.js and ~-nonretaned.js?
Thanks for the commit, Geoffrey! :-) On 04/19/2010 02:44 PM, Balazs Kelemen wrote: > Hi folks! > > I am doing some hacking around the GC, and want to test and benchmark it. > In GC related changes I see results of these two benchmarks, but I do > not find them in the tree. > Are those living in the tree? If not, I think it would be useful to > check-in them. > > Balazs Kelemen > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CMake vs. Apple's build farm
On Apr 16, 2010, at 7:39 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 7:17 PM, Bill Hoffman wrote: It is as native as we can make it. However, we do call cmake during the build at some points, to overcome shortfalls of the build tool. Also, to re-run cmake if any of the input files change. Also, basic system commands like cp can be done with cmake -E copy_file so it is portable. Calling cmake during the build would likely be a showstopper for the Mac port. As far as I know, Apple's build farm does not have CMake installed (at least not on older build trains). And it's not easy to convince the build engineers to install custom build tools. Here is what I have learned about this, and unfortunately it is bad news for CMake: 1) None of the Mac builders have CMake installed. 2) The organization that maintains the Mac builders is not willing to let teams use any build systems to build that do not come with the OS, or to install any custom binaries on the builders, because builds need to be reproducible. 3) CMake is not part of the standard Mac OS X install for any shipping version of Mac OS X. 4) LLVM compiles using a separate Makefile-based (and apparently autoconf and autogen based) build system in OS builds. 5) LLVM uses CMake to build on Windows. 6) The build organization is more willing to install custom tools on Windows builders. I think this rules out using CMake to build the mac port. Even if we got it set up, we'd need to maintain some kind of parallel build system for production builds via the build farm, which would negate the benefit. It might be possible to use CMake for Apple's Windows port, but if we switch away from native project formats at all, ideally we'd like to switch both ports to the same build system. Since gyp does not require any special software to be installed merely to build, it seems like a more plausible option at the moment. Note: this is not to hate on CMake, I just don't want to end up in a position where we have to maintain two parallel build systems for the Mac port, or fight with other organizations about the operation of the build farm. Requiring CMake to be installed at build time seems like a showstopper from that point of view. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Hi, Bradley Nelson: > 1. Ability to incrementally transition on Windows. It took us about 6 > months to switch fully to gyp. Previous attempts to move to scons had > taken a long time and failed, due to the requirement to transition while > in flight. For a substantial period of time, we had a hybrid of checked in > vcproj and gyp generated CMake should be treated like a separate buildsystem like qmake or gyp during a possible switch. > 2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly on > Windows, to generate vcprojs which resemble hand generated projects. It > doesn't generate any Makefile type projects, but instead produces msvs > Custom Build Steps and Custom Build Rules. CMake generates some pre/post-project building steps to the vcprojs (or an additional project), where it runs a CMake script. If you take a look in the current vcprojs you can't understand them more easy than compared to CMake IMHO. Anyway: How often do you look at these settings? I use the IDE only for writing code and debugging. I do all my buildsystem changes directly in the CMake files. If i see the source files in the IDE I'm already happy. Do you have other requirements? > 4. Strong notion of module public/private interface. Gyp allows targets to > publish a set of direct_dependent_settings, specifying things like > include_dirs, defines, platforms specific settings, etc. This means that > when module A depends on module B, it automatically acquires the right > build settings without module A being filled with assumptions/knowledge of > exactly how module B is built. Additionally, all of the transitive > dependencies of module B are pulled in. This avoids their being a single > top level view of the project, rather each gyp file expresses knowledge > about its immediate neighbors. This keep local knowledge local. CMake > effectively has a large shared global namespace. All dependencies are generated from CMake too (if declared correctly) and the "global namespace" isn't a real problem IMHO. > 5. Cross platform generation. CMake is not able to generate all project > files on all platforms. For example xcode projects cannot be generated from > windows (cmake uses mac specific libraries to do project generation). This > means that for instance generating a tarball containing pregenerated > projects for all platforms is hard with Cmake (requires distribution to > several machine types). Is there any demand for such a feature? Why you can't distribute the CMake file only? > 6. Gyp has rudimentary cross compile support. Currently we've added enough > functionality to gyp to support x86 -> arm cross compiles. Last I checked > this functionality wasn't present in cmake. (This occurred later). Supported since 2.6: http://www.cmake.org/Wiki/CMake_Cross_Compiling. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview
Hi, Gustavo Sverzut Barbieri: > Find attached 2 patches. > > ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that > implements CMake support for WebKit-EFL and also adds the missing > patches to make it compile (but runs with some bugs, needs updating to > some api changes). Apply it if you want to compile the port (also get > EFL from svn, see http://svn.enlightenment.org/) > > ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single > CMakeLists.txt and support *.cmake modules > > Please take a look if you are interested in CMake for WebKit-EFL. > > If you know CMake already, review it and send comments. My team just > started with CMake some days ago. Can you please post the patch at bugs.webkit.org. Maybe you can split it into a CMake and a "other stuff" part. (Was it already before you merged it?) I'd like to give you some feedback at the bug comments. The CMake file should be split into different projects for example. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Apr 19, 2010, at 11:58 PM, Aaron Boodman wrote: On Mon, Apr 19, 2010 at 5:53 PM, Peter Kasting wrote: On Thu, Apr 15, 2010 at 3:41 PM, Aaron Boodman wrote: I'm not sure what the path is for fetching favicons today. Does WebCore just implicitly do it, or does it expose the information to the host, who later may or may not make the request? Answering this is complicated by the fact that Chromium mostly uses a different codepath for all of this stuff than, say, Safari -- e.g. it bypasses the IconDatabase and pretty much all other classes/files called "IconXXX" entirely. Yeah, I looked into this over the weekend, and -- shock! -- it turned out to be a bigger change than I initially imagined. Since Chromium has a different backend, that would mean implementing two sets of changes. Also, I think it would be wasteful to have WebKit download all linked icons, even if the hosting browser has no intention of every using some of them. So I'd want to add code to allow the browser to tell WebKit which sizes it is interested in. I still want to do this, but I'm going to have to reduce the priority a little bit for now. I may come back to it in a month or so. You'd probably want an API that lets the embedding app request a particular icon size, and picks the best fit from the icon links available, taking into account size=any as well. Possible niceties - return windows-style .ico or mac-style .icns either if explicitly specified, or synthesized from available sizes. Not sure if there is a conventional multisize icon format on other platforms. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
